Version 2

New content implemented:

• Added randomized level selection after the completion of level objectives
  
  • Level selection is paired with possible new objectives and obstacles
• Added upgrade screen that is brought up by the player instead of automatically
• Added ability to accrue upgrade points and spend them when desired.
• Added upgrade rarities for each upgrade
  
  • Each upgrade rarity has a different value and will affect the players weapon accordingly
• Added different costs for upgrades so player is met with more agency and decision making
• Added several new enemies
• Added global difficulty scalar over time to control multiple aspects of the game
• Added weapon indicator for Bomb Betty to detail where AOE is applying damage
• Added new level obstacle
  
  • Falling meteors (fall and spawn speed scaled with current difficulty rating of game)
• Added endless mode after 3 maps are completed

‍

Added new version to Itch.IO

‍

Version 1

What Went Right:

1. [ Wave Spawner ] - [ The wave spawner was important to get right since it provides the stress and tension for the player throughout the game. As time progresses, greater amounts of enemies are spawned which provides continually more challenging obstacles for the player to overcome. At first, I had housed this wave spawner within the game mode blueprint. The thinking behind this was it had so much information that could be shared among other actors that needed it. Seeing that the game mode is ever present, it seemed like the obvious choice. As the wave spawner became more complex, it became clear to me that it needed its own blueprint to manage all its functions and to keep the game mode clean of excess code that did not pertain to it. After moving the wave spawner code, I felt way more comfortable expanding on the functionality within which allowed for me to create a more engaging player experience. ]
2. [ Game Feel ] - [ The game feel is a bit more subjective, but I put this in here because of the feedback I received from play testers. The feel of Megabonk is very particular and is heavily focused on a retro/toon aesthetic, mixed with a very large amount of enemies in a fixed area, while upgrading your weapons throughout the course of the game. Thankfully, from the feedback I received, this was achieved.  ]
3. [ Coding with Scalability and Dynamics ] - [ Since starting work in game design, I have discovered what it's like to create a game system and then have to make a small change to it later on resulting in a near complete dismantling of the old system in order to make the change. These days, I try to keep this in mind by designing systems that can be modular and scalable. Often times this means writing out how the system will flow on paper before hopping into the engine to implement the functionality. In the end, this allows for changes to be made with much greater ease than systems that are hard coded. ]
4. [ Multiple Mechanics ] - [ Do to the time constraints, the amount of mechanics I was able to work into the MVP build is something that I am proud of. In all, within a three week span, I was able to implement roughly four separate mechanics that can be seen within the reference game as well. (Weapon, Wave Spawner, Shrines, Upgrades) ]
5. [ Core Game Loop ] - [ The core game loop is something I am immensely proud of seeing that it required multiple mechanics chained together to pull off. The core game loop consists of exploring, killing enemies with your weapon, collecting XP to level up, upgrading your weapon, and looped. To achieve this, I needed a way to spawn enemies in, a weapon the player carries that deals damage,  the enemies to take damage, the enemies to drop XP, the  player to be able to collect the XP, a system that tracks the amount of XP the player has collected, a series of upgrade options for the players to choose from and a way for those upgrades to affect the weapon the player carries. Everything had to come together for the core game play loop to feel right and I feel confident that it did.  ]

What Went Wrong:

1. [ Originality ] - [ One of the main issues that I know I could've improved on was attempting more originality in the game's concept. When developing the game I was a bit too focused on being able to create the mechanics I saw, rather than taking the mechanics I saw and providing and interesting twist. As I work on the game more, I will be focusing on adding ways to differentiate my game form the reference game.  ]
2. [ Player Feedback ] - [ On the issue of player feedback, there could always be more. In the case of Megabonk Redux, the player feedback is enough to understand what is going on if the player knows what to look for, but not enough for the player to understand what is happening without searching for the answers. In most games, as players, we are able to generally figure out what each interaction and mechanic does just by the player feedback that is given. That same amount of player feedback is what I desire for this game and can be done by adding different sound effects for the shrines, more fan fare when the player levels up, adding a UI element that shows what your upgrades are directly affecting, etc.  ]
3. [ Enemy Differentiation ] - [ Due to the time constraints of the project being just a few weeks, I am happy to have made a single working enemy, let alone boss enemies. However, there is always room for improvement and I believe that adding in just a few different models for the enemies would have added a much better aesthetic than just the capsules themselves. In addition to this, I would have loved to have fleshed out the mini bosses and main bosses more with their own AOE attacks, sound effects, and models as well. Lastly, I would also like to implement different movement for all enemies as well. Similar to Megabonk, the ability of the enemies to freely climb up walls and each other is a core part of what gives its enemies that mob feeling. ]
4. [ Player Movement ] - [ Arguably my biggest downfall with the project is the player movement. A core aspect of the reference game is the ability to take your momentum into a slide. Using the slide movement in Megabonk allows the player to speed down heavily slanted areas of the map and even use that speed to jump over enemies or even just traverse large parts of the map with ease. Unfortunately, I was not able to get this implemented and I feel that it was absolutely an important aspect that I chose to cut out due to time constraints.  ]
5. [ Lack Of Meta Progression ] - [ In roguelike or vampire-survivors style games there is typically in-game progression as well as meta-progression. Meta progression is typically handled by way of collecting a currency while playing that can only be used from the upgrade screen in the main menu area.  Unfortunately, i was unable to get to this genre defining mechanic, but it is something I absolutely plan to add as I spend more time with this project. ]

Conclusion:

‍Above all, I am very proud with how this project came out considering all limitations. Since I went out of my way to make several of the mechanics dynamic and scalable, I am much more likely to continue this project when new ideas arise and I have extra time to implement them. I also am glad that based on player feedback I was able to capture the game feel of the reference game since that was my ultimate goal in all of this. On another note, I wish I would've spent more time attempting to re-create the slide mechanic since movement is such a key aspect of Megabonk. In conclusion, I am excited to keep working on this project and attempting to make it as scalable, dynamic, exciting, and juiced up as possible.

‍