# V2 Documentation Guide This guide is the curated front door to V2: the Unreal Engine 5 competitive fighting game, its racing and open-world extensions, its online and esports services, and the production system that turns authored combat data into a deterministic, supportable release. It explains which document answers which question and keeps product intent separate from implementation evidence. V2 is unusually broad for a fighter. Its canonical scope includes multiple combat ruleset families, tag and assist play, training and replay, signature modes, a large roster, ranked and tournament operations, a peer racing game, community and commerce, accessibility, localization, and platform production. The documentation therefore has two levels: complete feature and architecture hubs that preserve stable anchors, and focused pages that make individual systems readable and code-grounded. ## Documentation map ```mermaid mindmap root((V2 documentation)) Product Combat and game feel Modes roster and stages Online esports and live service Racing and open world Accessibility production and launch Architecture Deterministic combat core Rollback and online backbone Presentation and interface Vehicles and world modes Build data telemetry and security Delivery truth V2 backlog Dependency registry Product review Verification remediation Balance and patch evidence Operator detail Agent execution Decisions Integration notes Telemetry Legal and release records ``` The map is a reading model, not a completion claim. The feature and architecture documents describe the intended contract and its known implementation shape; the backlog, current code, tests, builds, provider readback, and dated release evidence establish what is actually supported. ## Start with the question | Question | Canonical starting point | What it proves | | ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | What does V2 promise players? | [Feature hub](../V2_features.md) and [focused feature index](../features/README.md) | Product scope, surfaces, modes, user-visible behavior, and explicit spec-only seams. | | How does combat remain deterministic? | [Architecture hub](../V2_ARCHITECTURE.md), [combat core](../architecture/combat-system-gas-frame-data-and-determinism.md), and [rollback](../architecture/rollback-netcode-and-tag-team.md) | Frame authority, data ownership, rollback/resimulation, tag simulation, and validation boundaries. | | How do online, ranked, tournament, and esports paths compose? | [Online feature guide](../features/online-services-network-and-tournaments.md), [online backbone](../architecture/online-backbone-and-competitive-integrity.md), and [esports services](../architecture/esports-companion-and-ai-services.md) | Player contract plus service topology, competitive-integrity controls, and broadcast/companion boundaries. | | Is racing a mini-game or a peer system? | [Racing features](../features/racing-vehicles-modes-and-online.md) and [vehicle architecture](../architecture/racing-and-vehicle-architecture.md) | Vehicle data, physics, tracks, online racing, crossover modes, and shared platform seams. | | What is implemented now? | [V2 backlog](../V2_TODOS.md), [product review](../V2_PRODUCT_REVIEW_2026-07-06.md), current tests/builds, and dated verification records | The most conservative evidence-backed completion state. | | Which external or shared systems are required? | [Dependency registry](../V2_DEPENDENCIES.md) | Ownership, version, integration, and fallback expectations. | | How should an implementation task be executed? | [Agent execution](./agent-execution.md) and the affected focused feature/architecture pages | Change order, evidence expectations, and nearby contracts. | | Where are the visual models? | [V2 diagram atlas](./diagram-atlas.md) and the generated Docs Center diagram gallery | Curated product/runtime mental models and every authored diagram by source heading. | ## Truth and release model ```mermaid stateDiagram-v2 [*] --> Specified Specified --> Authored: approved data assets or configuration exist Authored --> Implemented: runtime code consumes the contract Implemented --> Integrated: game service and platform paths compose Integrated --> Verified: deterministic automated and platform evidence passes Verified --> ReleaseReady: cook certification operations and rollback pass Implemented --> SpecOnly: named production or integration seam remains Integrated --> Withheld: provider platform or evidence is unavailable Verified --> Regressed: newer evidence breaks the supported claim Regressed --> Implemented: repair returns below the release gate ``` Use the lowest state current evidence supports. A populated roster table is not a cooked roster; an ability class is not a balanced match; a rollback unit test is not an online tournament; a service adapter is not a production provider; and a checked backlog item is not newer than a failing build or certification result. Focused pages deliberately label implemented, scaffolded, fixture, spec-only, and deferred behavior. ## Recommended reading journey ```mermaid journey title From V2 question to verified change section Orient Open the feature index and release scope: 5: Product, Design Pair the feature with its architecture page: 5: Engineering section Trace Follow authored data through runtime and services: 5: Engineering Inspect authority determinism and failure paths: 5: Engineering, QA section Establish truth Check backlog dependencies and dated evidence: 5: Product, QA Reproduce focused and end-to-end tests: 5: QA section Release Validate cook performance certification and rollback: 5: Release, SRE Update docs diagrams and evidence together: 5: Owners ``` ### Product, design, and balance Begin with the [focused feature index](../features/README.md), then read the relevant combat, mode, roster, online, racing, platform, or launch page. Pair it with the owning architecture page before changing frame data, economies, entitlements, matchmaking, or live-service behavior. Balance changelogs and patch notes are atomic records; they supplement rather than replace the system contract. ### Engineering and technical art Begin with the [architecture index](../architecture/README.md). Trace a feature through authored data, UE modules/plugins, deterministic simulation, presentation, online services, persistence, telemetry, build/cook, and tests. Confirm whether referenced paths are implemented or target paths—the V2 docs explicitly retain planned paths when the corresponding backlog task has not yet created them. ### QA, competitive integrity, and accessibility Test local and online success, disconnect, rollback, replay takeover, stale input, version mismatch, denial, platform loss, long content, assistive technology, and recovery states. Competitive claims require deterministic hash/replay evidence and real server authority; accessibility claims require the actual supported device and modality, not only a settings schema. ### Release, security, support, and live operations Read the telemetry/performance/release, security/compliance, live-ops, support, and balance-operations pages together. Verify store/platform configuration, entitlement and refund behavior, anti-cheat/provider posture, observability, content compatibility, rollback, and current operator evidence. ## Page-set organization - [Feature index](../features/README.md) — 16 focused topics grouped by orientation, combat, modes, roster/creator, online/live service, racing, and platform/launch. - [Architecture index](../architecture/README.md) — 16 focused topics grouped by deterministic core, presentation, world/vehicles, services, and platform engineering. - [V2 diagram atlas](./diagram-atlas.md) — the cross-system visual vocabulary for matches, identity, replay, modes, modules, production, and release. - [Backlog](../V2_TODOS.md) and [dependencies](../V2_DEPENDENCIES.md) — delivery order and external/shared requirements. - `balance/`, `docs/decisions/`, `docs/integration/`, and `docs/telemetry/` — intentionally atomic operational and decision records. ## Documentation quality contract A V2 documentation change is complete when the focused page remains substantial, its product and architecture boundaries agree, all focused pages remain indexed exactly once, complex relationships have an adjacent diagram, status language matches current evidence, links and source paths resolve, and the generated reader/search/diagram views render on desktop and mobile. Changes to behavior must update code, contracts, tests, backlog state, and release or operator evidence as applicable—not prose alone. The Docs Center HTML is generated. Edit Markdown, canonical code, schemas, or evidence; then regenerate and pass integrity, freshness, focused unit, and browser checks.