Back to the feed
Featured New Templates 2026-06-21

Verse Starter Template in Unreal Editor for Fortnite

Verse Starter Template in Unreal Editor for Fortnite

UEFN now ships a dedicated Verse Starter Template that gives you a pre-wired project scaffold — device bindings, a compilable Verse module, and a minimal island layout — all in place before you write a single line of code. This matters because the previous blank-slate workflow forced you to manually wire up creative_device subclasses, configure the Verse explorer, and resolve module dependencies on every new project, costing meaningful setup time before reaching any real logic.

What Changed

The Verse Starter Template is a new entry in the UEFN New Project dialog under the Templates category. Selecting it provisions:

  • A ready-to-compile Verse module (VerseStarterTemplate.verse) containing a skeletal creative_device subclass with lifecycle stubs (OnBegin, event subscriptions).
  • A pre-configured Verse Explorer tree with the module already registered to the island's content namespace, eliminating the manual "Add Verse File to Verse Explorer" step.
  • A minimal island that includes a Player Spawner, End Game device, and a Verse Device actor already dropped into the level and bound to the generated class — so OnBegin fires immediately on playtest without additional placement work.
  • Correct using block imports (using { /Fortnite.com/Devices }, using { /Verse.org/Simulation }, using { /UnrealEngine.com/Temporary/Diagnostics }) stubbed into the file so you are not hunting down namespaces for common device types.

The template targets developers who want to skip boilerplate and jump directly into feature implementation, and it is versioned alongside the UEFN release cycle, so the stub code reflects the current Verse runtime APIs rather than stale examples.

What You Can Build

1. Rapid Prototyping of Game-Loop Logic

Because the device actor is already bound and OnBegin is wired, you can prototype a full round-trip game loop — spawn logic, win condition, timer — in a single session without touching the editor's device placement panel. Drop your logic directly into the generated stub:

using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }
using { /UnrealEngine.com/Temporary/Diagnostics }

verse_starter_template_device := class(creative_device):

    @editable
    EndGameDevice : end_game_device = end_game_device{}

    @editable
    RoundDurationSeconds : float = 60.0

    OnBegin<override>()<suspends> : void =
        Sleep(RoundDurationSeconds)
        EndGameDevice.Activate(agent?)

Previously you would spend the first 10–15 minutes of a session creating the file, registering the module, placing the device actor, and resolving import paths before reaching equivalent standing.

2. Team Onboarding With a Consistent Baseline

When multiple developers collaborate on an island, diverging project structures — different module names, mismatched namespace paths, devices placed inconsistently — cause merge friction and compile errors. The template enforces a single canonical layout from the start. A lead can create the project from the template, commit it to source control, and every collaborator clones a state that compiles and playtests immediately. You can extend the base class without restructuring the module:

# Extended by a team member without touching module registration
round_manager_device := class(verse_starter_template_device):

    @editable
    ScoreManager : score_manager_device = score_manager_device{}

    OnBegin<override>()<suspends> : void =
        ScoreManager.Reset()
        super.OnBegin()  # Delegates to template's timer/end-game flow

3. Learning-by-Modification for Experienced Developers Exploring New APIs

Even seasoned Verse developers encountering an unfamiliar device category (e.g., mutator_zone_device, vehicle_spawner_device) benefit from a compiling baseline to modify rather than reading API docs in isolation. The template's pre-validated import block and device-binding pattern give you a correct structural frame. You swap in the new device type, keep the surrounding scaffolding, and iterate:

@editable
VehicleSpawner : vehicle_spawner_device = vehicle_spawner_device{}

OnBegin<override>()<suspends> : void =
    VehicleSpawner.SpawnedEvent.Subscribe(OnVehicleSpawned)

OnVehicleSpawned(SpawnedVehicle : fort_vehicle) : void =
    Print("Vehicle spawned: {SpawnedVehicle}")

This cuts the feedback loop on API exploration from "debug why the module won't register" to "debug the actual feature behavior."

References

Related topics