Jump to content

  • Log In with Google      Sign In   
  • Create Account


Rendering system for a "rogue-like" game.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 mike3   Members   -  Reputation: 149

Like
0Likes
Like

Posted 18 January 2013 - 02:30 AM

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. .

 



Sponsor:

#2 doeme   Members   -  Reputation: 641

Like
2Likes
Like

Posted 18 January 2013 - 03:05 AM

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.



#3 Milcho   Crossbones+   -  Reputation: 1171

Like
1Likes
Like

Posted 18 January 2013 - 03:22 AM

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.



#4 laztrezort   Members   -  Reputation: 950

Like
0Likes
Like

Posted 18 January 2013 - 07:52 AM

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


Edited by laztrezort, 18 January 2013 - 07:54 AM.


#5 mike3   Members   -  Reputation: 149

Like
0Likes
Like

Posted 18 January 2013 - 04:19 PM

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?



#6 mike3   Members   -  Reputation: 149

Like
0Likes
Like

Posted 18 January 2013 - 04:23 PM

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!


Edited by mike3, 18 January 2013 - 04:24 PM.


#7 doeme   Members   -  Reputation: 641

Like
0Likes
Like

Posted 21 January 2013 - 02:00 AM

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.



#8 mike3   Members   -  Reputation: 149

Like
0Likes
Like

Posted 21 January 2013 - 11:00 PM

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).


Edited by mike3, 21 January 2013 - 11:05 PM.


#9 doeme   Members   -  Reputation: 641

Like
0Likes
Like

Posted 22 January 2013 - 02:12 AM

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.



#10 mike3   Members   -  Reputation: 149

Like
0Likes
Like

Posted 22 January 2013 - 03:38 AM

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 smile.png 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?


Edited by mike3, 22 January 2013 - 04:01 AM.


#11 doeme   Members   -  Reputation: 641

Like
0Likes
Like

Posted 22 January 2013 - 09:12 AM

How to represent that and also present it to the rendering system (the layout, widgets, etc.). What would you suggest?

 

For representing the widgets in the Rendering/UI-system I would use any of the existing GUI-Frameworks that are out there. I personally would go with Qt because I know it fairly well, but this might be an overkill. Writing a widget-system from scratch is very tedious and a bit a waste of time, just use existing stuff to represent your GUI. I'm sure that some kind of UI-kit exists as well for the console.



#12 mike3   Members   -  Reputation: 149

Like
0Likes
Like

Posted 22 January 2013 - 04:14 PM

However, aren't Qt and similar systems for rendering windows and widgets in the OS desktop environment, not for rendering them inside a game's render area, like on the console or inside a fullscreen graphics display using OpenGL, SDL, etc.? So it would seem that to use them would require extensive recoding of their render system, no? Seems that'd take an extraordinary amount of work.

 

Also, I've noticed that I'm still not sure as to how to do the rendering system in general. Should one just have one big "renderer" object that takes in maps, dialog widgets, text messages, "stats" info (i.e. player's HP, etc.) etc. and renders them to the screen?


Edited by mike3, 22 January 2013 - 09:39 PM.


#13 doeme   Members   -  Reputation: 641

Like
0Likes
Like

Posted 23 January 2013 - 02:05 AM

You're right about Qt, however without any information on how you want to display your game exactly. There are a ton of Widget libraries for OpenGL, DirectX etc. around, but without any more information on what kind of render-system you want to use it's hard to recommend you any.

 

Also, I've noticed that I'm still not sure as to how to do the rendering system in general. Should one just have one big "renderer" object that takes in maps, dialog widgets, text messages, "stats" info (i.e. player's HP, etc.) etc. and renders them to the screen?

 

Simply said: do whatever works. This cannot be answered until you decide a way to go. If you design strictly along the MVC-Pattern it should be relatively easy to put a new and improved frontend onto your game once you get the hang of it. 

I recommend that you start out with a simple reprensentation of your game and then start to improve on the UI/Rendering later once you got more or less working game mechanics. Start out with a text-based frontend or a tile-based frontend that uses windows-widgets instead of also trying to climb the rendering hill at the same time. Better lower your goals and expectations and get the project done than fail miserably at your high expectations.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS