Can I really call myself a game developer if I’m not actually developing games? That question led me to join the A Monthly Game Jam – July 2022 game jam. I needed to work on something. And overall it was a good experience. So today, I’ll be making a post mortem for the my new game Radiance: 2691.
Note: this is just the post mortem for Radiance: 2691. If you are interested in playing the game, check out the Radiance: 2691 – Game Jam #2 page or play Radiance: 2691 on itch.io.
Inspiration Behind Radiance: 2691
As I mentioned, I’ve been struggling to just create anything lately. That led to research on productivity and eventually to the post Game A Week: Getting Experienced At Failure by Rami Ismail. From that, I decided to give that a try. And so I entered the game jam.
One goal I have from doing this is explore how games of different genres are actually made. Like what methodology or techniques are used.
Once the jam officially started, the theme was announced: strength in numbers. Using this theme, I went down a list of ideas and concepts I keep in my game design notebook until I found one that somewhat fit or could be adapted. The initial concept was:
A color-based SHMUP. Enemies are certain colors. Weak vs opposite colors.
My thought was to add additional ships of a certain color. Each one would target only the enemies that matched their color. They would rotate towards the closest one and fire independently of you. The drawback was their bullets could only impact enemies their color. The more ships you had, the easier it became. Thus, how I interpreted the strength in numbers theme.
What Went Right
I really tried to think about this game jam as a designer, not just a developer. So I came up with a list of every feature that might go into this game. Then I separated them out into what was essential and what was a bonus feature. And this was tremendously helpful.
By the end of day two or three, I nearly all the essentials working. They looked absolutely awful! But if absolute emergencies came up and I had to submit what I had, it would’ve been a working game.
Afterwards, I re-evaluated the bonuses features. I thought about how long each would take to implement and how hard it would be. All the ones I wasn’t super confident in were cut. I intentionally left one because I wanted to make sure I learned something new from this game (the Universal Render Pipeline and the bloom post processing effect).
This whole planning/scheduling process was a tremendous confidence boost. It kept me focused and on target. I highly recommend everyone takes the time to do this!
A New Challenger Approaches!
A few days into development, I mentioned on Twitter that I was working on a game jam. Was surprised when @MijimoGO reached out offering to do the music for the game. I felt bad because I was expecting to work solo and already had in my head what the music should be. Usually, I decide something like that with the team (and especially the composer). And I didn’t have that chance for him.
But he just jumped in anyways. Took what I described and crafted a great set of tracks that was pretty darn close to what I was planning.
I am tremendously thankful, as it freed me up to work on more features and extra polish. Be sure to check out his other work on SoundCloud. Some real bangers on there!
What Went Wrong
Time estimations were definitely a problem. Especially the last day. Did not factor in enough time for creating additional scenes (the title screen, options, credits, high scores, etc), creating the final build, and uploading to itch.io. Ended up cutting more than I wanted just because time ran out.
My code was an absolute mess. Seriously, don’t look at the repository (or do, for examples of what not to do). I usually try to stay super organized when I code. But with the time crunch, I felt like more would have to be cut if I decided to refactor the way I would like.
When I got the additional ships working, I had a bug where their bullets were being fired from an invisible point somewhere below them. This point seemed to get further and further from the ship the longer you played. I am almost embarrassed to say that the cause of this issue was…gravity. I left the damn gravity on the rigid body. My assumption is it was being pulled down from gravity in the Update() function, then my script was pulling it back to its proper position around the player. I lost at least 4 hours trying to debug what was fixed with a single checkbox.
I didn’t know how the Unity UI system worked. Kept trying to position everything by script before I realized how it worked in the Inspector. Still ended up decent, but at certain resolutions the UI just way too small.
What I Learned
Having a plan is critical to doing well. I started this game knowing what my goal was. Then, I listed all the absolutely essential pieces and focused on those. What I thought would be to hard or to long to implement, I didn’t worry about. And having all this in place early on was tremendously helpful.
Also learned a fair amount about visuals. I really wanted to make the game look nice despite being pretty basic. Still a lot to learn, but I felt like I got a good understanding of the:
- Universal Render Pipeline and basic post processing.
- UI system.
- Particle effects system.
I also learned how long it takes me to make a game like this. And that might not seem like a big deal. But when I work, I need that sort of information to be able to set realistic goals and expectations. By keeping track of when I started and ended, I can estimate how long it actually took me. The downside is I didn’t keep track of specifically what I worked on each time. Git repository history is the closest I’ll get for that. Now I know. Log start and end times as well as what you worked on.
