Class Act Post-mortem

12 February 2010

As promised, here’s the breakdown of what went right and what went wrong with the game Class Act: made by myself and 3 QANTM graduates during Game Jam Sydney.
Note that the entire game was conceptualized, designed and created over a very short (48hrs) time-frame; this alone makes it one of the most impressive projects I’ve been a part of. A lot of what I mention will be specific to how we tracked and used the time given to us, and may not be applicable to projects with less strictly enforced timeframes.

What went right:

The most fun section to answer!

  1. We finished it! Not every team involved in the jam managed to achieve that.
  2. We adopted an iterative development strategy. As the project came together we made an effort to force ourselves to find points where we could stop our work, play the latest version, then go into a separate room and decide what was missing and what was needed to make it closer to/a better game. It was sort of like planning sprints in Scrum, but without any formal management framework.
  3. Art. Our artist was experienced in 3D modelling and had never worked with pixel art or sprites at all. Which makes the graphics that he produced even more incredible. They were expertly crafted, pixel perfect, and had exactly the look and feel we were going for. Our artist single-handedly gave our game an 80′s reference, which was one of the requirements.

What went wrong:

Things to learn from

  1. Bad choice of tools. We ended up using what the majority of us were used to, which was Allegro: a 2D graphics library not far off from GDI. It did blitting and basic image loading and nothing else. Because of this we wasted a lot of time getting something on screen, and an epic amount of time writing our own movement, collision and animation code. We were trapped doing 2D because we weren’t all familiar with a single 3D framework and despite our artist doing some amazing pixel art, he would have been much happier making models. Because of the time taken to work with Allegro, we never even had time to polish.
  2. No polish. Yeah. Lack of time or code design for creating gameplay variables that could be tweaked to improve the gameplay. Little things like a visible view area for the teacher, or tweaking the reaction times of teachers/students would have upped the fun level if we’d had the time or the ability to tweak them in-game and find the perfect value. Bringing along a reusable console class for providing all that functionality would have made a lot of difference in the end product
  3. Time management. For all of us this was our first game jam event, and most of us had issues with managing our sleep and our work. Each of us had different issues: for some the sleep was ineffective, for others there wasn’t enough and they were fading during the last minute cram at the end. I don’t think it’s a common thing for many developers to know the limits of their bodies, or be familiar with their sleep cycles etc.; it’s the kind of knowledge that proves useful in a weekend game challenge though.

There was lots that went right, and lots of stuff to learn from, and I look forward to putting it all to good use as soon as the next Game Jam is announced!

For those interested in having a play, the files for Class Act can be downloaded from the Global Game Jam website here

 | Posted by | Categories: Blog | Tagged: , , , , |