Addictive new game called Orbit!

 click me!

How to play

1. To play on Android, copy the Orbit apk to your Android phones internal storage. Once you have done this, install the apk on your phone using the file manager. Press the ‘PLAY’ button when you want to play. Press the ‘STORY’ button for a narrative of the game.

2. Once started, press and hold to speed up the player to knock away the asteroids and defend planet Earth. The longer you do this, the higher your score will be. Press the on screen buttons to restart or exit, or press R to restart and esc to exit.

Below is the report I made for my final exam game (called Orbit) for my university course Game Design 3A at the University of the Witwatersrand. It is an Android game that can be downloaded here, clicking on the image above or visiting the itch.io page. I hope you enjoy!

Abstract

The purpose of this report is to shed light on the production of the exam iteration of the Orbit game for submission to WSOA3003A. The basic design of this project, after choosing Orbit from the three prototypes this student made, was to take feedback from Iteration 1 and 2 and discover what features and effects players would like to see if this game was taken further. The major findings of this process and the product of this iterative step was a much more player-friendly, engaging and replayable gaming experience. This student has concluded from this that it is always important to get consistent feedback from many different types of players to create a meaningful and fleshed-out gaming experience.

Introduction

In the Exam Iteration, this student was developing a simple prototype game into a complete gaming experience to be played on Android. It was important to get feedback from players to discover what they wanted to be able to do and experience in the game. It was found that players wanted consistent experiences with the User Interface and to have no glitches or weird occurrences while playing the game. This is what this student focused on with this iteration along with adding a new mechanic, adding a narrative element and cementing the art style and game juice.

Aim

The aim of this Iteration was to complete the prototype developed earlier this semester to become a finished game. This would be done by asking players what they would like to see in a finished version of the game and developing players desires. This final iteration is the product of this process.

Process

Design Plan for Exam Iteration

The process of developing this game further started with first writing down all the features this student would want to develop, and then working out how long each one would take, and which was the most viable. The next step was to let many players play the game to see what they would want.

This student got feedback from three people in total. The first was from a WSOA3003A tutor, who marked my Iteration 2. They suggested cleaning the UI to make it more readable and scalable for all Android devices, but said the game was fun and consistent, a good quality to have at this stage of development. The next feedback came from a WSOA3003A student who had played all previous iterations of the game. They suggested fixing a few of the bugs in the game that they hadn’t minded until now but said would greatly improve the game for the Exam Iteration. The final feedback came from a student at Wits University not in the WSOA3003A course whom had never played the game before. They noticed a few bugs in the final build of the game this developer had made and allowed this student to fix them timeously. Below are all the improvements made through the Iteration phases.

Figure 1: A summary of the improvement made with each iteration, along with screenshots.

Improvements for the First Iteration

The improvements this student wanted to make were:

  • Better Menus and UI ✓
  • Multiple levels ✕
  • Multiple Enemies ✓
  • Animations ✓
  • An extra protection mechanic for the planet –>
  • A story, narrative –>
  • General feedback, juice and art style ✓

The improvements requested by players were:

  • More feedback to the player if they had hit enemy meteors away etc. ✓
  • More exaggerated physics when hitting away enemy meteors ✓
  • More clear indication of the player asteroid’s size and their score and other UI elements ✓
  • More diversity in the enemy meteors ✓
  • More dynamic and interesting background ✓
  • A more engaging reason to get a high score, with multipliers etc. ✓

 

Improvements for the Second Iteration

The improvements this student wanted to make were:

  • A game mode that ends –>
  • A score multiplier if the player hits a certain number of enemy meteors in a row –>
  • A narrative element –>
  • A protection shield mechanic for the planet –>
  • Fixing UI scaling issues on different phones ✓
  • Indication of a high score, how far the player has progressed ✓
    • Visually
    • Auditory
  • Make code neater, have a better commenting system ✓
  • General feedback, juice and art style ✓

The improvements requested by players were:

  • More knowledge of the high score as you play ✓
  • The Game Over screen being black as opposed to white – to have a less harsh effect on the eyes ✓
  • Hitting the incoming meteors at different speeds gives that a different force ✓
  • Easier way to see meteors coming in from the top of the screen ✓
  • Curved meteor paths ✓
  • Pause Screen ✓
  • Restart game at Game Over screen after five seconds ✓
  • Being able to change the orbit direction –>
  • Addition of a mechanic that would change the player speed depending on where they press on the screen ✕
  • A square screen ✕

 

Improvements for the Exam Iteration

The improvements this student wanted to make were:

  • Additional planet defending mechanic ✓ (see Figure 2)
  • Narrative element to the game ✓ (see Figure 4)
  • Clean and commented code ✓
  • Playtesting game timing and requirement elements ✓
  • Convenient game tutorials ✓

The improvements requested by players were:

  • Fix all bugs ✓
  • Consistent User Interface ✓ (see Figure 2)
  • Pause Menu Overlay ✓
  • Scalable resolution and user interface for Android phones ✓
  • Dynamic orbiting mechanic ✕
  • Change orbit direction ✕

Key

  • –> – Will consider for next Iteration
  • ✓ – Completed in this Iteration
  • ✕ – Idea scrapped

Design Iterations for Exam Iteration

The first game element completed was to playtest some of the game timing and requirement elements added in Iteration 2. This includes the number of points needed to start the next wave of enemies and points needed to get a coloured points indicator. This was all done from playtesting feedback. The next element completed was cleaning and commenting the code this developer had made in Iteration 1 and 2 to make it more understandable. The pause menu overlay was added next to communicate to players when the game was paused.

An additional defending mechanic was added to the game in the form of the Defender Ring, which grants the player two extra lives every 50 points. This extends the lifetime of the game and negates the player feeling cheated by losing a life from narrowly missing an enemy meteor. A narrative element was also added, explaining to the player why the planet is being attacked and what the role of the player is. This invests the player in the game and leads to a more immersive experience.

Additionally, many game tutorials were made more convenient as the are removed from the screen after a certain amount of time or the requirement of the tutorial is fulfilled. This leads to a more clean and immersive gaming experience. Finally, many minor bugs, such as sounds still playing when the game over screen shows were removed. Exit to main menu buttons were also placed on every screen, improving the flow of the game for the player.

The game was the finally extensively playtested on an Android emulator for Windows. This was as many scaling issues were found for different size phones. Therefore, the game UI was updated to be scalable for different size phones.

Reflection

This Iteration was planned and executed to a satisfactory level. The improvements wished to be made were mainly about polish and narrative elements. Improvements that are only usually made at the end of development of a game. The outcome of the process has led to a fun, immersive and complete game. This game is at the stage this student hopes to have it at so they can release it on the internet on platforms such as itch.io or the App Store.

To improve further, this student hopes to:

  • Get additional feedback from five players on what they would like to see in the next iteration.
  • Add a game mode that ends at a certain score, unlike the current endless version of the game
  • Have a score multiplier system for hitting many enemy meteors in a row or similar
  • Investigate a changing orbit mechanic depending on where you touch on the screen
  • Create a score multiplier for hitting multiple enemy meteors in a row
  • Have a cosmetic selection for the planet, orbit player and enemy meteors
  • Have achievements for the game

Some ideas were scrapped from the game at various stages. These were due to the ideas, after thorough review, seemed unable to significantly add to the game for the amount of work they would be to implement. Therefore, only ideas that would significantly add to the game, were easy to implement or both, were chosen to be implemented. An example of this would be the dynamic orbiting mechanic. The idea was for the orbit size of the player to change depending on where the player pressed the screen. After a few attempts at getting this to work, it proved quite difficult and it was felt that it was inconsistent with the simple aesthetic of the game, and so was scrapped. Other ideas that enhanced the overall dynamic and aesthetic of the game were then developed instead.

Getting feedback was key to a successful iteration process. Often the developer of the game overlooks key aspects and feedback from others was immensely helpful to making a fun and immersive game. The iteration process was also help by good planning and note-taking done in a specific notebook that this developer always carried around when working on the game. Finally, picking a game this developer was passionate about led to a great deal of love and effort being put into this game. Without the passion for the game, this developer would not have toiled away with some of the most annoying bugs for hours at a time.

Conclusion

This exam iteration was intended to take improvements this student and other players wanted to see in this game and integrate them into the current iteration that already existed. The improvements wished to be made were mainly polish and narrative elements. Improvements that are only usually made at the end of development of a game. This was achieved in a timely and planned manner. Some ideas that didn’t add to the intended dynamic and aesthetic of the game were scrapped. However, ideas deemed essential were all thoroughly developed and playtested. Getting feedback from others was key to a successful iteration process. This developer will use feedback again to develop games further. The iterative process was also a very satisfying one as this developer was passionate about their game and knew it had to potential to grow into the game it now is. The result of this iterative process was a fun, immersive and complete game that can be played on Android.