ZOA Demo Suite

ZOA_Demo_MovementSandbox, roughly two minutes. A playground of platforms at varying heights, ramps, narrow walkways and interactable props, with no enemies and no weapons in it.

It exercises the Nucleon player controller and its movement modules, the Cinemachine camera rig, the Input System action map, and the interaction prompt path. The generator explicitly overrides PopulateAiSpawnZones to do nothing, because a tutorial scene with wandering AI is a worse tutorial.

The HUD profile is NonCombat: the Feature Set HUD controller plus compass, minimap and full map. Ballistics and weapon-debug HUDs are left out, since with no weapon in the scene they would render empty panels.

ZOA_Demo_InventoryEquipment, roughly five minutes. An L-shaped supply depot with several loot containers holding different contents, a workbench, and nested container items such as backpacks.

It exercises the grid inventory with real footprints, the twelve-slot equipment layout, container-in-container nesting, and the loot and pickup path through the interaction framework. The spawn anchor threads the canonical Sci-Fi weapon pack id, so the player arrives with a weapon and the weapon slot has something to hold.

Because the scene spawns weapons it installs the Combat HUD profile: the Feature Set HUD, the minimap stack, the weapon state debug HUD, and the combat feedback layer of floating damage numbers and directional hit indicators.

ZOA_Demo_WeaponCombatRange, roughly eight minutes, and the largest generator in the package. It builds a complete armory station: a weapon rack with a backdrop, an attachment table, an ammo bench and a crafting bench, then a firing range with targets at varying distances.

It exercises weapon modding and mount points, attachment swapping live at the bench, Armory ballistics, recoil, reload, and the full damage pipeline. Targets carry RangeTargetController, which is an IHealthDamageAuthority layered over the canonical HealthDamageReceiver. Producers build a DamageContext and call the receiver; the controller classifies the hit against an armour threshold using DamageContext.PenetrationPower, so a shot at or above the threshold penetrates for full damage and one below deflects. Penetrating and deflected hits are counted separately, so the range gives you numbers to tune against.

NavMesh is baked at generation time and serialises into the scene file, so click-to-move and AI navigation work the moment the scene opens with no runtime cost. This is the scene to use when tuning weapon pose, muzzle alignment and attachment sockets.

ZOA_Demo_AiEncounters, roughly twelve minutes. By default the arena is procedural mountainous terrain built through the com.zoa.terrain pipeline: a large heightmap with vantage markers and cover networks scattered at chokepoints. Setting the static AiEncountersGenerator.UseTerrainGeneration to false falls back to the legacy flat arena of crate clusters, pillars and a central platform, which is preserved for tests and small-scope work.

It exercises behaviour trees, spawner zones, and wave escalation. Grunts patrol, elites flank, snipers hold vantage points, and loot drops between waves feed the upgrade loop back into inventory and equipment.

Waves are driven by DemoWaveBootstrap, an IGameplaySubsystem wrapping the gameplay-neutral WaveController and bridging it to the DemoSession phase machine. A scene with no authored WaveDefinition gets the default from BuildDefaultWaveDefinition, whose counts come from the constants on DemoConstants: four grunts in wave one, six grunts and an elite in wave two, and so on, with an eight second intermission between waves.

ZOA_Demo_FullShowcase, roughly twenty minutes, and the flagship. The generator runs a six-stage procedural pipeline: build mountain terrain, run the enhancement passes for foliage, grass, water, a river spline, weather and a URP volume, place a five-building ProBuilder village near the suggested spawn, harvest scatter anchors into enemy and loot spawn containers, drop a boss arena building at the far edge, then bake NavMesh over the whole scene.

Play is directed by FullShowcasePhaseMachine, an eight-phase sequence: drop in, scavenge, hold Alpha, visit the vendor, hold Bravo, hold Charlie, boss, extract, then a terminal end screen that Replay returns to phase one. The machine advances by subscribing to ObjectiveTriggerBus rather than polling: six ItemCollected events end the scavenge phase, sixty seconds inside a hold zone ends a hold phase, an EnemyKilled with the boss archetype ends the boss phase. PhaseChanged is a static event, so the phase HUD and the music director subscribe without holding a reference to the machine.

It combines everything: the wave and boss loop, loot and vendor economy, objectives and missions, progression, save and load, localisation, and the guided tour. The eight phase ids match the objective asset slugs emitted by BundledFullShowcaseInstaller, and the mission graph aggregates them so objective progress shows in the HUD.

DemoSceneGeneratorBase owns everything common: creating the scene, building the DemoGameManager root with its GameplayDirector and DemoSession pair, adding the environment root with camera, lighting and ground, dropping the diagnostics HUD host, and saving. A subclass supplies a SceneId, a SceneName, and a PopulateScene body, and optionally overrides PopulateAiSpawnZones or ResolveDefaultAiSpawnOrigin.

The generated structure is a contract the scenario tests bind to. The root GameObject is named DemoGameManager, it carries a GameplayDirector and a DemoSession, its children implement IGameplaySubsystem, and the standard demo tags are Player, DemoEnemy, DemoLootBox, DemoSpawnPoint and DemoArena. Changing those breaks scenario tests silently at scene-load time rather than at compile time, so the base class documents them explicitly.

DemoSceneGeneratorCatalog is the single registry mapping a DemoSceneId to a display name, a stable template id such as demo.full-showcase or showcase.movement, a legacy type name, and a factory. Menu items, the Workbench module and external provisioning all go through it, so they cannot drift apart. TryCreateBySelector accepts an enum name, a template id or a legacy type name, so an external caller can ask for a scene by string without referencing the demo assembly.

A generated scene never contains a composed player rig. It contains a spawn anchor carrying a PlayerSpawnRequest from com.zoa.gameplay and a SpawnPointMarker, and ZOAPlayerSpawnSceneInstaller instantiates the rig from that request at scene load.

The request names the local prefab, optionally a remote prefab for networked scenes, an optional weapon pack id for auto-equip at spawn, and the session mode. Movement Sandbox leaves the pack id empty because it has no combat; Inventory & Equipment threads the Sci-Fi pack so the equipment slots have something to hold.

The old PlayerSpawnAnchor component from the retired persistent-scene design is a comment-only tombstone. The name survives as a GameObject naming convention that tests still look for; the component does not.

DemoWorkbenchModule contributes the Demo Suite page to the Workbench under the workflow.environment hub, with a scene picker and per-HUD diagnostics toggles persisted in EditorPrefs.

DemoScenesContentBrowserProvider registers a Demo Scenes tab into the Content Browser, listing both the generator descriptors and any Feature Set demo scenes contributed by content packs, so generated and content-driven scenes appear in one catalogue.

DemoWorkbenchSceneProvisioningProvider registers into the Workbench scene provisioning registry at priority 100, which is how the Workbench's Create Game Scene action produces a real demo scene rather than a bare scaffold when the demo package is installed.

The tour used to be a bespoke engine with its own step model, timer and completion state machine. It is now a tombstone. Guided tours run on the first-class com.zoa.objectives stack instead.

DemoTourCatalog holds each scene's tour as an ordered list of IObjectiveStep values defined in code. DemoTourBootstrap is thin glue: an IGameplaySubsystem that runs those steps through ObjectiveSequenceRunner with ObjectiveTriggerArmer doing the trigger arming, and renders the active step's text into DemoHud. All sequencing, progress and completion flow through IObjectiveTracker, so there is no parallel tour state to drift.

Toggle the tour at runtime with DemoSession.SetGuidedTourMode, or subscribe to OnGuidedTourChanged to react to it.

DemoSceneHudInstaller.Install takes a DemoSceneHudProfile: Custom for a scene supplying its own chrome such as the MOBA generators, Combat for the full FPS stack, or NonCombat for the UI and movement scenes.

Every EnsureXxx helper scans the manager's children for an existing host by well-known name, reuses it, and adds only what is missing, so re-running a generator never piles up duplicate HUDs. The HUDs then self-bind at runtime by resolving IPlayerContext, waiting on IWeaponLoadoutService.LoadoutChanged, or claiming a slot from ZOAHudSlotRegistry. The installer's only job is making sure the GameObjects exist before the rig spawns.

The crosshair is not scene-installed: it is rig-owned, baked into the player prefab and ensured at spawn, so installing it into the scene as well would produce two.