"Game time"

[Vanguard]

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.

[NON]

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.

[Gr3yling]

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

[Gr3yling]

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. 

[Gr3yling]

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.

[AgingMinotaur]

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

[Gr3yling]

Sorry, double post.

[Gr3yling]

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.

[Vanguard]

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.

[Gr3yling]

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.

[Gr3yling]

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. 

[Trystan]

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?

[Quendus]

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.

[Gr3yling]

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.

[Gr3yling]

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.