So I’ve just completed my first Ludum Dare, the 48-hour game competition.
I’ll probably do a longer post-mortem in a few days, but I figured I’d type something up while my youtube video is uploading. It will be available here.
It is a puzzle game involving the premise of “entanglement” (the theme of this Ludum Dare was “Tiny World”, hence quantum entanglement) – you need to move pieces around the playing area to complete the puzzle (connect the lasers to their targets), but the pieces are linked in either position or orientation. I suppose it strayed a bit from the main premise, but oh well.
Here are a few screenshots:
It doesn’t look like much graphically, but overall I’m fairly pleased with how it turned out. I ended up budgeting my time well. Something like this:
- Hours 0 – 4. I spent time thinking of ideas. I eventually locked on to quantum entanglement as a possibly interesting mechanic. To break up the time, I recorded my voice to use as music, and got it up and running “harmonized” in the game.
- Hours 4- 8. Once I had an the idea for the mechanic nailed down, I started building the framework for it.
- Hours 8 – 13. Sleep.
- Hours 13 – 20. I’m starting to realize the most interesting part of the puzzles is the stuff not related to “entanglement”. This makes me sad, but I figure I’ll figure something out.
- Hours 20 – 26. Mostly complete with the framework implementations of all the mechanics I will need.
- Hours 26 – 32. I start designing puzzles. It’s pretty tough at first, and I lose a bit of motivation because they aren’t very interesting. A couple of cool themes pop up in the end though, and when I go to bed I’ve got 8 of 10 levels done (10 levels was my goal). I end up needing to implement a level editor so that I can play with the concepts more fluidly. Pen and paper isn’t helping.
- Hours 32 – 38. Sleep
- Hours 38-42. Complete the remaining few levels. Except!
- Hours 42-44. A bit of a panic here, because an idea for an additional mechanic that arises out of my entanglement rules doesn’t fit nicely with the framework I’ve built. I go through a period of over an hour where my game is getting full of bugs. Finally I get back on track and finish all the levels.
- Hours 44 – 46. I polish up the visuals a bit more, and make some sound effects. I also switch out my voice for guitar string sounds for the music.
It was kind of neat watching the twitter feeds of others engaged in the competition. From claims of “I put my soul into this, prepare to be amazed, I’m probably going to win”, to “My original idea wasn’t fun. Now 24 hours into it and scrapping everything.”.
The only time I was terribly panicked was when my level design seemed really mediocre and I was worried the mechanic just wasn’t interesting enough. I think it has potential, but there really needs to be time spent exploring the world’s rules. All along I kept comparing my design to Jonathan Blow’s game design aesthetic: declare a few simple orthogonal rules, and ask questions about what interesting things might occur because of them (summed up).
Unfortunately my level design (at least for the later levels that are no longer “introductory”) tended to be, in my self-deprecating opinion, too much: “throw enough stuff in there that it’s kind of confusing and not easy to figure out what to do”. I’d better make sure I keep around the screenshots that show how to solve the levels!
It’s possible that there are still other more interesting mechanics to explore in this game, and I could make more (and more interesting) levels. We’ll see.
I thought it might be interesting to talk about how I managed to fit this all in 24 hours – because a lot of folks clearly don’t complete their game in time.
- The obvious stuff: have a framework/engine/libraries you’re familiar with ready to go.
- I was using an entity-component-system library of mine that I’m using in another game. It was pretty key to enabling flexibility and nicely structured code right from the start. Once the basic Entanglement functionality was implemented, having different types of objects support “entanglement” was as easy as adding an Entanglement component to them. As a result, a little more of my programming was “plugging in data” (compared to writing logic) that it would otherwise have been. And that’s always a good thing when it comes to robustness. I spent very little time chasing down bugs.
- Skip the fancy UI screens or game state management. A minimalist UI works better for comps like these. UI is hard and time-consuming. If you ever find yourself spending a lot of time on something that isn’t crucial to gameplay, give it up and do something different.
- Get some sleep. Not too much though.
- Scope your work so that you’ll get the game/gameplay 80% complete by the final day. The final day I did the last 2 levels of 10, and then just some visual and audio polish. All the base mechanics were implemented by 24 hours in.
- Resist the temptation to add new features in the last 6 hours or so. Give yourself a big buffer time.
- 3D vs 2D? I did 2D, but I’m not sold here. 2D pixel art is difficult. If you’re a really good at modelling maybe 3D is ok.
- Play-testing iterations are slow (you need to build a binary, upload it somewhere, etc…). Consider not bothering with play-testing, really.