GMTK 2022 Postmortem

New firsts

My last game jam was six years ago. I was still a novice developer with only basic Unity skills. Nowadays, I have a good history of development behind me, including a few years of working on games (although only tangentially with Unity). I wanted a challenge to pull together my learnings from the last couple of months. The Game Maker Toolkit jam provided the perfect opportunity. 

GMTK2022 was my second game jam, and to be honest, I had no idea what I could handle, especially on my own. I wasn't even sure that my skills were "real"- that I could produce any working game in 48hrs. On top of those concerns, I planned a busy weekend- my favorite band was playing in town Friday night, and my partner wanted to attend an art show two hours away. What if I missed out on life only to embarrass myself?

I flipped a coin, and it said, "do the jam." Here's what I learned.

What I did right

I got lucky and did a lot right.

Chose a design quickly

After reading the theme, I took a shower (this is critical). A vision of an old color-matching shooter popped into my head, and I realized it would probably work for the theme. What if I based your color on the dice roll instead of directly controlling it?

But you can't just accept your first idea. Throw out your first ten! So, I wrote down nine other ideas before deciding this was a waste of time and leaned into my first one. By jumping on a concept quickly, I could avoid decision paralysis and start building quickly.

Stuck with a more straightforward genre

I'm a big fan of LazyDevsAcademy and knew from the start that I wanted to lean on his advice found here: 5 Overlooked Genres for Your First Game. These genres have a high appreciation-to-effort ratio, making them ideal for game jams. From here, a simple shooter was the most obvious choice.

Wrote a solid plan out of the gate

My professional development and project management background informed me that I needed an organized plan from the start. I wrote a list of everything I wanted to build, then sorted those goals into three categories: Basic Features, Polish, and Additional Content. Each item had to be demoable on its own- for instance, "move the main character," "shoot a bullet," or "a monster spawns."

I set a target for 12hrs to have the essential features done.

This is what you need to playtest the game. You may notice that this game version supported normal WASD movement. There was also no Dash mechanic at this stage. At this stage, I could share my game with friends comfortable with prototypes and alpha builds to get their feedback. I implemented a dash mechanic that randomized your color based on their feedback.

After this stage, I got to work on basic polish- adding a backdrop, sprites and animations, UI, music, and SFX. The first coat of polish brings a lot of character to a game. It should be prioritized shortly after basic functionality. By the time this was done, we were at the 24hr mark, and I was ready for beta playtesting. I invited my partner to try it out and saw some fun gameplay emerge. She only used the dash button to move, so I tried the game without WASD and loved it. I also added in monster waves at this stage.

With the changes from beta playtesting implemented, I decided to wrap it up. While we still had 13 hours to go, my sanity was waning. I spent a couple of hours putting on the second layer of polish and hit the publish button. Of course, there are always flaws after getting to live, so I spent a couple more hours tweaking details and fixing bugs before finally calling it done.

Cut features after playtesting

When going into a playtest, it's essential to keep this thought at the front of your mind: "are any of these mechanics not necessary?" Don't keep features just because you've already written them. Cutting a feature is just as likely to lead to fun gameplay as adding one (perhaps more). For instance, by cutting WASD motion, Death Roll became an intense and chaotic clickathon.

Took breaks

While I missed that concert (it's ok, we saw them a few months back), I made time to stop and reset throughout the jam. I took walks, ate proper meals, and even spent Saturday afternoon attending the art show. By creating time away from the game, my mind was able to breathe. This meant that I could return more focused and engaged than before.

Leaned into the social aspects of the jam

I didn't expect the jam to be as social as it is. If you want reviews, you need to offer reviews. I quickly saw that providing empathetic feedback to other jammers was an excellent way to get eyeballs on my game.

I think I did a lot right, but I also did some things wrong.

Slept like absolute garbage Friday night

I'm sure some jammers spent all 48 hours in go-mode, but I'm not so young anymore. I need my sleep. However, I was so excited about this game that I couldn't. Every time I started to drift off, I'd have some idea I could implement the next day. I wrote these ideas down so I didn't keep ruminating on them, but I think this impacted my effectiveness on day 2.

Tried to learn the new Unity input system

I have no idea what I was thinking here. I wanted to add controller support on day 2. After a couple of hours of frustration, I finally reverted the changes and leaned into the mouse model.

I've added this to my upskilling goals when I have the time and space to do it right.

Was too conservative in my target

While my limited scope allowed me the comfort of getting done early, I ended up only using about half of my waking hours during the 48 hours of building the game. I could have reached higher and done more. I think this is a net positive. However, I'm doing game jams to stretch myself, so I want to target a more extensive game next time.

Went down a couple of rabbit holes that ate up time for no gameplay value

I spent a fair amount of time trying to generalize a couple of systems. In particular, I wanted to clean up the dice holder system for the giant monster and the wave state machine to reduce copy and pasted code. I eventually realized that this was a worthy goal for after the jam. Clean code, especially as a solo dev, makes very little difference in a project spanning 48hrs, and it costs you feature and playtest time. If you can cleanly build as you go, it's worth it. Otherwise, ignore the itch to refactor unless the refactor is required for features.

Development path for Death Roll

I don't know if I'll keep developing Death Roll. I think it has potential, but only if I can find a good release fit. Here are my high priorities to take it from a jam game to a finished product.

Better wave and mob management

The waves are precariously balanced to be feasible to beat given good rolls. However, I want to clean them up, so they're not overwhelming and grow in difficulty by design rather than by chance. I also want to upgrade the mob spawner system to add drama and juice instead of the gentle wandering they currently do.

Lives

Given the game's randomness, I think a life or health system is necessary.

Pickups and Powerups

It's not a chaotic shooter without pickups and powerups. I have a few designs in mind that didn't make it into the jam build.

Original asset 

I love 0x72's pixel dudes, and several commercial projects have used them. However, I'd want to invest in original assets so that Death Roll could stand out. Based on feedback, I would likely replace the demons with some sort of dice-themed monster, so their target number is easier to read. Also, I need some death animations. It's in the title!

UI scaling

I only have a rudimentary understanding of Unity's UI system. To take Death Roll to market, I would want to expand the resolution and scaling of the UI to look good on more devices.

Mobile controls

I have a control scheme in mind for a mobile build. I'll need to integrate Unity's new input system to get there.