Topics

1

Programming / "Game time"

« on: September 14, 2013, 05:15:34 AM »

Hi.

I was wondering about this: what are some good ways to do an "in-game time" system, that is, where there's a count of hours, days, etc. in addition to the turns and "logical time" used by the game logic, which is "ticks" or whatever, and where, for example, moving over a terrain takes a certain number of hours, and things can happen at certain times (measured on this hours/days/etc. clock)?

2

Programming / Kick command and other commands requiring interaction with the map

« on: August 20, 2013, 04:29:31 AM »

Hi.

I was wondering about this now. On this thread:

http://forums.roguetemple.com/index.php?topic=3212.30

I discussed some stuff with regards to how to program movement in a roguelike without the "critters" containing a reference to the map which they're on. One suggestion was to have a move method on the map itself, but what about other commands that require detecting if another critter or object is on the map, like kick? It seems that adding "kick" now to the map starts to sound like too many responsibilities for the map! Doesn't it make more sense to have that on the critter?

The discussion also went to the topic, which I discussed some more in later threads, of "component" architecture. It was mentioned in the referenced thead also that "throwing away code" is not a good idea (since I'm not using a component system now), but also was said "You might try encapsulating a few of the ideas into what you already have-- breaking the logic of your game into component-systems is a very good idea whether you are OOP or DOP.". Though I don't still yet have a good, strong feel for the component architecture, but it was mentioned that the systems in component architecture should be just stateless functions operating on a database... isn't that DOP? What would be the way to handle these kinds of commands (kick, talk, etc.) both in a component and also a more "traditional" non-component setup like I have now, since it seems a move to component would be a total redo of all the progress acquired so far?

3

Programming / Window managers and "printing messages"

« on: July 29, 2013, 10:59:01 AM »

Hi.

This thread is a follow-up to some issues mentioned here, where "requerent" brought up the concept of "window managers":

http://forums.roguetemple.com/index.php?topic=3497.30

I'm wondering now about that old problem of "printing messages" -- i.e. all the "you hit the <foo> and kill it" stuff. Suppose your game loop looks like this (this is just a text mode game, no fancy realtime animations or anything like that yet):

Code: [Select]

loop:
   receive input
   pass input to window manager
   tell the window manager to redraw

Now when the window manager receives the input, it then goes on to the focused pane. The game area may have several panes in use -- in my program, it'd be messages, world, and stats. The messages area shows all the "you kill the <foo>" messages, and the world area shows the game word, and the stats are shows the attributes and what not of the player character and indicates what level you're on. When input is passed to the world pane, it then may be processed in some high-level way, e.g. keys are mapped through to commands (since keys could be reconfigured, we don't pass keys on to the logic). Then the command goes into logic. In logic (remember, our call stack at this point now looks something like this: logic_routine | pane_input_handler | wm_input_handler | main_loop, where the first element is the function we're in and the rest are higher up), it gets handled in whatever way is appropriate, e.g. a movement command goes on to the movement system, or something. But during that logic processing, messages may be generated. E.g. there's a collision with a wall, or we attack a monster. Consider the case of monster attacking, since that's where multiple messages separated by logic are likely to occur. The player attacks the monster. A message is sent. Logic continues. The monster fights back (assume it wasn't killed). More messages are sent.

The problem? For one, the render phase comes only after wm_input_handler returns. Though, in the thread I link to, it's mentioned it's OK to tell the WM to update from the logic (the "separation of logic and render" refers to avoiding mixing low-level rendering operations in with game logic). But, the main loop is where input also is acquired as well. What if we have a "more" prompt, necessitating input to go to the message pane now, while there's still unfinished logic? It seems like we'd need to break out of the logic and go all the way back up the stack to the main loop, or spawn another input/logic/render loop down inside the one we're already in! And what if we want to support "more-less" as well as mored (e.g. if we were using a non-textmode interface where scrollbars and so on are available?) messages?

This is similar to something I mentioned here in earlier threads, only now I'm curious about it in the context of this new window-manager paradigm.

4

Programming / Rendering question

« on: July 14, 2013, 06:39:02 AM »

Hi.

I was wondering about this: When drawing the level map in a roguelike, there seems to be two things one can do:

1. draw the entire map every frame

2. draw only what's "changed".

In the case of a simple text-based one, which is better? It would seem 2) would be faster, but also at the cost of added code complexity (you need to notify the rendering system of any and all changes to the map somehow). Does this matter on modern machines or is it just not worth the added complexity now? How do you do this in your games?

And what happens when you get up to graphics like with tiles and animated tiles? Or with "chase" (is that the right term?) scrolling where the scrolling follows the player as they move around (which'd seem to necessitate a full redraw anyways since everything on the screen moves)?

5

Programming / Separating render and logic

« on: July 07, 2013, 09:15:26 AM »

Hi.

In a roguelike (or perhaps, any other kind of game) game loop, we may have:

input
logic
render

in that order. These should be separate. But suppose we need to print a message, which happens during the logic. Or show an explosion, or a magic, or an animation of a projectile firing, and so forth. These should all be handled in the "render" phase, yet the logic dictates if one does or doesn't happen. What's the best way to handle this? I was going to try a system where the render system is simply passed different things that happen which affect the display during the logic, which go on a queue, and then at render time for this turn it goes through the queue and handles each one, rendering it in the same sequence as they happened. So the actual rendering doesn't take place during the logic, only notification of the render system with what needs to be rendered. Would this be "correct"?

6

Programming / "Game state"-based game loop.

« on: May 28, 2013, 12:09:01 AM »

Hi.

I recently found this:

http://gamedevgeek.com/tutorials/managing-game-states-in-c/

and I was thinking of utilizing this idea for a roguelike game, to handle the menus and what not. Would it work? If so, then I'm curious about some fine points:

1. is it possible to dispense with the singletons (singletons are usually considered bad practice and for good reason -- see here: http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx and here: http://gameprogrammingpatterns.com/singleton.html)? E.g. they say "only one copy of the state objects is needed" -- but then to me it's obvious: just make one copy, don't bother with a singleton!

2. thinking about the future: suppose, instead of just having a simple text-based ASCII game, we move on up to one with more sophisticated graphics, such as sprites, and we have animations going on in the world view in the background of our menus. Yet the game loop would be in "menu state" at that time, yet the background still needs to be updated. Edit: I suppose this isn't much of a problem, since the renderer would render the background first anyway every frame, so it should know about the animations and so update them accordingly.

3. would a separate game state be needed to handle (c)hatting with various NPCs in the game? Note this can display menus (alternative dialogue options) when it's happening.

4. commands that change game state: to get to the menus, you obviously have to input a command. But suppose the game loop is like this:

 1. Handle input
 2. Do logic
 3. Render

Then if the game is in "Game" mode, if it gets an input to bring up a menu, thus switching to "Menu" mode, the state of the game FSM has changed and so now the loop will call the logic function on the menu, but the menu hasn't rendered yet. So what do we do?

5. return from commands: suppose we press "d" for "drop item". The game changes to menu state, with the inventory menu. But now, the menu will return an item index of what item to drop... and then what? The system switches back to game mode? If so, then how does that returned index get to whatever (and where should this code be) actually does the dropping? I.e. when it goes back to game mode, how do you make sure it remembers that it was in the middle of a "drop" command and more importantly, how does the menu system return the value of the selected item to the game mode?

Thanks.

7

Programming / Input system and the "-More-" prompt.

« on: May 14, 2013, 05:46:06 AM »

Hi.

I'm wondering: what's the best way to structure the input system in a roguelike game? That is, the part of the program that gets the input from the keyboard (or mouse, or both) and handles it. Namely, what I'm wondering about is, it is possible to somehow centralize the getting of input and then pass it on to the parts of the program that need it? The difficulty arises with stuff like inventory menus and the infamous "-More-" prompt. Suppose we have a "display" object which has a method in it to display messages in the message area. If we tell it to display a message, but the message isn't big enough to fit, then the "-More-" prompt has to be used, which requires waiting for keyboard input. But this would seem to require the display system to be able to fetch input from the keyboard itself. What's the best way to handle this?

8

Programming / Playing around with a new kind of program architecture: "component system"

« on: April 23, 2013, 08:54:41 AM »

Hi.

I just finished programming an attempt at a “component-based” roguelike system, for practice. It was done over the last 4 days. You can get it here:

http://www.mediafire.com/?61s2vlh9dqiz73v

The code is rough and isn't meant for production work, just for practice, and I've got some questions because there were a number of things I wasn't quite sure how to do “right”, especially not with the new style of architecture I was triying here. It's a simple “curses”-based terminal program and the compile script is for Linux and similar systems – since I use Linux for most of my computing and programming work. Though it shouldn't be too hard to modify it to make it compile on Windows as a console app, provided you can supply the curses functionality with a suitable library (I haven't tried it on Windows, though, or with MS's compilers).

The architecture also uses an “event-driven system” for the main game loop.

Sorry about the restrictive license, but that's because it's rough, unfinished, and for practice and not really serious work. I hope you understand.

Now, the questions:

There is a “renderWorld” routine in the WorldManager, which doesn't seem right – this is related to rendering... where should it be? It needs the data from the world to render it (entities, map, etc.). I also heard at http://www.gamedev.net/topic/618973-creating-a-render-manager/#entry4905254 that a graphics system should only take in basic graphical objects and not more sophisticated objects like entities or “models”, etc. (the linked post says: “Likewise, a model has no place within the graphics module. (...) a general theme is that the graphics module simply handles the commands needed to render things, and provides wrappers for textures, vertex buffers (...)”). The RenderManager works in just that way: the primitive objects it receives (RenderObjects) store simple graphical representations (here grids of characters) only. Yet something has to get that lower-level data (in this case, ASCII representation, in that case, triangles/textures/etc.) from the higher-level entity/map objects and feed it into the render/graphics system: what should it be?

There is a reference to the input manager in the player's “AI component”, which is needed because for the player entity to make decisions when its it's turn to act, it needs a command from the user. But it doesn't seem right it should “know about” the input system, does it? If not, then does that mean we should add more code to the event handler to check if the acting entity is the player entity and capture the input there and then pass it on to the entity, thereby avoiding the reference to the input manager but adding more complexity/specialization in the event handling system? But if that's bad too, where should we put the calls to the input manager (remember: we don't want input until the player's “turn to act” comes around, i.e. when the EVT_ENTITY_ACTION event with the actingEntity variable equaling the player entity is due)? Already we have a problem in that the “quit” command isn't really something the entity does, but a signal to the game to stop!

Where should the handler for game events go? Not all events (EVT_QUIT is an example – there'd be others in a real game) involve an entity acting. So putting it on the entities doesn't seem to work – or should one have handlers for those kind of events on the entities, and handlers for the other in the game? But would putting it on the entities violate the component system? If so, what should we do? Have something to translate events to messages?

Also, how would one make the part of the program that handles stuff like collisions/interactions between entities, with tiles on the map (right now, there is no collision handling and I only have an “ad hoc” stop in there (clearly marked!) to keep the player from running off the map altogether! Obviously that is a big no-no in a production program! It's just a placeholder until I can get how to work this out.), etc.? It doesn't seem right to make the physic component of an entity have full access to the map and all entities on it (i.e. essentially the whole WorldManager), does it? If it isn't right, then what should I do (that “ad hoc”-marked code is really just a placeholder because I'm not sure how to handle this dependency problem)?

And in a bigger game, where you can pick stuff up, what's the best way to distinguish a “pickupable” entity from a non-pickupable one?

I'd also like to hear a general review/comment/critique/etc. of the code – any pointers for improvement would be welcome.

9

Programming / "Event driven" roguelike architecture question

« on: March 28, 2013, 10:09:39 PM »

Hi.

I'm curious about this: I notice that there are some roguelikes (such as JADE/ADOM II and Incursion) that use an "event-driven" architecture. I was wondering: how does one reconcile this kind of architecture with the turn-based nature of roguelikes? If you represent the game activity as a bunch of "events", what do you use to determine where one turn ends and where another begins, which happen on which turn, etc.?

10

Programming / Tunneling algorithm.

« on: November 15, 2011, 08:56:51 PM »

Hi.

I'm wondering about this. I've been trying to make a tunnel generator, but am not sure if my current solution is really the best.

The goal is to make a tunneler that avoids this:

Code: [Select]

                .
                 .
..................
       .....................
       .
       .

That is two tunnels which have a stretch where they parallel each other so closely that no wall can be made between them, yet do not overlap, forming a 2x11 "pseudo-room" that is not an "actual" room. A similar phenomenon can also occur between rooms and tunnels. Both kinds are undesirable.

The current method I've got works by putting special "cue" tags on the "borders" of rooms and tunnels which then provide cues to an A* pathfinding system that is then used to form the tunnels. This method is very powerful, since we can create many different kinds of constraints and even tunnel shapes simply by varying the cost function. But the problem is that the A* part is slow. Though not really noticeable on a modern machine, on some really old stuff it might be a problem (10 seconds to generate a level on an old old old Pentium or 486 thingy, though I don't know if that should matter, and I haven't tested it on any, I'm just guesstimating -- it takes 20 milliseconds to generate an 80x80 level on my few-years-old Core 2 system with optimization turned on with the compiler, and imagining a 486 to be 500 times slower, which may be too high or low, I don't know as I don't have access to one to test with. It's much slower than even Angband's level generator though...). Is that bad? If so, what alternatives may there be, that are faster _and_ also give more diversity?

Another level generation algorithm I've considered is one I call as "KISS" (since it's "simple and stupid" but produces fair results (though not quite what I want)) or "ADOMian" (as it looks like something very similar is probably used in the game ADOM, though without the sources one cannot be totally sure). This method works as follows:

1. Place rooms at randomized positions in a grid dividing up the level. This gives a fairly uniform distribution of rooms. But all room sizes must be constrained to be odd numbers, as must be their coordinates.

2. Connect room edge points with tunnels. All edge points and tunnel corners must have odd-number coordinates. Tunnels can be L-shaped or have zig-zags.

It produces fairly decent results (see ADOM), but to me is not as nice as the A*-based approach in terms of output and also it's ability to produce diversity. Namely, zig-zags must be "bulky" (with length-3 minimum zigzags instead of length-2), which means highly irregular ("cave-like") tunnels may be a problem (though perhaps with those we may not care so much about "pseudo-rooms" and all that anyway).

So what would be a good approach to this problem?
 Is there a third option here which I have not considered?

11

Programming / Corner detection algorithm

« on: March 27, 2010, 09:19:00 PM »

Hi.

I have a question. What kind of algorithm could be used to determine if a wall square is a corner? E.g.

Code: [Select]

...
##.
...

identifies as

Code: [Select]

...
-X.
...

where - is a horizontal wall and X is a corner? So given the tiles in the vicinity of the wall square, how do we find out if it's a corner or straight wall?

12

Programming / Pathfinding implementation not working the way I want it to.

« on: March 25, 2010, 05:24:55 AM »

Hi.

I just wrote up some code to do the A* pathfinding algorithm for digging tunnels in a dungeon generator for a Roguelike game, and I'm getting some odd results. When I use it to dig a tunnel through free space between two points, I got this:

Code: [Select]

################################################################################
################################################################################
################################################################################
################################################################################
####.###########################################################################
#####.##########################################################################
######.#########################################################################
#######.########################################################################
########.#######################################################################
#########.######################################################################
##########.########################.############################################
###########.######################.#############################################
############.##################...##############################################
#############.##############...#################################################
##############.########.....####################################################
###############.##.....#########################################################
################..##############################################################

But that doesn't look good. I'd like to have it look like a straightish diagonal line between the two points, something sort of like what would come out of Bresenham's algorithm. Why is it goofy like that? I use a rounded-down Euclidean H-function (with sqrt), a same-cost G-function (i.e. move to any neighbor including diagonals is the same cost), and the open list priority queue is implemented via binary heap with supplementary tiebreaking key to enforce LIFO tie behavior (so it's more of a "stack" than a "queue" when it comes to ties) among nodes/tiles with equal F-cost. Neighbors are checked in a clockwise pattern starting at the upper-left.

If I switch the heap over to FIFO behavior (like a proper "queue"), I get this:

Code: [Select]

################################################################################
################################################################################
################################################################################
####.......#####################################################################
###########.......##############################################################
##################.....#########################################################
#######################.....####################################################
############################...#################################################
###############################...##############################################
##################################.#############################################
###################################.############################################
################################################################################
################################################################################
################################################################################
################################################################################
################################################################################
################################################################################

which looks a bit better, but the algorithm also seems to explore many more squares. And it's still got that "curve" which doesn't look too good. (Strange; it reminds me of the graph of the square root function. Is there something significant about that?) Both tunnels seem to have the same length (32 squares). I presume it has something to do with how it handles the multiple existent shortest paths between the points, but how do I get it to give me "nice" ones?

The code (C++) for the G, H functions is this:

Code: [Select]

float GCostFuncs_Flat(u16 y1, u16 x1, u16 y2, u16 x2)
{
  return(BASE_COST);
}

float HCostFuncs_Euclidean(u16 y1, u16 x1, u16 y2, u16 x2)
{
  double ydist(y2), xdist(x2);

  ydist -= y1;
  xdist -= x1;

  return(floor(sqrt(ydist*ydist + xdist*xdist))*BASE_COST);
}

And yes, I've tested the heap code to make sure it didn't have any bugs in it. I've tried various descriptions of the A* algorithm and have redone this like 4 or 5 times with the same results... which suggests I'm missing something, but I can't figure out what it is. What is going on here? Using alternative heuristics like, e.g. diagonal (max of x/y distances) doesn't help it, though it's not curved anymore, it has either a long straight segment before diagonaling down (FIFO) or it diagonals down, then goes straight for a while, before a short diagonal up to the destination point (LIFO).

13

Programming / Questions about programming a Roguelike game

« on: January 29, 2010, 06:54:14 PM »

Hi.

I have a couple questions:

1. Which one of C or C++ is more often used for making Roguelike games? I've heard of other languages being used as well, but for games written with one of these two, which is the more often used one, and why?

2. How can one make a good level generator that generates levels without having tunnels remove the walls from rooms (piercing a room is fine, so long as it doesn't take off stretches of wall, or knock off a corner), or "double up" (i.e. parallel each other so close no wall is in between them)?