From what I saw, most of these engines are events, not times. with a new tick caused by some interval after the end of the last tick . (thus mainly avoiding the tick question taking more time)
It also simplifies implementation; you just have a game loop that fires the tick event and then sleep s / yield for the required interval. Which is trivial.
This can be simplified by modeling the world as a tree, where each element controls propagation events (such as ticks ) to its children. as long as you avoid / control the loops, this works well (I did it).
This effectively reduces the tick system to something like this (psudocode):
while (isRunning) { world->tick(); sleep(interval); }
In most cases, they need little to become much more attractive than adjusting the length of the previous duration.
Any actions by individual objects will be part of their own action queue and processed during their own tick events.
Usually, user commands will be divided into "ingame" and "meta" commands, any game will simply change their character actions, which will be processed in the next tick, as usual for any other object.
A simple round battle follows naturally from this foundation. in real time it can be modeled with finer tick division with an additional βtime poolβ.
Textmode
source share