A First Time Entrant’s Write-Up

Posted by
April 22nd, 2009 6:24 pm


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:

mkdir /home/win/screenshots
for (( ; ; ))
scrot /home/win/screenshots/%d%k%M%S.png
sleep 30

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.


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!

Thanks everyone for a great event. Long live LD48!

-Windsor 04/22/09


3 Responses to “A First Time Entrant’s Write-Up”

  1. HybridMind says:

    Thanks for the postmortem and congrats on finishing your first LD! :)

    I hear you on questioning the sense of writing all that base code that many others get for free. I couldn’t imagine that. All my LDs I’ve done with a dev environment that had a lot of nice librarys and APIs for tying into a basic 2d game. Like Gosu game dev library with Ruby language or more recently this was the first compo I made the switch to Flash / ActionScript 3.0 It is great to be able to just focus on writing your actual game code and game logic and not having to re-invent a 2d sprite blit. 😉 I highly recommend what I hear you suggesting to yourself about developing a personal lib (just post it before the next compo according to the rules I think) or use a game dev lib with your language.. it really does make a lot of difference.

    I haven’t tried your game yet, but I will!

  2. Sparky says:

    Congratulations for finishing! This was my first Ludum Dare as well, so it was interesting to read your account.

  3. winferno says:

    Thanks for the input, guys. Hopefully I can make it back for next time!

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]