Playable showcases guide

Mass Forge ships its reusable framework, editor teaching tools, and examples in one plugin. The companion Unreal project is only a customer-style launcher and verification host. The examples do not depend on Game Master.

Launcher

The project starts in /MassForge/L_MF_ShowcaseMenu, located directly at the plugin Content root. Click a card to open its standalone map. Press Escape from an example to return to the launcher.

The initial release has five entries. Multiplayer is intentionally excluded from this sample suite.

Tower Defense

Map: L_MF_TowerDefense

Three routes feed mixed enemies toward a base. Actor towers acquire Mass targets and apply direct or area damage, slow effects, and upgrades through Mass Forge state.

The saved-world image shows construction before Play; the live image shows the same three routes under pressure. Towers are Actors for convenient placement, while target Health, effects, damage, and enemy lifecycle remain Mass Forge state.

This example teaches:

• schema-backed Health, Move Speed, Attack Power, Defense, and combat attributes;
• Actor-to-entity targeting and damage;
• effect application and removal;
• economy and upgrade state;
• stable entity presentation without origin stacking; and
• how wave roles change targeting decisions.

Third-Person Horde Defense

Map: L_MF_ThirdPersonHordeDefense

A third-person arcanist protects a fortified strongpoint through three finite assault waves. The player uses manual abilities while Mass enemies pursue, attack the player, and pressure the objective.

Fireball, frost-nova shards, hostile bolts, and VAT/skeletal attack timing use the same Mass projectile path. The attack pose begins first, the projectile releases at the authored frame, and damage commits on impact.

The expanding cyan bead trail is the example renderer reading one Mass projectile's snapshots. The attack starts before release, and the target loses Health only when the impact record resolves.

This example teaches:

• player-to-entity and entity-to-player damage;
• abilities, costs, cooldowns, charges, and tags;
• objective attributes and failure/success conditions;
• blocking obstacles, jump-aware pursuit, and bounded local representation; and
• Actor presentation that observes Mass-owned gameplay state.

Battle Simulator

Map: L_MF_BattleSimulator

Vanguards resolve melee damage on their authored strike frame. Rangers and supports launch Mass-owned projectile entities; the sample HISM renderer is presentation-only, and damage/healing resolves when the projectile impact record returns to the safe gameplay phase.

Two symmetric 1,000-entity armies fight until one side wins. Roles include melee, ranged, support, and healing behavior. The post-battle tableau retains the result instead of freezing in an unexplained intermediate state.

The saved map above shows how the example is constructed; this Play-in-Editor capture shows the same map after both armies have entered combat. The visible projectile field is presentation for real Mass projectile entities whose damage or healing resolves on impact.

This example teaches:

• project-owned faction tags, role-specific attributes, and the inspectable FactionDamagePolicy component that denies only shared configured tags;
• Mass-to-Mass target acquisition and retargeting;
• direct, ranged, and healing effects;
• deterministic balance inputs; and
• large-population outcomes without a per-unit Actor requirement.

Survivor Roguelite

Map: L_MF_SurvivorRoguelite

A third-person survivor loop combines automatic and aimed abilities, navigation around real collision, jumping, XP, ranks, and mouse-selected upgrade cards. Population presets are explicit about allocation versus active simulation and representation.

The example separates a 10,000-entity allocation from the bounded active set. The visible Arc Bolt, ability cards, Health, level, and XP are game presentation over Mass Forge state rather than hidden substitute counters.

This example teaches:

• scalable enemy allocation and bounded active work;
• player attributes, incoming damage, recovery, XP, and ranks;
• data-driven upgrade choices;
• ability evolution during a run; and
• readable pursuit across a 3D arena.

Third-Person Horde Defense — VAT

Map: L_MF_ThirdPersonHordeDefenseVAT

This is the same finite game as Third-Person Horde Defense: the same 420 Mass enemies, player controls, balance, obstacles, abilities, damage, objectives, and three-phase win condition. Its only intentional difference is presentation: the horde is rendered with the project-owned Arcane Sentinel VAT mesh, position/normal textures, and material state machine instead of the bounded skeletal near tier.

The twin map keeps the same 420-enemy gameplay contract and swaps only the enemy presentation backend. Cyan and purple states come from per-instance gameplay/material data, not per-enemy dynamic material instances.

The VAT textures are sampled from the same Blender rig and clips used by the skeletal map. Gameplay states select Idle, Move, Attack, Cast, Hit, Jump, and Death clip ranges through a versioned twelve-float per-instance payload. Damage flash, frozen, burning, shielded, selected, and dissolve flags originate in Mass gameplay state/tags; they do not own damage or death.

This example teaches:

• how one gameplay implementation can select skeletal or VAT presentation;
• genuine position/normal VAT playback with stable instance identity;
• animation transition and material-state data in a fixed custom-data layout;
• team palette and temporary status effects without per-entity dynamic material instances; and
• the separation between Mass-owned gameplay authority and replaceable GPU presentation.

The older L_MF_VertexAnimation procedural-WPO crowd map is retained only as an internal migration/performance regression fixture. It is not linked from the customer launcher and is never described as VAT.

Editor monitor

During PIE, Mass Forge Live Showcase opens automatically. Its pages are:

If the monitor was closed, reopen it from Tools > Mass Forge Live Showcase while an example is running.

Page	Purpose
Overview	Allocated, active, simulated, represented, animated, and resolved populations plus the map's proof statement
Gameplay	Current game metrics, concise controls, and safe pause/reset/scale actions
Performance	Frame observation and representation health without marketing unsupported benchmark claims
Recipe	Public integration steps and the ownership boundary between Mass Forge and sample presentation

The monitor observes gameplay at a bounded rate. It does not own the simulation and is excluded from Shipping runtime logic.

Inspectability rule

What customers see in the editor must be the real level or a clearly labeled, editable generator. Substitute preview scenery is not used. Any runtime-authored environment must expose its inputs in inspectable assets/components and be documented as runtime generation.

Every public map stores its Blueprint gameplay root, Blueprint world-layout actor, and Player Start. The running GameMode reuses those actors; it creates a fallback only when a developer deliberately runs the sample GameMode in a blank map. See How the examples are authored for the exact assets, editable definition references, and the Blueprint/C++ ownership boundary.

Verification

Maintainers run Examples/MassForgeShowcases/Scripts/Verify-Showcases.ps1 -RequireSecondPassGameplayProof -KeepWorkspace, then Capture-Showcases.ps1. The two character backends also pass Verify-CharacterPresentationPackage.ps1; its optional -CaptureVATProfile switch records a frame-bounded packaged observation. Passing automation is necessary but not sufficient: every final rendered frame and every saved map must receive human review before release.

See the character animation and VAT evidence for exact assets, counts, visual review, and benchmark boundaries, and how the examples are authored for the editable Blueprint and C++ ownership split.