Sol::Stuff

Sol's "rules" for surviving Ludum Dare 48h

Here's some of my "ground rules" I try to follow when attending the ludum dare 48 hour game design contest.

"If you obey all the rules you miss all the fun." -- Katharine Hepburn

1 Before the contest

Couple base rules on what you should definitely do before the contest.

1.1 Make sure you have time.

If you have lots of responsibilities, have to go someplace, it's your birthday, wedding, or some other reason why you can't allocate good 12 hours a day to the contest, it's probably better to skip the contest. Don't worry, there'll be other contests.

1.2 Prepare your tools

Make sure your development environment is working, and you have all the libraries you're planning to use. (Note that the contest rules make some limitations on the tools and libraries that you can use - make sure you follow those!).

This not only includes the compilation tool chain, but also graphics and audio! If you want to have sound effects, make sure you have a microphone or sound synthesizers installed and tested that they work. Same goes for music making tools, if applicable.

1.3 What to buy before the contest

Groceries! Especially if you live far from the store. Buy a lot of stuff to drink: no alcohol, some soft drinks, but mostly juices. Always keep something to drink handy when you work, as it keeps your brain awake. Skip fatty snacks, as they tend to make one sleepy.

Some candy is ok, as sugar is brain food. Don't overdo it though.

Consider light foods, like salads, to keep your head clear, but make sure you're not starving. Don't overeat either.

2 As the start is approaching..

Again, a couple of rules for the last few hours before the contest.

2.1 On pre-thinking on the theme

When there's only a handful of themes left in the voting, it's tempting to start planning a game for your favorite (or the most likely) theme. Your chances of choosing the one that's going to be selected are surprisingly small, but don't worry about it: plan ahead. It's much less frustrating than trying to supress your imagination, and might help to have your mind racing when the theme is announced.

2.2 Sleep, for chrissakes!

This is dependent on your timezone, but if the contest start is conveniently placed inside the time frame which the rational people call 'night time', SLEEP! Even if it's 1am, or midnight. You might even consider ignoring it if it happens at 10pm, and just get a good night's sleep before starting. Don't set a waking clock to wake you at crazy hours to check the theme, you can't get sleep afterwards anyway. And don't consider working from 4am onwards either. Sleep is critical. If you're tired (and you will be eventually), your brain won't work and you'll just cause more problems than you fix.

3 The theme, and design

Some thoughts on what to do after the theme is announced.

3.1 The theme

When you find out what the theme is, don't panic. Don't start coding either. Take a walk. Take a shower. Eat. Make your bed. Take the dog out. Doesn't matter, just do something normal. There'll be stuff happening between your ears. Think about different things that come to mind about the theme.

3.2 Design considerations

Couple points about design..

3.2.1 Time's short, design accordingly

Since you will, realistically speaking, have approximately two to three working day's worth time in your hands, you should discard any concepts that depend on time-consuming factors.

Minimize these:

Content. Especially 3d content.

Tweaking. Tweaking complicated physics to be fun kills a lot of time.

Level data. If your game is fun only with smart level design, you're done for.

Anything else that is tedious or time-consuming.

3.2.2 Aim low

Don't be afraid to aim low. You can always crawl upwards by adding little details and tweaking gameplay to be more fun. Gameplay, after all, is more important than flashy graphics. The latter sells games, but the gameplay is what is remembered.

3.2.3 Priorities

Your first priority should be the 'first playable' version. What is the minimal set of features that you need to build? Go for that. Avoid building anything else before you have a game in your hands. If you don't have a game, you don't have anything to submit.

Additionally, getting a playable game running early on will give you a morale boost, which will increase productivity. Keeping the game in playable form at all times after that will let you have something to submit even if something surprising comes up.

Having a build ready early on will also maximize the time you have for tweaking the game.

3.2.4 Do the players 'get it' ?

When you have your playable game, play it for a bit and think whether a new user will 'get it' in about 20 seconds. If not, do something about it. If the voter doesn't 'get' your game in a short timespan, it's likely that they won't play your game for long. Are bad guys easy to spot? What should the player collect? Is that clear? Should you add tutorial? Helpful popup texts? Help pages?

Help pages are easy and fast to do, but tedious to wade through. Interactive tutorials (learn as you play) are more fun, but take time to implement. Consider which way you should go when you're taking the next break.

4 Programming considerations

Couple words about programming style.

4.1 Procedural programming vs OOP

This is mostly for C/C++ programmers; Both OOP and procedural programming styles have their good and bad sides; go with whichever you're more comfortable with.

4.2 On toolkit code

Trust me: you're NOT going to reuse a single line of code you're writing this weekend. So you might as well forget building swiss army knives and only write what you really need. If you don't need to remove things from that container, don't implement removal. If circles and quads never collide in your game, don't write the collision code. Etc.

4.3 Write for clarity, not speed

Modern computers are so fast that you shouldn't need to optimize your ludum dare entry at all. Do not attempt any kind of optimization while you're writing the code, as you'll only end up with:

messy code obscure bugs

Optimizing for readability is much better, as it will save you time when hunting the eventual bugs. Comment things when you do something unobvious. It's easy to forget things even within two days.

4.4 Avoid obscure requirements

To maximize your target audience, try to avoid bleeding edge driver requirements (including .net, latest directx, etc). If you do need the latest and greatest, make it as easy as possible for the user to figure out what's needed and where to get them.

5 General things to keep in mind

Do's and do-nots within the contest.

5.1 SLEEP!

Again, you should sleep. This doesn't depend on your time zone: you should sleep at least 8 hours within the contest limits, between working times. (i.e. sleep-work-sleep-work, not sleep-work-work-work =) Again, this keeps your brain alive.

The time after getting that sleep is different; it's your buffer should some weird things happen, but don't rely on it. If you get your game completely done 10 hours before the contest ends, you've succeeded.

If you think you can save time by not sleeping, you're kidding yourself.

5.2 Drink

Remember to keep something drinkable handy at all times. Drink a lot. Even if it's water. Juices are best, but soft drinks (like cola) are ok. No alcohol or anything else that might mess up with your head. You should be able to down at least 3-4 litres during the contest, possibly much more.

Note that you shouldn't need more caffeine than on normal work days.

5.3 Take breaks

Take frequent breaks. Take a shower at least once within the contest. Take a walk. Take food breaks. If you have to eat at the computer, don't work at the same time. Hang on IRC instead. Also, since you remember to drink every now and then, you should visit the toilet every now and then as well.

5.4 Don't panic

If you don't feel like your game is any fun, don't worry about it. After all, you have plenty of time to test and tweak it within the contest. And even if you don't get it ready, you're learning a lot. Since you've kept breaks, slept enough and kept your brain energized with the juice you've drunk, you've set up ideal environment to learn things.

5.5 Keep time log

It's not only fun, but can help you in catastrophic situations, such as crash that kills off the latest version of your sources.

5.6 Take backups

Every now and then, take backups, preferably to some other computer. This can save your hide if you mess up your code, or if something really bad happens.

5.7 Release early, release often

Give alpha/beta releases for other people to try out. There's people on the irc channel all the time, and many are ready to try things out. Doing this will let you catch strange compatibility problems early on, and to avoid forgetting to place all required DLLs in your package.

6 As the deadline looms

When the deadline is approaching, it's still important not to panic. If things feel confusing, take a break. Even five minutes will do. Get some fresh air, take another shower. Your head keeps working even though you're not looking at the problem. Since it's all your code, you should be able to figure out the problem, but banging your head to the keyboard won't help anything.

The most important bit is not to give up.

Remember to leave some time for packaging and final testing.

7 Afterwards

After good night's sleep (or a couple), think back and write a postmortem. Try to learn about it. If you find that you're writing the following kind of comments, you haven't followed these rules:

"Slept too much"

"Took too many breaks"

"Wasted time setting up the environment"

"Aimed too high"

"Spent far too much time hunting bugs"

However badly (or well) things went, you've learned a lot, and next time will be much easier.

See you at ludum dare!

Comments are appreciated.