Cooldown based timing system for complex RL timing.

[Destroid]

This system is a variant of the energy based systems presented on the roguebasin wiki.  I believe it is the most flexible way to implement an energy system in a roguelike that requires sophisticated timing rules.  It is very likely a game out there uses this exact implementation, but I've yet to see it documented.

I shall refer to anything in the game which requires time keeping as a 'timedEntity'.  Mostly this will be actors, but sometimes it will be other game objects, or more abstracts things such as tasks performed by actors.

Each timedObject in the game has a cooldown attribute, which begins at 0.  When a timedObject acts, its cooldown is increased by the relevant amount for the action, say 100 for moving or 50 for drinking a potion.  Each timedObject may have any value for its various cooldown costs and each action may be customised individually.  Each time a new action is demanded, the game loops through the timedObjects, and determines the timedObject with the lowest cooldown.  All cooldowns are then decremented by the amount of cooldown said timedObject has, and said timedObject takes its action.  The process is repeated as the game loops.

This system allows for essentially limitless variety in speed of actions and various ways of modifying speed - individual actions may be slowed by a multplier or fixed amount, or an entire timedObject may have its cooldown increased or decreased by an amount.  If you are willing to spend a little more time determining the next timedObject to act (via iterating instead of finding the lowest cooldown) multipliers can be applied to cooldown decrements per tick.  There is no ceiling on how lengthy an action may be, and no 'saving up' of actions (unless you allow negative cooldown values).

Other timing based effects, such as damage over time, dissipating gas clouds, traditional interuptible actions such as resting, changing armor, or anything else may be handled under the same system.  By creating additional timedObjects which interact with their host timedObject, preventing them from acting while they are in effect, damaging them, etc.  In this way sophisticated or lengthy interactions can be modelled, outside of the standard 'act now, pay later' paradigm.



I'm pretty confident this system can handle pretty much any timing situation a roguelike will demand, with a fairly simple system, using the same timing rules for anything that is based on time (players, monsters, status effects, spell cooloffs etc).  Does anyone see any flaws?  Areas that could be made simpler?  Is there a game you know of using this system?  A situation that cannot be timed by this system?

[tuturto]

EDIT: nvm, after reading your posting and the roguebasin article more closely, Herculeum isn't using that system. Rather, it's the system described in the roguebasin article.

Your system would be neat to try out in the practice. I believe that it would solve the problem with instantly donning on the armour I described in my original posting.

---

Herculeum (https://github.com/tuturto/pyherc) uses system like that. Mainly for character actions, but also for spell effects (like potion of minor poison dealing a little bit damage now and then until the effect runs out).

Cost of actions are modified by speed of actor. That way faster characters can outrun and outfight their slower opponents.

The problem I'm currently having is the long running actions, like changing armour (not that I have armour implemented anyway, but still). Currently character changing armour would benefit added protection immediately, but be able to act only after the cooldown has finished.

[Xan]

A couple of things you might consider as improvements:

Implementation 1) Instead of storing the relative time to act (the cooldown), store the absolute time at which the actor will act.  Doing this, you won't need to subtract something from all the actors' cooldowns, but just increase the global timer.

Implementation 2) Store the 'timedEntity's in a sorted dictionary, so you don't need to search a list for the next actor, but just take the first one, and insert it back with its new time to act.

Design 1) Instead of only having a 'cooldown' for actions, have a "pre-action" and "post-action" time, so certain actions, such as equipping armor, can take a long time "pre-action", and then the action is done, whereas most actions (such as moving) happen instantly, but have a small post-action time.

[Omnomnom]

Does anyone see any flaws?

Not in the mechanic, but in the effect on gameplay. What you suggest would work well as a world simulator, but as a game it makes things too complicated for the player in my opinion.

For example when deciding whether to attack an adjacent monster I want to know:
a) how much time until the monster takes their next turn (ie can attack me)
b) how much time will my attack take

If b < a then I can hit the monster and step away before they can hit me. If not the monster will hit me after I hit them. Makes a huge difference. With simple RL timing this is easy, nearly always b = a so I don't even really need to ask the question. Sometimes a and b are some simple ratio like 1:2, 2:1 to simulate fast/slow creatures relative to the player, but again it's fairly simple to think through.

But for a complex RL timing as you describe a and b are not only different for each monster/player combo, they in fact change each turn as different entities will be out of sync with each other. So either somehow you visualize the numbers for a) and b) to the player (UI nightmare) or you don't and the player has to divine the ratios themselves (for optimal strategy).

This includes the player having to think "how long do I have to wait for b<a so I can kite this monster?" and then performing dummy actions to make that so. Unless of course the game offers a variable wait command (I want to wait for 0.157s!) which is a WTF in itself. With different attack and movement actions of various variable speeds (player and monster) the complexity of calculations required to figure out the optimal action to make explodes.

All this calculation is fairly boring IMO and even if the player does ignore it, it will leave a defeated player thinking "hmm I lost because I didn't spend time on the calculations." and possibly "I can't win without spending time on calculations. I don't want to spend time on calculations. I'll stop playing this game."

Another problem I found with variable action timings is combat vs movement. Imagine a lumbering monster a very slow move speed of 2s but a fast attack speed of 0.2s. The player is twice as fast. So movement 1s and attack 0.1s. So the monster steps towards the player. Now the player has 20 attacks before the monster can attack them back??? The problem is the monster's actions are frontloaded, as you put it " 'act now, pay later'". They perform some long move and then can't react again until some cooldown, even if in reality they've been "interupted". Okay you could paper over this problem by counting an attack as an "interruption" and allowing the monster to make a reaction attack, but this is just papering over the real problem IMO, which is that the turn/tile thing of roguelikes is a discrete abstraction of time and space with time still relative to the player. Trying to get variable action times to work on top of that is like trying to fit a square peg into a round hole (which is only possible in r'lyeh). The only way variable actions work somewhat with turn based is the (old) xcom style of turn units. Just my opinion though, I could be wrong, but this is the impression I got after spending time making a turn system similar to what you describe only to find I didn't like how it played.

So now my opinion has gone back to the idea of simple RL timing being better. In fact I wonder why I ever wanted to have complex RL timing. It's like having over complex combat mechanics. Sometimes simpler is better.

[Xan]

On the other hand, ADoM, ToME, Incursion, etc. all use a timing system very similar to this, and there doesn't appear to be many complaints about they way they do it.

[Omnomnom]

yeah i should probably add a signature like "disclaimer: omnomnom's opinion not worth shit. read at own risk."

[Xan]

yeah i should probably add a signature like "disclaimer: omnomnom's opinion not worth shit. read at own risk."

Well, what I said wasn't opposed to what you said.  It's quite possible some potential players are turned off by timing mechanics like this.  However, simpler mechanics clearly aren't required to have a relatively large number of players, and even to receive financial support from them.  So I'm more inclined to just let developers do what they want here, unless they specifically state that they are trying to make their game more accessible to more casual players.

[Destroid]

Cheers for the suggestions Xan.

Omnomnom: I have considered that, and certainly if you designed your monsters to have a great variety of different speeds things could get very complicated very quickly.  A simple UI resolution is to display on each monsters its time till next action, and have a sidebar on your player telling you how much time each of your actions cost, thereby shifting the calculating onto the computer.  You could inspect monsters to see their range of possible actions, and how long they take.  Certainly player understanding is the most problematic element of complex timing, and some additional design effort would be required in this area.

Complex timing in general does add complexity to the game, and also a new area of strategy.  DoomRL uses complex time with a similar system to this and it is not too difficult for the player to grasp, despite there being little in the way of player aids about monster speed, and player actions being non-interruptible and highly variable in time (from ~0.1 seconds to 4.0 seconds).

For mid loading or rear loading actions... I don't like them much myself.  They are ok for long actions but I don't find them suitable for the short actions that comprise most of the things you do in RLs, attacking, moving, drinking potions, casting spells.  With regard to your monster example, that is purely down to specific implementation, it's up to the designer to avoid making such a undesirable monster.

[Paul Jeffries]

Internally, AS.T.Ro uses pretty much exactly that system.  However, after some testing, I ultimately ended up making every action have exactly the same cooldown.  Mainly that was because it is a multi-character game, and it became very annoying when you couldn't predict the order in which you would control your party.  In a single-character game that obviously wouldn't be a problem.

I guess it depends mainly on the 'feel' you want the game to have - set length turns would make gameplay feel a bit more 'solid' and predictable, while variable-length actions would probably feel a bit more fluid and 'realistic'.

A happy medium might be something like Brogue's rapier (which attacks in half a turn) and Mace (which takes two turns to attack) - it gives those weapons interesting characteristics, but still leaves the outcome easily predictable.

[requerent]

One thing you might want to consider are actions that have an opportunity to cancel mid-way through, or combos and chained effects. Instead of preventing the actor from making a new action entirely, there may be skills or abilities designed solely for use while your cooldown is active depending upon the sequence of previous actions. This can be especially interesting with riposte and feigns if there are opportunities to read the actions of other actors.

I feel that if cooldown isn't a resource that the player can actively manage, then there isn't a point in obfuscating the system. A unicorn can take 11 actions per some arbitrary unit of world-turns whereas a horse can take 10 actions per turn. If the player is the horse and is fighting a unicorn, that extra action that the unicorn has over the horse will get snuck in somewhere- possibly at the precise moment that would be necessary for the player to die-- despite how meticulously they may have been managing their HP.

Because it is very difficult to communicate to the player that every 10 turns they take the unicorn gets an extra turn, it doesn't augment the sensation of strategy in any way. They just occasionally 'get owned' because a unicorn occasionally seems to deal double damage.

On the other hand, ADoM, ToME, Incursion, etc. all use a timing system very similar to this, and there doesn't appear to be many complaints about they way they do it.

It tends to undermine the meaningfulness of skills.

[Darren Grey]

ToME rarely has variances from standard unit time costs for things.  There are many examples of variances from it, but they occur rarely during gameplay.  This is extremely important with its cooldown system - you need to be able to know when a skill will become available again, or when an effect will wear off you or an enemy.  Playing with a character with non-standard speeds is less fun, even when you're faster, as you can never rely on exactly what state you'll be in next turn.

ADOM has a very complex system, with highly varying speeds and actions costs.  It either gets abused or ignored.  Importantly new players are often caught out by the speed trap - elements reducing your speed slightly (like being burdened) that cause you act slower, and thus make you much more vulnerable.  Overall though small variances are rarely tactically important.  They're like a "+1" to any stat, only really being noticeable when abusing small differences or when stacked high.

I have to agree with Omnomnom that from a design perspective highly refined speed is a bad thing.  Turns are a good system for a reason - you can plan and strategise properly, and make tactical positioning very important.  I try to only use half or double speed differences in my games so that the player can easily and quickly take into account speed differences of all units across the board.

Of course everyone designs to their own views.