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 have long been attracted to the idea of creating a game in a weekend. In large-scale (AAA) game development, the 3+ year game cycles often feel unbearably long. For the creative people who fill this industry, these marathon projects can be worse than stifling: they crush the soul. What’s more, long projects do a poor job at educating developers. A “veteran” developer will have shipped a few games but it may take a decade to have seen two or three full game cycles. Since many of the lessons that make a rookie into a veteran take place in the fevered finale of a project, developers have few chances to live through these experiences and level up their perspective and skills. Quick “practice” projects, I reasoned, could provide a crucible for experimentation, mistake-making, and learning as well as a creative outlet. Yet as full-time game developers, we seldom have the time or energy to burn a whole weekend doing more of what often exhausts us during the week. So I’ve never tried a game development contest.
In recent years I’ve focused on mobile and casual game development where teams are smaller and schedules are shorter and more humane. I’ve made shipping games in as little as two weeks; I’ve made rough prototypes for games in an evening or a weekend. But until Ludum Dare 27 I had never made a whole, fleshed-out, (mostly) polished game in two days.
I first heard about Ludum Dare from a former game programming student of mine who had participated. I was intrigued, but it took me almost a year to sync up my schedule to actually do one. I heard about this weekend’s Ludum Dare just a few days before it happened. It didn’t come at the best time but I resolved to take it on. I’m glad I did.
The idea in Ludum Dare is that you make the entire game, from scratch, within the allotted 48 hours. To discourage people from starting early, they announce a “theme” for the contest at the kick-off time. Contestants vote on various theme options in the days leading up to the event and the most popular theme is selected. For this particular Ludum Dare event the theme was “10 seconds.” I was pleased about this as it was one of the options I had upvoted, and favored it—probably like many others—because it seems to narrow the scope of the challenge. A game called “10 seconds” would surely be easier to create in a weekend than one called “10 hours” or even “10 minutes.”
As the competition started I felt a little nervous and a lot of anticipation. I’ve been a professional game developer for nearly twenty years, so you’d think if anyone had a reason to be confident it would be me. But I also know game development. I know how chaotic and unpredictable it can be and how the best laid plans may go awry. There was every chance I would fail to finish my project. I might submit something finished but lame. And as I started the contest I had no idea what I was even going to make: only that I would make it in Adobe Flash and that I might use the Box2D physics engine. What’s more, I haven’t worked in Adobe Flash for 3 or 4 years and I knew I was rusty. So there was some nervousness. I could fall on my face.
But the thrill of possibility was even stronger. The beginning of a game is a blessed moment. There’s nothing I enjoy more than pulling together limiting constraints and liberating opportunities and dreaming up something that is both realistic and surprising. As soon as the theme was announced I started planning.
I began, as is my habit, by identifying my goals. I wrote in my planning document (a text file in Sublime Text, actually):
- Get it done on time.
- Extremely fun.
- Fits the theme.
- Complete (sound, front end, etc.)
- Surprising, innovative, different.
There’s a priority sequence here. I would sacrifice fun (goal #2) if necessary to get the game done on time (goal #1). I would work the game to fit the “10 seconds” theme (goal #3), but if the theme threatened fun, fun would trump theme. As it happened, goal #4 probably lost the most attention: the lack of sound effects is the game’s most obvious gap.
Goals established, I sketched out a brief, coarse schedule: I like to have a measure by which to judge my progress. Then I started brainstorming: what kinds of games would fit the theme? From my notes:
- Could I make a game that actually takes 10 seconds? Replayability would clearly be of the essence. Interesting but sounds difficult.
- Time compression games strikes me as rich. The whole “event” takes 10 seconds, and it’s your job to sort it out. A play round takes longer than 10 seconds, though, because you can slow, maybe pause, maybe freeze, maybe reverse time.
- Of course another approach is more WarioWare like: the game as such takes more than 10 seconds, but each “level” takes exactly 10 seconds.
- Music has another interesting intersection here. 10 beats? Along with time compression?
That gave me some general structure, but what about some concrete ideas? I brainstormed.
Things that take 10 seconds. A car crash. A soccer goal. A ping-pong volley. Asking someone to marry you. Getting into and starting a car. A slow, deep breath. A leaf falling to the ground. A brain aneuryism. Death from a very strong poison. That Reliant K song. Lighting a cigarette. Putting on lipstick. Solving an arithmetic problem. Giving your full address. Softening butter in the microwave. Being snatched by an alien. Going from fully asleep to somewhat awake.
Some of these images seemed suggestive but none of them grabbed me by the shirt.
I then sketched out my first concept.
I set up a large, multi-body crash. (Box2DAS, everything’s a circle.) Certain elements are “to be saved”. Others are “to die.” Most are neutral. The player’s task: (1) find the crucial pieces; (2) slow down, scrub time to find the crucial moments; (3) apply limited force to adjust the simulation, saving the innocents (i.e. removing them from large collisions) and killing the evil ones. Probably top-down, but with faces showing. Or just symbolic objects (not people)?
The technical question hinges on whether we can create a randomized (?) situation that is uniformly solvable. Given enough total force for the player and enough opportunities to apply it, the player can solve anything. The question is whether the total force or number of opportunities can be tuned downward enough to keep it always-solvable, yet difficult (in later levels).
Of course, hand-creating levels resolves this problem at the cost of (1) finite levels and (2) time spent designing them.
This idea had some appeal. But I’m a believer in exploring one’s options, especially in creative matters, so I sketched out four other concepts: a high-speed RPG, a microcosmic Roguelike, a corewars code-cracking game, and an FTL-like space battle game called “Targeting Computers”. In the end, I went with the first idea.
In total this initial ideation phase took about two hours—a fairly heavy expense in a 48-hour project. I ended up settling on what I initially called “Crash!”, which became Spacetime Adventure. And although I threw away several other ideas, the whole process was necessary and well worth it: even the rejected concepts helped me to understand the nature of the theme and some of the difficulties I would be facing.
Before I fully committed to this concept I wanted to verify that it was viable. This would be a physics game; did the Flash version of Box2D have the performance to simulate the large number of objects that it would require? The concept hinged on the idea of recording the entire simulation for every frame that passed, thirty times a second. How much memory would that take? Would it cause performance hitches?
I spent the next couple of hours testing the feasibility of the concept. I dusted off my rickety ActionScript skills. I learned Box2D, which I had never used before. Then I worked from Box2D’s tutorial project to build an initial performance test. This soon convinced me that I could simulate up to 400 objects—plenty for my purposes—at full frame rate on my target platforms. That was one-half of the feasibility question answered. (All the source code is available online.)
Maybe reload the page if this is blank. The objects may have already flown off screen.
I next wrote the system (called WorldRecording in the source) that records and plays back what happens in the game. This is perhaps easier than it sounds. On each frame you visit every object, ask its position, velocity, rotation, and angular velocity and store them in a memento. To play it back, you simply recall this information. The recording consumes a fair amount of memory but my measurements showed it cost no more than a megabyte per second. Since the simulation was limited to 10 seconds (thank you, heavily constraining theme!), the whole recording would hardly break the bank.
Use space to pause and play. Use the +/= and -/_ keys to step forward and backward, holding shift to move faster.
At this point—it was 1 AM on Saturday, 5 hours into the competition—I was confident the game could be made. The only big question left was how it would look. So far the game objects were abstract physical bodies—just circular lines. What should they look like? What was the “story”? I set about brainstorming again.
Planets, possibly with cities for “moral/personal” quality
Little round people
Space ships + planets, asteroids, etc.
Guys in office chairs
Cars in a smash up
Cars and people
Little doodle bugs
Numbers and letters
Magical glowy orbs
Space people + planets, asteroids, etc.
You see from that list that I wanted, if possible, to find something with “moral/personal” quality. I meant by this that if the game was about rescuing and destroying impersonal things like billiard balls or planets the player would be left with a cold, detached feeling. I wanted faces on the “objects”—something you could relate to. When I reflected on the list, the idea that merged two other concepts—“little round people” and “planets”—stood out.
By 2 AM I was starting to lose focus but I was too excited to stop. I switched over from programming to Photoshop and worked on artwork until 4 AM. After that I caught a second wind and programmed again until six.
So far the project had gone swimmingly. I had taken a fairly risky approach, relying on ambitious physics and time-manipulation features, and so far the risks had paid off. It was an exciting start. But the next 24 hours wouldn’t remain so bright. Discover why in the next post.