Category: Game Design

As I play and rate Ludum Dare games, I see that games fall into a few groups:

• Highly polished games that feel complete
• Highly polished games that feel incomplete
• Unpolished games that feel complete
• Unpolished games that feel incomplete

By complete, I mean they have all the elements of a game: an objective, conflict, rules, unpredictable outcomes, endings, etc.

By polish, I am referring to the production quality. There’s few bugs, the aesthetics are cohesive, and everything feels balanced when you play it.

So how do you make a highly polished and complete game in 48 hours? What tips and tricks are developers using?

Make It Playable as Fast as Possible

Games are complex systems in action. You can’t design a game well unless you playtest it because it isn’t always obvious how the rules of a game interact. Making something playable early means you have more time to test it as you add, remove, or change mechanics. You also have time to make decisions, such as whether to kill planned features or spend time on making the controls feel better.

I’ve found that when I fail to submit a game to a Ludum Dare, it usually coincides with a game that either has no game play or gets the bare minimum of game play added at the very end. I have no time to play and see how the game feels, which means that even if I get it done on time, it’s more likely to be an unpolished and incomplete tech demo.

On the other hand, when I focus on getting something playable early, such as during Ludum Dare #24, it’s a game from the beginning. It might start out unpolished and incomplete, but by the deadline, even if I don’t get all the features I wanted in there and I can identify glaring problems, I have something to submit. For my entry for the theme Evolution, I didn’t get to add the features that take advantage of the theme, but I recall how sluggish the tank felt to move and I spent a little time tweaking it until it felt better to play. When you killed the enemies, I had points float up above their heads. I’m not saying it was a beautiful game, but it was more polished than most of my entries have been. And it didn’t have everything I wanted in it, but what was in it felt complete.

Ideally, your work in progress will be easy to deploy to other people so they can play test it and give you feedback. You might think the game is fine, but you’ve been immersed in it for hours and might miss how difficult it is for someone who hasn’t seen it before. Your game is ultimately for other people to play, so their feedback is very important.

Know Your Tools

If someone gave you a complex tool you’ve never seen before, you’d probably muddle through how to use it, but it would be slow and painful.

On the other hand, if you were given a tool you’re familiar with, you no longer need to worry about how to use it as it is almost second-nature. You can focus on the task in front of you instead of focusing on how to use the tool.

Years ago, I struggled with making programmer art in GIMP. I wrote code. I didn’t art.

Partly from learning during previous Ludum Dare compos, partly from talking with artists about their workflow, and partly from practicing outside of compos for my own projects, I learned how to do things I normally need to do during a game jam. For instance, I use layers, preferably named ones, to make it easier to create a complex image. I know how to scale images and layers with fewer artifacts. I know how to use an alpha selection to get an online of an image, and I can grow and shrink selections so I can create a silhouette or a border. I even learned common shortcut keys so I can quickly switch from the Pencil tool, the Bucket Fill tool, the Rectangle Selection tool, and the Ellipse Selection Tool, which saves me time.

I remember reading the manual for Applesoft BASIC and learning that instead of typing out:

PRINT “HELLO, WORLD!”

you could type out:

? “HELLO, WORLD!”

And that question mark would automatically get turned into the PRINT command. The manual mentioned that it saved four keystrokes and time. At the time I wondered how much time it could possibly save, but since I was typing PRINT almost all the time, I realized that it added up.

Today, knowing your IDE’s shortcuts similarly helps. As my friend Chris Freeman said in his presentation on refactoring, tools reduce cognitive load. Instead of using the mouse to hunt and click on everything in menus, you ideally should be able to unconsciously move your fingers to the right key combinations to make things happen. It’s like learning how to ride a bike or drive a car. Once you get the hang of it, you no longer focus on where your feet are. When you want to move forward, your feet automatically know what to do.

During a game jam, you don’t want to spend time reading a manual or searching online for help. You want to just DO things that move the game forward.

For my first Ludum Dare, I was learning how to use libSDL, and luckily I kept the scope of the game down because I knew I wasn’t going to be able to do very much. I spent a lot of my time figuring out what SDL provided and how to write code to take advantage of it.

For the latest Ludum Dare, I was often very pleased with how even major code changes compiled on the first try. I was much more familiar with the language and with the interface of my tools such as Vim and Gimp.

Come up with a Plan

You’re two hours into a 48 hour compo. What are you working on now?

With only two days of development, it might feel like you don’t have time to plan. Every moment not working on game development is a lost opportunity.

But planning saves time, and it doesn’t even have to be very complicated to be effective. There’s no need to create a Gantt chart for your project.

Some game developers create entire detailed design documents to keep their thoughts organized, and other developers use nothing more than a list of planned features that they cross off as they get implemented.

But what about time?

You could work on one thing at a time until it is all done, but the risk is that the later items don’t get done at all. What you don’t want is to find yourself with an hour left and realizing that you forgot to implement a way to end the game or that your game is completely silent.

Some people try to get a good chunk of the game done early so that the rest of the compo is spent on balancing and adding polish. Some developers set aside blocks of time, such as a couple of hours, to creating sound effects.

Other people understand that their energy levels are going to be different throughout the day, and when they are too exhausted from programming, they can switch hats to creating graphics or music. Einstein actively relaxed by playing the violin, and you could do worse than emulate him.

No matter how you plan your two days, having that plan gives you more insight into what to do at any given moment so that you have the best chance of submitting a finished game.

Your Tips?

I’m not saying I’m an expert, and I still feel like I’m learning how to pace myself and put together something. But after participating in 10+ Ludum Dare game compos and a handful of other game jams, I think I’ve gotten some worthwhile experience to share.

I should probably invest in The Game Jam Survival Guide by Christer “McFunkypants” Kaitila.

What are your strategies when participating in a game jam? How do you ensure your game is complete and polished before the submission deadline?