V4 Documentation Guide — Tactical Action

This guide is the curated front door to V4, the Unreal Engine 5 tactical-action universe that hosts five strongly differentiated ruleset cells on one governed engine: tactical FPS, stealth/real-time tactics, action RPG, RTS, and 2D run-and-gun. It joins the player-facing promise to cell/plugin ownership, shared gameplay systems, online authority, production, safety, and release evidence without implying that a designed cell or plugin is already shipped.

Documentation map#

mindmap root((V4 documentation)) Ruleset cells Tactical FPS Stealth and real-time tactics Action RPG RTS 2D run-and-gun Shared experience GAS animation and input AI perception and world simulation Modes replay and creator tools Online progression and live service Platform Cell plugins and shared modules Data build and content pipelines Telemetry performance and security Accessibility compliance and launch Delivery truth V4 backlog and dependencies Product review and remediation Verification and release evidence Decision and compliance records

V4's defining documentation problem is boundary clarity. A shared engine must provide common contracts and operations without flattening the feel, simulation, input, AI, camera, or content rules that make each cell distinct. The feature set explains those player contracts; architecture explains which shared and cell-owned modules preserve them.

Start with the question#

Question	Canonical starting point	What it covers
What is the multi-cell product promise?	Feature hub, feature index, and product promise	The five cells, shared experience, surfaces, and honest implementation posture.
Which cell owns a behavior?	The matching cell feature page and per-cell architecture	Cell-specific rules, shared contracts, plugin boundaries, and runtime specialization.
What belongs to the shared engine?	Shared cross-cell engine, high-level architecture, and GAS layout	Reusable gameplay, presentation, data, online, and platform foundations.
How do online and deterministic paths differ by cell?	Online features and networking architecture	Authority, rollback/replication expectations, integrity, persistence, and esports boundaries.
How do assets and worlds reach a release?	Build/data/content, world streaming, and platform operations	Authored data, cook, streaming, procgen, budgets, hardware, and platform gates.
What is actually complete?	V4 backlog, product review, verification, current code/tests/builds, and release evidence	Conservative implementation and release status.
Which dependencies and decisions govern a change?	Dependency registry and `docs/decisions/`	Shared/platform ownership and accepted architecture decisions.
Where are the visuals?	V4 diagram atlas and the global diagram gallery	Cell, runtime, data, state, production, and release models.

Truth model#

stateDiagram-v2 [*] --> Proposed Proposed --> CellDesigned: cell promise and specialization are explicit CellDesigned --> PluginImplemented: cell or shared module exists PluginImplemented --> Integrated: host shared systems and content compose Integrated --> Verified: authority gameplay and quality evidence passes Verified --> ReleaseReady: build platform operations and rollback pass PluginImplemented --> Scaffolded: shell exists but production behavior does not Integrated --> CellLimited: capability is valid only in named cells Verified --> Regressed: newer evidence contradicts support Regressed --> PluginImplemented: repair returns below release readiness

Always name the cell and authority model. A shared GAS ability does not prove identical combat behavior; a plugin descriptor does not prove playable content; a map or bot fixture does not prove the campaign, online, creator, or live-ops journey; and one cell's performance evidence cannot certify the others.

Recommended reading journey#

journey title From V4 cell idea to supported capability section Orient Choose the owning cell and player promise: 5: Product, Design Identify shared versus specialized modules: 5: Architecture section Build Evolve data plugin gameplay and presentation contracts: 4: Engineering Preserve authority determinism and content compatibility: 5: Engineering section Verify Test the target cell and cross-cell regressions: 5: QA Validate accessibility performance security and cook: 5: QA, Release section Release Prove platform operations and rollback: 5: Release, SRE Update docs diagrams decisions and evidence: 5: Owners

Product, design, and cell owners#

Start in the feature index. Read the chosen cell plus the shared-engine, mode, online, content, trust, and platform pages it composes. Write cell-specific acceptance criteria rather than assuming a shared mechanic has the same tuning, camera, input, AI, or presentation everywhere.

Engineering and technical content#

Start in the architecture index. Trace the host, plugin activation, modules, data assets, GAS/animation/input, AI/world, networking/persistence, presentation, telemetry, build/cook, and tests. Confirm that shared code exposes contracts and extension points rather than importing a cell's private implementation.

QA, accessibility, compliance, and release#

Exercise each affected cell plus cross-cell activation/deactivation, save and version compatibility, online authority, disconnect/rejoin, long/empty content, assistive controls, sensory alternatives, platform restrictions, creator content denial, and rollback. Compliance and decision records are focused evidence; current runtime and release gates remain authoritative.

Page-set organization#

Feature index — 16 focused topics covering all five cells, shared engine, modes/content, online/live service, platform/trust, and launch.
Architecture index — 16 focused topics covering cell hosting, gameplay foundations, AI/world, networking/persistence, presentation, build/data, quality, and launch.
V4 diagram atlas — cell boundaries, action flow, persistence, plugin composition, production, and release.
Backlog, dependencies, product review, remediation, decisions, compliance, and release records — delivery and evidence layers.

Documentation quality contract#

Every canonical feature and architecture topic remains substantial, indexed exactly once, explicit about cell/shared ownership and implementation state, and accompanied by an appropriate diagram. Changes update the affected product and architecture pages, source contracts, tests, backlog/evidence, and any decision or runbook. Generated links, search, diagram gallery, freshness, integrity, and desktop/mobile rendering must remain green.