Roguelike Review
Home ] News ] Intro ] Topics ] Reviews ] Previews ] Discussion ] Download ] Links ]



<-- Back to Topic 003 Return to Topics Index Forward to Topic 005 -->

Topic 004 - ASCII Interface

INTRODUCTION

One of the most immediately recognizable features of Roguelike games is their reliance upon an ASCII (text) interface for both input and output.

  • input - the game is controlled using a keyboard instead of a mouse, joystick, or other controlling device
  • output - output is restricted to the ASCII character set, so all visible objects in the game are represented using ASCII symbols.  For instance, ------ might be used to represent an East-West wall and B might represent a giant bat.

Some of the newer Roguelikes have replaced or supplemented ASCII with pixel-based graphics and/or mouse-driven controls.  However, the most popular, polished, and complete Roguelikes are ASCII based.

Check out the screen grabs on the Game Review page to see what I'm talking about.


PROS  (prospective developers, take note!)

"Why ASCII?  It's the 90s, darn it!!!"

Well, first of all, an ASCII interface helps make Roguelike games available to a wider audience.

  • The initial reason for the persistance of the text interface well into the age of mice is that it allowed Rogue and its children to be played remotely over modems and networks, with no need for client software other than telnet.
  • Also, text interfaces are typically far more portable than GUIs (Graphical User Interfaces), so Roguelike games are often easily ported to different platforms and operating systems, including various flavors of UNIX, DOS, Windows, Amiga, OS/2, Linux, etc.
  • Another reason for limiting the interface to ASCII is that such a game can be played on older, slower, less multimedia-endowed computers.


ASCII also provides an extremely dense, precise, and efficient mode of communication between the game world and the player.  This allows Roguelike games to be much more complex than similar graphics-based games.

  • Given an 8x8 area, you can represent a larger set of quickly recognizable objects in ASCII than you can with graphics.
  • We are already familiar with ASCII characters and can quickly and reliably recognize differences between them.  It's easy to represent 1000 different monsters using only 100 of the 200-some printable ASCII characters and 10 colors.
  • Imaging having to represent 1000 monsters by DRAWING them in an 8 bit by 8 bit grid.  Not only would it take forever to design them, but they'd be hard to recognize (especially if they represent unfamiliar objects such as rothes, phials, grid bugs, etc.) and distinguish from one another.
  • If you enlarge the tiles to improve recognizability and descriminability,  you unavoidability end up reducing the number of tiles on the screen.  This shrinks the view of the game world and requires that the player either scroll (which takes time) or play more cautiously (which also takes time).
  • Alternatively, a developer could choose to stick with 8x8 but represent fewer objects or  overload object representations.  This either shrinks the game or requires the player to either guess or request the precise identity of objects.  Neither compromise appeals to me.
  • The bottom line is that whenever you use graphics instead of ASCII, you inevitably end up sacrificing either representational efficiency, safety, variety, or scope.  Often it's all of the above.


The second part of the ASCII interface is keyboard input.  Once again, ASCII allows a much richer, safer, and faster means of communication than a mouse or joystick-driven interface.

  • Keyboard input allows quicker access to a larger command set.
  • More commands means finer control which in turn allows greater individuality to creep into your play.  This sort of micro-managing expressiveness is exactly what you want in a turn based, single-point-of-view, role playing game.
  • Also, as someone pointed out recently on one of the newsgroups, Roguelikes tend to be arranged in a rectangular grid.  Since the game is turn based and from a single point of view (the "@" cursor), actions don't need to be buffered and are handled immediately.  Movement takes place one space at a time, much as it does in any text editor; the directional arrow keys are therefore a much more natural means of controlling movement than a mouse or joystick.
  • For non-movement commands, mouse input would require menus or a button-laden screen area.  All that hunting and clicking takes time.  Plus, dozens of frequently activated commands would take a lot of menus and buttons, which clutters up the screen and further shrinks the player's view of the game world.
  • Keyboard commands can be more easily combined into macros and customized via keymapping.
  • Many of the keys on the keyboard are also symbols on the screen.  This provides an opportunity for making certain object-manipulating commands easier to remember.  (e.g., to descend a down-staircase ">" you hit the ">" key, to pray at an altar "_" you might hit "_").

CONS

The primary disadvantage of an ASCII interface is the necessarily high level of representational abstraction.  The only way it's not going to be abstract is if your game universe consists entirely of ASCII symbols.

Since the abstractions used are unique to the Roguelike genre (and often to individual games within the genre), the end result is a huge learning curve.  10 years after my introduction, I'm still learning...

  • As an example, a bat in NetHack does not look like a bat; it looks like a "B".  A Roguelike newbie therefore has to learn what a bat looks like.  In other kinds of games (like 3D shooters), bats look like bats.
  • Likewise, to eat the bat after you've killed it and picked it up, you need to type an "e" and then the character that represents its inventory slot (whose identity depends upon your character's former acquisitions).  In a graphical RPG a typical way to eat a bat is to click on it and drag it to your character's mouth.
  • Of course, over time, you become more familiar with the Roguelike interface.  Once you learn the abstractions, you can do more and experience more per hour than you ever could in a graphical Roguelike.


Also, ASCII isn't visually impressive; it lacks Baldur's Gate wow-factor.

  • It lacks novelty  (we see it every bleepin' day)
  • It reminds us of primitive BBS games like StarTrek, Empire, TradeWars, etc.
  • It doesn't provide many ambient details  (makes it difficult to convey a mood)
  • It doesn't provide textural variety  (lack of mood, might be visually wearisome)

THE ALTERNATIVE: GRAPHICS

There are two types of graphical Roguelikes.

  • The first are "dual-mode" versions of existing Roguelikes (e.g, SLASH'EM and some compilations of Angband variants).  These let the user choose between an ASCII or tile-based display.  The choice of display does not affect the game behavior itself.
  • The second are graphics-only Roguelikes (e.g, Rogue's Quest, Ragnarok).

ASCII-only and dual-mode Roguelikes tend to be more detailed, better balanced, less buggy, more portable, denser, bigger, funnier, better documented, better maintained, and consequently more popular than those with just graphics.

This is mostly pixel-based graphics take much more time to program than ASCII.  Every hour spent on graphics is an hour not spent on adding detail, testing, expansion, testing, documentation, testing, humor, testing, and testing. :)

Dual-mode graphics are usually implemented, tested [ugh, there's that word again], and documented by "third party" developers separately from the game itself.  Consequently, adding a dual-mode display to an existing Roguelike is usually a mere matter of simple patching and does not significantly cut into the game's essential development.

Games that have been developed with graphics from the get-go have to work twice as hard just to get the same features, depth, and robustness as their ASCII cousins.  Most are abandoned before they gain more than a couple dozen fans.

See my topic on A la Carte Gaming for a discussion on how better modularity in Roguelike games (such as providing a dual-mode display) can help developers and gamers alike.

HISTORY:

Graphical Roguelikes have been around for quite a while on non-PC platforms.  Erik Bolsų, author of the Roguelike Geneaology (see links),   writes:

Amusing facts: C64 Telengard (1983) has bitmapped graphics...  Mac Dungeon of Doom (mid-80's) had B&W bitmapped graphics...  ZX Spectrum Rogue (1987) sported bitmapped graphics and point-and-click interface...  AmiOmega (1990 or so) had quite fancy graphics...  Crossfire (1992) has tiled graphics...

Thanks for the info, Erik!


ASCII versus GRAPHICS: THE VERDICT

I love ASCII in Roguelikes.  I love the density of information and the fine control it gives me.  I love tables, statistics, and lists, all of which are encouraged by Roguelikes' text-based nature.  I love the speed (both processing and gameplay) granted by ASCII.

And I love how smart ASCII makes me feel.  It took me a long time to be able to make sense of all those characters and squiggles on the screen, and I'm proud that I can understand it all now! [well, at least most of it...]  Likewise, it takes a lot more brains to pick up and quaff a potion of healing in NetHack than it does to step on a powerup in DOOM, so the act itself is more rewarding.  And then there's macros, enscriptions, setting all those billions of options...

Playing and especially learning Roguelikes is hard work, and as a result I get a much greater sense of accomplishment when I play Roguelikes than when I play graphical RPGs.

Also, ASCII doesn't foster representational expectations, and therefore it cannot dissappoint in the areas of drawn artwork, sounds, or animation.   Though ASCII cannot set moods, it cannot ruin them either.

For instance, say I'm playing a graphical RPG and I see:

  • a comical looking dragon
  • squarish looking worm masses
  • food rations that appear the same size as giants
  • kobolds whose noses are too phallic for my tastes
  • pudgy little elves with pointy ears and boxes of cookies
  • skeletons with the wrong number of ribs
  • naked nymphs that scream "oh baby, do me now!!!" every five seconds
  • naked shopkeepers  (ugh)
  • naked dwarves
  • naked ringwraiths

You see, in a graphical RPG, there's plenty of opportunity for me to get annoyed, embarrassed, or distracted by what I regard as mood-wrecking or poorly rendered graphics (or sounds or animations).  When I'm playing an ASCII Roguelike, I don't have to worry about this happening, because dragons look like 'D's, worm masses look like 'w's, food rations look like '%'s, giants look like 'P's, etc.  There's not a single ASCII symbol that threatens to offend me or throw off the mood of my game.

Not only that, but I think I need ASCII.  I am so used to '%'s and 'P's and typing "maa" by now that graphical tiles and mouse interfaces slow me down.  I have tried many times to "get into" the optional SLASH'EM and Angband tile sets because I like the look of the terrain, but I inevitably find the object and monster representations too difficult to parse, and I end up switching back to ASCII. 

AngbandTk (and the other Tk variants) come closest to satisfying [me] by offering a somewhat schitzophrenic, "best of both worlds" mode in which terrain is represented graphically while items and monsters are represented with ASCII characters.  However, AngbandTk has its own problems such as bugs and a lack of window customizability.

The bottom line?  As of Feb99, my favorite Roguelike interface is the one provided with the MS-Windows version of Angband (and Zangband, etc.).  It gives you 8 permanently visible, extremely customizable windows so you can get lots of useful information at once (I use 7 of them and fill the whole screen), an option of ASCII or tile-based graphics, and optional sound.   It gives me more control over what I see than any other Roguelike interface.  -more-

And control is what it's all about, baby!


This page managed by txe@swa.com Last modified: 23 March 1999

Note: these are fan pages and not to be considered "official" or "authorized!"