Foundations, Subsystem Glossary & Conventions

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 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.

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 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.

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, and its architecture counterpart ../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; 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:

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§"<anchor>" → V2_ARCHITECTURE.md by named section anchor.
• features§"<anchor>" → 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.
• The fighting spine as a player feature — defense, game feel, per-ruleset identity: ./combat-systems-defense-and-game-feel.md.
• The authoritative engine module map, dependency graph, and dedicated-server slice: ../architecture/glossary-and-module-topology.md.
• The feature catalogue this page indexes: ../V2_features.md.