Combat Input and Latency¶
Document: Technical Design – Networking – Combat Input and Latency
Status: Exploratory
Last updated: 2026-01-12
1. Purpose¶
This document defines how player input is handled under latency in Atherion.
Goals:
- combat must feel responsive and controllable
- player intent must be respected even under moderate latency
- the server remains authoritative at all times
- no gameplay advantage is gained through latency manipulation
- rhythm-based combat remains viable in real MMO conditions
This document focuses on input flow, not damage resolution.
2. Latency Assumptions¶
2.1. Expected Network Conditions¶
Atherion is designed to be playable under:
- Ideal: 20–40 ms RTT
- Good: 40–80 ms RTT
- Acceptable: 80–120 ms RTT
- Degraded: 120–180 ms RTT (still playable, but noticeable)
Combat design explicitly does not target ultra-low-latency environments.
2.2. What Latency Cannot Break¶
Regardless of RTT:
- player actions must register
- animation flow must remain smooth
- the player must never feel “ignored”
Latency may reduce precision, but never agency.
3. Input Ownership Model¶
3.1. Client Owns Intent¶
The client is authoritative over:
- when an input was made
- which action the player attempted
- local animation start
The client is not authoritative over:
- hit success
- damage dealt
- block success
- cooldown resolution
3.2. Intent Packet Structure¶
Each combat input is sent as an intent:
CombatIntent
------------
entity_id: EntityId
intent_type: enum (Attack, Block, Dodge, Skill)
target_id: optional EntityId
direction: optional Vector3
client_timestamp: timestamp
sequence_number: int
Key properties:
- timestamped
- ordered
- idempotent-safe
⸻
4. Client-Side Responsiveness Rules¶
4.1. Immediate Local Feedback¶
Upon input:
- animation begins immediately
- stamina/resource preview updates locally
- sound cues play instantly
This happens before server confirmation.
⸻
4.2. No Input Locking on Network¶
The client:
- never waits for server ACK to animate
- never blocks input due to latency
- queues inputs locally when necessary
Player rhythm is preserved.
⸻
5. Server-Side Validation¶
5.1. Time Window Validation¶
The server validates intent based on:
- client timestamp
- current server time
- configured latency tolerance window
Example:
- a block is valid if it occurred within ±X ms of the server’s block window
This allows skill expression without punishing RTT.
⸻
5.2. Latency Compensation (Bounded)¶
Latency compensation:
- is symmetric (helps everyone equally)
- is bounded (cannot be abused)
- never rewinds other players
The server never rewinds the world to satisfy one client.
⸻
6. Reconciliation Strategy¶
6.1. Accepted Intent¶
If intent is accepted:
- server emits authoritative combat events
- client continues animation uninterrupted
- visual feedback aligns naturally
⸻
6.2. Rejected Intent¶
If intent is rejected:
- client receives correction event
- animation blends into recovery or failure state
- no hard snap or rollback
Rejection must feel like:
“I mistimed that”
not:
“The game lagged”
⸻
7. Dodge and Movement Inputs¶
7.1. Dodge Priority¶
Dodge inputs:
- have higher priority than attacks
- may cancel wind-up animations
- are validated with generous timing windows
This preserves survivability under latency.
⸻
7.2. Movement Prediction¶
Movement is:
- predicted client-side
- reconciled smoothly
- never hard-snapped unless egregiously invalid
Combat positioning remains readable.
⸻
8. Block Timing and Precision¶
8.1. Timing Philosophy¶
Blocks are:
- timing-based
- not frame-perfect
- validated with tolerance
Perfect execution is rewarded, but not pixel-precise.
⸻
8.2. Anti-Abuse Measures¶
To prevent abuse:
- timing windows are capped
- repeated borderline successes are flagged
- server-side randomness is avoided
Skill, not network conditions, determines outcomes.
⸻
9. Input Queuing and Buffering¶
9.1. Short Input Buffer¶
Clients maintain a short input buffer:
- allows chaining actions smoothly
- prevents “dropped inputs” under latency
- limited to avoid automation abuse
⸻
9.2. Server Ordering¶
The server processes intents:
- in sequence order
- per entity
- without reordering across entities
This preserves causality.
⸻
10. Visual Latency Masking¶
10.1. Animation Design¶
Animations are designed with:
- clear wind-ups
- readable recovery
- forgiving cancel windows
This masks latency naturally.
⸻
10.2. Audio as Primary Feedback
Audio cues:
- confirm action acceptance
- signal success or failure
- arrive faster perceptually than visuals
Sound is a key latency-masking tool.
⸻
11. Failure States and Player Trust¶
11.1. Never Blame the Network Visually¶
The game must never:
- freeze input
- pause animations
- stutter due to server delay
Failures must appear mechanical, not technical.
⸻
11.2. Consistency Over Precision¶
Players prefer:
- consistent timing
- predictable outcomes
over:
- perfect precision that varies with latency
⸻
12. Interaction with Content Difficulty¶
Higher difficulty content:
- expects better timing
- but not tighter latency requirements
Difficulty comes from pattern complexity, not timing strictness.
⸻
13. Why This Model Works¶
This approach:
- preserves combat rhythm
- supports MMO-scale latency
- avoids client trust
- avoids rollback complexity
- keeps skill expression intact
It is proven in action-MMO and large-scale PvE contexts.
⸻
14. Open Questions¶
- Should latency tolerance vary by role?
- Should players see latency indicators in combat?
- Should perfect execution windows scale with content difficulty?
- How should extreme latency (>200 ms) be handled?
These will be refined via playtesting.
⸻
End of document.