Ludum Dare 23 – “Naos”, a postmortem

This past weekend I made a game, “Naos”, for Ludum Dare 23, around the theme “Tiny World”. If you haven’t played Naos yet, you should do so now, the blog post will make more sense.

The sound.

Aesthetics were very important for me in this jam game. So I tried to pick carefully what kind of music I wanted to write. The game wasn’t supposed to represent a wholly realistic thing, so the music sort of reflects that in a haunting/minimal way (the organ-like house loop, the chime-like thing in the forest). The more action-like piece at the cliff helps to show that there is some action going on there (i ended up redoing this one the most…). As for the intro/ending thing…I couldn’t really think of a fitting melody, so I added some fancy-ass white noise that I thought fit.

I like the chimes piece the most, and would like to expand upon that. I feel like part of it was definitely influenced by listening to the Fez OST ( )way too much over the weekend – especially with the bitcrushing it uses, which I felt I may have overused in a place or two. Two pieces in particular I found salient were Spirit and Nature. Seagaia – Songs from Naos (Ludum Dare 23) by seagaia

Graphics style…WHY? MY EYES!

Admittedly the game’s blur was a bit much. I did think it suited the quiet/haunting/ethereal-esque nature of the game, though. I wanted to try the scribbly style. Spending more time would have of course improved…well, everything. In a normal setting they wouldn’t be that rushed, I’d use a tablet, etc. Right now, it looks just good enough to not seem completely sloppy. (But is, still, of course, sloppy :P)

I was playing a lot with BitmapData objects in AS3 (surprisingly for the first time…why? I don’t know…but now I’ve got a level of comfort). They more or less represent what will be drawn to screen. And you can do interesting things like pull out certain color channels, transform them, and superimpose them on the original graphic. Or, you can blur things at different levels. The way I did blurring wasn’t ideal, I surely could come up with a more plug-and-play way of doing it, rather than the somewhat terrible way I have now (at least it’s organized terribly), which was to copy the sprite’s data, and keep some external data that determines how much to blur it – essentially, I have a copy of the data – I copy it to the displayed sprite, blur it, draw that to the screen, etc. The same idea goes for the color offsets. I played around until it looked okay.

I also played with a new logo for Seagaia today. It shows up on the intro screen. I like it. It’s a bit of a rip-off from. It was fun to make, at least the top part. There’s this nice thing in GIMP where you can copy and paste every other row, and then you make it a bit transparent, modify it a bit and superimpose it to get this neat shadow-y effect.

oh so how was the coding

Straightforward for the most part. Every room was a different state, with its own events and so forth.

Became an ugly mess near the end with the event coding since I haven’t figured out a nice way to do events with flixel yet…want to definitely figure that out. I’ve been asking around a bit, but not much in the way of detailed cutscenes. x_x

Since I already talked about the graphics coding, the only really interesting aspect was the events. How do they work? Well, for one, it helps to draw a tree of your dependencies with state variables. For example, “E_CLIFF_2” represents the 2nd cliff cutscene, “DRAWING_1_DONE” represents finishing the second drawing. And so every iteration of the game loop, depending on what screen we’re in, we check to see if we need to start an event. Essentially, events just freeze character controls, and wait for some condition (my player’s x being at some point, pressing x to advance text) to occur. Each event has an “event_pos” variable that is incremented when that condition is true, bringing the event to the next part (text, movement, whatever).

While this method works for a game jam, it doesn’t really scale well (see the other game I’m making) when it comes to moving many sprites that you don’t want to have to hard code into the game…and it’s a bit hard on the coder with the repetitive switch statements (see. JEEZUS.)

An interesting bug resulting from this was that I didn’t nest one of the “if you press x increment the event counter” things deep enough, so if a player pressed X before they should have on the forest screen, you would be frozen when you actually pressed X over the right thing. Thanks to my friend Runnan for showing me that issue…gah!

One way this could have been done better is to have only checked for events once upon entering a screen, or have had some single “an event happened” variable to be checked, rather than all of these conditions on every iteration of the game loop. While this is okay because performance didn’t really become an issue here, it would be something to think about in some sort of later implementation.

so what the hell was this about?

it’s a secret! well, a few people have messaged me on NG about it, surprisingly. My interpretation of it is more or less solidified, but it’s interesting to see other people’s takes on it as well. In lieu of not looking all pretentious, i won’t write about it here. but if you’d like to know, shoot me a message.

that’s all for now.

if you found this interesting, you should follow me on twitter .

“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 –

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.

A short blurb on Dustforce (Hitbox Team)

Recently I was fortunate enough to stumble upon this trailer of the game Dustforce, by Hitbox Team. It’s available on Steam for $10, which is a pretty trivial price to pay. Give the trailer a watch.

Dustforce is one of the more beautiful games I’ve played in recent times. The soundtrack by Lifeformed (Terence Lee – ) is wonderfully fitting to the games visual aesthetics (just watch a few gameplay videos to see). The premise of the game is simple – use graceful, ninja-like moves to run and jump through the various stages, attempting to sweep as much of the dust/debris as possible, without getting hit or falling (which breaks your combo). There are effectively 3 (or 4) tiers of stages – 13 “easy” levels, 12 medium-hard, 12 hard-frighteningly difficult, and one that appears to be…well, “Giga Difficult”.

The learning curve is a bit steep, and you have to practice stages a lot in order to perfect them enough to unlock keys into the next level. Anything short of a perfect run earns you nothing in Dustforce, except letter ranks that sort of show how “close” you were, perhaps meant as a metric of how much more practice you need. This frustrated me a bit until I grew used to the controls enough to be reasonably confortable. Of course, there’s a large appeal to the game for speed runners, as every level has a high score table showing the best time, and best 100% time (getting all dust without getting hurt/dying). A nice addition is the availability of replay videos of *every* person’s run – so that means you can watch the best runs for the current stage, and learn! Or just be mystified by their beautiful performance.

In any case, you need to be patient with Dustforce to get a lot out of it…it’s easy to get the urge to quit right away because of how difficult it is at first (not that it *stops* being difficult later, by any means). But the calming soundtrack and visuals help you continue to restart the stages, over, and over, and over…the stages are varied in visual appearance, and all have a nice series of layered backgrounds, taking you from a playground at sunset, to a dusty library in an old mansion, to beautiful forest areas.’s hard to say much more. If you like precision platformers and are okay with the difficulty inherent in the genre, you should plop down the $10 to support the talented team of 4.