The theme was released at 1 PM EST, so we had plenty of time to set up and practice our high fives*. We decided to go for a walk and grab lunch while brainstorming. On the way, we tossed ideas around, each crazier than the last:

A pacman creature that must eat everything around it, then eat itself

Fight against your previous actions and past selves in some sort of tactical action thing

A platformer split into two mirrored worlds: use objects in one reality to overcome inner demons in the imaginary world

A game where you gain friends in a happy adventure. Then at the end you have an existential crisis as you realize you’re less happy than your character.

Using the mousewheel as input, fill a pleasure bar and avoid painful objects… Which ended up as a thinly veiled metaphor for masturbation.

A Facebook ‘social’ game: you win when you have zero friends. You can’t delete them – you must make them delete you.

*The strength of an indie game development group is directly proportional to the awesomeness of their high fives. True fact.

We challenged ourselves not to make incredibly depressing games, but it was difficult. When we got back, we put on some videogameOSTs to spur us on and got to work!

Everyone had a different style of development and worked at a different pace. Upon our return, Luca launched straight into GameMaker and started building an adventure engine. Harry doodled in his notebook and stared into space. Chad and Matt started with assets: a ship, a wicked looking explosion, a sphere with expressive eyes. Sam focused on early prototyping and soon had a masturbation-inspired-mouse-wheel-controlled-avoidance-game up and running.

For dinner we went out for delicious numplings (non pepper flavoured noodles + dumplings).

After dinner, Sam began work on a new game (which would become his entry, Leave Me Alone), Luca continued to build his adventure game, working on assets and code simultaneously, and Harry was still brainstorming. Chad left and unfortunately didn’t make it back. Matt went home on the first night to record some music and get some sleep.

Luke arrived the next day, driving all the way from Shepparton. He worked on a puzzle game about peeing in urinals while uncomfortably close to others. Unfortunately it wasn’t completed in time, but he did end up with a bathroom shooter / simulator:

Harry had a skype chat with Jarrel (in Singapore at the time) and started work on their jam entry. For everyone, the day was largely spent working in silence on their respective games. Just the fact that we were all working in the same room was motivating. We celebrated the squashing of bugs and took breaks to check out how everyone else was doing. Sam finished his game shortly after lunch and went home a winner.

Dinner consisted of cup noodles.

There was less sleeping on the second night; with the deadline looming closer, everyone jammed at full speed. At 4 AM even the more stubborn ones retired to bed, returning to their games in the morning with just a few hours sleep to fuel them.

The final few hours were peacefully frantic – an air of concentration and quiet panic. Luca deemed his game essentially finished in the morning, while Matt added gameplay elements to his and gave it a last second title. And suddenly, at 1 PM, it was done – at least for the solo competitors.

tl;dr Ludum Dare 22 was an amazing experience: inspiring and insane, but most of all fun. Hosting a jamsite is relatively easy, and the bonds you form with other developers as you slowly go crazy in the same room are strong indeed. We’re looking forward to the next event!

This was my first attempt at entering the Ludum Dare (a.k.a. LD48). It was a bit intimidating to see some of the really impressive games that came out of previous LD48 events, however the line on the LD48 website reading something like “Historically, less than 20% of the contestants submit an entry” was a bit of an encouragement. At least if I bailed, I wouldn’t be alone. As it turns out, I was able to eek out a ‘game’ in the 48 hours, even if the only machine it likely runs on correctly is my own.

Time Management

I got my idea pretty early on, and my game design was done in under an hour. I’d say roughly 40% of my time was spent coding what could have been reusable game engine things, such as a texture loader, sound effects loader, collision detection code, etc. Another 20% was spent on logic specific to my game such as collision response, physics updates, game end conditions, and state changes. I spent another 30% on the game resources, including artwork and music. The last %10 was spent on the initial design, some game tuning, writing a quick read-me, and finally a mad rush to get everything packaged and uploaded.

Although I had devoted the entire weekend to the event, my girlfriend had some friends in town, and I spent about 7 hours (~15% of the time). I slept also, which in retrospect, was a good idea. By then end of the event, my nerves were starting to feel shot.

Development Tools

I was doing all my coding in C++ on Linux, using OpenGL and GLUT for graphics, OpenAL and libvorbis for audio. I used CMake (a build tool) to help generate makefiles which is handy because it allows one to generate build files for other systems (Visual Studio solutions, for example) using a single cross-platform compatible input file.

Editor: I used XEmacs as my editor. I’ve spent some time using it and have it customized pretty well to suit my needs. What do you think I’m typing this write-up in?

Graphics: I used Graphics Gale to create all the artwork, which I saved as 32-bit Targa files. Graphics Gale is available for free in it’s basic version with some feature restrictions. It has a few features to make drawing ‘cell style’ animation easier, such as onion skinning and animation previews.

Sound/Music: I wanted to integrate the use of my MPC1000 hardware sequencer in to my work-flow, so that’s what I used to sample a guitar riff and some beat-boxed sound effects I recorded. I have a microphone, mic pre-amp/effects processor, and dedicated guitar effects processor to tweak sounds before I edited and sequenced them in the MPC1000. I also used a couple freeware VST synthesizers from Tweakbench.

Time-lapse Video: During the competition I was continuously saving desktop screen-shots every 30 seconds which I later compiled in to a video. To save the screen-shots I used a Linux tool named scrot, and a very simple bash script like this:

Note that in hindsight, I had some problems with the way the files produced by scrot were named. Some of the files had spaces in them, which might be a bug in scrot. This was a problem for me because my video encoder (ffmpeg) was unable to deal with anything other than files that were named in sequence numerically (no gaps in numbers). I was able to use the batch renaming feature of the Linux tool GQView to rename the files sequentially based on their date-stamp, and ffmpeg was happy. The ffmpeg encoding tool was able to splice in an audio file as it encoded the 1800 jpeg frames.

Game Design

I got lucky in that the chosen theme, ‘Advancing Wall of Doom’ was already my first choice, so my subconscious had some time to mull over the design. I wanted to keep the design dead simple so I wouldn’t bite off more than I could chew. Looking back, this turned out to be a good thing, as I was working right up until the end of the compo and wouldn’t have had time to add any extra features. Even though the design was simple, I feel I should have spent a bit more time considering the playability and fun factor of the game. During testing it was very apparent that my game lacked a lot of variability, and there wasn’t much room for any real strategy or technique. Every test-play through the game took about the same amount of time, and I hadn’t exactly intended the game to be based on any time limit.

Things Learned

Overall I’m happy with my performance during the competition, mainly in that I was able to complete my project in under 48 hours. Although my personal experience playing the game is biased, I’d say it’s good for at least a minute or two of genuine fun. I was also able to take a few things away from the experience which should make my life easier if I decide to compete again:

1. I was coding at a relatively low level, and ended up spending too much time writing and debugging code to provide functionality that others in the event were essentially getting for free (image loading, sound, collision detection, etc.). I also had to be aware of some platform-specific issues (namely timing functions) that users of other APIs could also ignore.

2. Sleep and getting up for breaks is important. I even went outside and ran around the block once during the compo. A couple minutes of jumping-jacks were helpful also. I didn’t regret spending about 15 hours during the compo asleep. I get the feeling my mind was still somehow at work debugging my code while I was sleeping anyhow.

3. I should have spent some time preparing a bit of template code that is generic for any relatively simple game (2D or 3D) that I might want to quickly create. Game loop, end conditions, state changes, main input/display/audio systems all seem like targets at first glance. I had a hard time deciding how to write my code in order to keep an architecture that wouldn’t strangle itself in the short time span of the competition. I think an overall ‘game template’ even if it was just a short checklist, would have been really helpful to me.

4. Although this wasn’t an issue during my time spent in development, I realized after the competition that my code would not be immediately available to other entrants because of the development tools I chose, and the because the corners I cut in testing meant that I produced code which had problems with timing and input on other systems I was able to test my code on afterward. This is a big problem because it makes judging by the other entrants much more inconvenient of not impossible. If I had developed for a virtual-machine environment such as Flash, I suppose I could have avoided this. problem.

Conclusion

I had a great time and am looking forward to entering in the next compo if I have time. I think as long as I can view the event less as a race and more as simply an exercise in programming and design on a very short time scale, and use the experience to become a better coder.

I also have to mention that the social aspect of the event is really great. Everyone in IRC was really friendly and helpful, and it was exciting to see what people had going on at any given time of day or night. I even found out that one entrant was a fellow student at my college, taking one of the same classes even. I’m glad that my comment about his entry on the web wasn’t too harsh!