On Zombies

Writing a game in Javascript, HTML, and CSS as "vanilla" as I can manage.

Early this year I decided to make a short game out of web standard technologies. My target was a re-implementation of the 1984 Mac game “Daleks,” which was itself a port of the 1970 game “Chase.” I chose it more or less for sentimental reasons. Also because it has a very simple rule set.

In this turn-based game, you try to avoid enemies by moving around the screen tile by tile. The enemies close in on you by taking the most direct path. If two or more enemies collide with each other they turn into a rubble pile. Enemies can also collide with the rubble, which also kills them. Your goal is to get all enemies to collide with each other or rubble piles.

My implementation is still very rough, and in an attempt to avoid IP issues I replaced the Doctor Who theme with zombies. Here it is for what it’s worth. For reasons I have not bothered to figure out it seems only to work correctly in Chrome.

I gave myself some constraints:

• Where I could use HTML, I’d use HTML.
• Layout would be done entirely with CSS.
• No frameworks, just JavaScript.
• Sprites should use the HTML content template standard.
• No data structures not reflected in markup.

It was an educational process, and one I am not likely to repeat. I could certainly take the game a lot further — and probably will — but not as an HTML / CSS exercise.

A couple of observations from the experience, though:

TypeScript is good, actually.

I originally started working with pure JavaScript. But the game became complicated fast, and I found myself staring down confusing bugs that TypeScript would have prevented. I did eventually end up switching to TypeScript.

Manipulating the DOM is still a pain in the butt.

If you want you can look at the source code. I haven’t done (won’t do) a full analysis, but it seems to me like most of the code involves DOM CRUD and associated error-checking. In some cases I created very framework-like functions to abstract this process out into a higher level.

This reinforces for me that the base JavaScript APIs are very low-level (and should be!) but working with them directly is error-prone and tedious. This is why so many non-trivial applications wind up using a framework of some sort (or end up re-creating one).

People’s opinions on this will differ, but I would much prefer to work in a framework that’s well-documented and battle-tested than a bespoke “vanilla” solution.

Emojis don’t make good sprites.

They make fun sprites, but differences in rendering across systems and browsers can make the results unpredictable. If I was going to make this game something more production-ready, I’d be replacing these emojiis with reliable art.

Web components are pretty good insulators.

Once I had the game created as a standalone HTML and JS package, I wanted to get it integrated into my own website. That easily doubled the work, partly due to going down some blind alleys. Finally, I decided to package the game as a web component and that helped a lot.

Running the same language server-side and client-side is confusing as hell.

Part of the problem I had is that Astro — which I’ve used to build my site — is also JavaScript-based. That seemed like a good idea, but it means you have to jump through a few hoops to distinguish code that runs on build from code that’s intended for browser execution. I learned a lot about this in the process, but if I had been using, say, a Go-based tool like Hugo I probably wouldn’t have had that issue.

Browser-delivery has its own issues

Some people are certainly of the opinion that browser-based applications are the way to go over native apps, at least in the mobile space. But the original “Chase” game ran on far more limited hardware than we have today, so it really shouldn’t take much memory. But to run this game you have to fire up a whole-ass browser, complete with its massive rendering engine. That’s a lot of stuff that has to be resident and active in memory. If you’re concerned about “bloat” you certainly have to take that into account.

I went into this expecting it to be a bit more inconvenient than using my typical tools would be, but I was still surprised how frustrating it was. And I, who have always been skeptical of the value of TypeScript, came out of it with new appreciation (and possibly more nuanced criticism).

That said, I really enjoyed working on a game for a bit. I’m going to re-write this one and incorporate a few more ideas into it — except this time, I’m going to write the game in Lua for the Pico-8 fantasy platform.