"Game time"

[mike3]

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

[Quendus]

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.

[mike3]

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?

[Quendus]

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.

[mike3]

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)

[Quendus]

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.

[Quendus]

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.

[mike3]

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?

[Quendus]

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.

[mike3]

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"?

[Quendus]

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?

[Gr3yling]

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.

[Vanguard]

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.

[Gr3yling]

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? 

[Quendus]

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.