Roguelike Magazine Issue 2
The Infinite Deadline Problem
Well, usually I tend to excuse myself again and again for not meeting deadlines, but of course I know that everybody in the roguelike scene tends to not even giving deadlines. So I will adopt this behavior for RTM ;-)
The problem with this is that the concept of a magazine requires to meet deadlines. Itâ€™s neither a piece of software (or, to be more precise, a computer program) nor a blog, itâ€™s a thing which is expected to return on a regular basis. The question is how wide this basis should be. One month? Did not work. Two months? Might be possible (and when RTM started, I even scheduled RTM #2 for May, not for April â€¦ ). However, three months would be the most realistic cycle.
And this produces another problem (but at least one I was always aware of): Reviews. If RTM is only published four times a year, writing reviews of games which are in development is rather useless. By the time the review is written, a new release could be already out, with issues fixed still mentioned in the review. The reviews could of course contain the version number of the tested game, but critical reviews might produce negative effects on games which already have been improved. Especially readers who donâ€™t visit r.g.r.d regularly and donâ€™t know about the fast update cycles of many roguelikes might get a wrong impression.
So what to do to make my life easier, but keep RTM interesting?
Step one: Continue publishing interviews and writing theoretical articles (e.g. the â€“ in this issue absent, sry again â€“ series Aesthetics in Roguelikes or the articles about languages and coding).
Step two: Cover new roguelikes which are in alpha or early-beta stage only with summaries, but not with complete reviews. The last 7DRL contest showed me that itâ€™s just not possible for me to play them with the effort needed to write accurate reviews.
Step three: Review only roguelikes which can be expected to be fun for other people than the developers on r.g.r.d â€“ this does not mean I donâ€™t respect the efforts of developing new games and concepts, but reviews in RTM will be more useful if they cover games which offer a wider range of gameplay (e.g. a minimal length; things to discover etc.) also for players still not so affine to roguelikes, and many alpha/beta-projects (and most 7DRLs) donâ€™t fulfill this requirement.
So this is the plan and it allows me to ignore most of the infinite [release]-messages, taking pressure from me, while it also admits me to have a look at older roguelikes â€“ so donâ€™t be surprised if there was a YANAIM (Yet Another Nethack Article In Media) in RTM some day ;-)
7DRL contest 2007.
Ever watched Star Trek? If so, you might know the, mostly evil, cyborg species Borg (Â»Sounds Swedish.Â«). By default, they know no individualism. Instead they live as collective on gigantic cubic or spherical space ships and want to assimilate everything and everybody into their collective. The collective is controlled by a queen, who does the same as the queen in a bee hive. Therefore the shared consciousness of the Borg drones is called hive mind. (Of course, Star Trek hasnâ€™t invented the concept of group mind. See the english Wikipedia article for a rather complete list of shared consciousness in science fiction).
In certain episodes of Star Trek, single members of the collective get separated and have to survive on their own. Usually they just have to wait for rescue or, if rescue is unlikely, they have to destroy themselves. However sometimes, these drones get aware of their individuality â€“ and like it. Reason enough for the queen to eliminate these broken parts of the collective.
So, now read the last two paragraphs again, but replace Borg with Bot and Queen with Hive Control. Then you know what the background story of the Gero Kunterâ€™s 7DRL Hive Awakening (site) is all about.
Resistance Is NOT Futile
In Hive Awakening, you take control of one of the bots with self consciousness. In order to ensure your survival, you have to find an hive interface and use it to reprogram the hive control.
After the game has told you about your quest, it asks you to enter a handle, i.e. a name for your avatar. By default it suggests 5DRL which is not only a side blow on the needed development time of Hive Control, but reminds also of famous robots like R2D2 or C3PO. After entering the handle, you are presented the dungeon view.
This view looks very clear. The @ is highlighted by the cursor. Walls look turquoise. The lines at the bottom present some status values, and the advice to press ? to get a list of available keys should be taken serious. In general, the player is not overburdened by too many things at a time and his eyes and mind can adopt to the atmosphere of the game without stress.
To the atmosphere just mentioned count the names of the status values, too. Instead of HP, you have to care about the structure of your avatar. Other values are weight, engine and speed. Although it seems natural to have such denotations in a game where your avatar is a robot, itâ€™s worth to notice.
Having a look at the key commands shows us that movement is controlled either by the number pad or by vi keys. Cursor keys donâ€™t work. Instead you get an invalid key message. Laptop users who arenâ€™t familiar with vi movement are forced to learn it (which, of course, wouldnâ€™t be bad at all), because even using laptopâ€™s virtual number pad (activated by pressing the Fn key together with a letter key) doesnâ€™t work. The only alternative to vi keys is using NumLock, but then 15 of the letter keys (i.e. the i key which is for example necessary to enter portals to the next level) are not usable. Although the game is just a 7DRL, these issues are rather annoying.
Anyway, once basic movement works for everybody, the game will soon show its qualities. One of these is the equipment system. Your avatar is provided with several sockets which can hold different modules. Now some modules need more than one socket to be equipped. In such a case, you need to connect the sockets with a socket link. While you start with only two sockets available, you will find modules that add more sockets to the bot. However, the more equipment you have installed, the more energy is needed. More energy is produced by better engine cores.
In many roguelikes, your health regenerates over time. This is possible in Hive Awakening, too â€“ but only with the right modules equipped. Although restorators, reconstructors and regenerators are available, you have to decide if you want to use one of these or if a weapon would do a better job for you. You can also equip different shells. These tools increase the maximum structure and therefore help to stay alive.
The described system reminds me of several battlemech inspired games (anybody here to write a Â»Front Mission RLÂ«?) and once you have understood the concept, it works very well. It contains a strong tactical component and much of the gameâ€™s fun is created by that.
The First Minutes
You start with two sockets, a drill, a restorator and a protium core. At the moment, you canâ€™t equip all three items at one time, so you have to decide which is less important. In principle, this is the decision between an active and defensive gaming strategy. If you enable the restorator instead of the drill, you will survive much easier, but canâ€™t do harm to the enemies. The other way around you do harm, but will be destroyed rather soon. The third alternative is to deactivate the core, but this only works as long as you donâ€™t need power for additional equipment. As items are richly available (too richly, i.e. repetitive sometimes), the power core will be needed soon.
Once you have discovered the first level, you surely want to go further. For doing so, you need to find the security interface of the level and deactivate it. Otherwise, the portal to the next area will be protected by a force field and canâ€™t be entered.
After some time you will have collected lots of items and parts that can be used to enhance your bot. As stated before, this can only be done with modules that add new sockets, and finding these socket forks requires some patience. Once you have one or two of them, the equipment system finally becomes useful.
Hive Awakening could become a great game if the author spent some time on it. The equipment system allows very deep tactical gameplay and the atmosphere is quite dense, thanks to the terms, the colors and the dungeon layout â€“ all three aspects fit the background story well. Though the story itself is not new, Hive Awakening is (as far as I know) the first computer game to put you in the role of an artificial life form that just wants to survive.
Paul Pekkarinen / Krice
This column is dedicated to you, the roguelike community. Its purpose is to introduce single individuals and their personal view on the RL scene. We start with Paul Pekkarinen, also known as Krice. Thanks for taking time to answer my questions.
Where are you at the moment, how was the day until now and howâ€™s the weather?
I live in a small village located at central Finland. The day was sunny and clear, +10 celcius degrees warm. Some spots of snow still on ground, but they are quickly disappearing.
What do you like most on the roguelike genre? Do you have a favorite RL?
I like role playing of course and replay value from randomness. My favourite RL is Nethack.
Do you believe that role playing can be done better in roguelikes or in more classical RPGs?
I think role playing experience could be made deeper but at the same time non-restrictive. The restrictions come from balancing between character classes. I donâ€™t believe in those restrictions.
You are developing the roguelike Kaduria. Its website states the game will be finished in 2 years. This statement is sarcasm, isnâ€™t it? How is the state of re-coding so far?
Itâ€™s very good, because itâ€™s mostly object oriented now and much easier to maintain.
When will you release a new public version?
Itâ€™s hard to say. It depends on so many things that are still unfinished.
When and why did you start to develop Kaduria?
I guess the project has seen several starts so to speak. In general the project began at 1995 and the reason I started to make it was just to create something like Nethack, but with easier gameplay. The newest start was a couple of months ago when I installed Visual C++. It's a great developing tool! I never realized how much it would matter to have a proper developing tool.
Do you speak of the latest version? I agree that Visual Â»whateverÂ« 2005 is the best IDE Microsoft has yet released, and indeed one of the best tools in general.
Do you have any advice for new developers who just start a RL?
Learn good programming skills. It took me really long time to realize that I was a poor programmer. I try to be a better one each time I write code.
If one has a look at Kriceland, your personal website, one gets to know you as damn creative person. Your output seems to be very high; just two days ago, for instance, you uploaded another of your several guitar music mp3s (which are actually rather good). Additionally, you draw, you paint, you write. So â€“ where does this need for total expression arise from?
I would say Iâ€™m an artistic kind of person. When you are an artist you donâ€™t have a choice, you must create stuff all the time.
Is programming Kaduria art, too? Could the game be seen the same way one could watch your drawings or read your texts?
And a rather dumb question: A clich???? says that finnish people are always sad and therefore drink much beer. Is this true and influences this your art?
I donâ€™t drink alcohol at all, but itâ€™s true that finns are sad and depressed people. Maybe I should drink beer a lot, too.
By reading some of your postings on r.g.r.d, not much leads to the finding that Â»KriceÂ« is active on so many different fields. Instead one gets the impression you wish to behave as troll, or as a person who enjoys to neglect many things going on in r.g.r.d.!?
Iâ€™m a half-troll.
How do you see the roguelike community, in relation to creativity, individuality or self-awareness?
Itâ€™s important to know there are people like you. Even guys like me feel somehow connected to that bunch of people who share the same dreams. The most important thing in life is to realize you are not alone.
Why did you change your real name to Krice on r.g.r.d?
I believe Google Groups asked for a nickname and began to use that for newsgroup posts.
You once stated that there is a lack of innovation in new RLs. Which topic should be covered?
The secret of a good game is small things done right. Itâ€™s all in the details and in the way of always trying to make something better than what already exists.
What does Â»Kitara, hevi ja naisetÂ« (the title of your blog at blogspot.com) mean? What is your blog all about?
It means Â»Guitar, heavy (music) and womenÂ« and itâ€™s about those three things. I also have a personal web diary, but I wanted to talk more about guitars and playing them etc. and of course about women. Or in my case lack of them.
What do you do in Â»real lifeÂ«, when not being creative?
Not much. Iâ€™m all creative person. I work as computer assistant for six hours per day, but I call that Â»a distractionÂ« which sadly takes six hours away from all the fun of making roguelikes. Occasionally I go to gym and pump iron. Itâ€™s good to have some physical activity so your brains can rest for a while.
(by Glenn R. Wichman).
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.
Trying it Out
First, the challenges:
5. Options for saving games are limited. Of course, most any roguelike will need a save game feature (see Saving Games below).
3. Your game will have the widest potential audience. Anyone who has a web browser installed on their computer (which is just about everyone with a computer) will immediately be able to play your game without having to download or install anything.
4. Players will always be playing the latest version. If you find a bug, fix it, upload the fix to your website, and you are done. You donâ€™t need to get patch releases out to everyone who has the game.
5. You can track your gameâ€™s popularity. Most likely, your website already gives you statistics for how much traffic each page is getting. You can use this information to see how many people are playing your game. With a little work, your game could use AJAX to communicate additional statistics; you could track which monsters are doing most of the killing, which level is the most vorpal, etc. 6. A browser is a very rich user interface engine. Creating your GUI in HTML can be a lot easier than a lot of the GUI tools available for other languages.
Visual Engine Sharing
Â»CodingÂ« aims at beginner level developers who have basic knowledge of their programming language of choice and are now at the first stages of creating a roguelike. The articles, although incorporating the subjective view and â€“ in no means perfect â€“ programming style of the author, point out some general issues which could seem to be difficult and try to show simple methods of solutions to these issues.
What You Should Know
In order to follow my explanations, you should know, at least in theory, how SDL works (i.e. that is uses so-called surfaces to represent bitmaps and window contents). I also expect you to know the very basics of programming, i.e. that you are aware of variables, constants, functions, loops and conditions.
You have an idea, you have time, you already have coded the first couple of lines and you want your game to run on a wide range of systems. Your target audience consists of roguelikers and players of classical RPGs. Therefore you want ASCII output for the former and graphics for the latter. What should you do to achieve this goal?
One way was to maintain two different branches of your game, with different sources, completely parted from each other. One branch could use the curses library for console output and the other branch could use SDL for displaying graphics.
Another, probably better way was to let both versions share the same code base, write routines for both display modes and just create two different binaries at compile time.
A third way, and the way described in this article, was to only create one binary for both modes and decide at runtime which mode to use.
One Output Function â€“ Two Display Modes
The goal of this article is to show that the use of an abstract output function instead of basic functions provided by a library makes the programmerâ€™s life much easier. Using FreePascal, we will develop a basic output system which will be capable of showing single characters, strings and tiles.
The concept is very easy. By using the chr() function, we can access characters of the extended ASCII set, i.e. all chars with a code higher than 127. With 255 chars in total, we have 128 chars which can be used for other purposes than just displaying letters. We will use these characters to display graphical tiles in SDL mode. In console mode, chars higher than 127 will be Â»remappedÂ« and shown in other colors, depending on our needs.
We will create two basic functions:
CharXY (intX, intY: Integer; chLetter: Char): Boolean; TextXY (intX, intY: Integer; strText: String): Boolean;
Whenever we need to output a character or a graphical tile, weâ€™ll use one of these two. TextXY() does nothing special, it just calls CharXY() so often as needed for displaying the complete string. The Â»magicÂ« is done in CharXY() itself.
The Universal Function
Have a look at the following code:
FUNCTION CharXY (intX, intY: Integer; chLetter: Char): Boolean; VAR TilesetRect, ScreenRect: SDL_RECT; intColor: Integer; chTransformedLetter: Char; BEGIN // set the result of the function to true CharXY:=true; // check if a valid character has been given to the function IF (ord(chLetter)<32) OR (ord(chLetter)>254) THEN CharXY:=false; // if the character is valid, process it IF CharXY=true THEN BEGIN IF blUseSDL=true THEN BEGIN // ** SDL output ** // get the correct character out of the tileset surface TilesetRect.x := (ord(zeichen)-32) * TILE_WIDTH; TilesetRect.y := 0; TilesetRect.w := TILE_WIDTH; TilesetRect.h := TILE_HEIGHT; // calculate the output position in the SDL window ScreenRect.x := intX * TILE_WIDTH; ScreenRect.y := intY * TILE_HEIGHT; ScreenRect.w := TILE_WIDTH; ScreenRect.h := TILE_HEIGHT; // copy the character to the screen SDL_BlitSurface(surTileset, @TilesetRect, surScreen, @ScreenRect); END ELSE BEGIN // ** console output ** // default color for all chars < 127 (used for text) intColor:=white; // transform chars > 127 (these are the graphics in SDL // mode) into chars < 128 and change the display color IF ord(chLetter)>127 THEN BEGIN CASE ord(chLetter) OF // closed door 128: BEGIN chTransformedLetter:='+'; intColor:=darkgray; END; // opened door 129: BEGIN chTransformedLetter:='\'; intColor:=darkgray; END; // wall 130: BEGIN chTransformedLetter:='#'; intColor:=lightgray; END; END; END; // Use a VidUtil function to do the curses output TextOut(intX, intY, chTransformedLetter, intColor); END; END; END;
To understand the function, you need to know the following facts:
- We use JEDI SDL for accessing SDL types and functions.
- The content of the SDL window is stored in the surface surScreen.
- Our tiles are saved in a bitmap stored in the surface surTileset.
- The constant TILE_WIDTH determines the width of a tile, e.g. 32.
- The constant TILE_HEIGHT determines the height of a tile, e.g. 32.
- FreePascal offers several color constants we can use in our game.
- For accessing curses, we use the Video unit.
- The TextOut function is provided by the VidUtil unit.
- We have a global variable blUseSDL to determine the output mode.
Now weâ€™ll have a more detailed look on the algorithm. First of all, we declare some variables. The SDL_RECT data type is a simple record, containing four integer elements. The values of these elements are coordinates and the record is an easy way to pass the values to various SDL functions.
After declaring, we check if the character that has been passed to the function in chLetter has an ASCII code between 32 and 254. If the value was lower or higher, the function would exit and return false.
If the character is valid, blUseSDL is evaluated to determine if SDL or console output should be used.
The SDL Part
If SDL output is desired, the function now copies a rectangle from our tile bitmap in surTileset into the window surface surScreen. The copied area contains the character or tile with the ASCII value of chLetter.
The bitmap with our tileset consists of at least 127 characters, aligned from left to right, without spaces, sorted from the lowest to the highest â€“ like pearls on a string. The first 95 tiles (number 32 to 127) contain letters, ciphers and special chars and are used for text output. Everything after tile 95 (beginning with ASCII value 128) is used for graphics.
If you now want to draw a wall tile somewhere on the screen, you just need to know the ASCII number of the tile which depicts that wall. In the picture above and in the example source, this number is 130 (normally shown as â€š character, but here Â»overriddenÂ« by a graphical tile). With this number you can simply call our function CharXY (15, 10, chr(130)); â€“ note that we do nothing more than using FreePascals standard Chr() function to display a graphics on the screen. Rather easy, isnâ€™t it?
A Virtual Console Window
The x- and y-coordinates used in the function call (here 15 and 10) refer to a matrix in which every cell contains one letter or tile at a time. It works like the 80????25-matrix of a console, but the actual size of every cell depends on the size of the tiles you wish to use (in fact, the cell size is the same as the size of your tiles). The total number of lines and rows in this Â»virtual consoleÂ« depends on the width and height of your gameâ€™s main window.
If your window size was 640????480 and your tiles had a size of 32????32 (like in the example source), you would get a Â»resolutionÂ« of 20????15. If your window size was 800????600 and your tiles were 32????32, the available size was 25????18. And if your window size was 800????600, but your tiles had a size of 10????20 (as seen in LambdaRogue), the resulting space was 80????30.
The Console Part
Although displaying tiles that way is practical, the main advantage of the function is its ability to create console output as well. If UseSDL is false, the SDL part will be skipped. Instead, the branch after the first else will be executed.
Basically this part could look very easy, as it does not need to translate an ASCII code to a bitmap graphics. So it could just display chLetter. However, the output that is done here needs to have the same meaning as the output that would be done by the SDL part of the function â€“ if ASCII code 130 stands for a closed door, both SDL and console output have to display a door. As there are many conventions in the roguelike genre how certain objects are symbolized, the standard character with that value canâ€™t be used. So we have to do an intermediate step.
In this step, we use a case construct to evaluate the ASCII code of chLetter. Then, we use the variable chTranslatedLetter to store an alternative letter; in the example this is a +, easily recognized as closed door in nearly every roguelike. When the translating from the original character into the new character is done, we yet change the color of the following screen output, using one of FreePascals predefined color constants.
Finally, we call the TextOut function that accesses the console:
TextOut (intX, intY, chTransformedLetter, intColor); .
For the sake of completeness, the other function, TextXY(), shall be shown, too:
FUNCTION TextXY (intX, intY: Integer; strText: String): Boolean; VAR i: Integer; chStr: Char; BEGIN // set the result of the function to true TextXY:=true; // go through the string char by char FOR i:=1 TO length(strText) DO BEGIN // extract one char from the string chStr := strText[i]; // display the character; if this makes any // problems, set the result of TextXY to false IF CharXY (intX+i, intY, chStr) = false THEN TextXY:=false; END; END;
For displaying text, you will most likely use this function. Calling CharXY() directly will be mainly needed for dungeon output routines or functions that show Â»special effectsÂ«, like flying missiles or magic.
Remarks and Problems
If a developer decides to program his output in a way like shown here, he may feel constricted after a while, especially concerning the maximum number of available tiles. As the functions expect ASCII tiles (for showing texts) and graphical tiles (for showing dungeon features, items and creatures) to be in one bitmap file and as the maximum value the chr() function can handle is 254, he canâ€™t use as many tiles as perhaps desired. Instead, he has to confine himself to a limited amount of tiles or (which would be the most logical reaction) adjust the functions to his needs.
It is, for example, possible to add a parameter intSubset that is used to switch between different parts of the bitmap. The calling function then has to care about the correct value of this parameter, and TilesetRect has to contain the correct part of surTileset, depending on intSubset.
The console part of the function also has to regard intSubset. This will of course complicate the, currently rather clear, case statement. In this regard we have to address another issue â€“ the hard-coding of the different Â»translated charsÂ« and their colors.
Hard-coded chars and colors
Doing so is not optimal. Instead, the chars and the colors should be read from a data file. This file would assign one ASCII value, e.g. our 130, to a character and a color. The function then would be much more flexible than at the moment. Such an assignment could be look like this:
 char=# color=lightgray
You might have recognized the format â€“ itâ€™s the one used by older Windows versions and (still) by several programs for .ini-files. Of course any other format, e.g. XML, will do just fine.
The file could be read into an array (textual color constants in the file had to be typecasted into integer). The data type of that array would be a record with two elements. The declaration in FreePascal would be:
TYPE ColoredChar = Record chChar: Char; intColor: Integer; END; VAR MyTranslatedChars: Array[128..255] of ColoredChar;
With such structures you wouldnâ€™t need the case statement any longer. Instead, you would just write:
chTransformedLetter := MyTranslatedChars[ord(chLetter)].chChar; intColor := MyTranslatedChars[ord(chLetter)].intColor;
This is way cleaner than to hard-code all possible characters and color combinations into a function whose only job is to bring these chars on the screen.
As you have seen, there exists a global variable blUseSDL. This might be criticized. This was mainly done to make the example code easier. The same goes for the lack of object oriented programming. It is rather easy to think of an object that represents the game window and to implement CharXY() and TextXY() as methods of this object. A valid call could then be for example
MyScreen.TextXY(2, 2, 'Status of '+TheAvatar.strName+':')
â€“ not very complicated at all.
Two Modes â€“ Different Screen Sizes
Finally, I want to address an issue related to window- and tile sizes. The basics were already covered above, but out of these basics a problem is born which can lead to strange results if not handled properly.
You probably want to use a standard resolution, e.g. 800????600, for the SDL mode of your game. If you now use the described functions to output text, chars or tiles, all will work fine until you accidently use a coordinate out of range.
This can happen very easily if the SDL window offers more rows or columns than the console mode. If you donâ€™t think about this and e.g. use a CharXY(20,27,'T'), in a 80????25 console your game will crash with an access violation.
To avoid this, you have several options. You could just stop to use rows greater than 25, but in SDL mode this would cause a fairly large amount of unused space (perhaps this could be filled by a nice background texture).
You could also check intX / intY and automatically decrease these values if they wouldnâ€™t fit the screen. This method is used by LambdaRogue, but it may be confusing.
The best way was to use tile sizes which translate perfectly between two modes. To have no overhead of rows and columns, you might have a look at the following overview:
Window Size Optimal Tile Size 640????480 8????19 800????600 10????24 1024????768 12????30
These sizes, of course, are very uncommon. Most available tilesets come in squared sizes and editing them would need as much work as creating a completely new tileset. However, if you donâ€™t want to use graphics, but use a virtual (SDL) console, you only need tiles with letters, ciphers and special chars. Such tiles can easily be created with every graphics editor. Just open a new file in your desired size, select a font and adjust the size of the font to make all characters fit into the center of your file. Create all files you need and copy them into one single bitmap. This bitmap is your tileset.
This article described one way to combine SDL and console mode in one binary, without needing to recompile, to maintain different versions or the need to always select the correct output mode. In fact, the function was planned to be as easy as FreePascalâ€™s console-only function WriteXY(). If implemented in a unit, it can be used again and again as the basis for the screen output of your roguelike.
However, there are also some traps and problems, and the article discussed the most important of these issues â€“ together with possible resolutions.
I guess that there are already similar approaches taken by other developers, but I saw the need for a clear description of the basic principles for Â»newbiesÂ«. Hopefully reading this article was somewhat helpful.
Directional Player Character Facing
Essential For All Modern Roguelikes
There is always a lot of debate, endless it seems, about what makes a roguelike (RL) a RogueLike. With continuing development in this field by various hardy groups of coders (see newsgroup: [[rgrd|rec.games.roguelike.development] for some of them) there is perhaps a contemporary version of the old question: Â»what makes a modern RLÂ«?
This finally might be the place to say a modern RL has graphics in at least tile form. Â»RL PuristsÂ« had good grounds to argue a traditional RL has text graphics only and one should imagine the red Â»aÂ« as an ant. The modern RL question is different enough to accommodate those Â»RL ProgressivesÂ« more fairly.
A modern roguelike?
Lets take a look at a quick list of Â»what makes a modern RLÂ« from features common to many newer RLs these days. As with any such Â»flavourÂ« list it is perpetually incomplete and a modern roguelike does not have to satisfy all conditions to qualify. (see note: 1)
* Tile graphics or better (e.g. H-World with very pretty isometric customisable graphics) * Sound (e.g. DoomRL great use of atmospheric themed music and sound from Doom including MP3s). * Monster inventory (been around for a while). * Small command set (not always but often). * Easier interface options (use of the mouse and menus and other handy ideas). * Faster paced gameplay (e.g. CastlevaniaRL is a fast paced RL). * Non classic gameplay (various examples of weird and wonderful ideas particularly during the 7DRL (seven day roguelike) competition. * Custom RPG systems. * Moddable (leveraging things like Lua to allow users to script their own functionality). * Open source (or other availability of code). * Larger more ambitious worlds and features. * Themed RL games based on some pop culture (e.g. DiabloRL). * Use of randomly generated plots and game worlds to add spice. * Not just one dungeon, usually an outdoor area and several locations to visit. * Ports or versions for mobile devices and other uses of latest technology. * Party members and pets that you can control. * Multiplayer and net based play. * Innovation of gameplay (extra features added on top of the traditional RL gameplay). * Special features (a modern roguelike will often have one or more features not seen in usual traditional RLs). * More playable (less time needed to look up keybindings or monster lists etc).
Note that we donâ€™t get into the nitty gritty yet of things like permadeath which cause heated debate. Some gameplay elements are still timeless â€“ although one could argue there is less permadeath in modern RLs. We will leave debating of what are the modern gameplay choices for a modern RL to the newsgroups. Now to move onto one important barrow to be pushed by this article â€¦
Advantages of directional player character facing
The title of this article claims that directional PC (player character) facing is essential for all modern roguelike. Modern RLs are defined by what is currently being produced but they also need to be pushed by vision and visionaries (aka ShockFrost the brave! [rgrd in joke]). A step forward in gameplay for all modern RLs, this article argues, is the inclusion of directional facing for the PC and monsters consistently in all modern RLs as though it were as obligatory as squares to move on.(see note: 2)
This means the player faces a particular direction and can only Â»seeÂ« in that view cone â€“ and the same goes for monsters. This adds a dimension to RL gaming for both the player and developer.
Monsters can sneak up behind the PC. The PC can sneak up on monsters too and more easily tell that they are Â»behindÂ« a monster. Backstabbing is an obvious feat/skill to flow from this. Hearing can play a larger role with a detected sound showing a Â»?Â« behind the player indicating s/he can not see the monster but did hear it. Feat/skills relating to hearing and sneaking follow this. Seeing through keyholes and cracks are examples of possible extensions that can be added to this base by inventive developers.
Since modern RLs now feature graphics it is easier to represent the direction that the PC and monsters face. Some fun for coders in adding another layer to their LOS (Line Of Sight) algorithms and on screen representation â€“ how to show the squares the PC can actually see at any one time as opposed to those that are lit and unlit. There are implementation options for movement/vision rules governing how the PC and monsters turn around, how long it takes in game time, and whether they can walk backwards or face directions they are not moving in (e.g. Ikari Warriors style). Possibilities abound for atmospheric and spooky settings as they also do for tactics such as ordering your pet to sneak up behind the monsters or performing distractions.
I hope you can see that the directional facing concept epitomises the progressive nature of modern RLs. As can be seen above, such concepts add a new dimension of interest and fun for gamers and also some novel opportunities and challenges for developers. I hope to see this feature and other such innovation became part of the stock features in all future RLs!
Go code. Go play.
1 The reader may be interested to know that the feature list is in the order of which they occurred to the think-tank assigned to produce it for this article (i.e. Slash and the author of this article).
2 The author realises that:
* There are examples of facing features out there already. * Moving on squares is not strictly necessary for a RL. * That a lot of conjuncture in this article is possible, as it always is with such RL issues, and the author chooses not to muddy the Â»messageÂ« by covering all caveats but invites debate.