Thoughts on Time System

Classic traditional roguelikes generally have a simple "Your turn, other's turn" time system:

• The player pick an action, the action happens immediately
• based on the "cost" of this action, the time is increased by that amount
• based on this increased amount, others performs their chosen actions several times
• the control is given back to the player.

This topic has been explored by the community and developers for a long time: (Hakl 2007), (Aaron 2007), (Eratosthenes 2009), (Korostelev 2013), (Reddit 2016), (Reddit 2019), and many more. "Modern" ones usually does not have a hard turn separation except for effects like burnt or toxic. They adjust the order of giving actions dynamically, by using a priority queue that is sorted based on "energy", "mob's clock", or whatever you name it.

This kind of time system is so widely used in this genre that players expect it as the default. And, a well-trained player apply the common tactics and strategies implicated by this kind of systems between different games. For example, in Elona, the speed, which affect how little the "cost" the player's actions will be, is so important that many player choose to stack equipments made of glasses, which increases speed by default.

However, if you think about it, the implication of this system is kind of strange, compared to the real life: if you smash an enemy with a very heavy hammer, you get the punishment for its heaviness after your action. You wait longer after that, but the smashing happens immediately. This for example can be utilized if the player can use an action that is "slow" but deal an incredible amount of damage so it instantly kills anything, because the punishment can be ignored if nothing will attack the player after that.

Also, this system does not naturally give space to multi-turn actions. Different games usually has different ways of implementing those into the system. A way to do so is to simply give the actor several actions to perform, and at the last action the actual outcome happens.

I've been planning a party-based roguelike for a while.

Party system is a unpopular feature among traditional roguelikes. There are a few explorations on this, for example (Antoine 2008). One reason is its implementation difficulty, which is kind of obvious. The second is that it does not fit the genre naturally.

Think about it: the player's control jumps between party members, and whenever the player move a character by one tile, the control jumps to the next party member. This becomes tedious very fast. One way is probably to include in the game a battle system similar to SLG/SRPG, where each turn the character can move for several tiles and then perform a non-movement action. However, this might be too far away from the genre's default.

So, many games use a so-called "companion" system: party members are not controlled by the player, and they just hang around the player's character, using mostly the same AI as enemy mobs. Games that allow summoned minions usually are implemented similarly. The most famous game that falls in the former sub-genre is probably Elona and its sequel Elin.

However, in games with companion systems, how to handle Permadeath is a somewhat problematic. Since companions are controlled by AI, they do silly things from time to time and they die easily. It's probably a sign of "shitty game" if the player is punished too much for their death. In Elona and Elin, for example, they can be either respawn by waiting in the home, or by paying a relative small fee. Other than that, the cost is just some affinities from these dead companion or other NPCs, which is trivial.

Then, since the punishment is totally affordable, especially compared to the player's character's own death, it then makes sense as a Hypothetical Optimal Play to let the companions tank the enemies, and when the case is dangerous enough, the player's avatar can just run away, leaving their companions as baits. This makes death of the player character an unlikely event if the player plays very wisely.

Well, then what's this implication to the time systems? Since I still want the game to be challenge-able enough, I want party members' death to have real impact. Then, it is probably a better idea to give the control of the party members to the player, or at least some kind of control. To do this I need a different time system (but still turn-based of course).

That is, if a mob move, it stays in the old place until the movement succeeds. This implies that 2 creatures can move into the same tile, when they thought they wouldn't. I leave this problem to the future myself.

All actions have a time cost. All actors have timestamps. Acting actions have an estimated finishing timestamp, and they are sorted with the timestamp of actors that do not have an action yet. Each time, the action or actor with the earliest timestamp is picked. If it's an action, then it happens, and its actor's timestamp is updated to be this one; if it's an actor, then they are asked for their next action. The global clock is updated to be this timestamp.

Then, there are several "game modes". They do not change the underlying time system, just how it is presented to the player:

• The game is paused and only paused when the game needs player's next action. This mimics the classic roguelikes behavior.
• The game is paused when any event happens. This is like Real-Time With Pause RPGs, although we are actually turn based.
• The game is paused at each turn separation. This is somewhat similar to Dwarf Fortress's Fortress mode, if you get what I mean.

At each pause, the player can replace its own character and / or party members' next actions. If there are any previous actions to be done, they are canceled.

The first game mode is mostly designed to be used when not in battle, or the battle is easy enough that the player do not want to intervene.

The second is the most hard-core mode: The player has control over everything.

The third is somewhat an auto-play mode, if the player just pick "continue".

A party member have their own intention on the next action to do, the player can let it happen or replace it.

After I think more about it, I feel that the above implementation is unnecessary and it is for sure very difficult to get it right.

For those actions that are supposed to be slow beforehand, all we need is actually "multi-turn actions", as mentioned in the first part.

Each such action has a discrete count of progress, and

• it is required to use the same action until the multi-turn action is fully accomplished, otherwise it is canceled
• some such actions has a partial outcome if canceled
  • rest can be half-way
  • disrupted magic casting can damage the caster
• the actual outcome happens at the last action