Home

What’s working:

I’m enjoying the “look and feel”. Games like Brogue and CogMind, built with the libtcod toolkit or related tools, have defined a new graphical style for roguelikes that combines classic ASCII (or Unicode) glyphs with sophisticated lighting and color interpolation effects. I haven’t spent much time on lighting yet, actually – my main goal has been to use color and symbols in a way that are visually pleasing but also communicate as much information as possible about a three-dimensional world on a two-dimensional grid. The logic that decides which symbol and colors to render on a tile is over a hundred lines long, all in the service of making sure the
The basic architecture I’ve chosen, which composes “entities” by attaching “behaviors”, seems much more robust than inheritance-based hierarchies I have used in the past.
Task assignment and zombie behavior seem to fundamentally work, and the logic seems to be scaling okay as I make the tasks more complex.
Hosting the game on a GitHub page makes it easy to test and update.

Scarcity and conflict. So far there are no hostile monsters and no real constraints on resources. Some ideas:

Wandering monsters that attack.
Waves of monsters that attack.
Zombies have limited lifespan (i.e. they rot.)
Maximum number of zombies that can be controlled at once, or risk of rebellion when controlling too many zombies.
Tasks have prerequisite ingredients – rocks for walls, wood for doors, et cetera.

Overlay windows, once I figure out the CSS layout issues:

Various performance issues you don’t care about, mostly relating to saving and restoring games.
I’m not at all happy with the way lighting currently works, per the day-night cycle. And because the rules for displaying color are already somewhat “overloaded”, I’m concerned as to whether adding another layer of logic on top of that might make things less clear.
Some day I’ll presumably have to migrate this to a client-server architecture.

Turf features on liquid-laden tiles show the foreground color of the turf, not the liquid. This may or may not be what I want. Showing the liquid's foreground color is a visual warning that digging there will cause flooding. On the other hand, showing the liquid's foreground implies to me that the ground is sodden, which could be distracting if it has few real consequences.
Serializing currently saves a great deal of unnecessary information. First, we don't need to save both the xyz coordinates of an entity and its position on a list. Second, many features, such as ordinary grass and still water, can easily be serialized as a single symbol without losing any relevant information.
There are currently several ad hoc ways for determining how many stackable items of a certain type are generated under various circumstances. It's probably safer to handle it in a unified way.
The console shows non-fatal errors under some circumstances if you hover the mouse outside the game display.