Bullet Survivors

Solo Project - Focus on level design, systems design, and player feedback, and rapid iteration.

Purpose:

Bullet Survivors is a solo prototype that focuses on rapid iteration, project planning, system design, and level design. I started by acquiring a reference game, which in this case was Megabonk, and then made a playable prototype that had the same gameplay loop as the reference game. From there, I started prototyping and utilizing project management boards like ClickUp to provide a clear-cut path of what needs to get done. When starting the project, I first worked on the player controller and researched how the player controller should feel to the player, especially for a game like Bullet Survivors.

The Entire project was made in Unreal 5.7 and was able to be prototyped and made into a playable slice in a span of a month. Tools I used while developing was ClickUp which allowed me to streamline project management.

From this project I learned value skills such as time management, building code that is clean and readable, and being able to expand that code and add more engaging features without sacrificing the quality of the code. This ensures that all actors within the game project knows who to talk to without needing to have any hard references.

Post Mortem:

Hello everyone. Today I will be talking about the postmortem of my game, Bullet Survivors.

The first thing you may think is, what is Bullet Survivors? Bullet Survivors is a bullet-heaven-type game that shares its DNA with other games like Vampire Survivors. What constitutes a bullet-heaven game? Essentially, a bullet-heaven game is a type of roguelite where the main objective of the player is to survive as long as possible while trying to avoid enemies and acquiring upgrades to become more powerful. The way the player attacks is through auto-attacking, meaning that the player character will shoot at an enemy without requiring input from the player.

How could this be fun? The fun lies within the replay value of the game. While the player may not have input over who or where they attack, they do have control over the stats they possess. This means that each time they play a new run, they have the option to choose what upgrades they want, giving the player a lot of agency over what they want to do during that particular run. In other bullet-heaven games and roguelites, this form of agency can come in the form of items that have unique effects for the player, requiring them to plan and understand what items they want to use.

So, how does the player complete a run? Like most roguelites and bullet-heaven games, there are usually one of two ways to finish a run: die or complete some sort of objective that ends the run. Typically, these types of games also reward the player for dying or completing an objective with some sort of meta-currency that they can use outside of the run. Some good examples of this are Hades and Megabonk, both of which offer a currency that can be used to get upgrades or new characters.

Here is a link to gameplay of my game: https://youtu.be/o84CpvuXZ0Y

Let’s get down to brass tacks. What were some of the challenges during development, and what went right?

Firstly, I would like to start off with what I found hard to do, which were a lot of things. My first challenge was trying to figure out the sources of stress for the player. After all, every game needs them, so how would I be able to stress the player out while also being able to scale that throughout the game?

All games scale their difficulty one way or another, whether it be by making the enemies stronger or faster, or simply spawning more of them as time goes on. With that said, at the time, I didn’t want to mindlessly spawn a bunch of enemies at once because that would overwhelm the player. I understood that if the player were met with an overwhelming force in the first two minutes of the game and didn’t have the stats to be able to deal with them, it would cause friction and make the game less fun to play.

To solve this issue, I opted for a spawner that gradually spawns more enemies over time. How it works is that when the player gains enough experience, the player character sends out a message to all spawners that are listening. This triggers an event that increases the number of enemies that spawn by one. This allows the game to feel fun to play because, as the player grows stronger, they become better equipped to face a bigger horde of enemies.

Next would be player-facing information. This would be the weakest link in my project. At the time of writing this, I plan to make great changes in order to make the feedback in my game feel more punchy. What went wrong is that there is a clear lack of feedback to the player. When the player moves, there are no footsteps or effects that represent locomotion. This, in turn, made the game feel one-dimensional because even when the player is doing well and has high stats, it is hard to see the difference between a run that is in the late stage versus a run that has just started.

So, what went right? What did I think went well?

Firstly, the main map that I used was something I was particularly happy with. At the start of development, the map that I used to gauge whether or not the enemies could path correctly was very bland and wasn’t very vertical. Taking a look at my research, I saw that games of a similar vein had very vertical maps.

Take Megabonk, for example. The first stage is teeming with hills and slopes that the player can use to their advantage. So, I took that inspiration and made a map in the same style, adding a few slopes and a catwalk area for the player to use. This ended up being my favorite addition to the game because the catwalk area provided a sense of safety while also letting the player assess what other areas they wanted to go to. It also served as an area to scout for the boss spawner, which we will talk about soon.

With enemies being able to path to you from wherever they are, the vertical areas also served as places to jump from in case the player became overwhelmed.

The second thing that went right was the boss spawner. This was something that was really fun to implement and offers replay value for the player. Essentially, how it works is that the altar that the player uses to spawn the boss is loaded into the level and runs an event that takes all actors designated as boss spawn points, which are target points. It would then randomly select a point and set that as its spawn location. With that said, every run will be slightly different because the boss altar spawns in a new location every time.

In conclusion, I think the development went well for the time I was given. I made the most of what I could do, and in the end, I was able to make a game that my friends and peers found fun to play!

I think my key takeaways from this are that player-facing information should be a key part of making a fun game to play. Another takeaway would be to really focus on my research and learn about design patterns. After making the final additions to my game before submission, I was introduced to the object pooling design pattern, which essentially eliminates the need to repeatedly spawn and destroy actors. It allows you to keep actors loaded and reuse them elsewhere, which sounds like it could be very useful in a game such as mine.