GMTK 2025 Game Jam Retrospective

Cover image for Pew Pew Pals

This year's game jam theme was Loop. My task over 4 days was to build a game that fit that theme. The theme and allotted time allowed for a lot of really interesting submissions. My game was not very original nor particularly engaging, but I am proud of it nonetheless. For me this game jam was more about the process than the outcome. That's because of one huge difference this year: I did not use a mainstream game engine.

If you want to play the game, you can find it on the itch.io page here.

Preparation

In past years, I usually start preparing for the game jam a couple of months in advance. Mostly that means practicing with the game engine I plan on using. I will do a small example project or two to try to make sure I know the engine's features well enough to be productive during the jam. That helps me know upfront what is feasible in the engine to accomplish at my skill level within the time limit. It also gives me the keywords I will need to search online when I need help.

This year was similar. But this time there were no keywords to search or features to learn.

Engine

In 2023 I started a new game engine project. One day I will write a post about what it is and my motivation behind it. For this retrospective what is important is that in 2023 I put in some focused effort over a couple of weeks and then put it down (like all good side projects). It was nowhere near ready to render a simulation, let alone run a game.

Fast forward to April 2025. I realized my engine wasn't going to go anywhere by just building plumbing. I needed to build example projects to keep me motivated to make progress on the engine itself. For 3 months, April through July, I made significant progress. I built a simple simulation (Conway's Game of Life) and a simple game (Pong). Both required new systems to be implemented, optimized, or otherwise improved.

Heading into the jam I had an engine that could open a window, render sprites, process inputs, play audio, and manage entities. All the building blocks you need for a simple 2D video game!

Jam Process

This year I once again worked with my sister to design the game. My choice of engine really limited our options on the game design side. The interactions had to be kept simple because I had no interactive UI layer, no scene system, and no physics system. We ended up deciding on an arcade style game heavily inspired by Asteroids. She brainstormed some names and we eventually settled on Pew Pew Pals which set the art direction for the game. While she went looking for 3rd party assets, I started working on getting the game working.

Day 1

Since the jam starts in the middle of the day in my timezone, this was only a half day. I also couldn't get away from work so we had to wait until the evening to start. We spent most of our time brainstorming ideas, and then I got the window rendering a programmer-art sprite. At this point we thought the name would be Cosmos Carnage, which is the name you'll see on the windows.

Window titled "Cosmos Carnage" with a simple triangle ship sprite
The very beginning - a sprite in a window

Day 2

Day 2 saw a lot of progress. The ship could be rotated, moved, and could shoot bullets. I also got asteroids spawning and moving. I then worked out a little bit of automation I thought would be helpful.

In the past when I needed feedback from other people I would have to use the engine's editor to build a release, zip it up, and then send it. This year I realized I have all of the pieces to do it automatically. Whenever I pushed commits to GitHub a workflow would build a release version, zip it, and push it to a container in Azure blob storage. Then I had a quick Azure function that could list the public contents of the container and provide a link to download each one. This gave me a link to send out that contained the latest build and all previous versions in case comparison was needed. This ended up making the final jam submission easy because the game build to distribute was just the most recent version!

A window with asteroid sprites and a rotated ship sprite
Flying, shooting, and dodging asteroids

Day 3

On day 3 we nailed down what mechanics we were going to finish and compiled a list of art that was needed. This required a lot of engine progress to add collision detection, simple physics, and fixing a couple of render bugs. Mostly it was heads down coding. Since my engine doesn't have an interactive UI system, I worked around it by having the menu system just be based on collisions with sprites. We built a shop that provided upgrades!

Fancy art

Day 4

Day 4 had to be the day for polishing. No new features were added. I had to refine almost everything - adding "animations", fixing bugs, tuning parameters so the game felt a little fun. I ended up adding a feature to load a JSON configuration at runtime so my sister could play with the variables on her computer while I kept working on the game.

I added sound effects, background music, and a background layer. I spent so long on the background it was a little embarrassing. I wanted something more interesting than a static background but struggled to find a simple way to do it. This was definitely a case of spending more time trying to cheat than just doing it the right way from the beginning.

My notes for this day perfectly sums it up: "So tired I forgot to get screenshots".

Day 5

The final "day" was just a few hours before submission time. I finished up a couple of things that still felt like a work in progress. Otherwise most of my time was spent working on the submission. I had to build the itch.io page, which involves gathering screenshots, writing descriptions, and choosing colors and layouts. I also quickly added a Linux build since that was what I was developing on the entire time anyway.

Final Thoughts

Overall I'm proud of what I could accomplish with what I had. A lot of code had to be written and my engine made some big leaps. The game itself is not going to win any awards but it will probably serve as a decent example of how to use the engine. It also gave me a lot of ideas for how to improve the developer experience.

For the jam itself I think we could have benefited from starting with a smaller idea. Even though we were aiming small, we still ended up being a little too ambitious. One example is adding a shop. It was a good idea for the theme but ended up not being fully polished. It needed a lot of work, and I could have used that time to polish other features like improving the audio or adding a real animation system.