The Aesthetics of Roguelikes.

Interface Concepts

Introduction

Whenever user interfaces of roguelikes are covered, e.g. by postings in the newsgroup r.g.r.d, mainly the question of usability is discussed. Nearly no relevant threads exist which talk about the aesthetics of game interfaces.

The lack of such threads may be explained with regard to the non-graphical history of roguelikes. Convenience and clarity were more important than visual beauty – but this does not mean that a roguelike is forced to look boring or even ugly.

However, aesthetics incorporates more than beauty, and the purpose of this article is to introduce three aspects to build an aesthetics idea for the context of roguelike interfaces.

I. Visual Immersion

Title Screens

The title screen is the first thing a player sees when starting a new game. The title screen’s job is not only to state the name of the roguelike, to tell about the developer(s) and to provide basic options like starting or continuing the game. A good title screen should also be atmospheric enough to draw the player into the game’s world.

Unfortunately, there don’t exist many interesting, well-done examples. Instead of showing individual intro screens, most roguelike games just display their name, perhaps a subtitle, a copyright and a menu. The name of the game becomes the only tool to define itself from others of the same genre – rather little compared to the possibilities even ASCII art offers in theory.

How it could be done is demonstrated by the roguelikes Ali Baba’s Cave and Frozen Depths.

Ali Baba’s Cave, developed in 2006 as 7DRL by Frédéric Back and Sebastian Kutsch, shows two ASCII images during startup and more ASCII art is the game’s reward for successful players.

Frozen Depths was created by the finnish developer Glowie. The game (its current version is 1.0.1, but probably an update will be released in summer 2007) is unique not only through its dark, cold, but intense color scheme. It also welcomes the player with a demonic looking creature, holding a sign with the menu in its claws. The creature stares at the player, taking the role of a silent representative of the game and the world that is waiting for the player.

A similar approach is taken by some multi user dungeons (MUDs). The Dune MUD, for example, displays an ASCII art of mountains and sandworms, drawn in yellow and gray. Motif and colors fit perfectly into the setting of the MUD and the Dune universe.

As the use of such pseudo-graphical screens enhances the player’s immersion into the game, at least at the first moment, I call such titles »immersive title screens« while the others could be classified as »pragmatic title screens« – pragmatic in the sense of a functional approach without any decorative attachments.

Note that, although I wrote »unfortunately« some paragraphs above, I don’t say that the immersive approach is superior to the pragmatic. Although ASCII art is often very pleasant, the use of it for displaying pictures in ASCII roguelikes has to be considered as inconsequent – because displaying pictures at all is inconsequent. I will explain this.

A typical ASCII roguelike is very abstract. One alphanumeric or special character symbolizes exactly one object in the game’s world and the sensual details are left to the player’s mind. ASCII art, in contrast, uses single characters to build a greater object. The single character has no symbolic meaning which could be interpreted by the player – instead it is just a way to »draw« pictures on the screen.

Using ASCII art in roguelikes therefore might look good at a first glance, but may fail to enhance immersion. Instead, it might even destroy the feeling, because the player has to switch from the symbolic world to a more objective one whenever a piece of ASCII art is shown. The moment of this switching is the moment in which the player remembers that he’s just playing, and creating such awareness has to be avoided.

Using immersive (or should they in fact be called »pseudo immersive« when used in roguelikes?) title screens and following consequently the symbolic means of ASCII chars at the same time seems impossible with the mentioned problems in mind. Fortunately, it’s not that bad if we just take the time to think about utilizing our symbolic inventory and using it to display title scenes in the »natural language« of the roguelike.

The various roguelike comics we can find allover the internet (e.g. here for Angband fans and here for the Nethack fraction) are helpful for this. In limited space these comics tell short stories mostly only by using the symbols of the game (though sometimes they reflect the genre on a meta-level, e.g. here).

With a bit of creativity it should be no problem to use this method along with the typical short textual messages for creating more interesting title screens, intro sequences or even »cut scenes« without the danger of breaking immersion.

 

Screen Design

The world of a roguelike is the centre of action. Therefore the map will take most of the available screen space in every roguelike. In order to make the game playable, more or less additional information needs to be displayed. This is mostly done in areas which are separated from the map. How this separation can be done is topic of this chapter.

In »modern« role playing games (e.g. Spellforce 2 on the picture above), interface objects are designed graphically, supporting the overall atmosphere of the game. Some conventions have formed in the last years, and a graphically complex interface seems to be standard.

Roguelikes with a graphical mode, like the Castlevania Roguelike by Santiago Zapata aka Slash, can look nearly like commercial games if the developer spends some time and talent into the interface design.

ASCII roguelikes mostly don’t have such possibilites. If they use only pseudo ASCII but in fact SDL (or another graphics library) for output, the developer has the chance to create a rather appealing environment. WarpRogue by copx, for example, does it well:

The only graphical object is the background texture. In its interplay with the black text areas it creates a dark and depressive mood that supports the gothic science fiction background of the game.

However, with a »true« console mode in mind, it’s not this »micro« screen design (i.e. just the look of certain elements) that is important. Instead it’s the overall, the functional, the »macro« design in which a developer should put his efforts – all relevant data should be displayed in a clear manner to give the player all the information needed to have as much awareness of the character as possible.

Most roguelikes show some data all the time while a complete profile of the avatar can be displayed by pressing a certain key. The screenshots below show three approaches to status displays.

All variants display rather much information and its questionable if that amount was really necessary. The most important value in these three games is health, shown as HP. While Frozen Depths and LambdaRogue show the current HP next to the maximum HP (divided by a slash; other roguelikes, e.g. Avanor, use brackets instead), Angband displays both values among each other.

It depends on the game type and its individual specifica what information are really relevant all over the time.

In Frozen Depths, SP are important, while some actions in LambdaRogue rely on a PP value. As in most roguelikes the avatar can be affected by negative and positive effects (e.g. poison or confusion) for a limited time, it is important to inform about these effects as long as their influence goes on. LambdaRogue displays them in the middle, left from the dungeon view, beneath an area that shows the current equipment (as symbols, like in Angband) and battle-relevant values which result from the equipment.

In addition to these basic stats, Frozen Depths, Angband and many other roguelikes display attributes like STR(ength), INT(elligence), DEX(terity) or WIS(dom). Such values aren’t displayed by LambdaRogue, because they are seen as less important for the basic flow of the game (the STR that is shown on the screenshot has another meaning than the STR in most other games).

Regardless how different the examples look, they have one fact in common: They use numbers. Commercial games often use graphics instead, some kind of diagrams, formatted in the general visual style of the game (e.g. the bowls filled with red and blue liquid to display HP and MP in Diablo). Except the display of enemy stats in Angband, none of the three examples goes such a way (however, several other roguelikes do).

Perhaps it is a specifica of turnbased games that numeric values are favored over graphical abstractions. A number is certainly more precise than a bar, and as you may think nearly endlessly before performing an action such accuracy may be helpful. In real time games, you don’t have the time to weigh all aspects against the others; mostly you have to act quickly, and an approximated value is enough.

II. Awareness

»Awareness« means that the player has always to be informed about its avatar’s status and about everything the avatar is able to see and do. Even better, the player should have the feeling that he is identically to the @ on the screen.

How can this be done? One important aspect, the display of status values on the screen, was already covered in the last section of this article, but there are some other issues a developer could have in mind while planning the game.

One aspect is text. If the map only consists of ASCII chars or simple graphical tiles, there’s not much input for the player’s imagination. So nearly all roguelikes at least display textual messages when entering special places, when fighting, when picking up items or, if available, when chatting with non player characters (NPCs).

The beta of Incursion, already shown at the beginning of the article, goes further. There are not only very detailed descriptions of the different races and classes the player can choose from. Also during the real game longer descriptions of dungeon areas are displayed, enhancing atmosphere a lot. They appear in some kind of dialog windows which don’t hide the complete map.

The map itself is important for awareness, too. Many roguelikes have a command which helps the player to identify the meaning of the chars or tiles used for displaying the world. Only a few games display a description of the current position or mention the currently visible objects as always visible status messages.

It seems that the developers of most games want the player to explore the map and the secrets of the game. Concerning immersion, this is no good behavior, because the avatar doesn’t need to actively look – its very likely that he will recognize a tree when seeing it or a river when swimming in it, without asking himself questions like ’What is this wet liquid in which I am?«

As consequence, a developer should decide: Either he displays descriptions all the time, or he uses the identify command only for objects and creatures which are probably unknown not to the player, but to the avatar.

In this context, and as a last point, the concept of field of vision (FOV) has to be mentioned. A correctly calculated FOV not only makes a game more realistic. It also supports the player with the process of identifying with the avatar. Games without FOV, like LambdaRogue, leave a gap between both subjects. If the player has a full view of everything, regardless if there are walls between the avatar’s eyes and the seen object, his role becomes the role of a god. That does not necessarly destroy the fun of the game, but it surely switches the perspective.

Now, if a game implements FOV, it should also visualize it. Mostly this is done by hiding creatures which are not visible to the avatar and by greying out or darken areas currently not visible. The second aspect is rather important – if there is FOV, but the player is not aware of it, he will also have problems to be aware of the avatars perspective on environment.

III. Connection

The ideal roguelike was a program able to anticipate the next steps the player will take in order to guide his or her avatar through the world of the game. Such an »IdealRL« would do whatever the player wants it to do, without the need of difficult key presses (both in the sense of moving the fingers on the keyboard and in the sense of memorizing complicated key combinations) or further input after a command has been given. These things disturb the connection between player and avatar, and roguelikes – as every game – should try to minimize disturbance as good as possible.

One approach to simplify user inputs has been the invention of the mouse, which soon has become a sine qua non in computer technics. Action-oriented role playing games like Diablo and games inspired by Diablo are controlled completely by mouse clicks. You click on the place you want the avatar to move, you click on items that should be picked up and of course you also click the enemies you wish to attack. This kind of interface is extremely effective.

However, since many roguelikes even run on very old systems which do not have a mouse yet, the mouse is not always supported. Mainly roguelikes written explicitly for graphical user environments like Windows can be controlled by the mouse. A rather new example is Lair of the Demon Ape. Also variants of older games which are ported to – at the moment still – exotic platforms like PDAs or Tablet PCs enable mouse control, which is not always bad. For an example, have a look at the current version of First Age Angband which can be controlled totally in the Diablo-style, although keyboard is still supported.

 

Inventory Management

Controlling means not only to move and to attack, but also to manage the different items one will find when exploring mysterious dungeons, dark caves and dangerous landscapes.

In the famous roguelike Nethack, you press a command key for a certain action and will often be asked to select an item for this action. By default you just get a line like What do you want to write with [- acde or ?*], and acde are possible keystrokes corresponding to items.

The dungeon view will not be lost when thinking about which item to use. This clearly preserves immersion (on the other hand, it’s good that you also have the option to display lists of all available or of all currently useful items; it can be rather difficult to memorize all keys).

Immersion is not only preserved, but even generated by Nethack’s shop concept. Shops are rooms filled with items and guarded by the shopkeeper, and in order to buy something, you first have to pick up the desired item and then pay the bill.

As conclusion for Nethack is to say that you are not forced to leave the ASCII char interface paradigma for item management which helps to avoid staying hours in the »nightmare world of interface« (R. Dopieralski on r.g.r.d) instead of actually acting in the game’s environment.

Other roguelikes try to accomplish that quest for immersive inventory management in other ways. For example, Paprika and LambdaRogue have a similar approach which forbids the player to try actions which will not work because he has no appropriate item. Instead of the actions, the available items are the starting point and only options that can be done with them are available.

When opening the inventory, Paprika displays an unobstrusive box at the upper left corner of the screen. This box shows different item types. By pressing a corresponding key or by using the cursor keys, all items of the selected type are displayed.

Now the item needs to be selected which works exactly the same way. After an item is chosen, the box displays all possible actions one can do with that item. Opening, selecting and using an item requires at least 4 keystrokes. If the player prefers the cursor keys, this number can increase depending on the amount of items stored in the backpack.

LambdaRogue doesn’t group items depending on their type. Instead, bringing up the (here so-called) quick inventory directly shows the first available item, along with name and symbol next to the avatar on the greyed out map. The player can scroll through all items by using the horizontal direction keys. Pressing the down-key selects an item and brings up all possible actions. The options are shown in an up/down, left/right scheme, so that pressing a direction key executes the action that is shown on the corresponding position on the screen.

Advantages of the last two inventory systems are:

• The map is always visible [both games].
• Both inventories are controlled just by direction keys [optional in Paprika].
• The need for eye movement is reduced [LambdaRogue].

However, there are also disadvantages:

• There are never all items visible at the same time [both games].
• Scrolling through a full inventory may last a while [LambdaRogue].
• The display of categories produces one key press more than needed [Paprika].

While Paprika concentrates on one system, LambdaRogue’s quick inventory can be switched off in the game’s configuration file. Afterwards a classical list view like in Angband’s shops will be shown whenever the inventory key is pressed. Showing the quick inventory then needs another key.

Both Paprika and LambdaRogue, but – in a basic approach – also Ali Baba’s Cave, try to implement a new way of inventory management, making it easier for the player to execute desired actions without changing to often the controlling paradigma and loosing connection to the avatar. It surely would be interesting to do a survey among roguelike players and to ask which system is doing the job better.

By the way, comparing different roguelike interfaces in an usability laboratory could lead to interesting findings. Unfortunately, the cost of such a study would be far too high than one could pay out of the petty cash. As the relevance of roguelike games for human society is rather small, it’s also very unlikely that financial support for such a project could be obtained from another source.

Conclusion

This article discussed various aspects of roguelike interfaces. »Aesthetics« in the interface context involves

• deep immersion into the game’s world
• full awareness of the avatar and the environment as it appears to him
• seamlessly connection between player goals and avatar actions

The aspects can’t be seen singularly and parted from each other. Instead, high awareness is the consequence of deep immersion, and seamlessly connection enhances immersion. However, if a roguelike manages to create a balanced state between all these issues, that game could be considered as »aesthetically pleasant« – which of course would state nothing about the overall quality (that’s why the aesthetical impression is just one value for calculating the rating in this magazine’s roguelike reviews).

We now come to an end, at least for this part of the »aesthetics in roguelikes« series. It was not possible to cover all aspects that detailed as necessary. I would be happy anyway if the text was able to give some useful hints and impulses for everyone who has to create an interface for a roguelike.

Mario Donick