A small team of Atoms recently participated in the 45th iteration of the Ludum Dare game jam. Ludum Dare is a semiannual game development jam where participants have 72 hours to create a video game based on a theme. The theme for this jam was “Start with Nothing,” and the game that we made is called Dead Again.
This was only our second game jam as a team; the first was Ludum Dare 44, where we created Root Maker. In fact, most of our team hadn’t really done any game development before the last Ludum Dare. Now that we had two events under our belt, I wanted to put together some thoughts about Ludum Dare and the tools we used.
Don’t Let the Theme Paralyze You
It’s easy to feel like your game has to perfectly match the theme for a game jam, especially if it’s your first time. This can lead to spending valuable hours trying to come up with a creative or unique take on the theme. It’s certainly worthwhile to spend time doing this. The key, though, is not to let it paralyze you and prevent you from starting. If you find yourself taking more than a few hours to come up with a game idea, it’s often best to just take an idea that fits with the theme and run with it.
In most game jams, Ludum Dare included, the theme is just one category. In this kind of a time-sensitive environment, you don’t need a perfect idea. As long as your idea makes sense with the theme, it’s often easier to come up with more interesting or unique mechanics after your basic gameplay loop is laid out. Even if you don’t find a unique twist that sets your game apart, that’s fine. You’ll still be able to spend more time working on your core mechanics. As most jam results show, a fun, polished, and complete game is the best way to get a good score. It also gives you the satisfaction of finishing something–an invaluable lesson that you never experience if your games fail to leave the concept phase.
Experience Matters
When our team participated in Ludum Dare 44 last April, we had a disadvantage going in. Not only had we never done a game jam before, but most people on our team had never done any game development. Fortunately, we decided to use a framework called Phaser that allowed us to work in TypeScript. We use TypeScript every day as software developers, and this familiarity made our lack of experience with game development much less of a hindrance.
For this Ludum Dare, though, it felt like we were able to hit the ground running a lot faster because of our previous experience. While game development isn’t a hobby most of us actively pursue outside of game jams, even a small amount of familiarity is a big help. We didn’t end up using Phaser for this jam, but it was still a lot easier for us to pick up new technologies because of prior experience.
An Engine Makes a Big Difference
Using Phaser for our last game jam was a great choice for us. Not only were we able to use a language where we were proficient, but we could work entirely in code. We didn’t have to learn an engine and all of the nuances that come with it. Phaser is a very lightweight framework, and it was easy for us to pick it up.
That approach worked perfectly for our first game jam. Now that we had more experience, though, we decided to try our hand at using an actual game engine. We ultimately decided to go with Godot, which felt much more lightweight and simple to use than an engine like Unity. Its node system is flexible and extensible, and it has a quick learning curve. Figuring out how to navigate the UI was significantly less time-consuming than other engines like Unity or Unreal.
Using a game engine made a huge difference. Most of us were using Godot for the first time during the jam, so we moved a lot slower than we potentially could have. Still, even with time accounted for learning Godot, the amount we were able to accomplish was vastly more than we could have done with Phaser.
Frameworks are great, and you can absolutely make as large or complex of a game with them as you can with an engine. The amount of convenience and abstraction the engine provides is a huge advantage, though. This is especially true for a game jam. Not having to worry about setting up our own systems for sprites, animations, and physics saved us valuable time. I’m excited about potentially using Godot in our next Ludum Dare to see how the experience we’ve gained will help us.
A Game Jam is an Excellent Way to Prepare Yourself for Larger Games
I started using Godot for personal projects a few months before we decided to use it for Ludum Dare, and I fell in love with it. At first, most of the games that I worked on were fairly small and not complex. As I started trying to make larger games, I struggled to find good ways to handle some of that complexity. Things like handling game state, changing levels, and creating script utilities were difficult to figure out in Godot. I wanted to do them correctly (to do them the “Godot way”), but it was hard for me to figure out best practices without prior examples.
Fortunately, we had to implement many of these things for our Ludum Dare game. We had to use global scripts and keep track of game state and player stats across different scenes. We came up with some good tactics for architecting scalable ways of handling game state as the game got larger. Getting this firsthand experience was valuable, and I feel much more prepared to work on large or complex games on my own because of it.
Conclusion
Game jams are great events to take up with friends or co-workers. Not only do you get to spend time working together on a project you genuinely enjoy, but you come out of it with a finished game. I’ve loved being involved in both of the Ludum Dare jams that we’ve done as an Atomic team. Our newest game, Dead Again, was especially fun to create. I’m grateful for the experience we all gained working on the game, and I’m excited to put it to use in my own projects. I’d love to hear some of your takeaways from game jams you’ve participated in!