Iteration 2 – Testing Evaluation

The final version of the game can be found here

For testing, I wanted to take a more hands-off approach than in Iteration 1. This was because I wanted to see how a user would naturally respond to what was on-screen as this would provide useful feedback as to how intuitive the UI design was.

My testing objectives were:

  • To see if my UI could be figured out by the user without any input on my behalf.
  • To see how players prefer to play the game – more upgrades or more tentacles?
  • To see if viewing the tutorial made any difference on a player’s success at the game.
  • To find out what players thought the primary objective/theme of the game was.

From these objectives, I compiled a list of questions I wanted to ask my testers, as well as any quantitative data that I wished to track. These questions would give me my qualitative data:

  1. How were the controls to use?
  2. What was the aim of the game?
  3. How did you find the UI? Was it clear what everything did?
  4. Any other feedback?

I wanted to see how different player choices stacked up against how much health they had left at the end of the game. Players tended to have more health if they went for a mixture of upgrades and tentacles, whereas players that either forgot to upgrade or summon regularly tended to suffer. However, I do not think that the data shows one dominant strategy which is what I wanted: I didn’t want players to feel forced to always go for one path and I believe that I have given them good flexibility.

I asked players to rate the games fun and difficulty on a scale of 1 – 10. I did this to see if players who thought the game was more difficult also found the game less fun, or if they thought the game was too easy and therefore boring. However, after looking at my graph, I can see no correlation between a player’s fun and difficulty ratings for the game. I was pleased that the average fun rating was high and had little variation as it shows a strong enjoyment across the board. I found the changes in the difficulty interesting, as there was no clear trend, and I do not think the average accurately represents the data. There was high variation in the data, with a range of 1 – 7. I think this is a result of personal player preferences, rather than inconsistencies in how the game plays.

Generally speaking I got positive feedback on the controls, but a suggestion I was given was to explain the drag and drop mechanic during the tutorial, as Brad found that he would forget to drag the tentacles the first time. After that, no players would have issues with remembering how the mechanic worked.

Interestingly, there was some variation in how players responded when asked about the aim of the game. 5 people discussed protecting yourself/keep yourself alive whereas 4 responses were about killing all the enemies that come to attack you. While these are very similar, it was cool to see the different interpretations of the game’s aim.

When I asked the testers if the UI was clear, there was a split in the responses. 4 players said that they either needed the tutorial to understand, or that it made the UI significantly clearer, while the rest said that it was clear what the UI did without the prior explanation.

After asking my testers for any additional feedback, 3 people asked for more monsters that they could summon. This is a feature that I would like to add in the future, but I had decided that it was out of scope for this project. Another suggestion was that the tentacles could change in some way visually whenever you upgrade them, to give the player more feedback that the upgrade had made a difference. I really like this idea, and it would be a feature that I would add in the future. It is a common way of showing progression in other games within this genre and it would give the game more visual variety.

Iteration 2 Easter Reflective Journal

For the first two weeks of the Easter break, I took the time off to relax and refresh myself so that I could look at my game with a new perspective. This allowed me to identify some minor errors that I had left in the code, like incorrect frame numbers and icons being in a slightly odd position.

I admittedly did take a few shortcuts, on some features that I added, but I don’t feel that the overall quality of the game is reduced due to this. For example, instead of an interactive tutorial, I have used a diagram and for my pause button I use a click anywhere to resume the game rather than duplicating my existing button.

Now that I’m at the end of the Easter break, I feel satisfied that I have met all of the goals that I originally gave to myself at the start of the project. I definitely found that using a goals based system rather than assigning tasks to set dates gave me the flexibility that I needed – especially given my difficulties with getting any coding done during Week 2 of the project.

For testing, my target device is a Google Pixel. I chose this phone because it’s the one that I have and I feel that most games or websites are designed with other, more popular phones in mind such as the Samsung S8/9 or iPhone X. As I have added resize and scaling functionality, it would be nice if I could test on two devices but it’s more important that I get thorough data on how the game plays on the Pixel as it is my main target device.

Personally, I like to write my test data on paper, by hand, as it allows me to add any observations that I make or that the user makes but forgets to mention during the post-game feedback. The main parts of the game that I want to get feedback on are the UI due to the major changes to it, if the game works on the server correctly and how interactive the game feels to play. This means that I will mainly be using the UI and Deployment Testing methods.

Iteration 2 Week 2 Reflective Journal

This week, I definitely didn’t get as much done as I would have liked. Throughout the week, I was feeling unwell, and so it made it difficult to concentrate on the problems that I was having with my code. Therefore, I have decided to do additional work during the Easter break to ensure that my project is at a stage that I am happy with for testing. This allowed me to properly rest up, so I will be ready to get more work done in the coming weeks.

To make things easier when I carry on working on the project over Easter, I made sure to get some planning done for features that I want to add. In particular, I thought about properties of the tentacles that I can upgrade and the pros/cons of needing to implement each feature.

On a positive note, I really enjoyed the additional changes that I made to the UI. When I spoke to Aaron last week, he said that it wasn’t clear enough which button summoned tentacles. To fix this, I made the button into a summoning circle that lights up red when the player presses it. I am happy with the way that this makes the button stand out more while still fitting with the theme of blood magic.

I haven’t completed any of my goals this week, but I do feel as though the work that I did do has set me up to finish up during the Easter break without any time pressure.

Iteration 2 Week 1 Reflective Journal

Due to needing to change physics engines, there was a lot of code re-writing that I had to do, meaning that I spent less time adding new features than I would have liked. However, this did mean that I could tidy up my code such as removing defunct animations and change some of my classes to extend Phaser classes such as my MonsterBaseClass now extending sprite. On the bright side, Arcade physics is much better documented and I find it easier to use than Matter which will make adding new features easier going forward.

When creating a group for the tentacles, I initially struggled with it as I hadn’t used groups since we were first introduced to them. Once I got it to work, it was especially satisfying and acted as a good reminder of a very useful feature of Phaser 3. This enabled me to have the confidence to use groups for other parts of the game, such as the attack areas for the tentacles and the enemies.

I am really pleased with the way that I have changed the UI to be simplier and easier to understand. I especially found discussing the changes that I had made with Aaron to be helpful, as he gave useful criticisms of how I could improve upon it further. When I look back on how the UI was in Iteration 1, I can already feel the improvements when testing and having to completely re-work my code made it much easier to change how the game looked than if I had to edit my existing code around.

Out of my original objectives for Iteration 2, this week I have completed:

  • Fix the collision bug,
  • Add in grid snapping for monster placement,
  • Waves of attack to add variety to levels.

I have also started working on:

  • Updating and streamlining the UI
  • Create better icons to communicate what things represent on the screen to the player in a more effective way.

Next week, my main aim is to add in the pause/play button, make the monsters upgradable and to finish up the UI changes.

Iteration 1 – Testing Evaluation

The final version of Iteration 1 is available here

For my testing process, I wanted to test how the game felt to play, to see if the buttons were of a good size on screen. As someone with smaller hands, I was unsure if the buttons were a suitable size for larger hands, or if they were too small.  It was important to see if the tester had previous experience with tower defense games, as it may affect how they score the game in the quantitative data section. Finally, I wanted to see what a player would be looking for in a tower defense game, and to give them a space for any further comments that they wanted to make.

To collect my qualitative data, I created a series of questions for my tester to answer at the end of their time with the game. These questions were:

A) Were the controls easy to use and well-scaled to the screen size?

B) Was the objective of the game clear?

C) Do you play any tower defense games? If so, are they on mobile?

D) What features would you like to see in the future?

Here are the responses I got from my testers:

Akira

A) The controls are easy to use, if occasionally a little fiddly.
B) Yes
C) No
D) Extra blood generators that you can summon, to make summoning more troops faster.

Marc

A) Well scaled to the screen, and the controls are easy to use.
B) Yes, the aim of the game is simple to understand.
C) No
D) Sprites for the enemies as they are currently missing them, plus, a proper tileset for your tilemap. More assets in general.

Zoe

A) The controls were easy to understand and use.
B) The objective of the game was sort of clear, but I might not have got it without a small explanation,
C) No, tower defense games are not my thing.
D) Some form of tutorial or instructions on how to play and make it clearer that blood is your form of currency, I didn’t notice it straight away.

Becky

A) Yes, especially for me since I have small hands.
B) The aim was to kill the wave of enemies, it was clear.
C) No, I don’t play any.
D) More monsters for the player to summon to defend themselves with.

Reace

A) Yes and the controls were responsive.
B) The goal was to stop the enemies from getting to your altar and to get more blood to summon more monsters with.
C) I’ve played tower defense games before and I’ve played the mobile game Balloons, so I have some experience with this type of game.
D) Being able to upgrade your troops, and have more monster options for the player to summon. Also, make the game a little easier.

Chloe

A) Yes, the controls are also very well suited to a mobile phone screen.
B) Yes
C) I used to play some tower defense games, but not on mobile.
D) It’d be good if there were more ways to defeat the enemies attacking you, and if it was easier to get blood to summon troops with.

After the player had completed their attempt at the game, I recorded my quantitative data. I wanted to track how much blood (currency) the player had, how much health, if they beat the game, how many tentacles they summoned and I asked them how difficult they would rate the game.

Due to an unfortunate bug in the code, some tester’s games crashed on them, leaving them without the opportunity to win. Plus, I made the game too difficult by giving the enemies too much health. When I was testing myself previously, I had made the game too easy, so I decided to make it harder to see how the testers would respond. Evidently, I had overcompensated for how easy the game was and made it too difficult. In Iteration 2 I will spend more time on getting the balance of enemies and player monsters correct.

Before the game begins, the player only has enough blood to summon 2 tentacles. If a player summoned 3, that means they figured out how to gain blood quicker and spend it on the fly. 5/6 players were successful in summoning an extra tentacle, demonstrating that it was clear that you could continue to summon troops, even after the game has begun.

Before the tester started playing, I briefly explained the basic mechanic of the game, and told them that it was a tower defense game. For Iteration 2, I would like to be more hands off with my testing, to better replicate how it would be if the game was released. This way I can test how intuitive my controls are, and how easy the game is to pick up.

Iteration 1 – Week 2 Reflective Journal

This week, I needed to catch up on some tasks missed from the previous week and ensure that my game was ready for testing next week. I am pleased with how the prototype has turned out as it has the majority of the features that I put into my Minimum Viable Product. The main features that I missed were a wave of attack system and being able to upgrade your monsters however, the game is playable without these at the moment. I want to add these during iteration 2, as they will provide an extra level of depth to the game and make it interesting to play more than once.

Over the past two weeks, I wish I had been able to create more art assets for the game. I am most disappointed that I didn’t get around to creating a spritesheet for the enemies, as this means that for testing I will have the Phaser placeholder image so I will need to let my testers know that they are the enemies. Generally speaking, I tend to have days where I cannot concentrate or get any work done, followed by days where I can do two to three days worth of tasks. This means that my production diary looks a little odd, as I skip some days entirely as I just didn’t have the motivation to work on those days. Personally, I would rather I spent those days resting, so that I could attack my productive days better, rather than sit staring at the screen in counter-productive frustration.

My major achievement for this week was my collision detection system. Admittedly, it does break when a new object is added during the same frame a collision happens but in the majority of cases it functions as expected; I put a lot of work into figuring out how to identify which objects were colliding, but now that I have a basic functional system I can push it further in iteration 2 to remove the crash. I also wish to make the system more efficient than looping through all of the enemies and the monsters that the player has summoned.

Iteration 1 – Week 1 Reflective Journal

At the beginning of the project, instead of spreading all my tasks over the course of two weeks, I initially planned for only one week of development time by mistake. This meant that even if I got a significant chunk of work done on a particular day, I was technically behind on my planning. To rectify this, at the beginning of next week I am going to re-organise when I want each task completed to spread out the remainder of my work. My issues with planning were made worse by the fact that I had to take nearly two whole days off from development time, as I fell ill with a nasty cold. Consequently, I spent the rest of the week trying to catch up with what I had missed on those days and my planning from last week was pretty much ignored from that point on.

Despite my illness and problems with improper planning, I still managed to achieve a good chunk of what I had set myself to do. I completed approximately half the tasks that I had assigned, which makes sense as I had given myself two weeks of tasks to do in a single week by mistake. The main tasks that I am behind on are write-up and allowing the game to start however, I have lain the foundation to begin on these parts in earnest next week.

Overall, this week was rather rocky, particularly due to the loss of development time and incorrect planning. I am please with how far into the project I am, but I would prefer to be ahead of schedule, rather than on the edge of being behind.

Tank Game – Reflection

When I initially got the brief to extend or edit the tank game, my mind utterly blanked. To generate ideas, I decided to sit down and create a list of different properties of tanks, and what you might find associated with tanks. This is how I got my first idea for expansion of having a super attack. Different tanks have differing equipment, including better missiles.

Rather than have the player be significantly stronger than all the enemy tanks (or vice versa) I decided to equip the player with a secondary shot type. I believed this was a good feature to add as often the player would die from simply having a lower rate of fire compared to the enemy tanks through a sheer difference of numbers. However, I still wanted the game to have some difficulty to it, otherwise it could become boring to play.

While thinking on elements that go with tanks, land mines came to mind. These wouldn’t utterly destroy all tanks, so I gave them the same amount of damage power as a standard bullet. I didn’t want them to damage the player, as I was still having balance issues between the player and the enemies, despite giving the player additional firepower. However, if I wanted to take a more realistic approach, a landmine wouldn’t be able to tell the difference between friends and foes, so I would have to make the player also take damage from them.

I did struggle with extending the tank game, as they aren’t a game style that I would personally play. I feel like this exercise was good for taking me outside of my comfort game of making games that I would want to play, and putting myself in the shoes of what other people may want or expect from a particular genre of game.

Reflection on Phaser

In the past, I have never worked with someone else’s library of code or game engine; everything that I have coded was my code only, therefore I was intrigued to be using a game engine for the very first time. Phaser 3 is the latest edition of the Phaser game engine, which gives you tools to create games in 2D using JavaScript. It has 4 key functions, that form the basis of your games: config, preload, create and update.

 

When creating a game completely from scratch, you must code everything yourself, allowing you to optimise code for your game. The drawback is that you must code potentially complicated maths functions to have basic physics and collisions. By using Phaser 3, I saved a lot of time that would have been spent creating collision and physics maths, as I could instead simply turn gravity on/off and use simple lines of code to cause objects to collide. While I did save a lot of time and lines of code, the collisions were simplified in places. Sloped tiles did not register as so, leaving them working like stairs despite being smooth.

On the whole, I found using Phaser 3’s built in arcade physics a faster solution than how I had been doing collision for past projects. I would like to explore Phaser’s other physics systems in the future, to compare their limitations and to expand my knowledge of Phaser’s capabilities.

 

During the development of my game, I had some friends who wanted to give the game a go on their mobile devices. Since I was using a game engine, I presumed it would be simpler to put in than coding by hand, as we did in the snake game. Personally, I had the opposite experience to what I was expecting; I could not understand how to implement the controls that I wanted, as the examples and API docs were not clear on the subject. I didn’t have the opportunity to follow through on this feature, and I wish I had simply used the same coding method as the snake game, rather than attempting to use Phaser’s.

 

When I am programming, my favourite part is debugging broken code to make it work. I enjoy how methodical tracing back through you code can be, despite my frustrations from the program not working. In particular, I can have a laser focus on the bug until it is fixed, and I can often resolve the issue in a single sitting. While using Phaser, my love of debugging was somewhat challenged. The tracebacks were significantly longer, as they often went through the Phaser engine’s code, and error messages were generally less helpful, as they would occasionally only give line numbers in the engine, or were about inaccessible properties/parameters with different names that you had given them. Resolving errors would often involve referring to the API docs, which are sometimes frustrating to navigate if you type in the wrong keywords to the search bar.

 

In conclusion, I am looking forward to working with Phaser more, despite my frustrations with parts of how it works. Several of my complaints – such as slopes not sloping and debugging – will be resolved by exploring more of Phaser and getting to grips further with searching the API docs. I still enjoy coding from scratch, as I feel as though I learn more about the core components of how to make the game work, but using an engine can be far simpler, and often quicker to implement complex features.

Reflection on Analyse This

For my analysis using The 100 Principles of Game Design I wrote about the game Rogue Legacy – a rogue-like game that involves dying over and over to make incremental progress in defeating an ever-changing dungeon.

For the principles I wanted to look at in Rogue Legacy, I chose to discuss the use of a core gameplay loop and imperfect information. I chose core gameplay loop as a principle, since Rogue Legacy operates on the basis of entering a castle, exploring, dying, and continuing on as one of your three children. Some of these children have negative traits, such as near/far-sightedness or dementia, resulting in an imperfect view of your surroundings.

It was interesting to write about the core gameplay loop in Rogue Legacy, as some games with a cyclical format can become repetitive, whereas Rogue Legacy stays fresh even after playing for over an hour. The two principles work in harmony here, where the use of imperfect information keeps each cycle interesting, as you sometimes have to pick the least bad traits available, giving your attempt at the castle different challenges each time.

These principles are relevant to me as I love rogue-like games and would like to make one in the future. Furthermore, many games in this genre use these two principles so it was key to understand how they were implemented in one of the best examples of the genre.

When following The 13 Basic Principles of Gameplay Design, I wrote about They Are Billions, a zombie real-time strategy game with a steampunk apocalypse setting. I decided to use Matt Allmer’s principles as they covered all aspects of They Are Billions and how its different components work.

The most important principles for me when writing about They Are Billions were sound, anticipation and communication. These are cleverly weaved together in the design of the game, with sound acting as the unifying factor. Sound design is particularly important to me as a player, since I have been a part of two national music organisations, so I’m often keeping an ear out for interesting use of music and sound effects in games.

Anticipation is core to They Are Billions, as from the very start of the game you are anticipating a giant wave of zombies coming to attack at the end of a set period of time. This is built upon through the use of music, from the Final Wave (Build Up) theme using frantic violins to the brass section blasting out through the speakers whenever there is a wave of zombies approaching.

Finally, They Are Billions would be a far worse game without the clever way that it uses communication. In games where many things can be happening at once, ensuring the player never misses a beat is crucial, otherwise the game could feel unfair, and punishing the player for trying to complete more than one task at any given time.

These two games are very different from one another, except for one common factor of crushing difficulty. I found it interesting to analyse two games from two distinct genres, and in doing so I learnt more about how each game worked, such as the strategy game nestled inside of Rogue Legacy, and the rogue-like features of They Are Billions where if your command centre is destroyed, you have to start over again when no two maps are the same.

References

Despain, W. et al. (2012) 100 Principles of Game Design. San Francisco: New Riders. [book]

Allmer, M. (2009) The 13 Basic Principles of Gameplay Design. [website]

https://www.gamasutra.com/view/feature/132341/the_13_basic_principles_of_.php [accessed
14/11/18]