# Foundations, Subsystem Glossary & Conventions ```mermaid mindmap root((V2 repository surfaces)) Unreal Combat modes racing and presentation Data assets and automation Services Identity online ranked and tournaments Store progression community support and AI Web Competitive public and operator surfaces Companion and creator experiences Authored data Roster moves balance modes and content Patch notes changelogs and validation Governance Contracts dependencies backlog and decisions Tests builds telemetry legal and release evidence ``` The map fixes vocabulary to repository ownership. Later pages can cross these surfaces, but every claim should still resolve to one canonical contract, runtime owner, and evidence path. This is the orientation page for the V2 feature set — the page to read before any of the deep feature pages, so that when a later page says "the HUD reads `V2Combat`'s `HitConfirmed` payload" or "the season pass lives in `apps/v2/season-pass-service`," the name already lands on something real you can open. V2 is a frame-deterministic competitive fighting game built on Unreal Engine 5.5, and its product scope is split across a small number of durable **surfaces**: one UE project, ninety-one TypeScript service packages, a balance authoring tree, two web homes, and a thin tools folder. Every feature this set documents ultimately resolves to code in one of those surfaces. The job of this page is to give you the map: the subsystem names and where they live in code, the repository surfaces and their target paths, and the cross-reference conventions the whole feature set uses. It is the **product-side companion** to the architecture glossary. Where the architecture page [../architecture/glossary-and-module-topology.md](../architecture/glossary-and-module-topology.md) reconciles the engine module graph against the compiler — load phases, the acyclic `Build.cs` dependency graph, the dedicated-server slice — this page reads the same disk from the player-feature angle: which named subsystem delivers which advertised capability, and where the glossary's name and the disk's reality diverge. The single source of truth for completion state remains the backlog; this page is the index, not the checklist. It is the foundations companion to the feature catalogue at [../V2_features.md](../V2_features.md). ## What ships, honestly **Real and on-disk.** The UE project at `V2/ue/` is substantial: **27 C++ modules** under `V2/ue/Source/`, each with a `*.Build.cs`, a `Public/`/`Private/` split, and a module class, and the `.uproject` `Modules` array lists the same 27 names with explicit loading phases. The fighting-game spine is deep, not skeletal — `V2Gameplay` carries ~218 source/header files, `V2UI` 172 (a wall of HUD and accessibility widgets), `V2Combat` 36, and `V2Tests` holds **407 `*.spec.cpp`** automation specs plus a suite of Gauntlet-style bot harnesses. Outside the engine, **91 service packages** under `apps/v2/` are real Nx libraries (every one has a `package.json` + `project.json` + `src/` + `vitest.config.ts`). The balance authoring tree at `V2/balance/` has **30 subdirectories** feeding DataTables; the web tile at `apps/oshun/web/src/app/v2/` and the standalone site at `apps/v2/web/` both exist; and the esports toolkit ships as `@v2/esports-tools` at `apps/v2/esports-tools/`. **Where the product glossary and the disk diverge** (found by reading both): - **The glossary names 16 engine subsystems; the disk has 27.** The Subsystem Glossary in [../V2_features.md](../V2_features.md) lists `V2Core` … `V2Tests` — sixteen rows. Eleven on-disk modules are _not_ in that table: the composition-root module `V2`, the C++→services bridge `V2Services`, the open-world/persistence aggregator `V2World`, the mod loader `V2Modding`, and the **seven-module racing cluster** (`V2Racing`, `V2Vehicles`, `V2RacePhysics`, `V2RaceTracks`, `V2RaceModes`, `V2VehicleAudio`, `V2VehicleVFX`). The product doc says so itself — it defers the full module list (engine + racing + plugins + surfaces) to the architecture monolith. Treat the 16-row table as the fighting-spine summary, and the architecture page as the authoritative 27. - **Three "subsystems" are thinner in code than the capability they name.** `V2Audio`, `V2VFX`, and `V2OnlineServices` are ~8–10-file in-engine _seam_ modules; the heavy capability they advertise is delivered by enabled engine plugins — MetaSounds/AudioModulation, Niagara, and `OnlineServices`/ `OnlineServicesEOS` respectively. `V2Audio.Build.cs`, for instance, links only `Core`, `CoreUObject`, `Engine`, and `GameplayTags` — it does **not** name MetaSound. The module is the gameplay-facing subsystem; the pipeline is the plugin. - **`V2Editor` on disk is not the glossary's editor toolbox.** The glossary describes "Move authoring widget, stage editor, frame-data inspector"; the real `V2Editor` Source module is `V2CreateRegionVariantsCommandlet` + `V2EditorSubsystem` + a blueprint library and types (10 files). The move-authoring/stage-editor/inspector widgets are aspirational at this name. (Separately, the `Plugins/V2Editor/` folder is an empty `Resources` shell — the editor module is the Source one.) - **`§` references point at the backlog, not at this page.** As the cross- reference convention below spells out, a bare `§N` resolves to `V2_TODOS.md`. Everything below is grounded in those files; where a claim is the glossary's intent rather than shipped code, it is labelled. ## The subsystem glossary, mapped to code The product glossary's sixteen rows describe the engine's fighting spine plus its presentation, persistence, online, and tooling seams. Here each name is resolved to the directory under `V2/ue/Source/` that implements it, with the load-bearing classes named and the honest caveats kept. | Glossary subsystem | On disk (`V2/ue/Source/`) | Anchor classes / files | Notes | | -------------------- | ------------------------------ | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | **V2Core** | `V2Core/` (16 files) | `V2CoreEngineSubsystem`, `V2CoreGameInstanceSubsystem`, `V2CoreGameplayTags`, `V2CoreSaveGame`, `V2CoreCheatManager` | Loads `PreDefault`; owns the native tag registry every later module queries | | **V2Gameplay** | `V2Gameplay/` (~218 files) | `UV2_GameplayAbility`, the `UV2_AttrSet_*` attribute sets, `V2GameplayEffects`, `FV2_MatchState` | The GAS spine; loads `PreDefault` alongside Core | | **V2Combat** | `V2Combat/` (36 files) | `UV2MoveFrameData`, `UV2_HitboxComponent`, `UV2CollisionAuthorityComponent`, `UV2CombatRulesetData` | Hitboxes, frame data, deterministic collision authority | | **V2Animation** | `V2Animation/` (10 files) | `V2AnimationBlueprintLibrary`, `V2AnimationNotifyStates`, `V2AnimationConfigAsset` | Binds the PoseSearch/Mover/IKRig plugins (referenced in config + types) | | **V2Input** | `V2Input/` (14 files) | `V2InputBuffer`, `V2MotionParser`, `V2InputReplayEncoder`, `V2InputConfigAsset` | Enhanced-Input parsing → integer-frame buffer → deterministic replay | | **V2Netcode** | `V2Netcode/` | `FV2SimWorld`, `V2RollbackSession`, `V2RollbackTransport`, `V2NetworkQuality` | Rollback for 1v1/2v2; client-server for larger modes | | **V2Modes** | `V2Modes/` (14 files) | `V2ModeRegistrySubsystem`, `V2ModeCatalog`, `V2ChampionshipData`, `V2ModeTypes` | Mode identity is registry-only; per-mode plugins are planned | | **V2UI** | `V2UI/` (172 files) | `V2ActivatableScreen`, `V2ColorblindSafePalette`, `V2ClosedCaptionAuthoringTool`, `V2CameraShakeIntensitySlider` | CommonUI front-end; the bulk of accessibility ships here | | **V2Audio** | `V2Audio/` (10 files) | `V2AudioSubsystem`, `V2AudioConfigAsset`, `V2AudioTypes` | **Thin seam** — MetaSounds/AudioModulation are engine plugins | | **V2VFX** | `V2VFX/` (10 files) | `V2VFXSubsystem`, `V2VFXConfigAsset`, `V2VFXTypes` | **Thin seam** — Niagara is the engine plugin | | **V2Cinematics** | `V2Cinematics/` (14 files) | `V2CinematicsSubsystem`, `V2EntranceData`, `V2FinisherData` | Sequencer-driven intros/finishers/replays | | **V2Persistence** | `V2Persistence/` (10 files) | `V2SaveGame`, `V2PersistenceSubsystem`, `V2PersistenceTypes` | `V2SaveGame` carries currency-ledger / offline-replay fields | | **V2OnlineServices** | `V2OnlineServices/` (8 files) | `V2OnlineServicesSubsystem`, `V2OnlineServicesTypes` | **Thin seam** — rides `OnlineServices`/`OnlineServicesEOS` plugins | | **V2Telemetry** | `V2Telemetry/` (8 files) | `V2TelemetrySubsystem`, `V2TelemetryTypes` | On-device emitter; the pipeline is the `telemetry-*` services | | **V2Editor** | `V2Editor/` (10 files) | `V2EditorSubsystem`, `V2CreateRegionVariantsCommandlet` | Region-variant commandlet, **not** the glossary's authoring widgets | | **V2Tests** | `V2Tests/` | 407 `*.spec.cpp`; `V2CombatBot`, `V2BotHarness`, `GoldenReplayCorpus` | Automation specs + Gauntlet bot harnesses + the golden-replay corpus | ### The fighting-game spine The six rows the rest of the feature set leans on hardest — `V2Core`, `V2Gameplay`, `V2Combat`, `V2Animation`, `V2Input`, `V2Netcode` — are the modules that turn an input into a hit. `V2Core` loads in the `PreDefault` phase because it owns `V2CoreGameplayTags`, the native tag table later modules query at startup; `V2Gameplay` is hoisted alongside it as the GAS spine carrying the `UV2_AttrSet_*` attribute sets and the `FV2_MatchState` state machine. `V2Combat` turns the per-move `UV2MoveFrameData` asset into real collisions through `UV2_HitboxComponent` and the rollback-snapshotting `UV2CollisionAuthorityComponent`, and `V2Netcode`'s side-effect-free `FV2SimWorld` re-simulates them deterministically. `V2Input` is the front door — `V2MotionParser` and `V2InputBuffer` translate Enhanced Input into the integer- frame queue, and `V2InputReplayEncoder` is the "deterministic replay" the glossary names. The full treatment of this spine is the combat feature page, [./combat-systems-defense-and-game-feel.md](./combat-systems-defense-and-game-feel.md), and its architecture counterpart [../architecture/combat-system-gas-frame-data-and-determinism.md](../architecture/combat-system-gas-frame-data-and-determinism.md). ### Presentation, persistence, and the thin seams `V2Modes`, `V2UI`, and `V2Cinematics` are where the spine becomes a product. `V2Modes` is leaner than its glossary line implies — `V2ModeRegistrySubsystem` + `V2ModeCatalog` register mode identity, but the per-mode `V2Mode_*` GameFeature plugins the architecture page describes do not exist yet, and the "mode-specific HUD" actually lives in `V2UI`. `V2UI` is the second-largest module on disk (172 files) and carries the accessibility surface wholesale — `V2ColorblindSafePalette`, `V2ClosedCaptionAuthoringTool`, `V2CameraShakeIntensitySlider` are real widgets, not stubs. The three thin seams — `V2Audio`, `V2VFX`, `V2OnlineServices` — are the honest caveat to keep in mind: they are ~8–10-file in-engine subsystems that bind capability provided by the engine plugin set (`V2Audio.Build.cs` links no MetaSound module at all), so "the MetaSounds pipeline" is a plugin the subsystem drives, not C++ the subsystem owns. `V2Persistence` (`V2SaveGame`, with currency-ledger and offline-replay fields) and `V2Telemetry` (an on-device emitter whose pipeline is the `telemetry-*` services) are the seams between the client and the backend. ### What the glossary omits The eleven on-disk modules the 16-row product glossary does not name are not optional: `V2Services` is the bridge that lets any of them talk to the backend, `V2World` is the aggregator that depends on online/persistence/telemetry, and the seven racing modules are a full satellite stack documented in the racing feature page. The composition-root module `V2` (six files: `AV2CombatCharacter`, `AV2GameMode`) is the one the `Game`/`Server` targets actually name. All eleven are catalogued, with their dependency edges, in [../architecture/glossary-and-module-topology.md](../architecture/glossary-and-module-topology.md); this feature set treats that page as the authoritative module map. ## Repository surfaces The feature catalogue's Repository Surfaces table maps each surface to a target path. Those paths are real today except where marked **planned**: | Surface | Target path | State | | ---------------------------- | ------------------------------------------- | ---------------------------------------------------- | | Game client | `V2/ue/` | Real — 27 modules, 3 targets, 4 project plugins | | Marketing / shell tile | `apps/oshun/web/src/app/v2/` | Real — `page.tsx` + `glossary/`, `roadmap/`, `wiki/` | | Standalone web surfaces | `apps/v2/web/` | Real — Vite SPA, sub-sites below | | Esports / tournament toolkit | `apps/v2/esports-tools/` | Real — package `@v2/esports-tools` | | Online services backend | `apps/v2/` | Real — 91 Nx packages | | Balance authoring | `V2/balance/` | Real — 30 subdirectories | | Build & release tooling | `V2/ue/Build/`, `V2/tools/release/` | **Planned — `tools/release/` not created** | | Localization workspace | `V2/ue/Content/Localization/V2/`, `V2/loc/` | **Planned — not created** | **The game client (`V2/ue/`).** Beyond the 27 modules it carries three build targets (`V2.Target.cs`, `V2Server.Target.cs`, `V2Editor.Target.cs`) and four project plugins — `V2AdaptiveAI` and `V2AICommentary` (runtime), `V2AssetLinter` (editor), and the synced `BellonaUnrealEditor`, each with a real `.uplugin`. The C++→TypeScript boundary is the `V2Services` module: `UV2OshunDomainAdapterLibrary::BuildRequiredAdapters()` / `ValidateRequiredAdapters()` declare which backend domains the client requires, `V2GrpcChannelManager` opens the channels, and `Generated/V2GeneratedGrpcStubs.h` is regenerated from `.proto` on every build. **The service backbone (`apps/v2/`, 91 packages).** These cluster into the families later feature pages describe: a large **telemetry** group (12 packages — `telemetry-ingestion`, `-data-pipeline`, `-schema-migrations`, `-privacy-compliance`, `-session-reconstruction`, …); **live-ops & store** (`season-pass-service`, `dlc-content-delivery-service`, `limited-time-game-mode-service`, `hotfix-delivery-service`, `economy-*`); **competitive integrity & governance** (`nous-anti-cheat-classifiers`, the four `themis-*` governance/dispute/originality/DSR services); and the **deity-named sister-monorepo adapters** that bridge V2 to the rest of Oshun — `oshun-adapter`, `oshun-identity-binding`, the four `aja-*` mocap/consent services, the three `aphrodite-*` age-gate/consent/likeness services, plus `psyche-*`, `iris-*`, `isis-*`, `maat-*`, and `kuanyin-*` clusters. Depth varies by purpose, but each is a buildable package, not a placeholder folder. **Balance authoring (`V2/balance/`).** Thirty subdirectories — `fighters/`, `racing/`, `stages/`, `feel/`, `progression/`, `modes/`, `pricing/`, `vault/`, and more — supply the tunable data the engine cooks into DataTables. The most load-bearing is `feel/`, whose `hitstop_curves.csv`, `camera_shake_curves.csv`, `slowmo_freeze_curves.csv`, and `photo_mode_tone_curves.csv` are the exact paths the combat game-feel catalog validates against. **Web, esports, and the thin tools folder.** Two web homes exist and neither replaces the other: `apps/oshun/web/src/app/v2/` is the in-shell product tile (`page.tsx` + `glossary/`/`roadmap/`/`wiki/` subroutes), while `apps/v2/web/` is the standalone Vite SPA with `calendar/`, `community/`, `support/`, `esports/`, `dev-portal/`, `hub/`, `legal/`, `live-service/`, and `balance/` sub-sites. The `V2/tools/` folder otherwise holds only the `@v2/esports-tools` package and a `validate-v2-docs.py` linter — its broader "build, release, mocap, data tooling" billing is aspirational, and `V2/tools/release/` does not exist. ## Cross-reference conventions The whole feature set, like the backlog, uses a single citation grammar so a reference is never ambiguous about which document it points into: - **Bare `§N` / `§N.M` → `V2_TODOS.md`.** The backlog is the only V2 document with section numbering used as hyperlinks (138 numbered top-level sections, ~1,000 numbered subsections), so an unqualified `§52.8` means `V2_TODOS.md` §52.8. - **`deps§N` → `V2_DEPENDENCIES.md`** (e.g. `deps§57` → Hardware Peripheral SDKs). - **`arch§""` → `V2_ARCHITECTURE.md`** by named section anchor. - **`features§""` → this document set** by named anchor. `V2_features.md` and `V2_ARCHITECTURE.md` (and these split pages) use **named anchors, not numbers**, precisely so they never duplicate or drift from the backlog's numbering scheme. When a page cites a feature by name, follow the anchor; when it cites a `§`, open the backlog. ## Where to go next - The promise these foundations serve, and the player-facing surfaces in depth: [./product-promise-and-surfaces.md](./product-promise-and-surfaces.md). - The fighting spine as a player feature — defense, game feel, per-ruleset identity: [./combat-systems-defense-and-game-feel.md](./combat-systems-defense-and-game-feel.md). - The authoritative engine module map, dependency graph, and dedicated-server slice: [../architecture/glossary-and-module-topology.md](../architecture/glossary-and-module-topology.md). - The feature catalogue this page indexes: [../V2_features.md](../V2_features.md).