This game was my first ever coding competition, me and my teammate had never tried anything like it yet we were still able to pull through. Together we designed, created assets, and coded up a game in just 48 hours.

The Robbery of Smokey Saloon is a 2d point-and-click puzzle game. You play as a detective sorting through evidence and slowly unraveling a larger mystery from what seemed to be a string of unrelated crimes.

The theme of the game jam was “uncanny/absurd” and with that me and my teammate went brainstorming. With a whiteboard and a free evening we went brainstorming, first writing down any ideas we had then refining the ones we liked best. After hours of discussion and a bit of arguing later we had settled on the basic gameplay loop and story.

After a good night's sleep, we got to work to actually implement our ideas. My teammate worked on the visual assets while I worked to implement the mechanics in the Godot engine. Up until this point, my only experience with Godot was making my game Kinetic Battery, a 3D movement-shooter, so creating a 2D point and click game was going to be a bit of a challenge. But, there was enough transferable knowledge that a bit of reading of the Godot docs was enough for me to set off and start coding up the game.

This game jam is where I learned that implementing the features of a game is pretty quick and easy, at least compared to the time and effort you’ll have to spend debugging. I had to sacrifice features because we didn’t have the time to fix them. This also led to me learning how to decide on which things to keep and which to abandon.

I had left too little time to debug so after frantically fixing all the bugs, we had even less time to properly test. This led to many bugs and issues falling through the cracks undetected. This also led to a panicked submission where I left out an important file. Thankfully the organizers let me fix it.

It was during the brainstorming process for this project that the reason for and beauty of brainstorming became apparent to me. Honestly, everything that followed could’ve been better. Time for testing and debugging should’ve been a day rather than an hour or two. And during implementation, I should’ve rushed for a barebones prototype rather than spend time implementing features that weren’t crucial. After a bit of playtesting after submission, I also realized the game should’ve been testing across multiple screen and window resolutions. While there were many places to improve, I had a lot of fun and learned things that I went on to improve on during my next projects.