Global Game Jam 2016 Post-Mortem
The Global Game Jam took place over last weekend and I participated at the lab I’m affiliated with at Concordia called TAG. The theme turned out to be “ritual” – a nice theme that, for one thing, led to Michael Brough’s important Vesper.5 in a different jam. After a false start where I tried to make something based on my notebook drawings (which I will return to), I decided to try to fast-build a version of the project I was planning to work on next about being a novelist/writer. Ritual played in with that whole optimism one feels around deciding that “this time” one is going to get up every morning and work on one’s novel etc. etc. Ah optimism. Anyway, my bold idea was to try to compress my usual development time-frame of 2-6 weeks into two days.
Lessons learned, you ask? Well.
For one thing, it kind of worked. I did actually finish a version of the full concept in two days. I’m not going to link to it here because I’m going to finish it properly over the next couple of weeks, but if you’re desperate you’d be able to find it on the Global Game Jam website (along with its awful, awful source code).
Awful, awful source code. Unsurprisingly, when working to a tight deadline, the code was really pretty terrible and was tripping me up a lot by the end. That certainly led to a bunch of problems, including bugs in the final version. That said, it worked remarkably well.
High-speed design decisions. Although the project was one I’d had in mind for about a week-ish before the jam, I hadn’t really nailed down many of the subtleties. The speed of the game jam both helped and hindered with that. It forced me to confront elements of design I hadn’t thought of pre-development, but it also forced me to make snap decisions about them that weren’t always particularly true/appropriate to the overall vision for the game. On the other hand the jam version has a “I know what I don’t like” quality to it, which is helpful for moving forward.
High-speed everything. Perhaps the big learned lesson was just that I can develop something about as sophisticated as my “usual” games in a weekend. But when I think about it, this makes sense anyway. I probably spent in the neighbourhood of 20 hours working on the game. When I consider that I might often put in a couple of hours five days a week ordinarily, that translates to four weeks of work. So it’s not that surprisingly in terms of hours, more just that it was possible to compress it so much. But, again, it’s pretty clear to me that all the “marination” time I have with the design for a normal project is a major contributor to the coherence of my usual projects – I spend a lot of time thinking about (agonising over) the “truest” way of doing something in a game and that’s an important part of what I do.
All up it was a positive experience. It’s a bit of a weird feeling to tell myself that a game is “finished” in some capacity (e.g. “for the jam”) when it’s blatantly not up to my standards, but that’s alright. Perhaps the oddest thing was just the decision to not really make a “jam game” at all but a super fast version of my standard practice?
Anyway, look out for the final version later on, when it’s, you know, better.