“In An Aeroplane Over The Mystery” Molyjam 2012 & IIT Spring Hackathon (HTML5 (Canvas + EaselJS))

A few weeks ago, I made a game for Molyjam 2012, and an IIT Hackathon. I spent maybe 14 hours total on it:


The premise is you’re on an airplane, children are complaining, the plane is crashing, and you need to alleviate their problems as quickly as possible to put off the inevitable – the plane crashing (well, MAYBE…)

(Go play it now, it takes maybe a minute)

Anyways, it was the first game I’ve attempted at making on HTML5’s canvas element, using the EaselJS library. EaselJS gives you access to a relatively easy to use library with tick functions (game loops) and bitmap drawing functions/etc., more or less everything you need for a basic game. The likely messy source code is up at my github – https://github.com/SeanHogan/iit-html5-jam.

I could see how javascript can get potentially messy, being untyped and all – near the end of the hacking period, throwing lots of variables one after the other in index.html .

There isn’t much that exciting about the programming involved. The messages are randomly picked from a set of sets, and then from the set itself, which sets a property of the kid in terms of what thing to respond to. Performing the right action lowers the bar in the top right corner, if you get it wrong it fills a little bit. As time goes on it fills faster. I did learn about loading assets in games for web-page based games – there’s a file called ContentManager.js which makes sure all the images are loaded into the game, so we don’t get some null error and crash everything when it comes time to render. It was nice to learn about that one small caveat.

In terms of game design there might be a little more interesting to discuss. Somehow, I managed to completely miss the fact that my small sound cue of an incorrect/correct response is not enough at all to let the player know whether they’re doing the right thing. The only other cue is the message changing. The bar is non-obvious how it moves either, it’s hard to tell exactly what is changing amidst all of the action. The hitbox action is a bit iffy in my opinion (at least the way it’s implemented…I was a little lazy), so that might not feel right either. More visual cues likely would have helped in this department.

The instructions, I believe, made sense. Although there was a lot of reading – but in a short game like this I don’t think there’s really much other way, unless the game was fleshed out and I could ramp the difficulty up.

Biggest thing learned was – feedback for performance is important, as it alleviates confusion!

Curiously enough, some guy at the end of the hackathon told me to put a better version on the App store or something. I have no intention of doing so since I don’t really find the game particularly salient, and with most hackathon things there are plenty of ideas to consider, but they’re not really worth talking about as, well, they’re ideas…moreso meant for journals and diaries doomed to be lost. Or not.