# Roster, Character Presentation & Stages

```mermaid
erDiagram
  FIGHTER ||--o{ FIGHTER_VERSION : versions
  FIGHTER_VERSION ||--o{ MOVESET_BINDING : equips
  FIGHTER_VERSION ||--o{ PRESENTATION_CUE : presents
  FIGHTER }o--o{ RELATIONSHIP : participates
  RELATIONSHIP ||--o{ BANTER_CUE : conditions
  STAGE ||--o{ STAGE_VERSION : versions
  STAGE_VERSION ||--o{ HAZARD_DEFINITION : contains
  STAGE_VERSION ||--o{ PRESENTATION_CUE : contains
  MATCH_CONFIG ||--|{ FIGHTER_VERSION : pins
  MATCH_CONFIG ||--|| STAGE_VERSION : selects
```

The validated roster and presentation catalogues pin versions into a match; they
do not prove the corresponding art, animation, voice, stage geometry, or
platform cook until those assets and build evidence exist.

A fighting game is its cast. Everything the combat core proves about determinism
and the rulesets layer proves about per-family feel only matters if there are
sixty distinct people to apply it to, each with their own walk-in, their own
trash-talk, their own home stage and their own reason to hate the fighter across
the screen. This page covers the three features that turn V2's one engine into a
populated universe: the **launch roster and its content inventory**, the
**character-presentation layer** (intros, matchup banter, win/loss quotes, and
the per-fighter signature library), and the **stages** they fight on. The honest
through-line — stated up front so nothing below misleads — is that this layer is
_logic-and-data shipped, art-and-VO pending_: the catalogs, validators, and
on-disk data that describe sixty fighters are real and tested; the animations,
recorded voice lines, and authored stage geometry they point at are the work
that remains. This is the feature-side companion to the "Roster, Story & Creator
Suite" group; the section hub is [../V2_features.md](../V2_features.md).

## What ships, honestly

Each piece below sits at a different point on the implemented-versus-spec
spectrum, and this page labels each where it actually is.

- **The launch roster is a real, validated C++ catalog.** Sixty fighters —
  forty-two original, eighteen partner-IP — are enumerated in
  `UV2LaunchRosterLibrary::BuildDefaultLaunchRosterCatalog()`
  (`V2/ue/Source/V2Combat/Private/V2LaunchRosterData.cpp:559`), with a strict
  validator that enforces the count, archetype diversity, and a **fail-closed
  rights-clearance gate** on every licensed character.
- **Character presentation is a validated catalog over a representative slice.**
  The `FV2CharacterPresentationCatalog` resolution logic is real and
  spec-tested, but the _default_ catalog populates **eight** fighters and a full
  8×8 banter matrix, not all sixty — a vertical slice that matches the eight
  authored dialogue CSVs. Quote counts, bark triggers, entrance styles, and
  mirror dialogue are all checked spec.
- **The signature library is sixty per-fighter checklists behind an honest
  attestation.** A checked box attests that the catalog _requirement_ is defined
  and validated, explicitly **not** that any asset is authored.
- **Stages are data plus a contract, no authored geometry.** A 60-row signature-
  stage registry and a Section-81 contract JSON describe lore, day/night, crowd,
  particles and destruction; the stage _logic_ (ring-out, destruction, weather,
  crowd) lives in `V2Combat` / `V2VFX` / `V2Audio`, but there are **zero**
  authored stage `.uasset` binaries.
- **The narrative data is real CSV.** Rivals, the relationship matrix, factions,
  the timeline, and the codex all ship as populated, cross-linked data files.

The whole-repo reality check: `V2/ue/Content/` carries exactly **eight**
gameplay `.uasset` (the `DA_RegionVariant_*` region data), and the rest of this
layer is Unreal C++ catalogs plus `V2/balance/**` data and `*_Contract.json`
manifests. The deterministic internals this layer hangs off are documented in
[../architecture/combat-system-gas-frame-data-and-determinism.md](../architecture/combat-system-gas-frame-data-and-determinism.md);
the audio/VFX/cinematic pipelines that render it are in
[../architecture/presentation-av-and-signature-content.md](../architecture/presentation-av-and-signature-content.md).

## The launch roster: a validated 60-fighter catalog

### The data model

A roster fighter is `FV2LaunchRosterFighterEntry`
(`V2/ue/Source/V2Combat/Public/V2LaunchRosterData.h:58`): a `FighterId`, a
display name, an **origin** (`EV2LaunchRosterFighterOrigin` — `Original` or
`PartnerIP`), an **archetype** (`EV2LaunchRosterArchetype`, a twelve-value enum:
`Striker, Grappler, Zoner, Rushdown, Powerhouse, Technical, WeaponMaster, SubmissionSpecialist, Aerial, CounterFighter, StanceSwitcher, Hybrid`),
a soft path to a `DA_Fighter_` data asset, a default moveset and its
`FV2LaunchRosterMovesetCoverage` (special/super/finisher move-id arrays), and
two rights fields: `bRightsClearedForLaunch` and `PartnerIPLicenseId`. The
rights flag is deliberately **fail-closed** — the header comment is explicit
that it "may only be set true once the entry is either original IP … or covered
by an executed third-party license for launch," and `MakeLaunchRosterFighter`
sets it to `Origin == Original` and stamps the license id only when one is
passed (`V2LaunchRosterData.cpp:136`).

### Sixty fighters the validator will not let you fake

`BuildDefaultLaunchRosterCatalog()` constructs the canonical roster: **42
original** fighters (Asha Storm the striker, Mara Voss the grappler, Cassia Vale
the zoner, on through Lyra Saint) and **18 partner-IP** fighters drawn from four
license families — Capcom (Ryu, Ken, Chun-Li, Cammy), SNK (Terry, Mai, Kyo,
Iori), WB/NetherRealm (Scorpion, Sub-Zero, Raiden, Liu Kang, Kitana), and Bandai
Namco (Jin, Kazuya, King, Nina, Mitsurugi). Crucially, the count is not
decorative — `FV2LaunchRosterCatalog::IsValidCatalog`
(`V2LaunchRosterData.cpp:241`) rejects any catalog that:

- carries fewer than **60 fighters** or sets `MinimumFighterCount < 60`;
- carries fewer than **12 partner-IP** fighters, or zero original fighters;
- fails `HasRequiredArchetypeDiversity()` — which demands all twelve archetype
  families be present with **at least three fighters each**
  (`V2LaunchRosterData.cpp:332`);
- contains a partner-IP entry without both `bRightsClearedForLaunch` _and_ a
  `PartnerIPLicenseId` (`:231`);
- has duplicate fighter IDs or duplicate default moveset IDs, or any entry whose
  data-asset path is not a `DA_Fighter_`, whose style tag is missing, or whose
  default moveset id does not match its coverage struct.

That validator is what makes the "≥ 60 fighters, archetype diversity, licensed
individually" promise from the source a checked invariant rather than a
marketing line. The `Combat.Module` automation spec drives the builder and the
validator directly, so a regression that dropped the roster below sixty, lost an
archetype, or shipped an uncleared licensed character would fail CI.

### Per-fighter content and the inventory targets

Each roster entry's `FV2LaunchRosterMovesetCoverage` carries the special/super/
finisher move-id arrays and a `bFinishersApplicable` flag (false for rulesets
without finishers), validated by `IsValidCoverage`. The broader content-
inventory numbers from the source — **≥ 4 specials, ≥ 2 supers, ≥ 2 finishers, ≥
4 alt costumes, ≥ 3 taunts** per fighter; a **≥ 200-move** universal CAW/CAM
pool with style-locked sub-pools (Wrestling ≥ 80, Martial Arts ≥ 80, …); a **≥
500-item** wardrobe library — are authoring _targets_, not all enumerated in
this catalog. Where they are enforced today is the per-fighter signature library
and the Creator Suite move pools (the latter covered in the Creator Suite page);
where they are not yet, the numbers describe the content budget the cook must
hit, not data that exists. This page does not present those counts as shipped.

## Character presentation: intros, banter, win quotes

V2 targets the Injustice / MK11 standard of presentation depth, and the
data-contract for it is `FV2CharacterPresentationCatalog`
(`V2/ue/Source/V2Cinematics/Public/V2CinematicsTypes.h:7090`), registered on the
cinematics subsystem via `RegisterCharacterPresentationCatalog`. It is exercised
by `CharacterPresentation.spec.cpp` — one of **37** dedicated cinematics spec
suites under `V2/ue/Source/V2Tests/Private/Cinematics/`.

### The presentation vocabulary

The catalog's enums map one-to-one onto the source's feature list. Bark triggers
(`EV2CharacterPresentationBarkTrigger`) are the eight gameplay events
`CounterHitLanded, ThrowLanded, ParryLanded, LowHP, ComboN, FinisherArmed, FinisherMissed, KO`
— the _same_ events the audio bark router consumes, so the presentation layer
and the foley layer fire off one shared signal. Entrance styles
(`EV2CharacterPresentationEntranceStyle`) are the five family walk-ins
`WWEWalkout, TekkenStageArrival, MKPitSummon, SFHubArrival, DefJamClubStrut`;
post-fight cutscenes (`EV2CharacterPresentationPostFightCutscene`) are
`VictoryPose, UFCPresser, UFCMicInterview, WWEMicMoment`; lore unlocks
(`EV2CharacterPresentationUnlockSource`) are
`MatchPlay, CombatTrialCompletion, MissionCompletion, TowerClear`; and Arcade
endings carry one of **nine** distinct art styles
(`OilPainting, ComicBookPanel, AnimeCelShade, GothicWoodcut, HipHopGraffiti, PhotorealPortrait, UkiyoE, ArtNouveau, MangaInkWash`),
with the catalog's `HasDistinctEndingArtStyles()` asserting the slice actually
varies them rather than stamping every fighter the same.

### Quote banks and matchup banter

The quote bank (`FV2CharacterPresentationQuoteBankSpec`,
`V2CinematicsTypes.h:6832`) defaults to **30 win quotes and 15 loss quotes** per
fighter, plus draw and double-KO quotes, plus a per-matchup win quote, and a
fan-out of context selectors: by opponent, by ruleset, and by finisher /
perfect-round / comeback / timeout / ring-out, and by pinfall / submission / KO
/ double-KO. Matchup banter is its own struct
(`FV2CharacterPresentationMatchupBanterSpec`): fighter A and B each trade two
authored lines, `bAuthoredPerOpponent` is set, and mirror matches carry the
`bMirrorSpecific` flag so a fighter facing themselves gets uniquely-authored
mirror dialogue rather than the cross-matchup pool. The spec asserts the slice
exactly: the default catalog has **8 fighters** and **64 matchup-banter
entries** (the full 8×8 matrix including the eight mirrors), Asha's quote bank
is exactly 30/15, her bark triggers cover the gameplay events, and her entrance
carries WWE arena, DJ club and MK pit intro variants. The runtime snapshot
exposes
`bCharacterPresentationRosterReady / …MatchupsReady / …LoreReady / …EntrancesReady`
so a cert pass can check coverage per area.

The honest scope note: this is a validated **eight-fighter vertical slice**, not
sixty. `HasRequiredRosterCoverage()` is satisfied at eight, and the eight match
the eight authored dialogue files below. The catalog _shape_ scales to the full
roster; the authored _content_ is a representative slice today.

### The dialogue database on disk

Behind the catalog sits real, per-fighter CSV under `V2/balance/dialogue/` —
eight files (`asha_storm`, `bishop_crowe`, `kai_voltage`, `lian_noor`,
`mina_kade`, `nyx_river`, `rook_vale`, `sol_vega`) with the columns
`situation, opponent, ruleset, line_id, english_text, locale_x_text, vo_file_path, emotion, length_cap`.
The situations span `prefight` (per-opponent, e.g. Asha vs. Kai under the Street
Fighter ruleset), `mirror` (a dedicated bank — `Line.AshaStorm.Mirror.001`,
never the cross-matchup pool), `final_round`, `comeback_round`, `win`, `loss`,
and `audio_diary`; each line carries an English string, an emotion tag, and a
`length_cap`. Alongside the CSVs are an `importers/` folder (Ink and Yarn
dialogue sources), a `barks/` folder (a `.v2barks.json` priority/cooldown bank),
and a `localization/` folder. The honest caveat, the same one the architecture
companion makes: every `locale_x_text` cell reads `TODO` and every
`vo_file_path` points at a `/Game/V2/Audio/Voice/…` asset that does not exist
yet — the **text and routing ship; the localized, recorded VO does not**. (The
dialogue tokens — `AshaStorm`, `KaiVoltage` — also use full-name forms distinct
from the roster's short `Fighter.Asha` ids, reflecting that this DB was authored
as an early sample bank.)

### The per-fighter signature library

What makes a fighter feel _theirs_ is a contract spanning animation, audio, VFX,
stage and HUD, modeled as `FV2FighterSignatureLibraryCatalog`
(`V2LaunchRosterData.h:357`) and built one entry per roster fighter by
`BuildDefaultFighterSignatureLibraryCatalog()` — so all **sixty** fighters are
covered, and the validator rejects any catalog that misses one. Each entry nests
five real sub-libraries with domain-specific minimums: animation (a unique 8–12
s signature idle, ≥ 3 taunts, 3 victory poses, a non-generic KO defeat,
slip/dodge/air-recover/pursue variations), audio (8 unique impact stings, 3
dynamic theme variants, stamina-driven breath, per-costume micro-foley), VFX
(low-HP comeback aura, weapon glow/trail, finisher VFX kit, X-Ray bone pattern,
blood spatter), stage reactions (cinematic close-up shader, throw-receiver and
hit-by-specific-move recoils), and HUD theme (faction palette, mastery-unlock
levels). Each also carries an authoring checklist at
`V2/balance/fighters/<Fighter>/signature-checklist.md` (sixty of them). Those
checklists are scrupulously honest: their legend states a checked item "attests
that the launch-roster signature catalog … defines and validates the requirement
— it does **not** attest that any game asset has been authored," and every
file's "Asset authoring (pending — no assets exist in this repository)" section
stays unchecked "until real assets land and pass the QA cert signature-library
audit." This is the single clearest statement of where this whole layer sits.

## Stages: signature homes, lore, atmosphere and crowd

### The per-fighter signature stage registry

Every fighter has a canonical home stage, mapped in
`V2/balance/stages/per-fighter-signature-stages.csv` — 60 rows of
`fighter_id, signature_stage_id, lore_page_id` spanning all the families
(`Fighter.Asha` → `Stage.MK.PitNetherrealm`, `Fighter.Mara` →
`Stage.WWE.RawArena`, `Fighter.Cassia` → `Stage.SF.MetroCity`, `Fighter.Juno` →
`Stage.DJ.NYCClub`). The contract that consumes it,
`V2/ue/Content/V2/Stages/StageLoreAtmosphereCrowd_V2_Contract.json` (Section
81), pins `requiredRosterCoverage: 60`, a `Preview.<fighter>.<stage>`
character-select preview pattern, and
`climaxAutoSelectModes: [Story, Arcade, SideStory]` — so a Story or Side-Story
climax auto-selects the relevant fighter's signature stage.

### Lore, day/night, atmosphere and crowd

The same contract enumerates the stage-presentation surface the source
describes: a per-stage lore schema
(`history, faction, ambient-creatures, cinematic-camera-presets, easter-eggs`);
a five-step day/night cycle (`Dawn, Day, Dusk, Night, Midnight`) that combines
with weather and survives multi-floor transitions; eleven atmospheric particle
profiles
(`SnowFlurry, DustMote, AshDrift, Ember, FogWisp, Mist, Pollen, Fireflies, FallingPetals, FlyingPaper, DriftingSmoke`);
and per-ruleset **crowd density profiles** that match the design intent exactly
— WWE at 10,000 instanced crowd actors, UFC at 2,000 octagon-side, Def Jam at
300 with individual actor reactions, Mortal Kombat "none-or-monster-crowd,"
Street Fighter avatar-driven Battle Hub, Soul Calibur medieval. Individual
reactions (`throw-the-rock, stand-up-applause, phone-up-record`), a stage-out
gasp/cheer reaction, a destruction lifecycle with persistent elements
(`BrokenPanes, ScorchedWalls, TornRopes`) and per-ruleset reset rules, a hazard
library that tournament mode disables, and per-stage commentary intro lines
round it out. The contract is CI-checked by
`V2/ue/Tools/check-v2-stage-lore-atmosphere-crowd.py`.

### Where the stage logic actually lives

No stage geometry is authored — there is no `Content/Stages/*.uasset`. What is
real is the _logic_ stages need, and it lives in the combat and presentation
modules rather than here: the **ring-out** condition is a combat-ruleset layer
(`RingOut`, active for Soul Calibur and Def Jam — see
[./rulesets-tag-and-kameo.md](./rulesets-tag-and-kameo.md)), stage
**destruction, weather and atmospheric particles** are `V2VFX` resolve/queue
pairs (`EV2StageDestructionResetRule`, `EV2StageWeatherKind`), and per-stage
**crowd noise and chants** are a `V2Audio` catalog — all detailed in
[../architecture/presentation-av-and-signature-content.md](../architecture/presentation-av-and-signature-content.md).
So a stage today is a data contract plus the runtime systems that will dress it,
awaiting the authored environment art.

## Lore, relationships and the codex

The narrative scaffolding the roster hangs in is populated CSV under
`V2/balance/lore/` and `V2/balance/codex/`. `rivals.csv` gives every one of the
60 fighters a reciprocal `primary_rival` plus a pipe-list of secondary rivals
(`Fighter.Asha` ↔ `Fighter.Mara`, secondaries `Cassia | Scorpion`).
`relationship-matrix.csv` types 78 directed pairs across the full vocabulary —
`Ally, Friend, Rival, Enemy, Mentor, Student, Mentor-Betrayed, Family, Romantic, Cordial, Indifferent`
— each with a `drives` list, an `asymmetric` flag, and a `canon_scope`.
`faction-relationships.csv` carries faction-to-faction status (Lin Kuei vs.
Black Dragon `At-War`, Special Forces vs. Brotherhood `Enemy`) with the modes
each feud drives; `timeline.csv` and `timeline.md` lay down the master
cross-character timeline; and `convergent-endings.md` defines the post-credits
cinematics that unlock only when an Arcade ending, a Story branch, and a Side
Story set all resolve on the same profile. The codex is `codex-categories.csv`
plus a 60-row `codex-fighter-entries.csv` (each a 255–260-word entry with
optional art, an audio diary, an unlock condition, and a replay/cinematic link).
The progression tracks that gate these unlocks (per-fighter mastery, account
level and prestige, the unified quest log) live as their own CSV set and are
covered alongside the Creator Suite in
[./relationships-progression-and-creator-suite.md](./relationships-progression-and-creator-suite.md).

## How it connects

The roster catalog is the cast every other system parameterizes over: the
ruleset layer re-skins each fighter per family
([./rulesets-tag-and-kameo.md](./rulesets-tag-and-kameo.md)), the combat core
gives them frame data and supers
([../architecture/combat-system-gas-frame-data-and-determinism.md](../architecture/combat-system-gas-frame-data-and-determinism.md)),
and the presentation pipelines dress them in audio, VFX and cinematics
([../architecture/presentation-av-and-signature-content.md](../architecture/presentation-av-and-signature-content.md)).
The bark triggers this page lists are the same gameplay events the audio router
consumes; the entrance and finisher data assets are authored in the cinematics
module; the lore and progression data feed the relationships, codex and Creator
Suite features. The consistent honest line across all of it: the contracts,
validators and data are real and tested; the authored art, audio and VO they
describe are the production work that remains. The section hub is
[../V2_features.md](../V2_features.md).

## Related

- [Rulesets, Tag-Team & Kameo Assists](./rulesets-tag-and-kameo.md) — the
  per-ruleset HUD overlay, ring-out rules, and team theme music that dress the
  roster per family
- [Combat Systems, Defense & Game Feel](./combat-systems-defense-and-game-feel.md)
  — the moves, supers, and finishers each roster fighter carries
- [Relationships, Progression & Creator Suite](./relationships-progression-and-creator-suite.md)
  — the rival/relationship-driven narrative, mastery/account progression, codex,
  and the create-a-fighter authoring surface (forthcoming sibling page)
- [Audio, VFX, Cinematic & Signature Content Pipelines](../architecture/presentation-av-and-signature-content.md)
  — the C++ subsystems that resolve and render intros, banter, entrances,
  finishers, and stage atmosphere
- [Combat System: GAS, Frame Data & Determinism](../architecture/combat-system-gas-frame-data-and-determinism.md)
  — the deterministic match state the presentation layer reacts to but never
  perturbs
- The section hub: [../V2_features.md](../V2_features.md)