I love reading everyone’s postmortems. Either people do clever things that I would never have thought of, in which case I’ve learned something; or they don’t, but then I at least get to feel smug; it’s a win either way. Here’s how my Compo entry, Jack and the Alarm Clock, came to be.
Concept
“10 seconds”… what to do with that? I expected many time-limited games, but I wanted to do something different, which got me thinking about other meanings of the word “seconds”. In particular, the one about having a second helping at dinner. This led to the idea of a game about Hansel and Gretel, where you play Gretel who has to collect ingredients for the witch to stuff Hansel with seconds, ten times (actually, thirds, fourths, …). I dropped this idea because it would force me to build 10 levels, ideally with different ingredients on each, and I wasn’t sure I’d have time for that.
But the fairy-tale idea stuck, clearly, and so Jack and the Alarm Clock was born. A time-limited game, as I tried to avoid, ironically… but a game nonetheless, and that’s what matters most. A platformer is probably the least original I could have done, but I had never made a platformer before (unless you count I Am A Ninja). And it would allow me to do both the objectives I’d set myself: to use pixel art, and to implement parallax scrolling (just because it’s super easy and looks cool).
Coding
Before I had decided on the final concept, I’d already started setting up a WebGL canvas (using my own support library Gladder) and writing a Tiled importer. I was worried I was going to have to parse XML with a compressed blob of data in it, but no, Tiled supports JSON nowadays! So that was a lot simpler than I thought.
A tile map loader could have gone many ways, for instance a tile-based puzzler, or a Wacky Wheels-like racing game. When the loader was done and I still hadn’t come up with a more original idea, I decided just to go for the Jack game, platformer or no.
Collision handling and controls presented some interesting challenges. This article led to the key thought of updating x and y positions sequentially instead of simultaneously, which made things a lot easier and more robust. Aligning everything to whole pixels nicely dealt with all the roundoff problems that you have in a general-purpose physics system. That also had some aesthetic effect: in pixelated games, it always bothers me if the individual sprites are pixelated, but they don’t align to pixel boundaries between each other!
I got pretty much all the coding done on day one, including graphics, sound, winning/losing, restarts and level progressions. This is what it looked like at the end of the first day:
Sound and music
By the end of the first day my brain felt like porridge, and coding had slowed to a crawl, so I decided to turn to music instead. Because I suck at composing (proof) I picked two traditional jigs that I learned to play on the Irish tin whistle. The slow(ish) tune is From the New Country, the fast one is Scatter the Mud (although I learned to play both a bit differently). I had done some experimenting with LMMS‘s C64 synthesizer emulator in the days before, so I felt confident I could use that to make a decent-sounding chiptune.
All sound effects were done in bfxr, with the exception of the game-over sounds. Both the “fee-fi-fo-fum” sound and the victory tune (notes shamelessly stolen from Mario) were done on the same C64 synth, taking care to transpose them to D so they would blend in well with the rest of the music.
Sound coding was a huge nightmare in my first HTML5 games (so much that I once dropped it entirely). I tried various sound libraries like SoundManager 2 and SoundJS but they either failed to deliver low latency, or failed to work at all in some browsers. But shortly before the compo I discovered Howler.js, which worked perfectly out of the box and made me very happy.
Graphics
This was the first time I tried my hand at pixel art, and I’m fairly satisfied with how it turned out:
With tile-based levels, there’s an interesting interplay between the level and the tile map, and I found myself switching frequently between Tiled and GIMP. Fortunately, both tools make this very painless. And while making levels, I discovered that my tile map supported something I hadn’t planned for: you can see the branching beanstalk in level 6.
If I have one regret about this game, it’s that I wasn’t able to put in as many graphics as I’d have liked. Some variety in the beanstalk, some more detail on the ground and in the castle, some birds flying through the air or clouds moving, some more different types of platforms…
Somewhat less faithful to the 256-colour era is that I threw in some noise to make the sprites look more interesting.
Fun fact: the most detailed-looking sprite is probably the cottage, but I only drew that in the last hour of the compo. I think I was improving; this also shows in the hen and harp sprites, which were also among the last ones. I wonder if Jack would have looked any better if I hadn’t started with him…
Level design
I’ll admit, level design is not my favourite activity. Perhaps this is also because I have very little practice and am not very good at it.
Tiled made the mechanics fairly painless, but there’s still a large amount of iterative test-adjust-test involved. Worse, by the end of it I had no idea if the difficulty level was about right. I tried to rope in some playtesters, but didn’t get much useful feedback.
Due to lack of time, there is also much less variety across levels than I would have liked. I made each next level by copying the last and putting in a new beanstalk, but the giant’s castle looks identical (and identically uninspired) each time. Worse, it’s in the same location, because moving it meant moving tiles around on three different layers, and (to my knowledge) Tiled doesn’t make that easy. It would have been nice if the beanstalk got higher, lifting the castle up, instead of just becoming more twisty.
Hacks and goofs
I thought it would be nice to end this post with some dirty secrets. Of course it’s horrible spaghetti code to begin with, with loads of global variables, public fields, and interactions and interdependencies that should not be, but here are some particular gems:
- There are hardcoded constants all over the place. These mostly represent coordinates inside the sprite sheet. But this is OK since these are also used inside the level tile maps, so they cannot easily be changed anyway.
- The fences on the left and right side are made impenetrable in code, rather than in the tile map. As I developed the first level, I increased its height several times, and I got tired of having to extend the invisible wall upwards!
- Someone reported that they couldn’t make a particular jump, even though I could easily make it on my machine. I figured this was a problem with my physics implementation, which used a variable time step and therefore could have slightly different results depending on the speed of the machine. I ended up using a 50 millisecond fixed timestep. If not enough time has passed when it’s time to draw a frame, the elapsed time is added to an accumulator, and when it reaches 50 we do another step. No interpolation or anything fancy, but it looks smooth enough to me. (If the frame time exceeds 100 we still only do one step, in order not to end up in a death spiral where frames take longer and longer to compute.)
- The clouds were one of the very last things I added, to spice up the background. It’s just a hardcoded grid of 256×256 tiles, 15 in the horizontal and 5 in the vertical direction. I knew this was sufficient because none of the levels are larger than that! (They run out near the top; this is intentional.)
- When the giant’s hand appears and lifts the player up, the player sprite’s update method would still try to apply physics to him. Instead of adding extra state handling to the Player class, I opted for the quick way out, something only JavaScript will let you do:
player.update = function() {};
I used this same trick for the alarm clock’s digits, which would otherwise be animated sprites cycling through the numbers 0…9.
- When you run out of time, the giant’s hand still appears from the top of the screen, even if you’re standing right next to him and he remains asleep!
Long story, thanks for reading. Now go play and rate it if you haven’t already!
But I didn’t. Out of the two final ideas we whittled our jam down to, one being experience/narrative weighted & one being untested mechanics weighted, we decided to go with the mechanics weighted one because it was more unique. It was certainly unique, but if you have a voice every creation should be. And as no game I’ve played yet from LD27 was even remotely like the other our worries were unfounded. I chose to make another game where I could grapple with obtuse mechanics and waste time getting pretty effects in. I’m not alone in creating something defined primarily by its mechanics though, I was a bit disappointed, like the last LD, to find that most of the other games are too. People like different things so that’s totally cool (although shout outs to 
At the Cafe by pierrec
- This resulted in what could be a rather unclear, obtuse game. The ‘twist’ of the game is built around the screen position not representing the room position. This is mentioned in the description and the opening images, but it’s very easy to not catch. And if you did understand it then it can still be hard to follow and play. I tried a number of things to make it easier, such as only shuffling columns so the rows are consistent (that is you can what level everyone is at) and lots of things around highlighting (the last one which semi-floods connected rooms being the most effective I feel). But it still doesn’t quite work if you don’t ‘get it’ in the first place.
The ‘physical’ lair in Unity. The rooms totally make sense, look!
