Casually Hardcore devlog

TOJam #3 Post-mortem

May 13th, 2008

As a TOJam vet and past organizer (TOJam 1 & 2), I’d have to say each year has been a completely different experience: New location, new jammers, new games. Each year has progressively gotten better in terms of size, quality and overall experience.

This year, I actually enjoyed myself and at no point felt stressed or guilty that I wasn’t helping out with the organization of the event. In short, this was my favourite TOJam!

What went right:

1. I finished my game!

Finishing a game in three day is a big accomplishment if you’ve dared to try it. In last two jams I completed “rather half-assed so-called games” that I would probably not play ever again and I don’t recommend you do either. For one, the first jam game require DK Konga controllers and a GameCube USB adapters (good luck!) and the second require a microphone and the Microsoft Speech SDK installed OR Microsoft Office… that eliminated 50% of the world!



2. I pre-visualized how the music-to-waveform tech would work beforehand.

Cowgirl and Gospelboy relied on a weird piece of technology played a MP3 file and generated 2D collision geometry on the fly. If I had tried to implement this in 3 days I would have ran out of time. Instead I built a sample app a few weeks ago to test out whether FMOD could dynamically generate a 2D waveform that looked reasonable. I did not write any music to physics code until the start of the game as I felt like that was cheating.



I also had experience with Box2D, the physics engine used, so all technology was well understood (or so I thought).

3. I didn’t use a 3D engine to make a 2D game!

Last year, I used OGRE to build a 2D game and that was a mistake. OGRE is fine 3D graphics engine, but is too complicated for simple tasks like drawing sprites and rotating them! I choose IndieLib because it was the easiest/cleanest 2D game engine I’ve seen in a long time. My second choice would have been PlayFirst or PopCap, but those game engines are overloaded and rather complex.

4. The game is actually fun!

My first two games were about experimentation and toying with novel technology like Konga controllers and microphones. This year, I decided upfront that this jam had to have all technology developed and understood. I swore to myself that I’d spend all Sunday gameplay tuning – which I did.



I found as people played the game Sunday night (as part of the open house gaming session), I slowly refined it to a point where by 11:00pm it was becoming addictive. As I’ve mentioned in another post, C & G was exactly the game I wanted to make in the first game jam, but I did not have the physics background then.

What went wrong:

1. IndieLib was missing features (or had features I thought were supported)

I didn’t realize IndieLib did not support joysticks nor TrueType fonts until the second day of the jam – I scrambled to include OIS support and made due with TWO fonts (big and small).

I also did not spend enough time with IndieLib before the jam and had to learn how it’s co-ordinate system worked when zoomed out and other quirks like issuing BeginScene(), EndScene(), RenderEntities2d calls.

2. The code was a disaster by Saturday night.

I was forced to refactor the codebase (took 3 hours) and add a state machine and migrate everything into classes because adding menus would have been impossible otherwise. The code was a mess of global variables due to how I just dove into making the game.

3. High-speed 2D physics creates major problems

There are some annoying bugs in the game and most of them are related to the wave moving at 150 units a second to give the player a sense of speed, but also causes the infamous “tunneling” problem.

Early on, I decided to remove constraining the max and min height of the wave and let it grow as high as possible to give a sense of worldly height without resorting shifting the wave up/down (causes physics problems).

The camera tries to keep the surfer in view, by zooming in and out and other tricks, but due to the high speed of action the player can slide out of view for a short period a time.

4. Some chosen songs were just not fun to play

The best songs to play are the ones with plenty of variation. Many radio-friendly pop songs keep an even keel with minor variations here and there, but not enough to keep interest for 4 minutes. Jill Barber’s “When I’m making love to you” is a fantastic song to surf to. It ebbs and flows like a bittersweet love song.

5. I did not provide clear art direction to the graphics floaters (artist)

The main characters needed to be re-designed THREE times during the jam due to my poor art direction. I told the artists to make “Stickin’ around” like characters which they did, but I didn’t realize that meant the clean and straight lines. I was thinking more like “Stickfigure theatre” with more squiggly animated lines. Not the case.

Entry Filed under: Game Development