Ilios
Joined: Apr 11, 2004
|
 Posted:
Sep 15, 2025 - 14:59 |
 
|
As I have been working on the Jervis Engine, the concept of timers is something that obviously needs to be tackled at some point. However, it is a complex topic with many challenging edge cases. Especially around slow connections and disconnects.
So I thought I would describe how I am thinking about approaching it. Maybe someone has a better idea?
(In advance, sorry for the wall of text)
Proposed Timer Model
At its core, each coach has an individual timer. This is not a wall-clock timer, but a virtual timer that only runs while waiting for or processing that coach’s actions. The system enforces time per coach rather than for the entire game.
It is possible to control the timer through a combination of "game"- and "phase"-timers.
Game Timers
Total Game Limit: (Optional) A fixed upper bound on total play time per coach. Once reached, an out-of-time policy is triggered.
Game Buffer: A shared pool of additional time that can be allocated across phases. Configurable per phase.
Extra Time: If Extra Time is triggered, both game time and buffer time may be extended.
Phase Timers
Each phase timer defines how time is allocated using three settings:
Game Buffer: (On/Off) Whether the phase can draw from the shared buffer.
Free Time: Allotted time before buffer usage begins.
Maximum Limit: Caps the phase even if buffer time is enabled and available.
When a phase timer expires, the phase-limit policy is applied. If the total game limit expires mid-phase, the out-of-time policy takes precedence.
The following phases are being proposed:
- Setup Phase: Placing the team and ending setup.
- Team Turn Phase: Actions during a coach’s turn (including inducements and kickoff events).
- Response Phase: Quick reactions such as coin toss choices, skill activations, prayer target selection, or card usage.
Game-limit Polict
Applied when a coach exhausts their total game time. Options are those commonly found in tabletop tournaments and include:
1. No Consequence: Timer may go negative.
2. Roll Over: Stunned players roll over, stand-ups occur if automatic, then the turn ends.
3. Immediate Turn End: All actions halted; turn ends automatically.
4. Forfeit: Game ends per concession rules.
Phase-limit Polict
Applied when a phase timer expires. Options include:
1. No Consequence: Timer continues into negative.
2. Warning: Coach is notified, but otherwise no effect.
3. Timeout Button: Opponent may trigger a turnover.
4. Automatic Turnover: Server auto-generates deterministic actions to end the turn. This will be done using the following algorithm:
a. It will prioritize selecting "No", "Cancel" or "End Action/Turn" actions, i.e., no skill will be used and the turn will end as quickly as possible.
b. Some situations are unclear:
- Block dice: Go from Pow -> Stumble -> Push -> Both Down -> Player Down
- Direction: Move clockwise until a valid direction is found.
- Setup: Players are placed on the center field LoS starting from the top, going to the bottom. In multiple rows if needed.
c. Obviously, this logic is a bit fuzzy and probably requires revision. The main idea is that control leaves the player's hands and all actions are handled by the server.
Example Configurations
Some game setups that can be modelled using this approach:
1. Free game: A game with no timer limits anywhere. Good for practice games or teaching.
- Disable timers completely or
- Set Game Limit to some really high number. Disable Game Buffer on all phases. Set both policies to None.
2. Hard limits: Each phase has a hard limit.
- Leave Game Limit empty
- Set Game Buffer to 0
- Set Setup Timer to 3 minutes. Team Turn Timer to 4 minutes and Response Timer to 30 seconds
- set phase limit policy to "Automatic Turnover"
- Game Limit policy does not apply.
3. Chess-clock: The game buffer is set to 75 minutes with no max. If the game limit is reached, the game is forfeit. It is up to each coach to either use 1 minute or 15 minutes pr. turn. It is up to them to manage it.
- Leave Game Limit empty
- Set Game buffer to 75 minutes
- For all phases: Enable Game Buffer, set Free Time to 0, and leave Max Time empty
4. BB3 time style: A timer setup that looks like the one used by BB3.
- Leave Game Limit empty
- Set Game Buffer to 7.5 minutes
- For Setup/Turn timers: Enable Game Buffer, set Free Time to 2 minutes. Leave Max Time empty
- For Response timer: Enable Game Buffer, set Free Time to 30 seconds. Leave Max Time Empty
- Set Phase-limit-reached policy: Automatic Turnover
- Set Game-limit-reached policy: None
5. BB3 timer with rulebook limits:
- Leave Game Limit empty
- Set Game Buffer to 7.5 minutes
- For Setup/Turn timers: Enable Game Buffer, set Free Time to 2 minutes. Set Max Time to 4 minutes
- For Response timer: Enable Game Buffer, set Free Time to 30 seconds. Set Max Time to 1 minute.
- Set Phase-limit-reached policy: Automatic Turnover
- Set Game-limit-reached policy: None
Open Problems & Edge Cases
The above only describes the timers in an "ideal world", but the devil is in the details. So here is a list of corner cases that all need some consideration:
1. How to handle Kick-off Events?
How should the timer work on kick-off events? E.g., should Blitz, Quick Snap, and Perfect Defense have the same
timer? At a glance, that feels weird, but at the same time, having different timers for each of them feels like
overkill.
Right now, I am leaning towards just using a Turn Timer for these, and accept that someone is allowed to use
4 minutes on doing their Quick Snap.
2. How to handle AFK's?
Right now, my best idea is to have a configurable number of AFK's, with a configurable timer attached. I.e., a coach can mark themselves AFK, in which case their normal timers pause, and the AFK timer is used instead. If the AFK timer expires, the normal timers are used again.
Example: Each coach has 2 5-minutes AFK's pr. game. If an AFK expires, the server will revert to using whatever timer policy the server has configured.
3. When does the server start and stop its timer?
In a distributed system like this, we cannot trust the client to report the time. It can only happen on the server.
This means the following:
a. We start the timer when the message is reported as "sent" on the Server (this doesn't mean the client has received it, see latency below).
b. When receiving messages, we can either choose to stop the timer when the server receives the message or when it actually handles it. There can be a small delay between these two events since the server can be busy doing other things (like writing to a remote database). The fairest seems to be that we stop the timer when the server receives a message.
One important note about this is that the timestamp recorded by the system might differ from wall-clock time.
Some examples:
- The client is showing a timer. Just before it reaches 00:00, the coach selects an action, but because
of latency, the message isn't received by the server in time. In that case, the Server will have detected
a timeout and potentially created an action of its own. In that case, the server will reject the client
action and ask it to revert its state (this happens automatically) and then apply (from the server's point of view) the correct action. For the coach, this might look a bit weird, as their action will disappear and be replaced by another. This is, however, the only way to ensure consistency in a distributed system like this.
- The server will at regular intervals, update the Client with its timer information, but since the Client is
already showing a timer, it needs to adjust it. This means that you might see "jumps" or "slowdowns" in the Client timer as it adjusts to the Server time. Again, this is an unavoidable consequence of a server-driven timer.
4. How to handle different latencies?
Example: A player from Sweden is playing against someone from New Zealand. If, let's say, the Sweden player has a
20 ms latency and the New Zealand player has 300 ms, over 1000 game "actions", resulting in a 280-second difference or 4.5 half minutes that the New Zealand player is effectively "losing".
Solution A: Just accept it.
Solution B: Subtract some fixed amount of time pr. network request. You can use a heuristic based on IP geolocation.
Solution C: Track latency in a sliding window, e.g., 30 seconds or 1 minute. Take the average of that and subtract it from the timer.
I am leaning towards C, it obviously requires a bit more infrastructure but feels the most "fair" although you
can potentially game it by faking a slow connection (which does require a fair bit of technical knowledge).
5. How to handle disconnects?
In a ruleset where the server is the ultimate arbiter of time, disconnects need proper consideration.
I see two categories: Intermittent (sporadic, less than 30 seconds) and Disconnects (anything above this).
1. Intermittent: Will be handled by the latency sliding window. It will give a slight disadvantage to
players with a lot of these (due to how the window calculates the average), but you probably
shouldn't be playing a time-sensitive game in that case anyway. So this seems reasonable.
2. Disconnects: The server will continuously monitor the latency through ping-pong messages every 10 seconds (or so). If it goes above 30 seconds, it will treat it as a disconnect. The server will then subtract the time from the last successful ping-pong from the current coach timer and then disconnect the player.
When they reconnect, the time they have left is the best guess by the server, which might not 100% reflect what the coach was experiencing.
Similar to the sliding window, this can in theory, be gamed by something with the technical knowledge, as they can prevent a client from responding to ping requests. But given how difficult this is compared to the advantage you get by doing it. It seems acceptable.
6. How to handle animations?
Since the server needs to be the owner of the timer, and it is the Client showing animations. There is no way for the Server to know if the Client used animations or not (since the client can lie about it). For that reason, the server ignores them in its timer calculations. Most likely, a very competitive player will turn them off, but in realistic cases, there is only a very small amount of them (when passing and during kick-off), so the "penalty" of having them enabled is probably in the < 1 minute range for an entire game. |
|
|
Hypnotic Gaze (HG) d...
Search
