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

Game screenshot made of black-on-white ASCII characters forming an abstract map, with status messages above and below.

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.

Comments

If you want to have an angband / Ultima style “field of view” to go along with your fog of war, I found this library to be great:

http://code.google.com/p/libfov/

It’s in C, so it won’t work with your javascript. But you can at least use it as a coding guide for such a beast 🙂

— Cheetah

Thanks. There are many algorithms, including some simpler ones. RogueBasin has a nice selection. But I have plenty to do before having to worry about the FOV.

— Felix

For your terminal information, how about doing an array of DIVs each containing an array of one-character monospace SPANs? Then you can control the content and the style of the SPANs separately, and even just put references to all the character SPANs into a separate two-dimensional array (or even make a two-dimensional array of objects that handle the SPAN attributes using dynamic JS properties).

— fluffy

Actually, the natural solution here would be to use a table element. Unfortunately, it would end up having 1600 TDs, which means 1600 DOM elements, which means… tons of RAM. And it just seems ridiculous to have a simple roguelike (text-based, no less!) use up so many resources just because it happens to be running in a browser.

— Felix

Well, a browser isn’t a dumb terminal. One could argue it’s pretty ridiculous to want to emulate a dumb terminal in a browser to begin with. 🙂

As a compromise you could have your PRE contain 1600 SPANs to allow the formatting thereof, which is the same order of magnitude of memory use as the table (as was my previous answer) but at least it would run pretty efficiently (I think). But a PRE is really just a DIV with a couple of default style rules anyway.

— fluffy

Yeah. I’ll just go with more geometric levels until I can get actual graphics for the game; the browser version is going to need it anyway. But, gameplay first.

— Felix