Instance Model¶
Document: Technical Design – Backend – Instance Model
Status: Exploratory
Last updated: 2026-01-10
1. Purpose of This Document¶
This document defines the instance model used by Atherion.
An instance is the fundamental unit of simulation, scaling, patching, and player experience.
Everything that happens in the game world happens inside an instance.
This model underpins:
- instanced open world maps
- Everspire runs
- social hubs
- tick rate differentiation
- graceful patching and draining
- scalability and fault isolation
This is a conceptual model, not a finalized schema.
2. What Is an Instance?¶
An instance is a self-contained simulation context with:
- a defined set of players
- a defined simulation loop
- a defined lifecycle
- a defined compatibility epoch
- clear ownership and entry rules
Instances are never exposed to players as “channels”. Players perceive them as natural parts of the world.
3. Instance Types¶
3.1. Hub Instance¶
Purpose
- Social interaction
- Trading
- Organization and matchmaking
Characteristics
- High player capacity
- No combat
- Very low simulation frequency
- Fast migration between instances
Typical lifecycle
- Long-lived
- Rarely drained aggressively
- Easy to migrate during patching
3.2. Open World Map Instance¶
Purpose
- Exploration
- Bounties and events
- World bosses and meta events
Characteristics
- Moderate player capacity
- Moderate simulation fidelity
- Multiple instances per map for capacity
- Dynamic entry/exit
Typical lifecycle
- Created on demand
- Destroyed when empty or stale
- Can be drained during patches with minimal disruption
3.3. Everspire Run Instance¶
Purpose
- Core progression
- High-difficulty PvE
- Skill expression and coordination
Characteristics
- Low player count (solo, party, strike-size)
- High simulation fidelity
- Strong ownership (party-based)
- Clear start and end
Typical lifecycle
- Created on entry
- Runs until completion, abandonment, or failure
- Drains extremely cleanly during patches
4. Instance Lifecycle States¶
Every instance exists in exactly one lifecycle state.
4.1. created¶
- Instance metadata exists
- No simulation has started
- Players are not yet active
Used briefly during setup.
4.2. running¶
- Simulation loop active
- Players may enter (subject to rules)
- Normal gameplay
This is the default state.
4.3. draining¶
- Simulation continues
- No new players may enter
- Existing players may continue
- Limited reconnect may be allowed (policy-driven)
Used during:
- patch rollouts
- capacity rebalancing
- planned shutdowns
4.4. ended¶
- Simulation stopped
- Results finalized
- Rewards distributed
- Instance eligible for cleanup
Ended instances must not accept reconnects.
5. Instance Ownership and Entry Rules¶
5.1. Ownership Models¶
Different instance types have different ownership semantics:
- Hub: system-owned
- Open world: system-owned
- Everspire run: party-owned (or solo-owned)
Ownership affects:
- who can rejoin
- who can invite others
- who controls abandonment
5.2. Entry Rules¶
Entry into an instance depends on:
- instance state
- epoch compatibility
- capacity limits
- ownership rules
Examples:
- A draining Everspire run allows rejoin for existing party members (within grace).
- A draining open-world instance rejects new entrants and redirects to a newer instance.
- An ended instance rejects all entry.
6. Instance and Epoch Compatibility¶
Each instance is associated with a build epoch.
Rules:
- Players may only enter instances whose epoch is compatible with their client version.
- New instances are always created with the current server epoch.
- Old-epoch instances may continue running during grace periods.
Epoch compatibility is the backbone of soft patching.
7. Tick Rate Association¶
Each instance declares its own simulation profile, including tick rate.
Working defaults:
- Hub instance: ~2 Hz
- Open world instance: ~10 Hz
- Everspire run: ~20 Hz
Tick rate is:
- defined at instance creation
- immutable for the lifetime of the instance
- implemented via scheduled simulation reducers
This ensures predictability and simplifies patching.
8. Reconnect and Resilience Policy¶
8.1. Reconnect Windows¶
Reconnect behavior depends on:
- instance type
- instance state
- patch phase
Examples:
- Everspire run (running/draining): allow reconnect for X minutes.
- Open world (running): allow reconnect freely.
- Any instance (ended): no reconnect allowed.
8.2. Patch Interaction¶
During patch draining:
- Reconnect is allowed only for instances in
runningordraining. - Reconnect is not allowed after hard cutoff with an old client version.
- New client versions may reconnect only to compatible-epoch instances.
9. Instance Cleanup and Garbage Collection¶
Instances should be cleaned up when:
- state is
ended - all rewards have been distributed
- no reconnect window remains
Cleanup may be:
- immediate
- delayed (for auditing or recovery)
- batched
Instance cleanup must never block the simulation of other instances.
10. Failure Handling¶
10.1. Instance Crash or Host Failure¶
If an instance crashes unexpectedly:
- players are disconnected
- reconnect may attempt to resume if state is recoverable
- otherwise, the instance is ended with compensation
Everspire runs should prioritize fairness and player trust.
10.2. Partial Failure¶
If non-critical subsystems fail (e.g., cosmetic updates):
- simulation continues
- degradation is preferred over termination
11. Scaling Implications¶
This instance model enables scaling by:
- creating more instances, not bigger ones
- isolating high-fidelity content
- draining instances independently
- limiting blast radius of failures
It explicitly avoids:
- global locks
- world-wide simulation loops
- single points of failure
12. Open Questions¶
- Should Everspire instances support pause/resume across long disconnects?
- How long should reconnect windows be per instance type?
- Should open-world instances migrate players automatically during draining?
- Should instances ever change tick rate dynamically?
- How visible should instance boundaries be to players (if at all)?
13. Relationship to Other Documents¶
technical-design/architecture.mddefines the macro structure.technical-design/backend/patching-and-uptime.mddefines epoch and drain behavior.technical-design/backend/tick-rates.mdwill define simulation details.game-design/world/everspire.mdinforms ownership and lifecycle expectations.
End of document.