Tick Rates and Simulation Frequency¶
Document: Technical Design – Backend – Tick Rates
Status: Exploratory
Last updated: 2026-01-10
1. Purpose of This Document¶
This document defines how simulation frequency (tick rate) is used in Atherion.
Tick rates determine:
- how often the server advances the game simulation
- how responsive combat feels
- how scalable different content types are
- how much load each instance can tolerate
This document intentionally avoids implementation details and focuses on design-aligned technical intent.
2. What a Tick Rate Means in Atherion¶
A tick is a single server-side simulation step.
On each tick, the server may:
- process player inputs
- advance AI behavior
- resolve combat interactions
- update instance state
- emit state changes to clients
Tick rate is expressed in Hz (ticks per second).
Example:
- 10 Hz → one tick every 100 ms
- 20 Hz → one tick every 50 ms
Clients may render at much higher frame rates; tick rate does not cap visual smoothness.
3. Core Philosophy¶
Simulation frequency is content-specific, not global.
Different content types have different needs:
- Social hubs prioritize scale over precision.
- Open world prioritizes survivability under chaos.
- Everspire prioritizes responsiveness and fairness.
Tick rates are therefore assigned per instance and remain stable for the lifetime of that instance.
4. Target Tick Rates by Instance Type¶
4.1. Hub Instances¶
Target: ~2 Hz
Characteristics
- No combat
- Presence, chat, trading
- Cosmetic updates only
Rationale
- Very low simulation cost
- Supports high player density
- Minimal server load
Hubs trade precision for scale intentionally.
4.2. Open World Map Instances¶
Target: ~10 Hz
Characteristics
- Exploration and events
- Moderate combat density
- Variable player counts
- World bosses and meta events
Rationale
- Proven viable by large-scale MMOs
- Acceptable responsiveness with proper design
- Allows higher player counts without excessive load
Open world combat must be designed to tolerate:
- delayed resolution
- batched damage
- forgiving timing windows
4.3. Everspire Run Instances¶
Target: ~20 Hz
Characteristics
- Low player count
- High combat intensity
- Dodge timing matters
- Encounter fairness is critical
Rationale
- Supports responsive action combat
- Reduces ambiguity in hit and dodge validation
- Improves player trust in outcomes
Everspire is where precision is intentionally “spent.”
5. Tick Rate and Combat Feel¶
5.1. Server Tick vs Client Frame Rate¶
- Server tick rate determines authoritative outcomes.
- Client frame rate determines visual smoothness.
Clients should:
- render at high FPS
- interpolate between server updates
- predict short-term movement and animations
This separation allows:
- lower server load
- smoother visuals
- acceptable latency masking
5.2. Dodge Windows and Validation¶
Design assumption:
- Dodge invulnerability spans multiple server ticks.
Implications:
- At 10 Hz, dodge windows should cover at least 2–3 ticks.
- At 20 Hz, dodge windows can be tighter and more expressive.
Dodge validation should be:
- timestamped
- tolerant to latency
- consistent across instances
6. Tick Rate Is Not a Blunt Instrument¶
Tick rate does not imply that all subsystems run at the same frequency.
Within a single instance:
- Combat resolution may run every tick.
- AI decision-making may run at lower frequency.
- Economy, loot, and progression updates are event-driven.
This avoids unnecessary computation while preserving responsiveness.
7. Event-Based vs Continuous Simulation¶
Decision (directional):
Prefer event-driven combat resolution over continuous per-frame simulation.
Examples:
- Skill cast → event
- Damage application → event
- Buff applied → event with duration
Events are:
- timestamped
- validated during the next simulation tick
- batched where appropriate
This model:
- scales better
- simplifies rollback/replay
- aligns with authoritative server logic
8. Tick Stability Over Tick Dynamism¶
Decision (current):
Tick rate is fixed per instance and does not change dynamically.
Rationale
- Predictable performance
- Easier reasoning about combat timing
- Simplifies testing and debugging
- Avoids fairness issues (“the tick slowed mid-fight”)
Load shedding should occur via:
- effect caps
- AI throttling
- interest management
Not by changing tick rate.
9. Relationship to Patching and Uptime¶
Tick rate design supports:
- instance draining (existing instances finish at their original rate)
- epoch-based patching (new instances inherit new logic but same rate)
- graceful shutdown (known tick cadence simplifies finalization)
Instances should not change tick rate during draining.
10. Performance and Scaling Considerations¶
Key scalability levers:
- instance count
- player count per instance
- effect density per player
- interest filtering
Tick rate should be viewed as one part of a larger performance envelope.
Increasing tick rate is expensive. Reducing effect density is usually cheaper.
11. Failure Modes¶
If a server cannot keep up with its tick schedule:
- simulation may lag behind real time
- player experience degrades
Preferred mitigation:
- reduce non-critical processing
- delay cosmetic updates
- cap effect processing
Avoid:
- skipping ticks
- variable tick spacing
- silent desynchronization
12. Open Questions¶
- Is 20 Hz sufficient for the most demanding Everspire encounters?
- Should certain solo challenge content run at higher rates?
- How aggressive should open-world effect caps be?
- Should tick rate differ between normal and challenge modes?
These questions will be informed by prototypes and profiling.
13. Relationship to Other Documents¶
technical-design/backend/instance-model.mddefines per-instance scheduling.technical-design/backend/patching-and-uptime.mdrelies on predictable tick behavior.technical-design/networking/combat-timing.mdwill define input handling and reconciliation.game-design/gameplay/combat-fluid-trinity.mdinforms combat expectations.
End of document.