Roguelike Magazine Issue 1

This is first issue of the Roguelike Magazine, copied from here to preserve it. All articles written by Mario Donick.

Intro.

Series: The Aesthetics of Roguelikes

Most of today's gamers, when presented with the ASCII-interface of a typical roguelike, immediately dismiss it as old, graphically unappealing, and boring. These sceptics refuse to have a deeper look into the game's mechanics and its »inner values« and it takes time and effort to convince them to just try to discover the fun roguelikes have to offer. The outward appearance of the game is not as important for a roguelike as it is for a more modern, commercial game.

However, an interesting task is trying to raise a player's awareness of aesthetics as they apply to this genre. The current and the next issues of Roguelike. The magazine will cover six aspects of this topic:

We start by having a closer look at different interface concepts, taken from well-known games on the one hand and from not-so-important or even dead games on the other hand. We'll also address the issue of typography - as ASCII is the default for most roguelikes, the role of fonts is very important.

The next issue of RTM will discuss the various graphical tilesets that can be used to extend the default appearance of many roguelikes. We will also reflect on language in roguelikes, not from a linguistic point of view (although this would be very interesting, too), but in the sense of literature.

Finally, in RTM #3, we'll first cover soundtracks and music, before we'll talk about roguelike-influences in other genres of art.

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

various title screensThe 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.

Title screen of Dune MUDUsing 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

Various RPG interfacesThe 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.

Interface of CastlevaniaRLRoguelikes 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:

Interface of WarpRogue

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.

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.

Animation: Paprika inventoryWhen 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.

Animation: LambdaRogue inventoryLambdaRogue 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.

Typography

The knowledge of the aesthetic, user-friendly and successful use of fonts is called typography. While there are numerous books and websites on this topic in relation to print and screen design, there don't exist similar works on effective typography in text based computer games, esp. roguelikes. Well, this is no surprise, of course. However, this article tries to give some general hints one should keep in mind when developing a roguelike.

The first line we have to draw is between real console roguelikes which run without a graphical environment and roguelikes which need a GUI, like Windows, X or Aqua. The latter either use TrueType or OpenType fonts or they depend on premade letter tiles, so actually graphics. Console roguelikes have the potential to run everywhere, while pseudo ASCII roguelikes can profit of a greater choice and a better display of letters.

Console Roguelikes

24, 25 or 50 lines? This is the first interface decision a developer of a console roguelike has to make. Games with 24 lines will run in almost every terminal emulation, games with 25 lines mostly, too, but games that require 50 lines to be displayed correctly can cause some problems. Ironically mainly when executed within a graphical environment.

The more lines are used, e.g. for displaying larger parts of the world at one time, the smaller the font will be. When in a non-graphical environment, mostly the built-in font of the computer or the terminal is used; as this font was created especially for this certain »resolution«, it's mostly quite readable. However, when using a terminal emulation in Windows, KDE, Gnome, MacOS or any other GUI, the player himself has to care about a proper font display. Unfortunately, using a 80????50 game in a typical desktop environment (where parts of the screen are covered by a taskbar and/or title bars of windows) and with a resolution of less than 1000 pixels in the vertical direction forces the player to use a very small font. These may look not only ugly, but may also become unreadable for the eyes after a certain amount of playing time.

So an 80x50 console roguelike can lead to the paradox situation that it can only hardly played within a typical desktop environment running on a modern computer. Of course it would be possible to just use a real console, but many players like to play roguelikes while having open other programs and windows.

It would surely be a good idea that roguelikes which can run with 50 lines don't require more than 25 lines. It could be done in a similar way commercial computer games do it. When the resolution is low, reduce the amount of interface elements or decrease their overall size. When the resolution is high, display additional information or increase the size of the elements. It is not very hard to write flexible output routines which adjust themselves automatically to different terminal sizes.

GUI Roguelikes with TrueType Fonts

Roguelikes written for a graphical environment and using the standard forms of this environment have the possibility to use nearly every out of the installed fonts. Want a roguelike in Comic Sans? Well, it will be ugly, but it will be possible. You want a game in Times New Roman 40pt? Just make it so.

Happily nowadays there exist many fonts which have been created especially for screen output under graphical environments. Rather famous are for example Georgia, Lucida Sans, Verdana, Tahoma or Trebuchet MS. These fonts look good even in smaller sizes. When thinking about font use in a game, consider always to use one of these fonts (although there exist some other which are as good as these; no, Courier New does not belong to them). Graphical Roguelikes with ASCII Bitmaps

The best balancing between freedom of font choice and safety of displaying the font is available to roguelikes which use a graphical tile engine for displaying letters. A complete alphabet is available in one bitmap file and the program blits small parts of this file to the screen, depending on the letter which has currently to be drawn.

The developer has the total control over the font used in this bitmap and he can be sure that it will look exactly the same on the player's PC and his own computer. However, this involves a certain responsibility. If the developer selects a font which is objectively hard to read, the player has no possibility to change it, except editing the bitmap file.

Colors

Except you are developing a game or a version for blind people, you should use colors to help the player with recognizing the different characters and their meanings. This is independent from the selected font.

Beware that colors in console roguelikes may look different depending on the operation systems or the settings of the terminal. So always test the look of your game under all environments you are releasing for.

Avoid the use of too many colors at the same time. This would be confusing and, even worse, exhausting. Try to choose a small, but efficient subset of all available colors. This advice is especially true for roguelikes in graphical environments, because there you theoretically can choose from millions of colors.

Finally, keep in mind that there might be colorblind players of your game.FOOTNOTE 1 If you are trying to have a somehow realistic coloring, mainly green grass and red blood, but also blue water or yellow gold could be problematic. In that case, you might think of making colors configurable or use symbolic instead of realistic means of colors.

To test how your game will look for achromates, you can make a screenshot of your game and store it on a server. Then you can use sites like Colorblind Web Page Filter to see your screenshot with colorblind eyes.

FOOTNOTE 1.Thanks to Billy Bissette (see comments on this article) for making me aware of this topic.

7DRL Contest 2007

Tactics on the Net: War of Wizards

In this year's seven day roguelike (7DRL) contest, english contestant Icey, mainly known for his in-dev roguelike Paprika, managed to develop and actually release a tactical roguelike for two players. Would its name be shortened, it would be WoW, but we don't talk about World of Warcraft. Instead Icey's game is named War of Wizards.

One vs. One

The parties of this war, however, are just two persons - mighty wizards in a random generated dungeon, with the goal to wipe out the opponent. A memory sneaks in my mind at this point - Orthanc, Middle-Earth, where Gandalf fought against Saruman. Although WoW has no plot or story behind its simple, but effective mechanics, and although it has nothing to do with existing literature, it immediately made me travel to an inner - phantasy star on which everything is possible.

WoW on LinuxWar of Wizards has been written in Visual Basic 6, so it needs Windows and the VB6 runtime. All other requirements are met by the download, so unpacking the zip-file and starting the game is all one needs to do. Non-Windows-users may be happy to hear that WoW seems to run smoothly using Wine (tested with Wine 0.9.32).

Besides playing the actual game, the program also offers a chat function, so even the community aspect will be retained when playing together WoW.

How it Works

Often it is said that multiplayer roguelikes are impossible, due to their turn-based nature. In the past, games like MAngband have proven the opposite. Now, with War of Wizards, there's a new example of working multiplayer, although it is restricted to two participants who fight against each other.

The first step after unzipping the game by both players is to find out at least one IP address. This address is needed to connect two WoW processes. While one player starts to »listen« for the second player's program to connect, the second player has to enter the IP of the waiting player. Once done - and not behind a restrictive firewall - both players should see their @ and the parts of the dungeon the @ is able to see.

As WoW implements line of sight, there are typically two stages in every game. At the beginning, one has to find the opponent in order to make most spells work. Once found, the real battle can begin.

WoW: A freshly started game

The spells are the sole possibility to harm the enemy and make its HP decrease to zero. They are, however, not casted by readings scroll found in the dungeon or similar items. Instead the game offers randomly generated choices of possible actions. In one turn, you might have the choice to teleport to another part of the dungeon. In the next turn, you might have the chance to cast thunder bolts. You might, it's never clear which spells will be offered next.

Like a Board Game

In some sense, War of Wizards reminds me of classical board games. In typical roguelikes, you explore the dungeon to find an artifact or destroy some evil creature. In WoW, the dungeon is similar to a randomly generated board and the wizards are the pieces one has to move.

The wizards have to be positioned into a tactically advantageous position. Afterwards, the best of the available spells has to be casted, always regarding the current dungeon layout, the different properties of the spells and, of course, the health of both wizards. One false decision and the game may be lost.

It's very interesting to be forced to always re-think a given situation due to the random spells. So the game offers a good mixture of short-termed (re)actions and long-termed planning to conquer the enemy.

The Future

There is, however, some potential for improvements and it would be great if this 7DRL turns out to become one of the greater roguelikes one days. Icey already confirmed that it could be possible for both players to work together to explore a dungeon, and with some rewrite of the network-code (at the moment both instances of the program have the same rights; to support more than two players a server version of the game was needed) it would be possible to increase the number of involved players.

It makes fun to play this game and I would recommend trying it out to everybody who is interested in new paths which roguelikes can follow.

The Seven Day Quest

One of the successful contestants on this year's 7DRL contest is Glenn R. Wichman / capmango, who recently released his webbased roguelike The Seven Day Quest. The roguelike is written entirely in HTML and JavaScript, no Flash or PHP-stuff added.

The author's participation in the contest is the first of three contests he wants to take part in (according to his blog, there's still a 24 hour comic to draw and a one-month novel to write), and the name of his roguelike surely is a ironic reference to these goals.

What To Do

The Seven Day Quest: Town LevelThe object of the game is easy: Within one week, you have to explore seven areas (called realms), e.g. a forest, a castle or a desert, each consisting of several levels. Hidden somewhere in the areas there are seven lost amulets and you have to - of course - find them and bring them back to Wentora, your home town. There, the tourist season will begin soon and the amulets are one the main targets for visitors.

After the game has begun, you can decide by yourself which area to visit first; when you start, a timer begins to run and with every turn it increases. When this clock has reached 24:00, the game will be over, but if you succeed in carrying one of the amulets to Wentora, it will be resetted to zero.

User Interface

Controlling the game differs not very much from other roguelikes. Move your @ with cursor keys, pick up items with p-key and use portals and steps with < and >, (or, alternatively, by pressing Enter).

While the realms are displayed using graphics, for the character, the monsters and all items capmango uses ASCII-chars. ! is a potion, ? a scroll etc. However, the ASCII-chars are in fact transparent PNGs, so the fonts on the player's computer are not used. There are several variants of the ASCII-PNGs, adjusted to the current realm-style. This is good on the one hand (as it makes everything more consistent), but bad on the other (because sometimes it's hard to read). Anyway, I'm sure the latter is easy to improve.

The Seven Day Quest InventoryThe inventory is represented by simple choice boxes. Every box contains one item, plus options to use the item. As only relevant options are shown, the handling feels very user-friendly. This is important, because you will soon stumble upon lots of items.

Beneath the dungeon view and the player status, there's the message area, followed by several buttons which are used to start a new game, to view the help file or to adjust the game's balancing. With this option it is possible to change the difficutly of the game in detail - from the strength of the enemies to the amount of items generated.

The Seven Day Quest ScreenshotAdjusting some of the mentioned factors is really necessary, because - sorry to say this - the default balancing of the current version sucks. Getting killed by a kobold on level 1 after one hit was an unexpected event.

Final Thoughts

The realms only differ in the tile-style that is used to show them. The rather slow random dungeon generator does not create realm-specific layouts, there is no character generation, saved games disappear after closing the browser window FOOTNOTE 2 and the HTML is no XHTML. Although all these points can be mentioned, there's no reason to criticize them. The Seven Day Quest is a roguelike written in only seven days and especially the speed issue is clearly a problem of the platform. The game is, as far as I know, the first roguelike using only JavaScript and HTML, and it does it well.

Overall, the game is really fun, due to its simplicity. You don't have to memorize dozens of keys, you don't need to think of complicated concepts, just try to survive and find the amulets. Here's the link, again: [babelsphere.com/7dayquest/game] .

FOOTNOTE 2. Correction on 2007-03-19: Saved games don't disappear. Instead, they are stored in cookies that expire after one year.

Save Scummer

The third 7DRL reviewed in this issue of RTM is Save Scummer by Jeff Lait who already released two other 7DRLs in the past - namely Letter Hunt and You Only Live Once - and who is developer of POWDER, a roguelike for the GameBoy Advance. While You Only Live Once has bypassed quick game overs by just letting the player control another character after the first one died, Save Scummer goes completely mad.

In principle, Save Scummer is an interactive bot. First naive attempts to control the @ by the player fail, only two keys work. The right direction key goes forward in time, the left direction key goes back. Every turn the bot continues its journey through the dungeons. The readme of Save Scummer calls this ironically »Intelligent 'Do What I Mean' commands that reduce all possible actions to a single keystroke«, a statement which seems to be a sideblow on too simplified user interface concepts.

Save Scummer screenshot

The game as whole can't be taken serious and I doubt that the author does it. Instead it's a well-done parody on the genre and on players who always make copies of their save files. »Good thing you made that backup savefile!« is displayed every time the bot dies (which, in fact, occurs not very often, as the bot seems to be rather intelligent). More irony is given by the welcome message. It refers to roguelikes with large amounts of text; text which is often skipped by impatient players.

Although there is no real game in the game, it makes fun for a while - watching the bot conquering the enemies, clearing dungeon levels and diving deeper and deeper is quite exciting and simply looks cool. Will he survive or will he need to go back in time and try another decision? Because of this, Save Scummer would make a great screen saver, and it also shows how non-textual, non-ASCII-art intro sequences or »cut scenes« in a roguelike could look like (read the article on interface concepts for more details of this problem).

Roguelike Languages.

Gambas

[i]The column »Roguelike Languages« introduces several well-known or not-so-well-known programming languages in which somebody can write a roguelike. It is assumed that you already have some basic knowledge about programming techniques.[/i]

This first issue of the column talks about Gambas, a language for Linux and very similar to Visual Basic, but with its own flavor. The word »gambas« means »prawn« in spanish. However, it's also an acronym which stands for Gambas Almost Means BASic. This describes the language pretty good, as the syntax is nearly 99% compatible to VB.

Gambas is developed by Benoit Minisi and updated rather frequently. The most recent development version is 1.9.47. The last official stable release is 1.0.17. Because this release lacks of many features and because the development version does not make many problems, this article describes Gambas 1.9.47.

Compiling and Installing Gambas

To compile Gambas, X11, QT3, KDE3, PostgreSQL and MySQL resp. their development packages have to be installed on the system. After getting and extracting the source archive, a simple

./configure make make install

will install the environment (of course, the last command has to be given as root). The Gambas compiler and all available components will be built, then the Gambas compiler will compile the Gambas IDE which is written entirely in Gambas itself. Once everything is ready, you can use gambas2 to start the IDE.

Creating a Project

The first thing you will see is the startup dialog in which you can create projects, open projects or open one of the examples which come with Gambas. For now, just create an empty project by clicking New project …. You will then have to select the application type (choose »QT graphical application« and click next).

Gambas project type selection

The next dialog asks for a name and a window title (enter in both input fields for example »RoguelikeGambas«). Then select a directory for the project (there all project related files will be stored) and click next again. Now the project will be created.

Trying Out

If you are familiar with Visual Basic or similar development environments, you will feel right at home in the Gambas IDE. On the left, there is the project browser. All project related files, like forms, classes, modules and data files (e.g. graphics or sound files) are shown in it. At the moment, it should be nearly empty, except one form called FMain.

The Gambas IDEDouble-click on the form's entry in the project browser to bring it up. It will then be shown in the middle of the screen. There you can add controls to the form, change its properties and start to edit its code. Right-clicking on a form or a control brings up a context menu in which several editing options are given, together with the possibility to select events which you want to process.

If you have a button called btnQuit, for example, and you want this button to close your program, you may right-click on the button and select the event Click. Then the code editor will be shown for this event and you can fill in the needed code, e.g.

PUBLIC SUB btnQuit_click()

 FMain.Close

END

Starting that example will result in a working (but rather useless) program.

If you have entered the example code with your own hands and not just copied it from this article, you might have noticed that Gambas has a very useful code completition feature which helps a lot when writing code for the numerous controls that are available. It also works for built-in and defined functions.

Gambas for Roguelikes

Although Gambas is so easy to use, using Gambas for developing a roguelike is depending on the intended target environment. Graphical applications, using QT, GTK+ or SDL, can be created very fast. Nasty things like memory management or low level interaction with GUI or graphics libraries are hidden behind the very complete, but easy-to-use object framework.

In theory, this is also true for console applications. Unfortunately the console output is very basic (only the PRINT command for linear text output seems to be supported, or at least the docs don't state anything else) and there doesn't seem to be support for the rather popular curses library.

Avadan: A (dead) roguelike written in GambasBesides this, Gambas has another major obstacle: While Visual Basic programs just need a single runtime DLL or, in newer versions, the .Net framework to be installed, deploying a compiled and linked Gambas program forces the enduser to compile and install the whole Gambas environment. I fear that this will surely prevent a lot of people from trying out programs written in that language.

Hopefully, Benoit Minisi will make console development more effective and program deployment easier soon, because Gambas is a modern language with a userfriendly IDE and has a lot of potential - not only, but also for roguelike development.