The Art of ASCII


Just in time for roguelikes becoming mainstream, my own attempt at one (called Dungeon Romp) is taking shape. Third time, it seems, really is the charm. Which doesn't mean this new project is free of problems.

dungeon romp screen

I'm settling for showing you a screenshot, as opposed to a live version, because there's nothing you can do in it right now except wander around. But judging by how it went so far, I'm optimistic about the next stages. Interestingly enough, the one thing that helped me the most is also the most troublesome. Namely, the ASCII display.

See, the reason I went with good old ASCII instead of graphical tiles wasn't tradition, but a desire to focus on game mechanics instead. And indeed, it is a liberating experience when you can just decide that an equal sign represents a wooden plank and be done with it. But there's a snag: emulating a text console inside a web browser is not as easy as it seems.

The most obvious way, using a table, would use ridiculous amounts of memory, unless I go with a much smaller viewport (on the order of 10x10... bleah). A canvas element, on the other hand, would be slow (text on <canvas> is, for some reason), wouldn't work on all browsers and would miss the point of using, you know, text. I could do a clever trick with <span> elements wrapping stretches of identical characters, but that would require a rather sophisticated piece of code known as a state machine...

You'll understand, then, why the current implementation uses a simple <pre> element. Unfortunately, that limits the display to black and white, which in turn makes a jumble out of organic environments like this one. Worse, it prevents me from (easily) implementing a command such as "look" or "target". I tried to supplant the former through status messages, as well as sticking to an unambiguous visual language (more on that below). As for the latter, I could always restrict ranged combat to the cardinal directions -- a fairly common approach.

As for the long term, I can see several solutions:

Come to think of it, point three will be a necessity anyway, if I want my game to be played by anyone outside of a hardcore audience. As for point two, a tighter, coffeebreak roguelike design is more appropriate for a browser game in the first place.

On the plus side, the current technical limitations validate my early decision to have strict rules about how I use the various characters. If you ever wondered whether a green capital "T" is a tree or a troll, you know what I mean. And having each map symbol represent only one piece of terrain -- at least on the same map -- means my game will not confuse color blind players either.

But there's much more to a game than the graphics, hard as it may seem to believe nowadays. Fog of war, stats, combat, inventory... Oh, and more levels. Did I mention level generation? Fascinating topic, that. Stay tuned.