“10 Seconds Left, Mr. Pink Rabbit!” – Postmortem

So, here we are! The dreaded moment when we decide to post our postmortem. Did I say “dreaded”? I meant “delightful” of course! Without further ado, let’s go!

*

What Went Neither Especially Right Nor Wrong But Is Worth Noting

*

– Everything goes fast, even emotions: it’s funny to see how we felt the same emotions as we would have during a “real” 6-9 months project (excitement, creative rush, discouragement, tension, sadness,, weariness, final exhilaration, pride, etc.) in the same order and at roughly the same moments of the development. It’s as if we were in a time bubble where everything goes real fast and all of a sudden – BOOM! The project is over, we can celebrate as if we had been working on it for the past year.

– Much in the same way, we feel we actually brought a project – however modest and narrow-scoped it might be – to fruition. That is pretty much, to me at least, the whole point of entering a Ludum Dare. As the organizers put it: LD is here to give us an excuse to hatch a game. And that feels good and gives a motivation boost for the “normal” projects.

– Working under a 72h constraint and an imposed theme was a first for all of us, and it was a pretty intense! Constraints are almost always great for creativity because it forces you to focus, keep motivated and think astutely about how you will create stuff.

– It is interesting to see that not everybody tackles the very concept of the LD jam with a common mind set. Partly that went wrong (see below), but mostly it’s just an “interesting fact”.

▲ Sure, now that the game is done we’re smiling…but at what cost?

*

What Went Right

*

– Choosing a third party IDE over our in-house engine: this was actually decided long before we started the jam. There were two main reasons: first, it allowed me – Foug, to take part in the coding process. My meagre programming skills are limited to Game Maker: Studio with which I have a long-time experience. Secondly, our in-house engine, Black Hand, is powerful and reliable (we can import .swf animations as 2D skins for example), but it’s still under ongoing development as any in-house technology, and while some features would have been overkill for a 72 hour jam, some vital others could have been missing at a critical moment (I have no example to give and that’s part of the problem: we are simply unsure how and when we would have been limited, IF we had been limited).
So Game Maker: Studio (Pro and Standard version) was chosen. As we will see in “What went wrong”, it comes with its lot of flaws and incomprehensible limitations. But overall it was a good choice, if only for the dual-coder capacity.

– Living together in the same flat for the duration of the jam: this point does not seem to sound obvious to many jammers but to us it was important to regroup at a common place and work together with a common sleep and meal schedule. We deemed it to be important to limit the risks of having some of us oversleep at their place or be distracted by external factors and, in hindsight, it turned out to be a very good decision because we had an almost perfect synchronization.

– Keeping a good sleep/nap/break schedule: it might be because we’re getting old (we are all around 30 years old), but we felt right away that we wouldn’t be able to crunch-time our way through 72 hours straight. It would have been madness (and not even SPARTAAAA!!!1!11!) to even try. Because making games is also our job, we know how important it is to abide by the “fair and softly goes far in a day” saying. We managed to cram in a perfect 6-7h night’s sleep every day, with power naps here and there when nodding off. It allowed us to be almost 100% dedicated to work during waking hours. We even had time to watch the WCS finals 😀 We reckon approximately 50 full hours of work per person (minus a little less than one day for one of us that couldn’t be here on Saturday).

– Managing to keep a healthy lifestyle: “a healthy mind in a healthy body”; it goes with a good sleep schedule, but it is important to listen to your body and not overload it with junk food, energy drinks and caffeine. We did eat a lot of salty, fat and sweet food, but we didn’t go overboard as we would have during a purely non productive LAN party.

– There is no “i” in “team”: being a tightly knit team of developers (and friends!) gave us a edge in the production flow. Autonomy is key, too.

– Recording the sound effects by mouth, as well as the vocal music, was a ton of fun and gave surprisingly decent results. Writing the game’s page with fake reviews on our website was fun too :)

– In spite of the sporadic tensions and fights now and then, we feel that, overall, our bonds as a team and as friends have been strengthened.

▲ PIZZA TIME!

*

What Went Wrong

*

– A clash of visions: while having dinner by the end of the second day, we started discussing how we felt about the project. It turned out we didn’t have a common vision of what it should have been (although it may sound paradoxical because we were perfectly aware of the design goals, the limitations and of all tasks to do).

Some of us had regrets that we didn’t spend more time finding a more original concept or clever interpretation of the theme, even if it meant delivering a half-baked game, while others wanted to kick off as soon as possible and deliver the best possible game in 72h. However, because we tackled the problem relatively early we could start singing on the same song sheet and the last day was exhilarating partly because of that. If we ever enter another jam, the vision will be agreed upon beforehand so I guess you have to learn it somewhere :)

– Debriefing too soon: this conversation around dinner of the 2nd day was also something of an unofficial debriefing. The problem with this kind of unofficial meetings is that you can’t anticipate or prevent them from happening. But what can go wrong with a short conversation?

Well, the problem is, we sounded like the jam was already over and we were judging a finished game when, in fact, we were closer to alpha than master. So basically some of us were a bit disappointed by how the game turned out and we had a fight over personality clashes. Might not be such a bad thing but the atmosphere was uselessly awkward for the rest of the day because of that. Again, it allowed us to make proper adjustment and be on the best possible tracks for the last day of the jam.

– Perforce and Game Maker: Studio don’t mix well! We had quite a hard time merging the resources, especially the first two days when both coders had to work on the same things. Game Maker: Studio has a huge flaw when you don’t work with its embedded source control options (which we couldn’t use because only one of us had a Pro license): whenever you save or launch the project, for some reason, GMS opens and writes ALL the files in the project, even if it doesn’t change anything. Should even one single file be read-only, you’d screw up the project file immediately.

So everybody working on the repo needs to checkout ALL the files at any given time. The problem? Well, because Perforce sees files checked out, it will systematically ask you to resolve merges before checking in even if you didn’t bring any changes to the files others were working on. It was not such a big deal by the end of the project when little changed at each check-in, but it was horrible to maintain the first two days!

▲ ‘kay guys, try to look busy, I’m taking a picture!