Deterministic combat too complicated?

[naughty]

It can be very confusing when the player or enemies get 'out of sync', e.g. if the normal tick rate is 10 and you do a move that takes 5 ticks you can feel that you're out of sync from then on. It can happen in crawl sometimes and I've had it bite me on my own project. This can also be caused by using heaps as a priority queue, they are normally unstable in the sense that two actions that have the same tick counter can happen in either order.

I think it's best to restrict to whole multiples or simple fractions like 1/2, 1/3, 1/4 (so no 3/4 or 2/3). In mathematical terms either the numerator or denominator should be 1. In fact using fractions for ticks is something I surprised isn't really done, it's always integers which causes all kinds of problems if you want an action that takes exactly 1/3 of a usual tick. (I think Brogue uses 100 base ticks per turn and there's at least one action in the game that's supposed to take 1/3 of a turn but 1/3 of 100 is exactly representable. Not a major issue perhaps but it triggers my programmer OCD).

You could remove some of the out of sync issues by forcing actions to always take a whole number of 'big' ticks. So a stance could be modelled as a set of actions that always add up to whole number, e.g. defensive stance move is 1/2 tick movement then 1/2 tick defend (defend is a state that reduces damage say), fast stance is 1/2 tick move, 1/2 tick move (so you get two moves but you aren't defending so take more damage if hit), aggressive stance is 1/2 tick move and 1/2 tick 'prepare to counter' so you can hit back at enemies if they hit you but you take more damage than when defending.

[mughinn]

There is a way to make it so that same tick moves always happen in the same order. If i remember right it's using the > comparison instead of >= (or the other one, depending on how you order the heap), that way, if 2 monsters are doing the same things, they always are doing it in the same order.

But of course i get what you're saying, and i think using multipliers of 2 can solve that.

Say the standard tick is 32, you get, 1/2 with 16, 1/4 with 8, 2 with 64 and 4 with 128. You don't get thirds, but i guess I can live with that.

There are things against the system, and that's the reason i posted it, i'm trying to get feedback before i go an implement everything and end up with something boring or confusing.

I'm in the process of trying to combine everything said here, I feel the heap method is very good, but i won't know until i code it, and I'm currently somewhat far away from there, So I'll have to wait until I do it.

[naughty]

You can fix the heap issue by using a user-defined < operator or function and having a 'tie-break' value, e.g. an incrementing id assigned to each actor. So if the ticks values are the same it uses the tie-break value to determine who goes first.

You can easily calculate a number of ticks per turn to use given the smallest fraction you want by using a factorial. So if you want to be able to use 1/2, 1/3, 1/4 and 1/5 you calculate 5! which is (1*2*3*4*5) = 120.

To be honest I'd guess that quarter turns would be enough so that's 1*2*3*4 = 24 ticks per turn.

[wire_hall_medic]

I had a very granular system in my last project, and I found that the system broke down if the player could become very fast.  Also, some players reported having difficulty telling how many turns they got relative to the enemies (I like a fairly gentle learning curve; to me it's more fun to come up with strategies than to figure out the information necessary to come up with strategies).

So for my current project, there are only 5 speeds:


Speed          Cost     Actions per 6 ticks
Very Fast        2         3
Fast             3         2
Normal           6         1
Slow             12       1/2
Very Slow        18       1/3


Every creature has an energy level; when they act, their speed is deducted from their energy level.  This means that faster creatures are noticeably faster.  A change in speed is a big deal; creatures will only have speeds from Slow to Normal, with buffs and debuffs making the extreme values possible.  There will be a couple of different values, specifically Attack and Move have their own speeds.  Some actions may receive a bump up or down a tier (such as (o)pen speed being Move + 1 tier).

[mughinn]

Okay, thanks for the information, though, what do you mean by broke down? did the player have infinite turns because he had 0 tick moves?

The difficulty you speak of is my main concern with my system, it' be awesome if I could do the granular time without that confusion.

I was thinking something along the lines of your speed tiers, maybe I'll use something close to that.

[requerent]

You can fix the heap issue by using a user-defined < operator or function and having a 'tie-break' value, e.g. an incrementing id assigned to each actor. So if the ticks values are the same it uses the tie-break value to determine who goes first.

You can easily calculate a number of ticks per turn to use given the smallest fraction you want by using a factorial. So if you want to be able to use 1/2, 1/3, 1/4 and 1/5 you calculate 5! which is (1*2*3*4*5) = 120.

To be honest I'd guess that quarter turns would be enough so that's 1*2*3*4 = 24 ticks per turn.

That can create inconsistencies if the number of ticks used doesn't sum to 1 (or whatever your factorial is) at the end of each turn. That is, if you have something moving at 1/3 for 2/3 of the turn but then changes to some other movement factor, it goes out of sync. While this isn't necessarily undesirable, it can result in the 'extra turn' phenomenon relative to the player's experience. If you lock the user into a specific speed for the duration of a turn, that can be solved- but, imo, it's unpleasant unless you have a fatigue system or something of the sort that makes it clear that a player's last action in a turn is limited to, say, a move or something- but this really gets into certain degrees of incoherence- the currency of fatigue, ticks, and turns only obfuscates the experience. There's also the issue of a monster having different attack rates and movement rates, or different abilities functioning on different timescales- you can't ensure that they resolve in a consistent way.

[Quendus]

You can fix the heap issue by using a user-defined < operator or function and having a 'tie-break' value, e.g. an incrementing id assigned to each actor. So if the ticks values are the same it uses the tie-break value to determine who goes first.

You can easily calculate a number of ticks per turn to use given the smallest fraction you want by using a factorial. So if you want to be able to use 1/2, 1/3, 1/4 and 1/5 you calculate 5! which is (1*2*3*4*5) = 120.

To be honest I'd guess that quarter turns would be enough so that's 1*2*3*4 = 24 ticks per turn.

Don't use the factorial. Use the lowest common multiple. In complex cases the factorial can be a lot bigger than the least common multiple. For instance if your speeds went from 1 to 8 (which is not uncommon) the factorial would be 8 * 7 * 6 * 5 * 4 * 3 * 2 * 1 = 40320, and the least common multiple would be 8 * 7 * 3 * 5  * 1 * 1 * 1 * 1 = 840. The LCM can be computed pretty easily using the Euclidean algorihm.

[wire_hall_medic]

Okay, thanks for the information, though, what do you mean by broke down? did the player have infinite turns because he had 0 tick moves?

The difficulty you speak of is my main concern with my system, it' be awesome if I could do the granular time without that confusion.

I was thinking something along the lines of your speed tiers, maybe I'll use something close to that.

A standard turn was 20 ticks; the fastest speed allowed was 2 ticks.  If the player was making 10 attacks for each one the enemies made, those enemies were no longer challenging.  You had to find some fairly rare gear to do it, but once you had it set up, victory was easy.

How much faster the player can be than the enemies without upsetting game balance would depend on a lot of factors, like the size of enemy groups, how hard they hit, etc.

My thought process at the moment is, "how much normal variation do I want, and how far are the extreme cases?"  For the system I described above, the usual limits would be the fast guy getting four moves to the slow guy's one.  The extreme limits (player uses consumable resources to make an already fast character faster, and more consumable resources to make an already slow character slower) make the ratio 9:1.

The differences are big enough that it's easy to tell who's faster, and by how much, at a glance, but not so large that being slow is crippling.

[Quendus]

Okay, thanks for the information, though, what do you mean by broke down? did the player have infinite turns because he had 0 tick moves?

The difficulty you speak of is my main concern with my system, it' be awesome if I could do the granular time without that confusion.

I was thinking something along the lines of your speed tiers, maybe I'll use something close to that.

A standard turn was 20 ticks; the fastest speed allowed was 2 ticks.  If the player was making 10 attacks for each one the enemies made, those enemies were no longer challenging.  You had to find some fairly rare gear to do it, but once you had it set up, victory was easy.

How much faster the player can be than the enemies without upsetting game balance would depend on a lot of factors, like the size of enemy groups, how hard they hit, etc.

My thought process at the moment is, "how much normal variation do I want, and how far are the extreme cases?"  For the system I described above, the usual limits would be the fast guy getting four moves to the slow guy's one.  The extreme limits (player uses consumable resources to make an already fast character faster, and more consumable resources to make an already slow character slower) make the ratio 9:1.

The differences are big enough that it's easy to tell who's faster, and by how much, at a glance, but not so large that being slow is crippling.

My KleinRL had a similar problem. Speed stats ranged from 1 to 100, but the game mechanics reduced that to a constant number of ticks per move. The result was a big jump in actual speed from 24 to 25, from 33 to 34, from 49 to 50, and from 99 to 100 (the latter was almost impossible to achieve in game).
It's a good idea to have diminishing returns for stacking speed bonuses. The biggest boost to speed (x1.5 or x2, for instance) should be the first bonus the player takes, not the last.

[mughinn]

Oh, I get it.

But of course, that's what balancing is for, I'll have to make sure speed differences are not making the too easy or impossible.

That can create inconsistencies if the number of ticks used doesn't sum to 1 (or whatever your factorial is) at the end of each turn. That is, if you have something moving at 1/3 for 2/3 of the turn but then changes to some other movement factor, it goes out of sync. While this isn't necessarily undesirable, it can result in the 'extra turn' phenomenon relative to the player's experience. If you lock the user into a specific speed for the duration of a turn, that can be solved- but, imo, it's unpleasant unless you have a fatigue system or something of the sort that makes it clear that a player's last action in a turn is limited to, say, a move or something- but this really gets into certain degrees of incoherence- the currency of fatigue, ticks, and turns only obfuscates the experience. There's also the issue of a monster having different attack rates and movement rates, or different abilities functioning on different timescales- you can't ensure that they resolve in a consistent way.

I don't think having an out of sync monster would be noticed, the player would notice it if suddenly the monster changed speeds. But if the monster start the turn at tick 360 and you start at 365, and both just move (let's say 16 ticks per movement) then they'll have the same number of turns in X ticks.