The Ludum Dare Experience:
The Melancholy Middle

This weekend I participated in Ludum Dare 27, a programming competition in which competitors create a game in a weekend. I made a game, had fun, and learned a lot. In this series of three articles I reflect on my experiences before, during, and after the competition, looking for lessons to apply to other kinds of projects.

I learned this weekend that a 48-hour project is a faithful microcosm—a diorama—of a 3-year game project. I was struck by how many classic features of game development are preserved in this dilation. The high-energy, optimistic initial phase. The grueling, pessimistic middle phase. And the steady, realistic ending phase. You inevitably live them all whether you’re making a game in a weekend or through the better part of an Olympiad.

Although the Ludum Dare competition is limited to 48 hours, in my time zone it takes place over the course of three days. Beginning on Friday night, I conceived and designed my game with great enthusiasm and began the implementation. Sunday’s work, too, would prove enjoyable. It was the middle day—Saturday—that became a long, worrying crunch, the Empire Strikes Back of the experience.

Sleeplessness

The first problem was lack of sleep. On Friday night I worked until 6 AM, yet on Saturday morning I couldn’t keep myself asleep, and got up about 8 AM. All my work on Saturday would be undertaken with at least a little mist in the brain, which sometimes thickened into a fog.

Games are Complicated

My next problem was the sheer number of tasks. A full, complete game is a complicated thing: the game world itself with its objects and rules; the user interface enabling the player to exert control; and the menu-heavy front end with its buttons and icons and text. By the end of the project, my running list consisted of 25 substantial, distinct tasks. Examples:

• Playback/scrub controls
• Victory screen
• Parallaxing background
• Character portraits on HUD
• Title/logo artwork
• Random level generation

Some of these are even more extensive than they sound: I created two different versions of the game logo, for example, before settling on the third.

There was simply a lot to do, and I really didn’t know whether I could actually finish.

I also had other priorities. Unlike some of the contestants (most, I suspect), I’m a family man. My time is not always my own. I spent some of Saturday morning just hanging out with the wife and the kids. That night we went out for a special family meal. I wanted to get the project done, but it wasn’t my only responsibility. So as I worked I was mindful that this long list of tasks would have to get done with some long breaks and gaps.

By the end of the 48-hour competition I had spent thirty hours in total actually building the game. I slept 10 hours: 2 on Saturday morning and 8 on Saturday night. The other eight hours were spent doing other things that couldn’t be sacrificed.

The Exposure of Invention

Along with the fear that I wouldn’t finish the game was a fear that it just wouldn’t work. Not just that it wouldn’t work technically, but that the gameplay would prove unsatisfying.

One of my goals was to create an innovative gameplay concept. The physics/time-travel approach I had picked seemed to fit that bill. But one of the risks of innovation is that the idea may turn out to be dumb. The game might work functionally but offer no sense of challenge or fun to the player.

This risk was particularly acute with this concept because I elected to randomize the levels. Doing so allowed me to avoid spending time designing levels, but it put the burden on creating a level randomization system that would generate fun challenges. There was a serious risk that the system would never pan out: that levels would be continually too hard, too easy, or too confusing to entertain players.

There was an even more fundamental problem. My hope from the start was that the intersection of physics and time control would create a venue for exploring causation. This makes it sound boring, but I believed the game’s structure would generate fun. How? I saw it working like this.

1. The player sees a friendly character die. The death is caused by an incoming asteroid. This creates a goal: stop the asteroid.
2. The player investigates by moving around in time and space. Where did the asteroid come from? What caused it to veer toward the character?
3. In some cases the asteroid hit the character without help. In other cases the player would find that another asteroid had caused the killer asteroid to hone in on the character. We now have a chain of causation with more than one link.
4. The player keeps tracing the chain back through the series of asteroid collisions to its start.
5. Having diagnosed the sequence of events that led to the character’s death, the player then decides on a strategy for preventing the death by breaking one link in the chain. This is accomplished by applying quite limited forces to asteroids so that the sequence of events plays out differently.

For whatever reason, this model of play sounded fun to me. But “whatever reason” doesn’t amount to much. Would the game sound fun to others? Would it be fun to others?

There was a serious risk that I would finish a game no one would love.

Serenading a Statue

Another concerned nagged at me as I coded through that Saturday. What if I finished the game, and it turned out fun, but no one happened to notice it?

Ludum Dare started small but has grown into a large event. At the end of this weekend’s competition there were over 1,500 entries. Now imagine trying to get noticed in a crowd the size of a high school football game—a crowd consisting only of people who are also trying to get noticed.

Would people actually play my game? Would it stand out at all?

In a way this was my darkest fear because it was the one I had the least control over. Would the game be great? That was up to me. Would anyone notice? That was out of my hands.

The Bright Side

Despite these fears, Saturday’s work remained enjoyable and satisfying. I was surprised at how well my mind held up after only two hours of sleep. I was able to code without serious slips or defects almost all day and late into the night.

Through the whole project I only encountered four or five bugs of any real substance—bugs that required careful stepping through code or littering functions with trace messages. Only two bugs—one on Saturday and one on Sunday—took longer than 10 minutes to fix. The vast majority of the time was spent getting value into the game. Indeed, one of my largest “lessons learned” (which I will cover in another, more technical, post) was how various aspects of my programming environment through the competition—the use of Flash Professional and a decent scripting language, for example—made me much more fluent as a programmer than my usual environment does.

Finally, my fears about the gameplay were eased on Saturday night when I noticed I was actually enjoying the game myself. I had to stop myself playing it while debugging or testing. I let my teenage son play it and he thought it held promise. I began to think the game would turn out cool.