Signature Events & Standalone Modes

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.

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; 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 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:

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.

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; 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; 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. The section hub is ../V2_features.md.

Related#

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