My First Ludum Dare – Postmortem

Though this was my very first Ludum Dare, and the solo competition at that, I feel like it went really well for me! (My entry can be found here) I ended the weekend happy with my game and with a nice mental tiredness that was not crippling exhaustion. I’m going to write about my process and the things I think helped make this Ludum Dare a pleasant and successful experience…


1. Preparation.

By this I mean knowing your tools and your process and feeling comfortable with them ahead of time. Since I am a professional game designer, some of this was just built-in experience by this point, but I’ve also been recently doing a lot of rapid prototyping at work so I was already in the “make stuff really fast” mindset before the weekend began. I think this just comes with making lots of stuff over time.

2. Rest

Back in grad school I participated in a 48 hour game jam for the XO laptop, and I approached it with the whole “stay awake as long as possible” attitude that I’d done for similar marathons in the past (24 hour comic challenge, 24 hour play festival, etc). It did a terrible number on my health and I swore off game jams at the time, but I’ve been re-introducing them to my life and just taking a more reasonable approach. One thing I’ve always admired about LD is its emphasis on being reasonable with pacing, but I was nervous to try the solo competition. I did it anyway!

This weekend I got a full 8 hours of sleep both nights, and during the day took ample breaks for food, walking my cat, and just getting away from the computer. This was a big help, because the real person doing all the work is subconscious brain, and I needed to get out of her hair on occasion to let her solve all the hard problems I ran into.

3. Planning

Though the majority of working time is spent making the game logic and creating assets, I found it really helpful to set aside time to do some planning, which is why you occasionally see workflowy popping up in my timelapse video. This planning was nothing too extensive, but doing things like outlining the structure and screen flow of the game would help me spot transitions I would need early on that I hadn’t thought about (or allocated time for).

I would also jot out a rough schedule, and revise it after each break. This helped me keep in scope and know when I should take a break from iterating on game structure or bug fixing to write a song. I tried to keep this very lenient with a lot of open room, which worked out as I spent a lot of unplanned time on Saturday night addressing a physics issue that I had not anticipated.

Also, just listing out to-do action items for stuff like “sound effects needed” helped me churn through asset creation without wasting a lot of time figuring out what I needed to do next. So it may not seem intuitive to spend precious work minutes writing out a next-actions list, but I found that it helped me be more efficient on a whole over the entire weekend.

4. Let your Problems Dictate your Design

On Saturday night I ran into an issue with physics syncing. I’d wanted the “preview” mode of my game to simulate the same way each time on any machine, so it would be more of a plan-and-place puzzle. but the pausing and restarting of time was making the play-through part inaccurate and making it framerate dependent caused other issues. I spent a lot of time figuring out how to record the simulation and do playback and how to stop playback and begin recording again when you placed an object on the screen, etc. It was going to be complicated.

After a good night’s sleep, I realized a much easier path would just be to change my design intent. The preview would just show a general possibility of how the ball would behave, and the goal of your placing objects would be to react to what was happening in the moment. I think it ended up being a better choice in the end, too, since one level can potentially play out a different way twice in a row. A friend of mine described it as akin to “turn-based pinball.”

I was able to use the simulation recording work I’d done the previous night to do a simple replay (which had its own bugs) so no work was wasted and I was able to move on from a complicated problem to finish off the game.

5. Music Composition for Noobs

By far the most daunting part of the compo for me was creating my own music. I can code, I can draw, I can spam the “random” button in sfxr until I find something I like, and I design for a living…but music? I’ve never written a song in my life! Fortunately I got some fast, noobish composition tips beforehand.

Step 1: Pick a chord, any chord A-G. Look it up on the internet to find out what the notes are in the chord.

Step 2: Lay out those notes in music program of choice (I used LMMS).

Step 3: Grab the notes and reorder them and spread them all around, just keep the notes themselves the same

Step 4: Hit play. Hey that kind of sounds like it could be a thing! Adjust until it’s a thing.

Step 5: Layer on top of a base track of just 1 or 2 of the notes repeating. Add in a few more layers of the same process. Pull things all around until the timing sounds like it’s something.

Step 6. Put the song in your game and turn the volume down super low so even if your song is terrible, it won’t be too distracting. Success!

Closing Thoughts

Again, I was really happy with what I was able to accomplish this weekend. I felt challenged and the tiredness of good mental exertion. I was even confronted with an unexpected and difficult problem during the course of my work and was able to conquer it. Overall, a fine experience!

I think my biggest thing is that I get very caught up in tuning game feedback at the expense of making more elaborate art that I know is within my abilities. I don’t think that’s necessarily a terrible thing, though.

Will I do Ludum Dare again? Most likely!