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#
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 and focused feature index | Product scope, surfaces, modes, user-visible behavior, and explicit spec-only seams. |
| How does combat remain deterministic? | Architecture hub, combat core, and rollback | Frame authority, data ownership, rollback/resimulation, tag simulation, and validation boundaries. |
| How do online, ranked, tournament, and esports paths compose? | Online feature guide, online backbone, and esports services | Player contract plus service topology, competitive-integrity controls, and broadcast/companion boundaries. |
| Is racing a mini-game or a peer system? | Racing features and vehicle architecture | Vehicle data, physics, tracks, online racing, crossover modes, and shared platform seams. |
| What is implemented now? | V2 backlog, product review, current tests/builds, and dated verification records | The most conservative evidence-backed completion state. |
| Which external or shared systems are required? | Dependency registry | Ownership, version, integration, and fallback expectations. |
| How should an implementation task be executed? | Agent execution and the affected focused feature/architecture pages | Change order, evidence expectations, and nearby contracts. |
| Where are the visual models? | V2 diagram atlas and the generated Docs Center diagram gallery | Curated product/runtime mental models and every authored diagram by source heading. |
Truth and release model#
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#
Product, design, and balance#
Begin with the focused feature index, 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. 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 — 16 focused topics grouped by orientation, combat, modes, roster/creator, online/live service, racing, and platform/launch.
- Architecture index — 16 focused topics grouped by deterministic core, presentation, world/vehicles, services, and platform engineering.
- V2 diagram atlas — the cross-system visual vocabulary for matches, identity, replay, modes, modules, production, and release.
- Backlog and dependencies — delivery order and external/shared requirements.
balance/,docs/decisions/,docs/integration/, anddocs/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.