“Ludum Dare” (pronounced dah-reh) literally means “To give a game”. It is a quarterly competition that attracts thousands of participants from all over the world. The rules are simple: each contestant is given a theme and has just 48 hours to develop a game from scratch. You are not allowed to use existing assets such as graphics, music or special effects and you must work alone.
It may seem that 48 hours is not a lot of time to make a game and it’s true. But this year 1,201 contestants managed to do just that. Most of the completed games were original and fun to play. Some of them even had nice graphics and a good soundtrack.
Even though I have very little game making experience this year I finally plucked up the courage and decided to give it a go. It was more fun than I thought it would be. I managed to accomplish my personal goal of making something shippable in 48 hours and along the way I learned some things that I thought I would share here.
ADVICE NUMBER ONE: HAVE A PLAN
Before the competition starts you can lookup what the 20 possible themes are. Sit down and go through each of them before the competition. Try to have a general idea of how the game would work for most of the themes. A general idea is enough, once the theme has been announced you can refine the game mechanics.
When the competition starts, first write down your concept or use drawings or a mind-map: whatever you prefer. Once you have it written down don’t rush out and start coding immediately. Take some time to evaluate your concept. Ask yourself:
- Is it fun enough?
- Is it original?
- Do I have enough time?
- Do I know how to implement it?
Then modify your concept accordingly. Don’t wait till you’ve wasted precious hours to eliminate a feature. Don’t put yourself into a position where you’ll have to change your game logic to accommodate a new element in game mechanics. You cannot afford evolutionary design here! The incremental bits are level design, backgrounds, music and small details, but not the core mechanics of the game.
When planning the effort, you should be certain that you can finish the core mechanics in the first day. Think about the amusement to effort ratio. Avoid things like animated humanoid characters or long branching stories. Even though these elements are commonplace in many games, they all require a lot of effort and don’t provide a “wow” factor anymore. Also tailor the game mechanics to what you know and limit the new things that you have to learn.
Once you have the core mechanics game concept it’s time to start planning the optional tasks. These are game menus, graphics, backgrounds, SFX, music etc. Write down your ideas and sort them according to priority. Being specific here like “Draw a tree for the background”, “Make SFX for explosions” puts you in a better position to understand how important the task is and how long it will take. But also feel free to put more vague placeholders like “improve background”. In any case, don’t waste too much on this list because it will evolve over time: you will be removing, adding and re-sorting these tasks.
Overall the initial planning should take between half an hour and a couple of hours. If you haven’t spent at least half an hour, you haven’t thought things through well enough. If you’re spending more than two hours, you’ve either included too many tasks or you’re going too much into details.
ADVICE NUMBER TWO: KNOW YOUR TOOLS
Before the competition you should have already decided what framework you are going to use. A lot of people decide to try out a new framework, programming language or 3D modelling software. If you want to try a new tool, spend a day or two getting familiar with it beforehand. You should be able to make a minimalistic game in your chosen tool before the competition.
Unlike large software projects, during a 48 hour competition there is no management strategy that will overweight the impact of your skills and familiarity with the tools. When it comes to game making, you’re the one deciding what the game will be, so you’re allowed to tailor the game to your tools and capabilities. If you’re not talented at drawing, make the game abstract. If your framework doesn’t include physics simulation, don’t try to write it yourself.
For such a short competition automated testing is out of the question. First of all because testing games is difficult unless you have a turn based game. Secondly, you’re supposed to be writing new code most of the time and doing very little refactoring that could break existing logic. As a consequence testing your code once should be enough.
While you develop it is good practice to create a test level that will allow you to quickly test the behaviour of your game without having to run through the whole game. Also when it comes to testing levels, you can temporarily use cheats, but just be careful that the cheats don’t make it possible to complete a level that would otherwise be impossible to complete.
It is very easy to fall into the perfectionism trap, especially with graphics and music. That’s why you have the list of optional tasks. You need to be very careful of time-boxing each task to about one hour. If you don’t complete a task in an hour, put it in the game as it is and put another task in your list to finish what you started. The list is probably longer than what you’ll be able to do. This gives you the flexibility to exclude the less important things instead of the important ones.
It may sound a bit risky, but you should leave the making of each level to among the last tasks. It is better instead to focus first on functions that will make it easier to make your levels or make them more varied. As a rule of thumb, half a day for making the different levels should be more than enough.
One very useful trick to use is deterministic procedural generation. No, you don’t need to collide bosons in a particle accelerator. Procedural generation means that you will write algorithms that generate your game content rather than doing it manually. This is extremely helpful for creating the background, but if you’re good at it you can use algorithms for level design and even music. You should try to make your algorithms deterministic. This means that for a specific input parameter, which is typically a number, an algorithm will always generate the same content. This makes it possible to test the generated content. Alternatively you can generate the content outside of the game and then import it as a fixed asset.
It is also a good practice to keep the procedurally generated content modular. This means that different parts of your level are generated using separate input parameters, so that you can replace only part of a level if you don’t like it.
Making videogames certainly requires a very specific software development approach. Writing a game in 48 hours even more so. It is certainly natural to question the usefulness of entering a 48 hour game making competition for a software engineer who does not make video games in his day job. However, being in such an extreme environment allows one to get a feel on how these conditions affect software development. Many software development practices that we use every day are the consequence of the kind of projects that we work on. This is also the reason why there are so many different schools of thought around software development. A dramatic change in your environment forces you to go back to the fundamental principles that are behind common software practices and understand better how to adapt these practices for particular situations.
If you are interested in trying a new experience by developing a game there are plenty of frameworks and tools you can use and online resources to help you start with. A lot of Ludum Dare competitors live streamed the whole development process and you can get the source code for every game submitted to Ludum Dare. If you want, you can have a look at what I managed to accomplish here.