Ludum Dare for Pragmatists

A Ludum Dare Survival Guide

This is not going to be one of those survival guides that advises you to stock up on caffeinated energy drinks and pizza. It’s more of a pragmatic set of guidelines from someone who loves taking part in Ludum Dare and is still learning what works and what doesn’t. As with all advice, you are free to use it however you like, so please don’t follow it blindly. Do what works for you.

Preparation

During the challenge weekend you will want to spend as much time as possible working on your game. To be able to do that, you need to take time beforehand to smooth out all of the glitches that might occur. The key to that is to minimize all of the distractions that prevent you from being able to focus. These take several forms, including:

• demands on your time from family and friends not knowing that you’re busy
• installing a piece of software for the first time
• not knowing how to use your tools
• poorly matched tools
• tiredness

Clear your Calendar

If taking part in Ludum Dare is important to you (and I hope that it is) then you need to make sure that the important people in your life are aware of it.

If you have a spouse, or children, or anyone else who is normally reliant on your presence over the weekend, then spell it out to them well in advance that you’ll be chained to a computer for most of your waking hours. If you share a calendar with them, then book the time in that calendar, otherwise you could find that your weekend has been taken over by a visit from the in-laws.

If you have a job, and you live in a time-zone where the challenge ends after midnight, then be sensible and take the next day off. Theoretically it is possible to go to bed at 2am and get up at 6am, but it isn’t worth it. You’ll be useless at work and your colleagues won’t thank you for it.

Know your Tools

Ludum Dare has a habit of sneaking up on you. One minute, it’s Christmas and the next Ludum Dare isn’t due until April, then, before you know it, there are only 2 weekends to go and you haven’t a clue which toolset you’ll use.

So do yourself a favour and figure out as early as possible which tools you will use. Doing this up front will mitigate issues caused by lack of familiarity. It will also give you time to sort out any “impedance mismatch” between tools. For example, it is no good having the world’s best paint program if it takes ages to convert the files to a format that your game engine can use.

It is very important that you know how to use the tools that you’ll be using. Master those that you’ll be using the most, so you can establish a good workflow. If you still don’t know how to use your tools by the time of the Ludum Dare weekend then you will be slowed down significantly because of the mental drag that occurs when you’re trying to learn a new tool. Sure, other people may have used Whizzbang 2011 during the last challenge, but they most likely did so by taking time to learn the toolset, not by figuring it all out on the day.

Test your Tools

About a week before the challenge starts you should also take time to ensure that all of your tools are up to date and installed correctly. This obviously includes things like your favourite game engine or framework, IDE, editor, compiler, paint program and sound generator, but there are other things that are too easy to overlook. For example, when you finish writing your game then you’ll want to upload it somewhere. If you haven’t already sorted that out then do so before the challenge weekend and, for goodness sake, have a trial run. Current Ludum Dare rules allow for an extra hour after the challenge closes to upload, but this is something that you want to be able to do without thinking.

Do you know how to upload your game? Is it easy for other people to download it?

During the Contest

You’re mostly on your own here. My one suggestion is that unless you already have a fantastic idea, and even if you do, then you should take a couple of hours to sit down with a pen and notebook to figure out how your game is going to work. There’s nothing worse than being half way into the contest weekend, mired in several hundred lines of code, only to discover that the game will never work because of some fatal flaw that you should have seen 24 hours earlier.

Having done that, write down some features and plan when you’re going to do them. Figure out which ones are high priority and do those first. Give yourself a timeline for each feature, as that will help you to focus on delivery.

In short, treat the whole thing like a job and apply yourself to it, but don’t kill yourself by overdoing it.

Getting People to Review your Game

I fully admit that I don’t have a good answer to this, but the one thing that I can say is that Ludum Dare appears to be getting bigger. LD15 had around 140 entrants. The current LD19 had over 240 finished games, with 3 weeks for judging.

At the time of writing, there are just over 11 days to go before the judging for Ludum Dare 19 ends. In the last 10 days I’ve reviewed about 53 games, which puts me a little over a fifth of the way through. If I keep up the same rate for the next 11 days then I’ll have played less than half the games.

I could just go through the list of games in order, and I certainly did that for the first 20, but at some point I’m probably going to pick those that catch my eye. And of those, I’m most likely to play those that make it easy for me to start playing right away.

I think there are two rules here:

1. Provide a compelling reason for people to review your game.
2. Make it easy for them to play it.

Screenshots and Names

I’m rapidly beginning to understand the importance of a good screenshot and, to a lesser extent, a good name. My own game, Eureka! Vaults of Knowledge, is burdened with having a poor screenshot and a dreadful name.

Given the two preview screenshots below, which one are you going to click on? I know which I’d be clicking on, and it’s not mine.

The screenshot on the left, from spacsm’s game Eureka!, attracts attention. It also works very well when shrunk down to 120 x 90 pixels, because it is still possible to see what is going on.

The screenshot on the right, from my game, Eureka! Vaults of Knowledge, shows a bunch of indistinct green blobs and a red line. It is almost impossible to figure out what is going on and frankly it looks dull.

The annoying thing is that the game plays quite well, but it doesn’t stand out from the crowd, so what reason does anyone have to click on it?

If it could be Web Playable then it should be Web Playable

A large percentage of games submitted to Ludum Dare can now be played over in a browser. If you are developing for a runtime that allows your game to run in a browser then make that your primary platform, because it means that the reviewer doesn’t have to download anything else to play your game, other than the plug-in for the runtime if they don’t already have it installed.

If you are using HTML5 / JavaScript, Flash or Silverlight then your job is done already. If you are using Processing or Unity then it is very simple to make your game run in a browser, and Java isn’t too far behind if you know what you’re doing.

Provide an Executable

If your game is downloadable then you really must provide an executable. I like Python and pyglet as much as anyone, but I have limited time and would rather spend it reviewing your game than fiddling around trying to figure out the dependencies. As for anyone who doesn’t have experience … forget it, because they’re not going to know where to start unless you spell it out.

Provide links to the Prerequisites

Ideally your downloadable game should be self-contained, but often games have dependencies. If your game relies on something that may not be installed by everyone, such as the .NET framework, or the redistributable runtime used by Visual Studio 2010, then please provide links to those dependencies, but don’t include them in your download.

Ask yourself, “Does it really need XNA 4.0?”

A few games that I’ve tried to play just won’t run on my review laptop. This is a new laptop, but it has Intel GMA graphics. The sad thing is that the games in question don’t look like they do anything spectacular in terms of graphics, so why insist on Shader Model 3?

Name it Uniquely

If your game is downloadable, then please give it a unique name. The name ld19.exe will be unique on your system until the point that you download everyone else’s game with the same name. I’d also suggest packaging one level down from root when you create your zip file, as that also makes the reviewer’s life a lot easier. And no, you shouldn’t call the file ld19.zip either!

Conclusion

These are not hard and fast rules. They’re just my take on how to prepare yourself for Ludum Dare, and how to make sure that it is easy for everyone else to review your game. If you have any tips on this then please share them in the comments.