Strangely Consistent

Theory, practice, and languages, braided together

July 26 2012 — doom and cavern collapse

If there is one thing I regret from the design of last year's game, it's making Doom a thing.

Now, Doom was simply what killed you in the game. It was the only thing that could kill you, in fact. But it wasn't really a thing in the game. You couldn't pick it up, or see it. It wasn't anywhere. It just killed you. But at that point, I had already created separate classes for most things in the game to give them special behaviors, so creating yet another class for a non-thing felt bad, but not very bad.

This year, I'm doing it right. In case you were wondering.

"What's right?" I hear you ask. What's right is a factoring which doesn't need to put this functionality on an object, but just allows the game engine to carry out what Doom used to do. Which, if we look at it, was three things:

The interesting new technology here is fuse hooks, delayed actions which you put into the game as closures. Other kinds of hooks go off when things are handled in certain ways; fuse hooks go off after a given number of ticks — discrete player actions.

Unless the game engine decides to defuse the fuse hook, in which case it never goes off.

Note; this kind of factoring of things feels entirely natural and in line with the rest of the design. I'm happy.

I ran to jnthn (on IRC), waving my arms enthusiastically and shouting "closures are awesome because they give downstream the freedom to supply arbitrary code, while giving upstream the freedom to choose when to invoke it!" jnthn said everyone already knows this. So, um, well. OK. 哈哈

Anyway, we're well positioned to implement the last room of the game tomorrow. Then the rest is just polishing and refactoring.

A hat tip to lue++ who contributed a failing test today. lue, your test now passes