Game Jams

I’ve been getting into game development in the last six months or so. I’ve been playing video games my entire life and, once I learned programming, I thought it would be fun to build one myself.

I’ve been working on a more complex, “real” game (coming soon…) for a few months now, but it’s mainly a playground for learning and experimenting with game dev. As someone new to game dev without any real experience, I have no idea when that game will be done. It’s kind of a blue sky idea where the end result can be as little or as much content as I’d like to include, which is great for learning but not so great in terms of releasing a product I would consider finished.

So, I thought a game jam would be cool, specifically the Ludum Dare jam. I participated in the more casual jam side (rather than the more strict competition) where it’s mainly about having fun rather than trying to compete with other developers and their games. I had 72 hours to come up with a game based on the theme “Deeper and deeper.” There are usually around 40 possible themes that the community can vote for, and the winning theme is announced at the beginning of the jam. This theme was one of the seemingly more difficult ones to match well with a game, at least given my amateur skills and the time constraints, so I opted to only follow it loosely, rather than basing the game’s mechanics on it directly.

Gaucho Reloaded

I’m a big fan of the band Steely Dan, so the first idea I had was to go “deeper and deeper” into their music. I’ve also been thinking about a pizza delivery game for a while, so I combined the two: deliver pizzas to make money to buy Steely Dan records.

The game is divided into two parts. First, the “arena,” where the player throws pizzas at moving targets:

Then, after making some money by delivering pizzas, the player heads to the record store to buy Steely Dan wax:

72…ish Hours

The jam started at 2am Berlin time on Saturday morning, so I opted to skip the very beginning, in favor of getting a normal night’s sleep and starting work in the morning. I put in 10-12 hour days on Saturday, Sunday, and Monday.

I ended up not fully finishing within the 72-hour period. After completing 10 to 12 hours of work on Saturday, Sunday, and Monday, by 9pm Monday evening I was toast and opted to finish the next day. In the strict competition they offer a single additional hour for packaging and uploading your game, but I ended up needing a full additional day to fix bugs that weren’t present during the development stage but showed up in the exporting process, and then compile the whole app in the proper way for others to download and play. If I was going to participate in the competitive aspect of the jam I’d make sure to dial in a process for these technical aspects well in advance.

For Next Time

My biggest takeaway was that developing a game during a game jam is about as related to normal game development as competitive programming is to normal software development. If you want to have a decent, halfway enjoyable game done in 72 (or even 48!) hours I think you’d have to throw most “best practices” for normal, sustainable development into the trash.

For starters: I would spend more time up front designing the game itself. I did spend some pen-and-paper time at the beginning designing the game and came up with the idea of running through a neighborhood and delivering pizzas to houses and apartment buildings. I implemented quite a bit of this, including modeling various houses and buildings and coding up a system to build procedural neighborhoods on a grid. This idea proved a little (or a lot) too complex for a 3-day project and I pivoted to the more straightforward and homogenous space prison design. Next time, instead of starting with someone complex and spending time on it, only to strip it down later, I’ll come up with a simpler idea at the beginning and make it more complex if time permits.

One thing that did work well was having the levels increase in difficulty, and giving each individual target or obstacle a form based on the current level. For example, in level 1 the tower obstacle is stationary, and in the later levels it moves vertically at increasingly greater speeds.

This is pretty common in video games. A game like Zelda might implement a basic single enemy and then create variations with color or animation to produce multiple versions. One example is the Bokoblin enemies from Breath of the Wild:

Adjustments like this are relatively straightforward to reason about once you have the basic idea for an obstacle or object in your head. Creating the base and then adding speed or variation, as the difficulty increases, can allow you to reuse the same art and code relatively easily while still giving the player something new to interact with as they progress through the game.

Overall

Game jams are fun! The theme and the time constraints take away a few of the obstacles you face in blue sky game development, and it’s fun to take a coffee break and check in on the jam’s hashtag to see what other developers are doing and what progress they’re making.

The next Ludum Dare is in October and I will definitely be participating!