Roll’em Golem – GGJ 2012

Roll'em Golem screenshot

Click the image to go to a page where you can play the game, read the instructions, or visit our Global Game Jam page to download a build. This game is compiled against Flash Player 11. This version is what we submitted on the final day of jamming. There’s another one in the works with cleaned up effects, many more levels, new backgrounds, and “sexier codez” (scientific term).

The 2012 Global Game Jam was a lot of fun. At first the theme, Ouroboros, had everyone confused, but before long plentiful tie-ins to game mechanics seemed to abound. I worked with Stefan Woskowiak, Kendall Noble, David Turchin, and Burak Karakas again. We were also fortunate to have Rahil Patel join us on Saturday.

For this game, I had a much more clearly defined role for myself. Burak makes awesome music, so we decided to just have him compose all the tunes. Then, he and I split up the work for sound effects. He took a little more, because I needed time to hook up the audio code. I also took on the responsibility of getting DAME working with our levels. It wasn’t terribly sophisticated code, but it allowed Stefan to stay up all night clicking together little tilemaps that could get turned into levels for the game.

Read on to hear about the audio implementation.

The audio code for this used some of the methods I’m stockpiling for Flebang. It directly embeds mp3 files and loops them using sampleDataCallback (and the magic LAME mp3 encoder delay number that Andre Michelle figured out). Thanks to this, I can guarantee the position of a music loop within 2048 frames of audio. it sounds like a lot, but it’s actually only about 47 milliseconds. You might hear a gap or jitter if you’re an audiophile or if you’ve got a slow computer (or you’re like me and have way too many tabs open at once). But it works well enough.

At first this audio code was bogging the game down (if you play the build we uploaded to the GGJ website, you’ll see it hit a huge lag spike about 12 measures into the music). This was because I was buffering samples in a Vector.<Number>, and it turns out that Flash performs better if you just implement your own linked lists. So I did that after the jam and got a good 15fps back as a result.

It might also be possible to eliminate more latency. The sampleDataCallback for audio gets fired as needed in Flash, so approximately every 40ms. If the game can keep its FPS above 25 or so, then the ENTER_FRAME event would actually fire more often than sampleDataEvent. This means that either I could lazily pre-buffer the samples for each sound on every frame, or even always prepare at least one buffer of samples, occasionally electing not to buffer samples every couple of frames. The second option might provide a more consistent gameplay experience since it wouldn’t be erratically deciding to buffer samples randomly every 3 or 4 frames. But I’ve never done this kind of performance analysis with Flash, I’ll have to see how it goes.

And of course there’s the fact that I’m needlessly calling readFloat() on the byte buffer extracted from the embedded mp3. This was done because I reused the code from a class DSP project, in which I actually did need access to the samples.