This atlas is the visual orientation layer for V2. It condenses the product,
runtime, durable records, lifecycle, module ownership, mode estate, production
journey, and release order into complementary models. The focused feature and
architecture pages remain authoritative for detail; current code, tests, builds,
platform evidence, and operations determine support status.
flowchart TB
Player[Player surfaces] --> Shell[Menus HUD accessibility and input]
Shell --> Modes[Combat training replay events racing and world modes]
Modes --> Sim[Integer-frame deterministic simulation]
Sim --> GAS[GAS abilities effects and authored frame data]
Sim --> Rollback[Rollback resimulation and replay]
Modes --> Presentation[Animation camera audio VFX stages and broadcast]
Modes --> Online[Identity matchmaking ranked tournaments and integrity]
Online --> Services[Progression store community support and companion]
GAS --> Data[(Roster moves balance modes and content versions)]
Rollback --> Evidence[(Hashes replays receipts telemetry and audits)]
Services --> Evidence
Presentation --> Build[Cook patch platform certification and release]
V2 is one product spine with several peer experiences. The racing and open-world
paths are not decorative side modes, but they still share identity,
entitlements, content/version, telemetry, accessibility, and release controls
with combat.
sequenceDiagram
actor P1 as Player one
actor P2 as Player two
participant Client as V2 client
participant Online as Online services
participant Server as Authority or peer coordinator
participant Integrity as Integrity and replay
P1->>Client: Queue with ruleset roster and region
Client->>Online: Auth entitlement build and preferences
P2->>Online: Compatible queue request
Online->>Server: Allocate match and signed configuration
Server-->>Client: Seed frame zero peers and policy
loop Every simulation frame
Client->>Server: Bounded input frame
Server-->>Client: Confirmed frame and corrections
Client->>Client: Predict rollback and resimulate
end
Server->>Integrity: Result hash replay and anomaly evidence
Integrity-->>Online: Accepted held or disputed result
Online-->>P1: Ranked progression and replay reference
Online-->>P2: Ranked progression and replay reference
The exact authority model varies by mode. The invariant is that compatible
content, signed configuration, deterministic input, result evidence, and
idempotent progression are established before a competitive result is final.
erDiagram
ACCOUNT ||--o{ PLATFORM_LINK : owns
ACCOUNT ||--o{ FIGHTER_PROFILE : progresses
ACCOUNT ||--o{ RANKED_ENTRY : earns
SEASON ||--o{ RANKED_ENTRY : groups
RULESET ||--o{ MATCH : configures
CONTENT_VERSION ||--o{ MATCH : pins
MATCH ||--|{ PARTICIPANT : includes
ACCOUNT ||--o{ PARTICIPANT : controls
MATCH ||--|| REPLAY : records
REPLAY ||--o{ FRAME_HASH : verifies
MATCH ||--o{ INTEGRITY_SIGNAL : produces
MATCH ||--o{ RESULT_RECEIPT : settles
RESULT_RECEIPT ||--o{ PROGRESSION_EVENT : emits
Account, fighter progression, season/rank, match participant, replay, integrity,
and settlement identities remain separate. A replay can verify a match without
being the progression ledger, and a provider receipt cannot be replaced by a
client result screen.
stateDiagram-v2
[*] --> Assembling
Assembling --> ReadyCheck: compatible build content and policy
ReadyCheck --> Loading: all required participants accept
ReadyCheck --> Cancelled: decline timeout or incompatibility
Loading --> Active: frame zero and authority established
Loading --> Cancelled: asset network or platform failure
Active --> Paused: governed local or tournament pause
Paused --> Active
Active --> Recovering: disconnect or authority migration
Recovering --> Active: bounded rejoin succeeds
Recovering --> Abandoned: recovery budget expires
Active --> Completed: terminal game state
Completed --> Verifying: replay hashes and integrity checks
Verifying --> Settled: result accepted idempotently
Verifying --> Disputed: anomaly or version mismatch
Settled --> [*]
Disputed --> [*]
Cancelled --> [*]
Abandoned --> [*]
Lifecycle state must be durable enough to distinguish cancellation, abandonment,
dispute, and settlement. Retry or reconnect cannot double-apply rank, rewards,
challenge, or commerce effects.
classDiagram
class V2GameHost {
activateMode()
pinContentVersion()
}
class CombatSimulation {
fixedFrame
seed
stepInputs()
}
class RulesetPlugin {
rosterPolicy
tagPolicy
damagePolicy
}
class RacingSimulation {
vehicleModel
trackRules
}
class OnlineBoundary {
authorize()
allocate()
settle()
}
class EvidenceEnvelope {
replayRef
hashRef
auditRef
}
V2GameHost --> RulesetPlugin : activates
V2GameHost --> CombatSimulation : hosts
V2GameHost --> RacingSimulation : may host
CombatSimulation --> OnlineBoundary : bounded by
RacingSimulation --> OnlineBoundary : bounded by
OnlineBoundary --> EvidenceEnvelope : emits
Shared hosting and evidence do not flatten ruleset or vehicle specialization.
The host owns activation/version boundaries; each simulation owns its
deterministic rules; the online boundary owns admission and settlement.
mindmap
root((V2 estate))
Combat
Versus and ranked
Tag and assist
Training and replay
Signature events
Racing
Vehicles and tracks
Online racing
Fighter-driver crossover
Open-world activities
Community
Tournaments and esports
Spectator and broadcast
Creator suite
Companion and support
Platform
Accessibility and localization
Store progression and entitlements
Telemetry and integrity
Build certification and live operations
Use the estate to find the owning focused page; use the runtime landscape to
trace shared dependencies. A feature may appear in several branches while still
having one canonical data and authority owner.
journey
title From V2 design change to supported release
section Define
Specify player contract ruleset and platforms: 5: Design, Product
Update canonical data and compatibility rules: 5: Design, Engineering
section Implement
Change simulation presentation services and tools: 4: Engineering
Add telemetry accessibility and recovery behavior: 5: Engineering
section Verify
Run determinism rollback balance and journey tests: 5: QA
Validate performance cook security and certification: 5: Release, QA
section Operate
Stage cohort inspect evidence and roll back safely: 5: SRE, Release
Publish docs patch notes and support guidance: 5: Owners
No one test substitutes for this journey. In particular, deterministic combat,
online settlement, presentation, platform packaging, accessibility, and live
operations have different evidence owners.
timeline
title V2 evidence progression
Contract : Player promise and compatibility policy
: Canonical authored data and schema
Runtime : Deterministic simulation and presentation
: Online authority persistence and providers
Verification : Unit integration replay and end-to-end journeys
: Performance accessibility security and balance evidence
Candidate : Cook patch certification and support readiness
: Staged rollout observability and rollback proof
Supported : Named platforms modes regions and content versions
: Current operational and regression evidence
The timeline is an ordering of evidence, not a calendar. A later artifact never
retroactively supplies missing proof from an earlier boundary.
Start with the landscape and estate, follow a match through the sequence and
state machine, use the ER and class models for data/contract reviews, and use
the production journey and evidence order during release review. Continue to the
V2 guide, feature index, and
architecture index. The generated gallery links
every additional diagram to its source page and heading.