# Signature Events & Standalone Modes

```mermaid
flowchart LR
  Catalog[Versioned event or standalone-mode definition] --> Eligibility[Schedule entitlement platform and cohort]
  Eligibility --> LoadPlan[Ruleset roster content and service load plan]
  LoadPlan --> Session[Deterministic event or adventure session]
  Session --> Checkpoint[Run checkpoint replay and result evidence]
  Checkpoint --> Reward[Idempotent progression and event rewards]
  Checkpoint --> Recover[Resume abandon or rollback policy]
  Reward --> Archive[Public result season and support record]
```

Signature scheduling and standalone runtime logic meet at a validated load plan.
Limited-time presentation never weakens compatibility, replay, checkpoint,
reward, accessibility, or recovery contracts.

Most of V2's mode catalogue is evergreen — Arcade, Story, the careers, the
towers run from launch day to sunset. This page covers the two clusters that sit
at the _edges_ of that catalogue: the **signature events** that V2 wheels onto
the calendar to dramatize each franchise's marquee occasion (a 24-hour charity
Marathon, a 50-fight Endurance Tower, the King of Iron Fist ladder, a
WrestleMania-style PPV, an EVO Top 8), and the **standalone modes** built as
self-contained experiences rather than wrappers around a standard fight — the
flagship of which is a Hades-style **roguelike adventure mode** with permadeath,
procedurally-generated dungeon runs, boons, and meta-progression. The two
clusters share a backbone: both are authored as **validated data catalogues in
the `V2Modes` module**, exposed through `BlueprintPure` factory functions, and
pinned by contract automation specs. Where one of them owns genuine runtime
logic — and one of them does — this page says so in code. It is the feature-side
companion to the "Game Modes" group; the section hub is
[../V2_features.md](../V2_features.md).

## What ships, honestly

These features live at two different points on the implemented-versus-spec
spectrum, and the line between them runs right down the middle of this page.

- **Signature events are a validated data catalogue, not a runtime.** Marathon,
  Endurance, King of Iron Fist, the five branded events, and the four
  tournament-organizer stipulations are all fields of one `USTRUCT`,
  `FV2SignatureEventModeCatalog` (`V2ModeTypes.h:3551`), built by
  `FV2ModeCatalog::BuildDefaultSignatureEventModeCatalog()`
  (`V2ModeCatalog.cpp:5405`) and gated by a real cross-checking validator
  (`IsValidCatalog`, `V2ModeTypes.cpp:2918`). What is **not** there: a Marathon
  session clock that auto-pauses at hour six, a bracket runner that seeds eight
  fighters, a card sequencer that plays eight WrestleMania walkouts. Those are
  described by the data (`MarathonDurationHours = 24`,
  `AutoPauseReminderHours = 6`) and not yet executed by code. The monolith's
  "each signature event ships as its own `UGameFeaturePlugin`" is a _target
  artifact_: the architecture companion confirms only three `.uplugin` files
  exist on disk and none are named `V2Event_*`.
- **The roguelike has real runtime algorithms.** Alone among the modes on this
  page, `Mode.RoguelikeAdventure` is one of the **52 registered modes** in the
  canonical catalogue _and_ carries two genuine, deterministic algorithms — a
  seeded procedural room-graph generator (`GenerateRun`) and a keyword-token
  boon-synergy resolver (`ResolveSynergies`) — both exercised against
  known-correct outputs by the contract spec. Its catalogue is also the one that
  is actually wired into the editable config DataAsset
  (`V2ModesConfigAsset::RoguelikeAdventureCatalog`); the signature catalogue is
  build-default only.
- **Scheduling is a separate service.** The "wheel it onto the calendar, remove
  it after the window closes" half of the signature-event story is a TypeScript
  live-ops service, `@v2/limited-time-game-mode-service`
  (`apps/v2/limited-time-game-mode-service/`), not engine code.

The mode-registry machinery these features register against — the 52-mode
catalogue, the load planner, the lifecycle, the replay pipeline — is documented
in the architecture companion
[../architecture/game-modes-training-and-replay.md](../architecture/game-modes-training-and-replay.md);
this page stays on the feature surface and dips into C++ only where a claim
needs backing.

## Signature event modes (§93)

### One catalogue, one validator

Everything in the signature-event cluster hangs off a single value type.
`FV2SignatureEventModeCatalog` carries a `MarathonEndurance` spec, a
`KingOfIronFist` spec, an array of five `SignatureEvents`, a
`LimitedPoolPolicy`, a `HordeMode`, a `SpeedrunRace`, and a `DeathMatch`
stipulation set, plus a `FindSignatureEvent(EventId)` lookup. The contract spec
`V2.Modes.SignatureEventModes.AssetContract`
(`V2/ue/Source/V2Tests/Private/Modes/SignatureEventModes.spec.cpp`) builds the
default catalogue and asserts each field — and, critically, asserts the
_negative_ cases too: removing any one of the five required events, or deleting
the Def Jam entry from the Death Match's per-ruleset definition map, must make
`IsValidCatalog` return false. That is what makes this "checked spec" rather
than decorative data: the validator at `V2ModeTypes.cpp:2918` enforces that the
catalogue holds **exactly five** signature events, with unique ids, and that all
five canonical event ids are present.

### Marathon & Endurance — the always-on duo

Marathon and Endurance share one spec, `FV2MarathonEnduranceEventSpec`
(`V2ModeTypes.h:3278`), because they are the two "how long can you go" events.
**Marathon** (`MarathonModeId = Mode.Event.Marathon24`) is the 24-hour
charity-aligned community event: `MarathonDurationHours = 24`,
`MarathonRewardTierHours = {4, 8, 12, 18, 24}`,
`bCommunityLongestSingleSessionStreak = true`, and a
`CharityProgramId = Charity.Marathon.PartnerCreators`. The player-health rule
from the source — auto-pause after six continuous hours — is the field
`AutoPauseReminderHours = 6`, and the "broadcast the final stretch" hook is
`PartnerCreatorBroadcastFinalHours = 8`. `IsValidSpec` (`V2ModeTypes.cpp:2699`)
hard-asserts all three numbers and the full five-tier reward ladder, so a
designer cannot quietly drop the 6-hour pause or the 18-hour tier. **Endurance**
(`EnduranceModeId = Mode.Event.EnduranceTower50`) is the 50-fight chain:
`EnduranceFightCount = 50`, `bEnduranceHPCarryOver = true`,
`bEnduranceRareDropRewards = true`, and an `EnduranceAutosaveEveryFights = 5`
checkpoint cadence so a crash twelve fights deep does not erase the run — the
validator rejects any value other than 50 fights, autosave-every-5, with both
the HP carry-over and rare-drop flags set.

### King of Iron Fist — the eight-fighter throne ladder

`FV2KingOfIronFistEventSpec` (`V2ModeTypes.h:3325`) models the Tekken-lineage
crown tournament: `BracketFighterCount = 8`, `bSingleEliminationLadder`, the
full launch roster eligible (`bFullLaunchRosterEligible`), a per-bracket
cinematic between fights (`bPerBracketCinematicsBetweenFights`), and a final
fought in `FinalArenaId = Arena.Tekken.ThroneRoom` under
`bFinalFightThroneRoomCinematic` with a `bPerFighterUniqueEndingIllustration`
awarded on the win. It also carries the unlock grammar — two
`UnlockConditionIds`, `Unlock.KOF.HiddenFighterClear` and
`Unlock.KOF.AltCostumePerfectRun`, behind
`bHiddenFighterAndAltCostumeUnlockConditions`. (One naming trap worth flagging:
that `KOF.` prefix abbreviates _King Of iron Fist_, not the King of Fighters
ruleset that the [rulesets page](./rulesets-tag-and-kameo.md) discusses — they
collide only in the abbreviation.) `IsValidSpec` (`V2ModeTypes.cpp:2735`)
refuses the spec unless it is an 8-fighter ladder ending in the throne room with
both unlock conditions named.

### The five branded events

Each of the marquee franchise events is one `FV2SignatureEventSpec`
(`V2ModeTypes.h:3363`) — a typed bundle of `RulesetId`, `CardMatchCount`,
`BracketFighterCount`, `CrewSize`, and a fan of boolean production flags. The
default catalogue (`V2ModeCatalog.cpp:5438`+) builds exactly these five, and the
per-event branch of `FV2SignatureEventSpec::IsValidSpec`
(`V2ModeTypes.cpp:2760`) asserts each one's defining shape against its
`EventId`:

| Event (`EventId`)                | Ruleset                        | Shape & production flags                                                             |
| -------------------------------- | ------------------------------ | ------------------------------------------------------------------------------------ |
| **WrestleMania PPV**             | `Ruleset.WWE.PremiumLiveEvent` | 8-match card; cinematic walkouts, commentary intermissions, custom title-belt reveal |
| **UFC International Fight Week** | `Ruleset.UFC.UnifiedMMA`       | 4-event card; weigh-ins, cinematic walkouts, post-fight pressers                     |
| **SoulCalibur Mishima Cup**      | `Ruleset.SC.WeaponMaster`      | 16-fighter Weapon Master tournament; per-fight modifier roulette                     |
| **EVO Top 8**                    | `Ruleset.Standard`             | 8-fighter bracket; broadcast overlay, caster polls                                   |
| **Def Jam Crew Wars**            | `Ruleset.DJ.FightForNY`        | 4-per-crew (`CrewSize = 4`) elimination; hip-hop set production between matches      |

These flags are not free-floating: the WrestleMania branch _requires_
`CardMatchCount == 8` and all three WWE production booleans before it will
validate, and Mishima Cup _requires_ the 16-fighter count plus both the
weapon-master and modifier-roulette flags. The broadcast overlay these events
lean on is the same one the esports toolkit produces — see
[../architecture/esports-companion-and-ai-services.md](../architecture/esports-companion-and-ai-services.md).

### Tournament-organizer stipulations

The cluster closes with four TO-facing stipulation types, each its own validated
spec inside the catalogue:

- **Limited-fighter-pool** (`FV2LimitedPoolTournamentPolicy`, `:3419`) — a
  TO-curated roster restriction with worked example ids
  (`Restriction.Height.Under6Ft`, `Restriction.Archetype.GrapplerOnly`,
  `Restriction.Roster.NoDLC`) and capability flags for height, archetype, and
  no-DLC restrictions plus a `bRandomRollRosterOption` that assigns fighters per
  event.
- **Asymmetric Horde** (`FV2AsymmetricHordeModeSpec`, `:3448`) — one boss
  (`BossPlayerCount = 1`, `BossHpMultiplier = 3.0`) against a 3-4-player crew
  (`CrewMinPlayers = 3`, `CrewMaxPlayers = 4`), with `bBossHasCinematicMoves`,
  `bBossRotationCoop`, and a win condition of depleting the boss's HP within a
  time limit. The boss can be CPU or a guest player
  (`bBossCanBeCPUOrGuestPlayer`).
- **Speedrun Race** (`FV2SpeedrunRaceModeSpec`, `:3483`) — 2-4 players racing
  the Arcade ladder side-by-side (`bArcadeLadderSideBySide`), a finish line at
  the boss KO (`bFinishLineAtBossKO`), a `Leaderboard.SpeedrunRace.PerRace`
  board, and a broadcast view (`bBroadcastViewShowsAllRacers`) with an overlay
  timer, per-racer fight count, portrait, and lap-split visualization.
- **Death Match** (`FV2DeathMatchStipulationSet`, `:3527`) — a single round
  (`bSingleRound`), no time limit (`bNoTimeLimit`),
  `bSuddenDeathFirstDecisiveHitWins`, with the genuinely interesting field a
  `RulesetDecisiveHitDefinitions` **`TMap`** that pins what "decisive" means per
  family: `Ruleset.MK → FirstFatalBlowLands`, `Ruleset.SF → FirstDriveImpactKO`,
  `Ruleset.UFC → FirstKO`, `Ruleset.WWE → FirstFinisherPin`,
  `Ruleset.SC → FirstRingOut`, `Ruleset.DJ → FirstEnvironmentFinisher`. The
  catalogue validator rejects the whole thing if any one of those six
  per-ruleset definitions is missing — the spec literally tests that removing
  the Def Jam entry fails validation.

### Scheduling onto the live calendar

The "removable after its window closes" promise is real, but it lives in
services, not the engine. `@v2/limited-time-game-mode-service`
(`apps/v2/limited-time-game-mode-service/`) builds a server-authoritative
schedule that can enable and disable game modes on a timetable, publish the
active `queueId` and `rulesetId`, and mark `eventExclusive` modes — all
**without requiring a client patch**. It exposes `GET …/limited-time/schedule`,
`GET …/limited-time/active`, and `POST …/limited-time/{scheduleId}/state`, with
each definition resolving to an `upcoming | enabled | disabled` state, and
validates schedule windows, duplicate ids, and overlaps. The broader seasonal
cadence sits in `maat-live-service-calendar`. So a signature event's _content_
is the engine's validated catalogue; its _availability window_ is this service's
schedule.

## The roguelike adventure mode (§126)

### One registered mode, one validated catalogue

Unlike the signature events, the roguelike **is** a first-class registered mode.
`Mode.RoguelikeAdventure` is built into the canonical 52-mode list
(`V2ModeCatalog.cpp:6337`) as an `EV2ModeCategory::Roguelike` mode with an
`AsyncService` network model (for leaderboards and daily seeds), a `Profile`
save model, a 1-2 player band, and the tags `Roguelike / Permadeath / DailyRun`,
tied to design-section "Section 126." Its content is a deep catalogue,
`FV2RoguelikeAdventureModeCatalog` (`V2ModeTypes.h:9771`, `SectionId = 126`),
built by `BuildDefaultRoguelikeAdventureModeCatalog()`
(`V2ModeCatalog.cpp:6168`) and — uniquely on this page — surfaced as an editable
`RoguelikeAdventureCatalog` property on `UV2ModesConfigAsset`. The contract spec
`V2.Modes.RoguelikeAdventure.AssetContract`
(`V2/ue/Source/V2Tests/Private/Modes/RoguelikeAdventureMode.spec.cpp`) validates
the catalogue _and_ drives its two runtime algorithms.

### Run structure & deterministic generation — the real algorithm

`FV2RoguelikeRunStructureSpec` (`:9458`) sets the frame: a 30-60-minute run
(`MinRunMinutes = 30`, `MaxRunMinutes = 60`),
`bHadesInspiredRunBasedPermadeath`, `bDeathResetsToHub`,
`bMetaProgressionCarriesBetweenRuns`, and a cinematic boss every
`CinematicBossEveryNthRoom = 6`. The genuinely load-bearing part is
`FV2RoguelikeRoomGraphSpec::GenerateRun(Seed, RoomCount = 12, BossEveryNth = 6)`
(`V2ModeTypes.cpp:9086`) — a real, deterministic procedural generator, not a
placeholder. It seeds an `FRandomStream` from the run seed, builds a non-boss
room pool **weighted toward combat** (Combat ×3, BoonShrine ×1, Shop ×1, each
added only if the graph authored that kind), then walks the rooms placing a
`BossGate` at every Nth slot and at the final room, tagging every Combat room
with a procedurally-picked hazard from the authored set
(`LowGravity, Fog, ShrunkenHurtbox, Armored, ElectricFloor`), and giving each
shrine/shop/boss room a **2-option reward fork** drawn from
`{Defensive, Offensive, Cosmetic, Lore}` with the two options forced distinct.
The contract spec pins the behaviour against known-correct outputs: a
12-room/seed-`20260530` run must place boss gates at room index 5 and the final
room 11 (and _not_ at room 0), every combat room must carry a hazard, every fork
room must offer exactly two options, and — the determinism check — the same seed
must reproduce a byte-identical room/hazard sequence. A random or hardcoded
implementation would fail these immediately.

### Boons, rarities & synergy resolution — the second real algorithm

`FV2RoguelikeBoonLibrarySpec` (`:9571`) is the build-crafting layer. It authors
boons from per-fighter CSVs
(`SourceCsvPattern = V2/balance/roguelike/<fighter>/boons.csv`, with real files
on disk for Asha, Kaz, King, and Ryu), round-trips them to a DataTable
(`bCsvRoundTripsToDataTable`), and bounds a run to 5-8 boons and 2-3 passives
(`MinBoonsPerRun = 5 … MaxPassivesPerRun = 3`). Each `FV2RoguelikeBoonSpec`
binds a `FighterId`, an `EffectTag`, an `EV2RoguelikeBoonRarity`
(`Common → Rare → Epic → Legendary`), and the `bStacksAcrossRun` flag — the
default library ships one per rarity (Asha _Common_ LightPunchFreeze, King
_Rare_ ThrowsStun, Ryu _Epic_ DriveImpactBleed, Kaz _Legendary_ HeatSmashAOE),
and the validator rejects a library missing any rarity or any of the four
fighters. The synergy system is the second real algorithm:
`ResolveSynergies(EquippedEffectTags)` (`V2ModeTypes.cpp:9240`) decodes each
synergy id (e.g. the `FreezeStun` token in `Boon.Synergy.FreezeStun.Frostbite`)
against an effect-keyword vocabulary
(`Freeze, Stun, Bleed, AOE, Armor, Electric, Burn, Poison`) and fires the
synergy only when **every** keyword it encodes is represented among the equipped
boons' effect tags. The source's worked example — Freeze + Stun = Frostbite — is
a test assertion: Freeze + Stun activates exactly the Frostbite synergy and no
other; Bleed + AOE activates Hemorrhage; a lone Freeze boon activates nothing;
and all four effect boons together light up both available synergies. That is
domain-correct logic verified against specific expected counts.

### Hub, bosses, narrative, and the social loops

The rest of the catalogue is broad but honest data.
`FV2RoguelikeHubMetaProgressionSpec` (`:9613`) is the persistent between-run
hub: NPC dialogue, lore progression, and meta-currency spending across four
named permanent upgrades — `bMoreBoonSlotsUpgrade`,
`bBetterStartingEquipmentUpgrade`, `bAdditionalStartingHealthUpgrade`,
`bAdditionalRevivesUpgrade` — each of which the validator requires (the spec
tests that flipping `bAdditionalRevivesUpgrade` off fails the catalogue).
`BossEncounters` ships five cinematic realm bosses (FrostMonk, IronOni,
ThunderQueen, BoneChampion, VoidEmperor, each with its own realm), with
`HasRequiredBossCount()` enforcing the source's "5-8 per complete run" band and
each boss carrying `EliteHeatTiers` for the per-boss Heat difficulty multipliers
(the spec checks that the Heat +3 variant survives).
`FV2RoguelikeNarrativeArcSpec` (`:9684`) sets the per-fighter arc — a 10-30-run
primary arc (`MinRunsToCompletePrimaryArc = 10`) with a
`bTrueEndingAfterMaxDifficultyCompletion`. The social loops are
`FV2RoguelikeMultiplayerSpec` (`:9710`) — 2-player local couch and online co-op
with shared room boons and shared meta-progression, plus a PvP parallel-race
variant whose win condition is clearing the final boss first
(`bFinalBossRaceWinCondition`) with an opponent ghost overlay
(`bOpponentGhostOverlay`, which the spec requires for PvP) — and
`FV2RoguelikeDailyRunSpec` (`:9742`), a shared-seed daily
(`bDailySeedSharedForAllPlayers`) with a per-run leaderboard, a top-100 cosmetic
reward (`TopNCosmeticRewardRank = 100`), and a weekly Heat challenge at
`WeeklyHeatDifficultyTier = 2`.

## Standalone modes & where they sit

The roguelike is the flagship of V2's **standalone** modes — experiences with
their own loop, scoring, and progression rather than a stipulation layered over
a normal fight — but it is not the only one. The same `V2Modes` catalogue
registers the three specialty rulesets (`Mode.Specialty.BoxingSim`,
`Mode.Specialty.BushidoBlade`, `Mode.Specialty.MKOneHitTournament`,
`V2ModeCatalog.cpp:6338`+, with their own `FV2SpecialtyCombatModesCatalog`) and
the three 100-player battle-royale variants
(`Mode.BattleRoyale.Fighter100 / Vehicle100 / Hybrid100`). Those, along with the
karaoke rhythm mode, the arcade mini-game suite, and the world-boss raid, are
covered alongside the full 52-mode roster in the catalogue companion
[./mode-catalog-training-and-replay.md](./mode-catalog-training-and-replay.md);
this page keeps its scope to the signature events and the roguelike because
those are the two clusters the source groups together under "signature event
modes" and "standalone Hades-style adventure."

## How it connects

The signature-event catalogue and the roguelike catalogue are both
`V2Modes`-module data validated by contract specs, but they diverge sharply: the
roguelike is a registered mode with real generation and synergy algorithms wired
into the editable config asset, while the signature events are a build-default
catalogue whose runtime (bracket runners, card sequencers, the Marathon clock)
and plugin packaging (`V2Event_*`) remain target artifacts. Both register
against the mode registry, load planner, and lifecycle in
[../architecture/game-modes-training-and-replay.md](../architecture/game-modes-training-and-replay.md);
both surface per-mode HUD through the same gameplay-inert injection seam. Their
availability windows are driven by the live-ops services, and their broadcast
production (overlays, caster polls, director-cam) is the esports toolkit's. The
presentation beats that bracket each event — walkouts, win illustrations,
throne- room cinematics — are authored in
[./roster-presentation-and-stages.md](./roster-presentation-and-stages.md). The
section hub is [../V2_features.md](../V2_features.md).

## Related

- [Mode Catalogue, Training & Replay](./mode-catalog-training-and-replay.md) —
  the full 52-mode roster, the load planner, training, and the replay pipeline
  these events register against
- [Rulesets, Tag-Team & Kameo Assists](./rulesets-tag-and-kameo.md) — the
  per-ruleset feel that each signature event's `RulesetId` selects
- [Roster, Presentation & Stages](./roster-presentation-and-stages.md) — the
  walkouts, ending illustrations, and throne-room cinematics these events stage
- [Game Modes, Mode Plugins, Training & Replay](../architecture/game-modes-training-and-replay.md)
  — the mode registry, the 52-mode catalogue, and the target-artifact convention
  behind the `V2Event_*` plugin URLs
- The section hub: [../V2_features.md](../V2_features.md)