HeadBlaster Postmortem: Struggles and Future Revisions
Development Process:
HeadBlaster Presentation: Presentation
Character Design/Theme-
In considering what would be a more unconventional and jarring theme for a traditional Shmup game, I rolled the idea of a floating head around in my mind during the brainstorming phase. Eventually I came up with the idea of a floating zombie head which uses corpse gases to propel itself forward, while it shoots projectile vomit out of its mouth as an attack. After settling with this idea, I went on to think about the theme and overall enemies in this game; I wanted something more traditionally Halloween-esque for my game. As such, I came up with enemies such as Bats, Grim Reapers, Fireballs etc which would all have different behaviors.
Level Design-
For my game levels, I wanted something closer to a traditional space shooter where enemies descend from the top of the screen while you ascend toward them. I chose to make the game this way because this was the first time I was going to design a game that used waves of enemies which come down on the player by instantiating, with different movement patterns and abilities. In terms of the levels themselves and their structure, I decided to create one or two waves of different enemy types which the player would need to eliminate before the Level Boss is spawned. These bosses would be the enemies holding the Amulet Pieces that the Zombie Head needs to complete himself, thus tying the level design with the overall premise of the game itself.
UX/UI Design-
For the UI elements of my game, I wanted to create a more old school 2D feeling like the Metroid games, but as I will discuss further down, with more organic 3D effects. As a result, for the UI itself I created more traditional text indicators to let the player know about their health, enemies remaining in the game and how many amulet pieces they currently held.
In terms of UX, I wanted to make the game as rich in feedback as I was able to, given the time and knowledge that I had. As a result, I used sound indicators for when the player gets hit, when enemies get hit, when enemies die and for when bosses arrive onto the scene. Other sounds I decided to use where different soundtrack themes for every level, as well as for the Start and Game Over screens. In terms of effects, I used a lot of impact indicators, such as camera shaking when the player gets hit and explosion effects when enemies die. For these I went for more 3D effects to make the game look more visually pleasing and also jarring to the player. Some of these effects, such as blood gushes whenever an enemy or the player gets hit are more realistic in that they are part of the game world itself.
Successes:
In terms of success, I believe that this game has had a lot of victories in terms of the development process and playtesting feedback. Indeed, I managed to create an original take on the space shooter genre which follows a very unconventional theme that playtesters appreciated. Indeed, the character and enemies seem unique enough to be distinguishable from each other while their in game behavior is also unique to one another. Playtesters also appreciated the UX effects and player feedback I implemented in the game, praising the satisfaction these granted to them as they played. Furthermore, I believe that the sound system itself came out very well considering my limited knowledge of audio design. Indeed, the soundtracks play whenever they need to play and smoothly transition into the next theme whenever necessary.
Also according to playtests, the difficulty ramp of the game is also quite smooth and well thought out, which was the main goal of this project, especially for me. Indeed, there is a clear distinction between easy, medium and hard levels, but not jarringly so.
Challenges:
I faced numerous challenges during the development of this game, some small and others large and serious. Firstly, a serious challenge, which I still have yet to resolve and had to settle for a text compromise, was the Amulet UI for the amulet pieces the player collects. Indeed, I tried numerous methods in an attempt for the image UI to update and fill out an image of the amulet as player feedback that highlights their progress in the game. However, no matter which pieces the player collected, the UI would only update the very first segment and leave the other parts of the amulet blank. As such, I went for using a numerical indicator instead of an image one.
Secondly, keeping track of where all the enemies in each wave where and how the player could know was another issue I had. This was because some of the enemies spawned off screen or at different areas and the player would never see them. This also ties in with the bosses as the player had to kill all enemies on the level before the boss appeared. As such, I created a UI counter which tells the player how many enemies are still alive on the level.
Another challenge I faced was in implementing different behaviors for each enemy and boss without this tampering with the difficulty ramp of each level. Although it took a while and a few iterations before I could settle on what each enemy should do, I managed to figure it out in a way that does not jar the player with overly powerful enemies versus substantially weaker enemies in other levels.
Lastly, the bosses themselves and the dropping of the amulet pieces upon their deaths was another thing I struggled with for a while. This was because I needed to find a way to still spawn the amulet pieces even after the boss itself is destroyed, along with the script calling for the amulet piece itself. Eventually I managed to figure out this problem but it had me considering changing the scenes based on another thing rather than collecting the amulet pieces at the end of every level.
What I learned:
Through the development process of this game I learned how to effectively compromise on things that will inhibit the game itself or my time to complete the game before its deadline. Indeed, even though I enjoyed some of the features I had in the game, such as the Amulet Image UI, I knew that I needed to change them and get rid of them due to the fact that they were not functioning how I wanted and the problem solving process was draining my time. Furthermore, I learned how to code more effectively in that different scripts work together and are tied to each other like in a web, making the game function better and making programming easier for me to understand and problem solve whenever possible.
I also learned how to do basic sprite animations while working on this project, as well as how to implement different sounds all at once in Unity.
Future Iterations:
Due to the limited time I had to work on this project as well as the fact that my knowledge was very limited in fields such as animation and audio, I had to make many compromises that I would want to see edited in the future. The most important of these are the animations for the sprites, their effects and the various sounds I used in the game. Firstly, I would like to create better, more organic and fluid animations rather than the more static and rugged ones I am using now in a future iteration. However, this would mean I would have to learn a lot more about animating sprites which would require many hours of practice. Secondly, the effects I use in the game for impacts, death and firing are mostly 3D particle systems due, again, to my limited knowledge of creating and animating particle systems. Although I am proud of the effects I created and my playtesters were satisfied overall with them, I would want to have created and used 2D particles that follow the theme of the game. In terms of sound, some of the sounds I use for this game are taken from various themes, such as firing weapons or human grunts. As such, some of them are inconsistent with the theme of the game and with each other and appear strange when heard together. As a future iteration, I would like to use different sounds that perhaps I create on my own with the improvement of my knowledge.
Two last iterations I would want to make would be to find a way to get the Amulet UI to work, as it is a more satisfying feedback form, and to be able to better manage the enemies on each level and how they interact with each other and move on the map. In terms of the enemies, the way they work now is entirely dependent on one script, meaning they all act as one entity, one wave of enemies and not as individuals. As such, I would want to find a way to make some of these enemies behave differently to others without having to manually change each enemy itself.
Playtests:
During all of the playtests I carried out, I noted that the overall theme and player feedback of the game, such as the enemy death explosions and general particle systems in the game, were well received by my playtesters. Indeed, all three complemented the juiciness of the UX and the satisfying feeling of exploding enemies and the camera shaking when the player received damage. Another thing which was successful and well received by playtesters was the difficulty ramp of the levels. Indeed, it was unanimously acknowledged that there were initial easy levels that led into more difficult levels, while the enemies themselves were also differentiated well enough for the player to recognize that they were different enemies with different abilities. Furthermore, players also enjoyed how jarring the game was in its humor and level design of bosses popping in to attack the player once all enemies had been defeated.
In terms of recommendations and changes, one playtester recommended that the camera allow for a more wide and zoomed out field of view as the game felt claustrophobic in that it was too wide but short and so they could not see enemies descending down on them until they were right on top of the player. This was successfully edited and the game plays much better now with a bigger field of view. Other testers recommended that the enemy and player bullets disappear sooner since they could kill enemies or the player without enemies being in the field of view yet. As such a player could just sit back and fire randomly upward and kill enemies. This was a little harder to edit since finding the point where bullets don't die too soon or too far in time was quite tricky, but, nevertheless, I managed to reach a point where the bullets are more satisfying in their lifespan. Continuing, another playtester suggested that the health of some enemies be decreased due to the fact that they required too many projectiles to die and were already overpowered, leaving players struggling to evade and shoot at the enemies at the same time. This was also edited to allow players to both maneuver enemies while also fighting them to successfully eliminate them. Another major suggestion that a playtester made was the inclusion of powerups in order to ramp up the player's power in tandem with that of the enemies on harder levels. As such, a powerup which allows for faster movement and projectile fire speed was developed for future levels, equalizing player and enemy strength. Lastly, this playtester also recommended that the particle systems for effects such as explosions be changed to be pixelated and not 3D, but due to a lack of knowledge on how to create particle systems, as well as the fact that all other playtesters enjoyed them, I decided to keep the 3D effects.
Further playtest results can be found below listed under each playtest in the Playtest Notes section.
Playtest Notes:
Playtest Images:
Get HeadBlaster (Shmup Project)
HeadBlaster (Shmup Project)
Space shooter style game with a Halloween twist
More posts
- ResearchSep 20, 2019
- ExercisesSep 16, 2019
- Game Design Workshop ResponsesSep 16, 2019
Leave a comment
Log in with itch.io to leave a comment.