GTMK 2023 Game Jam Retrospective

Screenshot from video game -- asteroids exploding

This is my 4th time participating in the annual Game Maker's Toolkit game jam. Game jams are events where you must build a complete game within a specific time frame, in this case 48 hours. As always it was a fun experience but it felt a little different this time. I thought I'd take a little time to reflect on it, and game development in general, today.

Dioretsa by nhitze
You are the asteroids.

The final product – for the impatient reader

2023 Game Jam

This year the theme was Roles Reversed. After the announcement I went straight into brainstorming and planning. This was maybe one of the biggest lessons I've learned through these – game development is so much more about the idea than the actual development work. I've worked on plenty of games that sounded like a good idea but were not fun or were impossible to finish on my own. This year I wrote down everything I was thinking and explored multiple ideas before settling on one. Once I had settled on one I made sure I had a solid idea of how the game would play, how the player would progress, where the fun is, and win/loss conditions.

The idea

Game jams are an exercise in having a well scoped idea that you know you can execute on. A submitted game that is a really good idea but only 50% done won't be a winner. I know that I'm not an experienced game developer so I tried to stick to extremely simple ideas. The idea I settled on was reversing the roles of the computer and the player in the classic game of Asteroids. Asteroids is a simple, recognizable idea that most people will understand just by seeing it.

Implementation

The first thing I realized was I should have practiced. I have used Unity almost exclusively for 3D games (and it has been a little bit since I last used it..). I knew going into this jam that I needed to do a 2D game. It's just easier in so many ways and one of these days I'll finish my post about why.

I started with prototyping everything. The menu navigation, the asteroid movement, and the code to "wrap" an asteroid around the screen. I was really proud of my prototype so I closed Unity and took a break for dinner.

When I reopened the project, everything was gone. All of the scenes I created, prefabs generated, code written. Gone. I still don't know why but it seems like it had to do with a shortcut I launched Unity from. This never happened again for the rest of the jam, but I still religiously backed up my project folder every time I took a break. Losing 6 hours of work in a 48 hour project was crushing to say the least. I rebuilt everything again, this time in about 2 hours (I remembered most of how the code works), which I guess illustrates how much time is spent figuring things out rather than just typing code.

After the prototyping stage I started to refine all of the mechanics, fixing bugs as I went. Code for game jams (and I've heard for games in general) is not at all like the code I would write for a job. The limited scope of the game and lifetime of the code led to some horrendous brute force algorithms whose only advantage was fast to write. Some bugs aren't worth fixing – they just get mitigated and swept under the wrong. For instance the collision code is terrible. I used my own collision detection instead of using the Unity physics system which ended up meaning slow updates or fast moving objects would fly through objects without having a collision detected. How did I fix it? Speed limit everything and said a prayer.

After all of the systems were built and the game was functional it was time for polish: adding animations, pickings fonts and colors, and adding particle effects. Mostly this went well. The only rub was that due to a bug in Unity (or its Flathub packaging) I wasn't able to add audio. That was a bummer since audio is an important component for a game, but the bright side was that it saved me a little time implementing audio systems.

Final product

In the end I submitted my game about an hour before the original deadline. It's the most complete game I've made so far and I'm pretty proud of it. It's not going to win any awards, but it is a testament to how far I've come over the years. Now that you've made it this far I'll let you in on a secret: the first GMTK game jam I participated in was my first time doing game development. I tried to make a simple game where the player shoots out a hook to grapple ... asteroids. I didn't finish it and what I did have wasn't even worth submitting.

Dioretsa by nhitze
You are the asteroids.

Lessons Learned

"Learned" is the wrong word though. "Lessons Made More Obvious" is probably a better phrasing.

  1. Prepare more before the jam - practice making pieces of games in the style you think you'll use. This helps keep you fresh on the tooling, APIs, and other practices.
  2. Spend as much time as possible on prep before coding or designing. It's so much faster to write out ideas than coding them only to find out they don't work.
  3. Limit scope and resist all temptations to grow that scope.
  4. Backup any electronic data you would be sad to lose