I spent most of the month working on reviving a game I started writing in 2004, called Demon of the Fall.

Demon of the Fall was a way for me to pay tribute to my favorite game, Solstice (and its sequel, Equinox, and related isometric puzzle-platformers like Head over Heels). It started as a straight-forward clone, but as Retsyn and I worked together on it, we came up with some uniquely appropriate gameplay elements. I won't say too much about that here, though, because I will probably be giving Demon of the Fall another shot later this year.

All I'll say is that music is central to Demon of the Fall. Because February is also the month of the RPM Challenge, I decided I could get rid of two albatrosses at once by recording the soundtrack as my album for RPM¹, and completing Demon of the Fall.

I started with the best of intentions, as we always do, and resolved to do a little work on it every day. However, the code was in an unusable state in the darcs repo I found, a casualty of a "refactoring" gone wrong.

Over the course of the year, we will examine more of these corpses, and in each case, the cause of death will be the same: refactoring without tests.² I'm sure 2004-me could have given you countless justifications for making these changes without unit tests, but they were all wrong, as 2015-me gets to discover, again and again.

I'll talk about this more throughout the year in these #1GAM posts, but let me just relate this to what I got out of February:

Christer Kaitila talks about the wall as a reason games don't get finished. That's the point where it stops being the drug-like rush of implementing interesting stuff and becomes all about patience, discipline, and other dirty words you spend your early adult years trying to avoid.

I think that a lot of my projects had a cycle like this:

• inspiration strikes: I hack out something in a frenzied night or weekend;
• there's enough kindling that the fire burns while there are interesting problems to solve and clever algorithms to implement;
• but the logs don't catch, and what remains to do is boring (which we dismiss as "too simple" to preserve our ego, though the truth is it's actually "hard but not fun");
• time passes, and I wonder whatever happened to project X;
• I jump in, but I realize the code is a complete hack, or I've learned a much better way to do some major structural thing, or my knowledge of whatever novel programming language I used has completely changed;
• instead of proceeding cautiously (or better yet, just doing the hard-but-not-fun bits), I start cutting huge swathes through the code, breaking everything – "We had to destroy the code in order to save it".

Thankfully, at some point I turned around and saw the trail of dead projects stretching back for miles. Awareness was the first step; I also tried to improve not only my testing and refactoring habits, but also my version control habits (an area where DVCSes have helped a lot). Now I recognize when it's happening, and avoid the sunk cost fallacy that can accompany breaking changes ("I can't revert these commits, they were so much work!").

Anyway, it took a long time to not only undo some of that damage, but also to modernize the code and port it to Windows. Although I worked diligently, an hour or two a day was not enough. My kanban board was like a frozen river.

On February 22nd, I realized that, even if I could ignore all my other work (which I couldn't, since money pays for electricity and guitar strings), there was no way to get Demon of the Fall done by the end of the month.

After January, though, I had come up with multiple backup plans, in case my primary game for any month didn't pan out. These were mostly plans for clones of simple but fun games that I like. After a bit of deliberation, I decided that I would write a clone of Tricky Kick, a PC-Engine game in the fine tradition of puzzle games about kicking or shoving things, such as Kickle Cubicle and Mendel Palace.

Tricky Kick's puzzles have an excellent property of inducing Einstellung through suggestive placement of the pieces.

One of the reasons I had Tricky Kick in mind was that I had worked on a solver for the levels before, as well as Rush Hour and other Sokoban-like games.³ I knew it had simple mechanics I could implement quickly, and minimal art requirements.

Because of the simple, grid-oriented game state, I considered writing the game with a roguelike interface:

****************
****************
*.*****..*****.*
*.1***....***2.*
*...*....@.*...*
*...3..12..3...*
*...3..12..3...*
*...*......*...*
*.1***....***2.*
*.*****..*****.*
****************
****************

Indeed, the tests still use this ASCII representation:

let kicked_beast_with_no_obstruction_wraps_til_player () =
  compare_boards "
.....1
.1@...
" "
.....1
..@1.."
    (fun it -> move Left it; kick it)

It seemed like something that would be fun in a vector-oriented language like J, but I realized that resolving collisions would be tricky to do idiomatically in J, since they are much easier to deal with sequentially than in parallel.

I had been doing a lot of work in OCaml lately, and since I had prototyped some of my shape grammar stuff with OCaml and the Tsdl bindings for SDL2, I figured I could use a decent language and still get things done. I had delivered software under Windows and OS X with OCaml before, so I figured the porting friction wouldn't be too bad.

In the first ten levels of Tricky Kick, you are kicking adorable animals into each other so that they explode. This is a little bizarre. ZooKicker seemed a suitable name to play on that idea, and I had figured I would draw a bunch of hyper-cute animals to kick around in keeping with that surreal theme.

Of course, none of that polish got done, so the game should really be called SquarePusher RectangleSlipper. What happened?

So, as a result of this project, I have now added two more code dumps to the FOSS landscape, despite resolving to avoid this. I'm going to write more about this soon, but I've realized that I have been a poor free software citizen over the past two decades: I would just leave a tarball somewhere to gather dust (or open a public repo, in the github era), rather than tending my open source code like a garden, and I am changing that.

I still believe code dumps are better than not releasing code at all. Sometimes it's much better to be able to build on someone's unmaintained implementation of something than to start from scratch. That said, there's something unconscientious about it.

There is, of course, an irony about pointing this out in a post about a game like this, which is often the purest form of code dump, since games are rarely maintained.

What have we learned?

• learning lessons is hard;
• content has to come into the picture early;
• never do more than one new thing at once.

Is this a game? Yes. Can I release this? Yes. Am I disappointed? Sure, but March is another month, and all I can do is try again.