#asteroids postmortem

I am happy with what I was able to complete for this game, however, as I also stated in the development post, I had too many ideas for this game, and the scope of the project was way out of reach. However, here is a screenshot of the final game, "Space Labyrinth"

Instructions:

Avoid the red balls that will kill the player if in collision

Collect the yellow balls to unlock the green goal at the end, (Shows in this case just for demonstration)

Complete the maze and go through the goal to reach the next level

The deaths will count up as the player dies

Each level becomes more and more difficult

Controls:

WASD to move around

Use the mouse to look around and aim

Left click to shoot

Overall, I am extremely happy with what I have created, and I look forward to what I might create in the next game.

However, continuing my review of this project, I would have liked to include the ideas I had mentioned in the development post, however, time was not in my favour, and this is where I ended up. I think more enemies and upgrades definitely add to the thrill of the game, as the player must come up with new strategies and combine mechanics to defeat them.

I thought about creating a tutorial for the game that would help the player learn what they are trying to do, however, I remembered that one of my PX goals was to make the player frustrated, so I thought that going into the game as a complete novice would add to that goal, and it certainly did. During a playtest, one of my players, asked "Was this game meant to annoy me? Because it's certainly working". With this in mind I considered my game complete.

By Shannon Tetley

I'm finished with my asteroids game for now and I think it turned out pretty good. I put it together by following the tutorial I was given which taught me some new concepts and left me with a skeleton to work on. I expanded on it by adding random movement to the asteroids and by adding variables to them that determine there average speed and other traits like how much damage they do to the player. I think the biggest influence the textbook Game Design Workshop had on my design process was that it suggests that interesting choices are what make a good game and that players need to be challenged or those choices are meaningless (Fullerton). I tried to implement this idea by making the asteroids move at a random speed that is faster on average based on the asteroid size. I also added randomness by making the asteroids bounce off of the boundaries of the screen which also makes the game harder by concentrating the location of asteroids around the player.

Another concept that I leaned form T.Fulleton, was that play testing should be core to the design process (Fullerton). Knowing this I have been a lot more formal about how I've done play testing this time. I've used a template that was provided to me by the uni to create a questionnaire that players fill out after trying the game. I added to this template by including questions more relevant to my game that I though would elicit helpful feedback. My readings have taught me that I shouldn't be making games that are fun for me, I should make them fun for the audience. Playtesting is how I measure how fun the game is for my audience and is used to inform future iterations of the project. This testing has been very encouraging for me as players have a tendency to keep playing the game despite dying or achieving the main objective of the game.

Player Feedback

Some interesting insights where discovered through my play testing. I find it intriguing that despite having different issues with the game, the issues had some overlapping themes.

Generally speaking they said that:

The game was challenging and rewarding to defeat.

Some said that the asteroids where too fast.

The ones that could handle the speed didn't like the turning speed of the ship.

I suggested upgrades for the player ship which everyone agreed would be a good idea. Some testers even came up with this idea unprompted.

Some players died before realising they were losing hit points, others didn't notice they were dying till it was too late. Everyone agrees that it needs to be more obvious when your are taking hits.

My conclusions from this are that the game has some balance issues, some issues with the controls and issues getting feedback when events happen. I agree with them about the feedback when you lose hit points, its not obvious and it happens quickly. For the general game balance I think there are many options to fix this. I think simply changing the asteroid speed and frequency would alienate the less confident players. I could also fix the ship turning speed but being slow is a challenge in itself. Instead of addressing these issues individually I think the best option, as the players mentioned themselves, is to add an upgrade system to the game.

How would I change the game?

I would implement an upgrade system to the game by adding a store. I think that allowing the player to have a breather would help them out. Pausing the game to allow them to access a upgrades store would help in many ways. Simply pausing the game would allow them to rest and cope with what is happening. The can then make interesting decisions by buying upgrades that can help them deal with the challenges of the game. Is the ship turning too slow? Upgrade the turning speed. Are the asteroids too fast or numerous? Buy a slow down time machine, or buy a better gun to thin out the horde.

If I continue this project I would also add more feedback in general. Feedback for destroying asteroids to reward their success and feedback to warn them they are taking hits. Also I would add a title screen to invite them to play and improve the death scene I added.

A lot was learnt on this project particularly after playtesting. Now I know the basics of creating new scenes I'm going to start with the title screen for my next project as I think and introduction to a game can be quite important. Providing feedback to the player adds to their experience and ease of use for the game, I'll be sure to concentrate on including this for the next project.

References:

Inspiration from Readings

The readings invited me to rethink my perspective on games as dynamic systems, and helped broaden my understanding of what is meant by the “predictability of outcomes”. Each of the elements in my game has attributes and behaviours; the elements interact with each other accordingly and these relationships make the system dynamic and contribute to the game’s complexity (Fullerton, 2018).

I had never perceived the predictability of games in this context before, at least not as an informed game designer. I know that increasing factors and elements can increase the outcomes and thus affect the predictability of the outcomes but actually exploring that as a game designer was completely different to just experiencing it as a gamer. This outlook really helped inspire my design for the behaviors of bubble entities as well as the IHW abstract “boss” which was derived from pondering what would happen if all the bubbles popped. Can I more strongly engage my players with this high-pressure game mode? The answer was yes, I can.

Changes to Prototype Development

I’m quite happy with how I developed the prototype. I think I could have done things more elegantly in GDevelop but for a design and playtesting centric unit, I’m not unpleased with the technical implementation processes. In that respect, there are 2 things that I would’ve done differently while developing RDH.

Less time making art. This was very helpful for assessment 3 as all the base assets had been drawn (and were also required for assessment 2 anyway) but it wasn’t the most pragmatic development approach. In the early stages, the most critical facet of the prototype’s function would be its ability to keep the player active and facilitate the player experience. The aesthetic appeal of the game should not have been a forethought.

Less time (attempting) paper prototyping. I tried using an assortment of sticky notes as arbitrary representations of game entities but honestly the entire process was quite futile and a little bit redundant. RDH was supposed to be a fast-paced and movement-based experience—attempting to replicate this manually with physical pieces was not very effective. In retrospect, I should have done digital prototyping, even If it would be crude due to my limited GDevelop skills.

Also, maybe this is just an inconsequential thought born from retrospect and hindsight, but I wonder if I lowballed myself with the implementation goals. If that was the case, I would’ve aimed higher for a more complete prototype. At the very least it would’ve been nice to implement even simple powerups like a speed boost or a shield. The former would just require me to add a game object that temporarily increases the player’s speed upon collision and the latter would need some kind of shield sprite that covers the player (or to replace the player sprite for the shield duration) and either prevents player-shark collisions or nullifies the damage effect from the collision.

Changes to Design

Most of the design changes would be informed by playtesting observations/results. As such, my ideal iterations would surround the interesting strategies/tactics deployed by players. I wondered how can I invite players to take certain actions, how can I motivate them to use strategies rather than play aimlessly? For this, I am inspired by Fullerton’s (2018) discussion of the utility and scarcity of resources—powerups, in particular. I think adding powerups such as a temporary shark shield might entice players to take more risks under the shield’s protection and thus, the behaviour of this new game entity (speed powerup) contributes to the unpredictability of the game (Fullerton, 2018) and can impact the strategies employed by players.

Also, I would like to add more obstacles or enemies. Obstacles are a game structure that can introduce conflict to a game (Fullerton, 2018). I’ve utilised them in RDH; however, I’d like to design obstacles that aren’t dependent on the bubbles. For example, I’d avoid having the bubbles automatically pop after a set duration of time in regular mode as I suspect it would lessen the impact of IHW (when all the bubbles pop). That may reduce the stress induced by IHW, potentially lessening player engagement which is influenced by a game’s ability to emotionally move players (Fullerton, 2018). Instead, maybe something like a pirate ship or tsunami wave could occasionally appear as an environment hazard. Pirates might deduct 20% of your accumulated RP upon collision, tsunami waves might do the opposite of IHW and just sweep all the bubbles away so the player is forced to wait for new bubbles to spawn, etc. The additional obstacles/enemies would just have to complicate the player’s otherwise easy method of rescuing ducks.

Overall, I’m quite happy with how RDH turned out. I look forward to presenting it as my pitch for assessment 2 and hopefully that will be enough for it to be selected by my group for assessment 3.

Thanks for reading!

References

Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Forth Edition (4th ed.). CRC Press LLC.