Hi.

I was wondering about this. For those of you who don't know, "rogue-like" games are a kind of game that feature randomly-generated levels and other content, are a kind of RPG, are turn-based, feature "permanent death" (no save games, or saves only work as indefinite game pauses and not reversion steps), and usually have simple graphics, sometimes even just "text-based graphics" (using symbols like "#" for walls). Now, I was wondering: how would one go about making the "rendering" system for such a game, so as to be able to support both text-based graphics and also being abstracted right so as to relatively easily drop in a render system to render tile-based graphics? Note that these two may use both hugely different low-level libraries and APIs (e.g. terminal output for text mode, SDL or similar for tile mode), and also the data that need rendering are different (you render text characters in text mode, sprites in tile mode).

What would you suggest? I was using C++ to write the program. It also needs the ability to put up a "dialog box" (perhaps drawn in with text characters, or with simple graphics in graphical mode) that can have options/lists, e.g. the stuff you're carrying in your pack, magic spells, etc. .

Rogue-like games are a perfect example to implement the MVC-Pattern (Google it there is a ton of information around), in fact during my early days of programming I coded a very simple nethack-like game as a way to get familiar with the MVC-Pattern.

Define abstract data containers and interfaces for the map-representation, dialogs and user-interaction and write custom frontend that interact with these interfaces. The very simplest representation of a map could be a 2D-vector/array where every index correspondents to a tile of the map. Create a tile struct with the needed information in it. For example you put in information if it is an empty space, a wall or a trap, plus a list of items or creatures that are on this tile.

From the rendering-side you now write a frontend that reads this vector from the game and draw the appropriate portion of the map on the screen. So the game-mechanics itself does not know hot to represent the information to the user at all.

Along with what doeme said, I'd also add that you don't necessarily need two different renderers to toggle graphic tile/ascii mode.

You can, as a bare basic, implement a texture atlas to represent your tiles, and when you want ascii mode, just switch to a texture atlas that contains the ascii characters drawn in the atlas, instead of actual graphic tiles. (after all, ascii characters, when printed on screen are nothing more than simple graphics)

This may not be the most efficient way, in terms of memory usage or data storage - storing an atlas with drawn ascii characters - but on any post-2000 pc that should really not be an issue at all.

I am working (in fits and starts) on such an animal, actually. In my case, I'm using OpenTK and C#, but the concept would be similar. I based the API loosely on Libtcod (found here http://doryen.eptalys.net/libtcod/), but I also wanted (limited) support for tiles.

Basically, for the ASCII glyphs, I use a source texture atlas for the characters and map the positions to ASCII codes. The shader is very basic, and just colors the fragments based on the alpha channel of the texture. Once you have that, you can add layers of logic for printing strings, dialog boxes etc.

The only real conceptual difference between glyphs & tiles (in my API) is that glyps are given in character coordinates, while tiles are placed in pixel coordinates.

In case it helps, you can browse the source here: http://code.google.com/p/sharprl/wiki/Introduction

Edit: better link

Rogue-like games are a perfect example to implement the MVC-Pattern (Google it there is a ton of information around), in fact during my early days of programming I coded a very simple nethack-like game as a way to get familiar with the MVC-Pattern.

Define abstract data containers and interfaces for the map-representation, dialogs and user-interaction and write custom frontend that interact with these interfaces. The very simplest representation of a map could be a 2D-vector/array where every index correspondents to a tile of the map. Create a tile struct with the needed information in it. For example you put in information if it is an empty space, a wall or a trap, plus a list of items or creatures that are on this tile.

From the rendering-side you now write a frontend that reads this vector from the game and draw the appropriate portion of the map on the screen. So the game-mechanics itself does not know hot to represent the information to the user at all.

What would be the best way to represent the dialogs?

OOOH! I just noticed that this thread should be moved to the "Game Programming", or perhaps the "Graphics Programming" forum. Can anyone do that, please? Thanks!

[quote name='mike3' timestamp='1358547595' post='5023002']
What would be the best way to represent the dialogs?
[/quote]

Abstractify similar to the map, create an interface where you return a queue of structs containing all pending messages and valid answers (and maybe some more information) and then poll from the UI on every action. Internally you create a tree, graph or a simple state engine to deal with the possible answers.

What would be the best way to represent the dialogs?

Abstractify similar to the map, create an interface where you return a queue of structs containing all pending messages and valid answers (and maybe some more information) and then poll from the UI on every action. Internally you create a tree, graph or a simple state engine to deal with the possible answers.

What do you mean by "messages" here? Like telling the dialog to add an item to its list box, etc.? What uses the queue? What do you mean by "answers"?

As when I hear "messages" in a dialog context, I think of like how the Windows API works, where you have messages to/from a window signalling various things going on (add item to list box, resize window, etc. -- obviously, this simple system only a subset of all that would be needed).

[quote name='mike3' timestamp='1358830822' post='5024179']
What do you mean by "messages" here? Like telling the dialog to add an item to its list box, etc.? What uses the queue? What do you mean by "answers"?
[/quote]

I mean it more like a message-box not a system message. Like any string you want to represent to the user, like "Really drop item XYZ" which has possible answers "Yes/No" and a follow up message of either "you dropped item XYZ" or "you stow item XYZ in your bag again". You use the queue to make sure the user doesn't miss any of the information. Say you move on a square with a trap on it, which will generate information for the user: 1. there is a trap, 2. whether you fell into the trap, 3. if you fell in how much damage did you take. The Queue ensures that the UI can digest the messages in it's own pace and you don't miss any message.

What do you mean by "messages" here? Like telling the dialog to add an item to its list box, etc.? What uses the queue? What do you mean by "answers"?

I mean it more like a message-box not a system message. Like any string you want to represent to the user, like "Really drop item XYZ" which has possible answers "Yes/No" and a follow up message of either "you dropped item XYZ" or "you stow item XYZ in your bag again". You use the queue to make sure the user doesn't miss any of the information. Say you move on a square with a trap on it, which will generate information for the user: 1. there is a trap, 2. whether you fell into the trap, 3. if you fell in how much damage did you take. The Queue ensures that the UI can digest the messages in it's own pace and you don't miss any message.

Ah! A queue for the display messages. That makes sense But I'm asking about how to represent/implement dialog boxes with widgets on them that show various kinds of information, drawn on the game screen. Not as many kinds of widgets as an OS GUI would have (and nowhere near the same level of functionality), but some, like simple list boxes and text fields (as mentioned in the original post, this is to show stuff like the items in your pack, magic spells, and so forth.). How to represent that and also present it to the rendering system (the layout, widgets, etc.). What would you suggest?