Temple of The Roguelike Forums
Development => Programming => Topic started by: mike3 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)?
-
I would pick a small unit of time (a tick) and decide how many ticks there are in a second, how many seconds there are in an hour, and how many hours there are in a day. I would definitely not use numbers from the real world.
The tick small enough for the time of all in-game actions to be expressible as an integer number of ticks. That might mean that 1 tick = 1 second and all actions take one tick, or it might mean that 100 ticks = 1 second and action times are rounded to 2 decimal places. A middle ground would be 2 ticks = 1 second and action speeds can be 1 tick, 2 ticks, or 4 ticks.
If you want to express action times in terms of speed rather than time, you might consider an energy system.
-
I would pick a small unit of time (a tick) and decide how many ticks there are in a second, how many seconds there are in an hour, and how many hours there are in a day. I would definitely not use numbers from the real world.
The tick small enough for the time of all in-game actions to be expressible as an integer number of ticks. That might mean that 1 tick = 1 second and all actions take one tick, or it might mean that 100 ticks = 1 second and action times are rounded to 2 decimal places. A middle ground would be 2 ticks = 1 second and action speeds can be 1 tick, 2 ticks, or 4 ticks.
If you want to express action times in terms of speed rather than time, you might consider an energy system.
However, what about terrains with differing movement cost? In "logical time", which is the time used to sequence actions or events from entities, movement might take some number of ticks regardless of where you are. But in "game time", it might take 6 hours to move across a world map square, while only a few seconds to traverse a dungeon map square (because the world map square represents a much bigger area "in-universe".). So what do you do?
-
I don't see a problem. If a world map tile corresponds to a combat map of a certain size, then the time to traverse the world map tile is the diameter of the combat map divided by the entity's speed. Or if you want to be strictly simulationist for no good reason, you can use pathfinding to find the shortest route across that combat map.
If world map tiles don't correspond to combat maps, then there's even less of a problem - you set an arbitrary travel time for world map tiles, which might be a function of terrain types. If you have difficulty making up numbers, you can calculate the physical size of a world map tile (size of the world map by comparison with a real-world country/island/continent, divided by number of tiles) and divide by 1.5 metres per second.
-
I don't see a problem. If a world map tile corresponds to a combat map of a certain size, then the time to traverse the world map tile is the diameter of the combat map divided by the entity's speed. Or if you want to be strictly simulationist for no good reason, you can use pathfinding to find the shortest route across that combat map.
If world map tiles don't correspond to combat maps, then there's even less of a problem - you set an arbitrary travel time for world map tiles, which might be a function of terrain types. If you have difficulty making up numbers, you can calculate the physical size of a world map tile (size of the world map by comparison with a real-world country/island/continent, divided by number of tiles) and divide by 1.5 metres per second.
I'm not sure about something here. When you're on the world map, no combat maps have been generated (they are generated upon encountering an enemy). So the game is not dealing with movement across the combat map, but on the world map itself. Are you suggesting to use the size of the combat map just to get a number, as opposed to having to have one generated at the time? But if a world map tile represents, say, 2 km, and a regular map tile 2 m (for example), then that'd need a ridiculously huge combat map of 1000x1000 (bigger than any dungeon map!) to get the right travel time via that method.
And my question was also about the logical vs. game time thing. A tile movement may take 6 hours, but each action may correspond to only a small number of logical ticks (for example, an entity of speed 1.0 may have, say, 1000 logical ticks between actions, which does not necessarily correspond to the amount of in-universe-clock time spent.). That's the discrepancy problem I was wondering about. Should one try to make the logical time and in-universe time in 1-1 correspondence, or what? (so that a move across the world map advances the logical counter a million ticks, for example)
-
I'm not sure about something here. When you're on the world map, no combat maps have been generated (they are generated upon encountering an enemy). So the game is not dealing with movement across the combat map, but on the world map itself. Are you suggesting to use the size of the combat map just to get a number, as opposed to having to have one generated at the time? But if a world map tile represents, say, 2 km, and a regular map tile 2 m (for example), then that'd need a ridiculously huge combat map of 1000x1000 (bigger than any dungeon map!) to get the right travel time via that method.
It's just a possibility. I don't know how crazy you are about perfect realism (I've seen some people on this forum and IRC who would settle for nothing less). It might not be practical to run A* on a 10^6 tile map every time the player moves on the world map, but who would want to deal with combat on a map that size anyway? And who would take 6 hours to walk 2km?
And my question was also about the logical vs. game time thing. A tile movement may take 6 hours, but each action may correspond to only a small number of logical ticks (for example, an entity of speed 1.0 may have, say, 1000 logical ticks between actions, which does not necessarily correspond to the amount of in-universe-clock time spent.). That's the discrepancy problem I was wondering about. Should one try to make the logical time and in-universe time in 1-1 correspondence, or what? (so that a move across the world map advances the logical counter a million ticks, for example)
It all depends on the system you use. If the combat map of a world tile is supposed to be a literal map of the whole extent of that tile, then it should probably take the same time (or approximately the same time) to traverse it in either mode. If it's just a representation of a typical region within that world tile, then it doesn't matter what you do in that tile - time stops on the combat map, and it can't be used for travel. It doesn't matter if it takes 5 game minutes to cross the combat map, because it's just a microcosm of that world tile.
-
My advice to you: choose a system that's good enough for you in terms of realism and feasibility to design/program.
If it's important to you that you can cross the continent on both the world map or the combat map, and you want both methods to take the same time, then make it that way. If that sounds completely pointless to you, then use a simpler way.
-
I'm not sure about something here. When you're on the world map, no combat maps have been generated (they are generated upon encountering an enemy). So the game is not dealing with movement across the combat map, but on the world map itself. Are you suggesting to use the size of the combat map just to get a number, as opposed to having to have one generated at the time? But if a world map tile represents, say, 2 km, and a regular map tile 2 m (for example), then that'd need a ridiculously huge combat map of 1000x1000 (bigger than any dungeon map!) to get the right travel time via that method.
It's just a possibility. I don't know how crazy you are about perfect realism (I've seen some people on this forum and IRC who would settle for nothing less). It might not be practical to run A* on a 10^6 tile map every time the player moves on the world map, but who would want to deal with combat on a map that size anyway? And who would take 6 hours to walk 2km?
That's right, so I wouldn't have the combat map that huge... yet the tile still needs to represent 2km. Also, 6 hours and 2 km were pulled from my head separately.
And my question was also about the logical vs. game time thing. A tile movement may take 6 hours, but each action may correspond to only a small number of logical ticks (for example, an entity of speed 1.0 may have, say, 1000 logical ticks between actions, which does not necessarily correspond to the amount of in-universe-clock time spent.). That's the discrepancy problem I was wondering about. Should one try to make the logical time and in-universe time in 1-1 correspondence, or what? (so that a move across the world map advances the logical counter a million ticks, for example)
It all depends on the system you use. If the combat map of a world tile is supposed to be a literal map of the whole extent of that tile, then it should probably take the same time (or approximately the same time) to traverse it in either mode. If it's just a representation of a typical region within that world tile, then it doesn't matter what you do in that tile - time stops on the combat map, and it can't be used for travel. It doesn't matter if it takes 5 game minutes to cross the combat map, because it's just a microcosm of that world tile.
Yes, the combat map is just supposed to be part of the tile. As mentioned, having the entire tile would create a ridiculously-large combat map (1000x1000). In which case, advancing the time by the time required to walk across the map would vastly underestimate the time it "should" take, no?
Also, what should be done if we want to have things that happen at different clock times?
-
Yes, the combat map is just supposed to be part of the tile. As mentioned, having the entire tile would create a ridiculously-large combat map (1000x1000). In which case, advancing the time by the time required to walk across the map would vastly underestimate the time it "should" take, no?
It all depends on the system you use... If it's just a representation of a typical region within that world tile, then it doesn't matter what you do in that tile - time stops on the combat map, and it can't be used for travel. It doesn't matter if it takes 5 game minutes to cross the combat map, because it's just a microcosm of that world tile.
Also, what should be done if we want to have things that happen at different clock times?
Make a data structure representing dates and times of day. Make a function to convert those to tick numbers. Make a list of important dates and times of day. check every tick to see if one matches. If there are too many to check, then check every day for events that will happen today, and then check every tick for events that happen today.
I don't know why you can't make these decisions yourself.
-
Perhaps this is the source of difficulty: in the program as it exists now, I use an internal unit of "ticks" to separate various events on a queue. Each entity that does something has a place on the queue which represents when it acts. So there may be 1000 ticks (say) of this between actions (it depends on the entity's speed). But this queue doesn't relate directly to the time represented on the clock. An entity gets 1000 ticks (say) between actions, but such an action may take a lot of clock time, e.g. the player walking on difficult terrain. Are these kind of ticks the same as what you are calling "ticks"?
-
Yes. But if world time stops on the combat map, then you'd have to use a different tick on the combat map (one which just makes actors move in the right order, and doesn't advance the world clock). In that case, the "tick" on the world map could be a comparatively long period of time like a minute or 5 minutes.
There are dozens of ways of doing this - dividing a world up into tiles which each contain a higher-resolution map that allows smaller-scale actions on or off the clock. Many of these systems have already been implemented in games like ADOM, Age of Wonders, Elona, TOME4, Total War, etc. It's not at all difficult to figure out the programming and realism implications of the systems they use. Why not play some of them, choose a system you like that doesn't have too many difficult design, programming, or multiplication problems, and implement it?
-
So, as I read this, I notice that a pattern similar to what I have observed in other rogue-likes, which is that there is a tendency to adopt unusual units of measurement. Why not use units that are immediately understandable to the player, like milliseconds, rather than made up ones, like "ticks?"
This is similar to the problem of saying that an action takes "X turns" to perform. I'm not sure that this is exactly what is being suggested here, but I have seen this concept used in other games, and I don't think it is the best way of doing things. Why use the concept of fixed length turns at all? In my thinking, a "turn" would consume an amount of time that depends on the specific action performed, since it lasts from the time an action is input/scheduled by a creature/actor until that action is completed and a new action can be scheduled.
-
Ticks can be milliseconds, or any other unit of time you'd like, but mechanically speaking, it isn't important whether the 500 ticks needed to attack represent 500 milliseconds, 5 seconds, or anything else. Turns are useful because they're the units in which the player interacts with the game. If a badguy starts doing a super move that takes 5 turns to fire off, you know exactly how much time you have to prevent it, but if it takes 15 seconds, things aren't as clear.
If you're concerned with realism and/or simulationism, there's no problem with expressing ticks or turns in terms of real units of time, but there's no "gamist" benefit for doing so.
-
Ticks can be milliseconds, or any other unit of time you'd like, but mechanically speaking, it isn't important whether the 500 ticks needed to attack represent 500 milliseconds, 5 seconds, or anything else.
Maybe, but non-mechanically, I can think of good reasons to use real world time measurements rather than made up ones. What about keeping the player connected to the flow of time in the game? Ticks and turns are both ambiguous, because they don't give the player a sense of how much time an action requires or how much time has elapsed since they started playing. Telling the player that 1000 turns have passed since they started their adventure doesn't really have the same meaning as saying that 2 days, 12 hours, and 30 minutes have passed.
This is particularly important if a game has a day-night cycle. Without some sort of time piece on the HUD, they player only knows what time it is if they are outside and happen to get a message that describing the environment, which won't occur really often.
Turns are useful because they're the units in which the player interacts with the game. If a badguy starts doing a super move that takes 5 turns to fire off, you know exactly how much time you have to prevent it, but if it takes 15 seconds, things aren't as clear.
I would argue just the opposite. If the game has a speed stat, the length of a creature's turn depends on who they are. So, saying that a very fast creature needs 5 turns to ready and execute an attack means something different than saying a very slow creature needs 5 turns. Also, most roguelikes don't let you know how many turns it will take an opponent's attack to resolve to begin with, do they?
-
Why not use units that are immediately understandable to the player, like milliseconds, rather than made up ones, like "ticks?"
I can smell a strawman. Ticks are a useful abstraction for designing and programming games with fine-grained timing. This is standard practice when making real-time games. They don't have to be a round number of milliseconds. A developer can use them without exposing them to the player.
If there's a lot of variation in the time taken by individual player actions, or if there are infrequent timed events on the clock, then it's sensible to write them in real-world units of time.
If there's no day/night cycle and most actions take the same amount of time, then there's nothing wrong with calling it a "turn" and letting players' experience with board games and card games inform them about the concept.
-
I would argue just the opposite. If the game has a speed stat, the length of a creature's turn depends on who they are. So, saying that a very fast creature needs 5 turns to ready and execute an attack means something different than saying a very slow creature needs 5 turns.
That's why you communicate that information in terms of the player's turns.
Also, most roguelikes don't let you know how many turns it will take an opponent's attack to resolve to begin with, do they?
No, but most of the time everything resolves on the same turn it activates. I think a RL built around multi-turn abilities with varying degrees of slowness could be interesting, though.
-
Why not use units that are immediately understandable to the player, like milliseconds, rather than made up ones, like "ticks?"
I can smell a strawman. Ticks are a useful abstraction for designing and programming games with fine-grained timing. This is standard practice when making real-time games. They don't have to be a round number of milliseconds. A developer can use them without exposing them to the player.
In my game I have "atomic turns" and "standard turns". A standard turn consists of several atomic turns. Most monsters, including the player, acts once per standard turn. The fastest monsters acts every atomic turn. The slowest monsters waits more than one standard turn - but not necessarily an even number of standard turns, it's rather X standard turns + Y atomic turns.
Some things are updated on atomic turns, for example which cells have light on them - to ensure this is always updated even from the perspective of the fastest monsters.
-
I can smell a strawman. Ticks are a useful abstraction for designing and programming games with fine-grained timing. This is standard practice when making real-time games. They don't have to be a round number of milliseconds. A developer can use them without exposing them to the player.
That's true, but I, personally, would want to show my time keeping system to the player. That's the main reason that I would use the methods that I am talking about for my particular purposes. I want to show the player the amount of time that their actions take using a type of measurement that is easy to recognize and understand. And I don't want to measure time internally using non-millisecond ticks and then convert that measurement back to milliseconds to show the player.
If there's a lot of variation in the time taken by individual player actions, or if there are infrequent timed events on the clock, then it's sensible to write them in real-world units of time.
If there's no day/night cycle and most actions take the same amount of time, then there's nothing wrong with calling it a "turn" and letting players' experience with board games and card games inform them about the concept.
No, I get that. But I am imagining a game where the things that you just mentioned, like a day night cycle and variable turn lengths, are important in gameplay. I am talking about exactly the types of situations that it seems like you are saying would be reasonable instances not to use ticks.
Look, a better way of putting my previous statement might have been: "Don't you think that in games where the passage of time is important and turns are of variable length, real world time measurements can work as well or better than made up ones?"
-
That's why you communicate that information in terms of the player's turns.
But the length of the player's turns varies over the course of a game as the PC's speed stat changes. Just like in ADOM. So that can't always be the standard.
-
I can smell a strawman,..
Also, I'm not sure how this is a straw man. There's not any opponent here who's argument that I'm trying to misrepresent. A lot of roguelikes really do use turns or ticks rather than real world time units. I don't think there's anything deceptive (or even controversial) about that statement.
EDIT: Is it because I was making too broad of a statement by saying that roguelike games in general would be better with my sort of timekeeping system? I guess I should have been more specific? I certainly wasn't trying to deceive anyone with my statements, either way.
-
I guess it's because, at the end of the day, does it really matter if you call your time units "ticks" or "seconds" or "slartibartfasts"? Gameplay is typically going to be the same, so just choose whichever term you're comfortable with, I'd say.
As always,
Minotauros
-
Sorry, double post.
-
I guess it's because, at the end of the day, does it really matter if you call your time units "ticks" or "seconds" or "slartibartfasts"?
...Except for the situations that I just listed where it does matter? Maybe what I would want to accomplish with timing isn't important to you guys, but there are significant differences between the timing systems we have been discussing, at least to me.
Honestly, I think what it boils down to is that people who make games have a tendency do things a certain way because it has become ingrained in the collective thinking of game makers and game players.
As far as what Quendus said, I guess that "straw man" is just a term he uses to mean "a claim that I disagree with"? I think the expression has pretty negative connotations, though, so I was kind of taken aback by his choice to use it.
EDIT: Or, maybe what he means is that I seem like I am arguing just for the sake of arguing. I'm honestly not, these are things I think a lot about and are actually important to me.
-
This is particularly important if a game has a day-night cycle. Without some sort of time piece on the HUD, they player only knows what time it is if they are outside and happen to get a message that describing the environment, which won't occur really often.
They still won't. No one's going to figure out how many 2-second turns they are away from sunrise.
But the length of the player's turns varies over the course of a game as the PC's speed stat changes. Just like in ADOM. So that can't always be the standard.
Obviously you use the player's current speed in cases like that. If you want to also communicate absolute time in whatever units, that's fine too.
I just don't think there are many situations where seconds would be more useful than ticks or turns. If you want to do it it's still ok. There's nothing wrong with it.
-
They still won't. No one's going to figure out how many 2-second turns they are away from sunrise.
It has not escaped my notice that the player needs an easily accessible way to reference the current date and time, thank you. I would include both that and time and the amount of time consumed by the PC's last action in the HUD. That way the player would know what time it was and how fast their character was able to perform a given action.
Again, let me point out that most (or maybe no?) roguelikes tell you the amount of (player) turns it takes an opponent to perform an action, and the length of player's turn is variable depending on the player's speed anyway. So communicating the duration of events to the player in a constant unit of time other than a "turn" is a useful thing.
Obviously you use the player's current speed in cases like that. If you want to also communicate absolute time in whatever units, that's fine too.
That's right, both are fine, and one actually tells the player how much time has passed in a way that they can understand.
I just don't think there are many situations where seconds would be more useful than ticks or turns. If you want to do it it's still ok. There's nothing wrong with it.
I don't know what you mean by "many situations". All the examples I have listed are situations where it would be important to use real world measurements rather than time. Most people may not make games that involve the situatoins that I am talking about, but that does not mean that my arguments are not logically sound for the type of game that I would like to make.
-
They still won't. No one's going to figure out how many 2-second turns they are away from sunrise.
*Sigh* and in fact, that's exactly my point, Vanguard. I wouldn't measure time using turns at all, and I wouldn't do so for exactly the reason that you just pointed out: turns are not a unit of time measurement that is quickly understandable to the player.
-
I think the unit of measurement - for space, time, weight, money, or whatever - should be based on it's utility. So I see no value in knowing that quaffing my Potion Of Health will take 12 times 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom (which is what 12 seconds really is). Every unit of measurement is a comparison to something else; which is why, in real life, I still view purchases in terms of how many dinners they cost rather than how many dollars they cost - that's a far more important comparison for me. I don't care about how many milliseconds my actions take any more than I care about the currency exchange rate between Zorkimds and US dollars.
Another way of looking at it is that I like the turn based way of looking at time for the same reason I like the grid based way of looking at space: coarse-grained abstracted units are easier for me to mentally handle.
For example, if I (who is 1 tile big and can move 1 tile per turn) am 3 tiles from a door and a bat (who is 1 tile big and moves 2 tiles per turn) is 9 tiles from the door, I know that I can get to the door in 3 turns but the bat will take 4 turns. So I'm safe.
But if I (who is 1 foot 2 inches by 2 feet 1 inch and can move 3.5 feet per 1045 milliseconds) am 8 feet 10 inches from a door and a bat (who is 7 inches by 1 foot 4 inches and moves 4.1 feet per 790 milliseconds) is 21 feet 4 inches from the door, I need to do more calculations than I'd like to if I want to figure out if the bat will bump into me before I can make it to the door.
Although I could be wrong. Do you have a prototype you can share with us?
-
So, as I read this, I notice that a pattern similar to what I have observed in other rogue-likes, which is that there is a tendency to adopt unusual units of measurement. Why not use units that are immediately understandable to the player, like milliseconds, rather than made up ones, like "ticks?"
I can smell a strawman,..
Also, I'm not sure how this is a straw man. There's not any opponent here who's argument that I'm trying to misrepresent. A lot of roguelikes really do use turns or ticks rather than real world time units. I don't think there's anything deceptive (or even controversial) about that statement.
EDIT: Is it because I was making too broad of a statement by saying that roguelike games in general would be better with my sort of timekeeping system? I guess I should have been more specific? I certainly wasn't trying to deceive anyone with my statements, either way.
I described a system that - internally - uses a minimal division of time (a tick) in order to keep track of time in reasonably fine detail (sub-second) reasonably efficiently (ie. less than 1000 ticks per game second). By implying that this was bad because it was a made-up unit, you misrepresented as being a description of the system the player sees, rather than the game's system for determining what the player sees (which obviously should be in more comprehensible units than "ticks").
Both turn counts and absolute times can be useful for the player to know - in combat, how many turns it takes a rod to charge at the player's current speed is more useful than an absolute time in combat. On the other hand, in DoomRL the absolute times given for different actions (moving, firing, reloading) are more compact and useful in-game than anything that could be done with relative measurements.
-
I described a system that - internally - uses a minimal division of time (a tick) in order to keep track of time in reasonably fine detail (sub-second) reasonably efficiently (ie. less than 1000 ticks per game second). By implying that this was bad because it was a made-up unit, you misrepresented as being a description of the system the player sees, rather than the game's system for determining what the player sees (which obviously should be in more comprehensible units than "ticks").
Oh. I guess I misunderstood you before, and based on what you just said, I agree with you for the most part.
Both turn counts and absolute times can be useful for the player to know - in combat, how many turns it takes a rod to charge at the player's current speed is more useful than an absolute time in combat. On the other hand, in DoomRL the absolute times given for different actions (moving, firing, reloading) are more compact and useful in-game than anything that could be done with relative measurements.
I agree that there are a lot of games where turns work just fine. I promise I understand that. In fact, whenever ticks and turns are mentioned, I tend to think of final fantasy tactics, which uses such a system and is objectively a fantastic game. The only situations where I am arguing that real world measurements might be better are the specific ones I listed.
-
I think the unit of measurement - for space, time, weight, money, or whatever - should be based on it's utility. So I see no value in knowing that quaffing my Potion Of Health will take 12 times 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom (which is what 12 seconds really is).
Look, it's fine if you disagree with everything I've said, but I actually gave specific examples of situations where the methods I described at least might work better. Here it sound like you aren't saying that you dispute the validity of those examples, but instead it seems like you are just ignoring them. Again, I am totally fine with you completely disagreeing with my ideas, as long as you have a complete understanding of what those ideas actually are.
Every unit of measurement is a comparison to something else; which is why, in real life, I still view purchases in terms of how many dinners they cost rather than how many dollars they cost - that's a far more important comparison for me. I don't care about how many milliseconds my actions take any more than I care about the currency exchange rate between Zorkimds and US dollars
You instantly know how long an action took, without requiring any other context, if I tell you it took one second. You do not have any idea, without context, how long an action that required one turn to complete took. Even within a gameplay session, turn lengths are variable if the PC's speed changes over the course of gameplay.
If these things don't matter (and usually they don't), I think you should do things exactly as you described. But in the situations I am describing, my methods may be better. That's all I'm saying.
Another way of looking at it is that I like the turn based way of looking at time for the same reason I like the grid based way of looking at space: coarse-grained abstracted units are easier for me to mentally handle.
For example, if I (who is 1 tile big and can move 1 tile per turn) am 3 tiles from a door and a bat (who is 1 tile big and moves 2 tiles per turn) is 9 tiles from the door, I know that I can get to the door in 3 turns but the bat will take 4 turns. So I'm safe.
But if I (who is 1 foot 2 inches by 2 feet 1 inch and can move 3.5 feet per 1045 milliseconds) am 8 feet 10 inches from a door and a bat (who is 7 inches by 1 foot 4 inches and moves 4.1 feet per 790 milliseconds) is 21 feet 4 inches from the door, I need to do more calculations than I'd like to if I want to figure out if the bat will bump into me before I can make it to the door.
And using coarser measurements is fine. I'm not saying that is a bad way of doing things at all. It is a fine way of doing things. Again, all I am saying is that in some situations (the ones I described) it is better to do things a different way.
Admittedly, I would be lying if I said I didn't fantasize about games where creatures had volumes and distances were measured in millimeters rather than squares.
Although I could be wrong. Do you have a prototype you can share with us?
No.