AI can draft or revise a Verse device, but only UEFN and a live Fortnite session can establish whether the mechanic actually works. The reliable workflow is: choose Epic Developer Assistant for guidance or UEFN MCP for an editor-connected agent, request one small change, review the generated code, run Verse > Build Verse Code, place and wire the resulting Verse device, launch a session, trigger the event, and inspect both the behavior and logs. A generated answer is not a build, a successful build is not a runtime pass, and an agent’s report is not a substitute for observing the game yourself.
This guide follows Epic’s documented UEFN workflow and distinguishes what each AI route can do from what you still need to verify in the Fortnite client.
Which AI route should you use for Verse in UEFN?
Use Epic Developer Assistant when you need an explanation, a first draft, or guided instructions. Use UEFN MCP when you have completed its setup and want a compatible AI agent to inspect or edit project Verse, compile it, work with supported devices, and interact with play sessions. UEFN MCP is a beta integration, so it adds operational capability but also setup and reliability constraints.
| Route | Best for | Project context | Editor and session actions | Status |
|---|---|---|---|---|
| Epic Developer Assistant | Questions, explanations, Verse generation and step-by-step guidance | Information you provide in the prompt; it can also be used within UEFN | You perform the review, build, device placement, wiring and playtest | Documented Epic tool |
| UEFN MCP | An editor-connected agent that can operate on supported UEFN tasks | Can read or edit project Verse and work with supported editor tools after setup | Can assist with compilation, device operations and play-session interaction; you still verify the result | Beta; Epic warns of rough edges and possible editor hitching |
Epic’s MCP documentation lists compatible-agent examples rather than requiring one exclusive provider. Do not assume that a general Unreal MCP toolset is compatible with UEFN; check the UEFN-specific documentation before attempting a connection.
What should you prepare before asking AI to change Verse?
The best prompt describes one observable behavior and the project objects it must touch. Start from a Verse Device file, not a blank text document.
1. Create the right starting file
- Open your UEFN project and choose Verse > Verse Explorer.
- Add a new Verse file using the Verse Device template.
- Open the file in the UEFN-bundled Verse extension for VS Code.
A Verse file is source code. It becomes a gameplay device only after you build it and drag the resulting device into the level. Keeping that distinction in your prompt prevents an AI from treating an unplaced class as if it were already active in the map.
2. Describe the trigger and the observable result
Give the assistant the event that should start the behavior, the exact result a player should see or a log should show, and the names of any existing devices. Say whether the change is meant to run once, on every round, per player, or on repeated interaction. If an existing device must be controlled, identify that device and explain how it is configured in the level.
3. Ask for a small, reviewable edit
Request the changed lines, an explanation of assumptions, and a build report. A grounded example is:
In my existing Verse device, add a log message when the round starts. Explain the changed lines, compile the project, and report the build result; do not claim gameplay passed.
The final sentence separates a compiler result from a gameplay result. It also gives you a clear expected observation: a message at round start.
How do you ask Epic Developer Assistant for a Verse draft?
Epic Developer Assistant can answer questions, generate Verse and provide instructions online or inside UEFN. Treat its response as a proposed change that needs local review.
- State the current structure. Include the Verse device class, relevant imports, editable properties and the names of placed Creative devices. Do not ask it to infer references that you have not described.
- Specify one behavior. For example, “When the round starts, print a diagnostic message,” is testable. “Make my game logic better” is not.
- Define the expected evidence. Ask for the exact log text, the event that should produce it and any visible device response.
- Request minimal code. Tell the assistant not to rewrite unrelated functions or rename existing devices unless necessary.
- Review before saving. Check the generated device name, imports, event names, function assumptions and every editable property. Ask follow-up questions about anything it cannot tie to a real object in your project.
Do not interpret confident prose as proof that a Verse API, event or device reference exists in your project. The project’s compiler and your placed level are the authority.
How do you connect an AI agent with UEFN MCP?
UEFN MCP requires a compatible agent and a documented setup; once connected, it can provide more project and editor context than a chat-only answer. Epic announced the integration on August 20, 2026 and describes it as beta: “Unreal MCP in UEFN is in beta, so expect some rough edges and more capabilities on the way.”
- Read Epic’s UEFN MCP documentation and follow its current connection and compatibility requirements.
- Use an agent listed as compatible with the UEFN integration. Compatibility with a generic Unreal MCP toolset is not automatic.
- Keep UEFN open on the project you intend to change and confirm which project and editor operations the agent can access.
- Start with a read or inspection request, such as asking it to identify the existing Verse device and its editable references. This exposes a wrong-project or failed-connection problem before code is changed.
- Give it the same narrow prompt you would give a chat assistant. Ask it to report each action separately: file edit, compile result, device operation and session interaction.
Epic notes that tool calls can cause editor hitching and that the integration does not support every general Unreal MCP tool. Keep edits small, review diffs yourself and stop the agent if its context or target project is unclear.
How do you review AI-generated Verse and build it correctly?
Review first, then use UEFN’s build command. The bundled VS Code extension helps with editing and checks, but Epic warns that editor diagnostics can miss compiler errors.
Review this checklist
- Class and device: Is the generated class the Verse Device you intend to place?
- Imports: Does each imported module match the APIs used?
- Events and functions: Are the event names, signatures and asynchronous assumptions valid for the project’s Verse version?
- Editable references: Does every
@editableproperty represent a device that will be assigned in the Details panel? - Scope: Did the assistant alter only the requested behavior?
- Diagnostics: Are warnings or errors explained rather than ignored?
- Save the Verse file.
- In UEFN, choose Verse > Build Verse Code.
- Read the build result in the Output Log or Message Log. Capture the actual diagnostic text if the build fails.
- Give that exact diagnostic to the AI and request the smallest correction. Build again after each correction.
A green build means the code compiled. It does not prove that a device is placed, that references point to the intended level objects, or that the expected event occurs during play.
Why does a compiled Verse device do nothing?
The most common reason is that the source file was built but the resulting device was never placed or wired in the level. Compilation creates an asset; it does not automatically insert an instance into your map or assign its editable references.
Place the device
- After a successful build, find the generated Verse device in the Content Browser or Verse device list.
- Drag that device into the level.
- Select the placed instance and open its Details panel.
Assign every editable reference
For each @editable device property, use the Details panel to select the intended Creative device in the level. An initialized reference in code is not the same as a reference to a particular level instance. Epic’s barrier example demonstrates why the editor assignment matters.
Check the trigger’s ownership and timing
Confirm that the event you are waiting for belongs to the placed device and that the device is active when the session starts. If your prompt says “round starts,” do not test only by interacting with a button later; exercise the exact round-start path.
How do you launch a Fortnite session and test the mechanic?
UEFN playtesting runs in a Fortnite client. Use the session to observe the specified trigger, visible result and logs instead of trying to execute Verse only in the text editor.
- In UEFN, choose Launch Session.
- When the Fortnite client opens, choose Start Game.
- Perform the exact action from your prompt: start the round, interact with the device, enter the trigger volume or perform the relevant player action.
- Compare the visible behavior with the expected result you wrote before coding.
- Check the in-game Log and UEFN Output Log for the message, warning or call stack associated with the event.
For a round-start logging change, the pass condition is not “the agent said it ran.” It is that the round starts and the expected message appears in the appropriate log. For a device-control change, verify both the log and the device’s visible state.
Which update command should you use after editing?
Use the update that matches what changed, then repeat the relevant test.
| What changed | Action | Why |
|---|---|---|
| Verse files only | Build, then use Push Verse Changes in the active session | Updates Verse code without treating unrelated level edits as part of the push |
| Placed devices, level objects or editor properties | Use Push Changes | Sends level and device changes as well as code changes to the session |
After either push, run the same trigger again. A successful push only tells you that the update reached the session; it does not establish that the interaction now behaves correctly.
What should your Verse test matrix include?
Run the checks in this order so a runtime failure is not confused with a build or wiring failure.
| Check | Procedure | Evidence to record |
|---|---|---|
| Build | Run Verse > Build Verse Code | Build success or the exact compiler diagnostic in Output Log or Message Log |
| Placement and wiring | Confirm the Verse device is in the level and inspect every editable reference | The selected level devices and their configured properties |
| Happy path | Launch Session, choose Start Game and trigger the specified event | Visible result and expected log message |
| Failure and edge path | Try an absent or differently configured referenced device, plus relevant repeated or multiplayer interactions | Whether the mechanic fails safely, logs a useful error or behaves as designed |
| After changes | Use Push Verse Changes for code-only edits or Push Changes for level/device edits, then repeat the trigger | Observed behavior after the update, not just a successful push |
The failure and edge cases above are test suggestions, not claims that Epic ran them or that a particular script passes them. Select only the cases that apply to your mechanic, but do not skip a case merely because the generated code looks plausible.
How do you debug a Verse script that builds but fails at runtime?
Use logs and call stacks to locate the failing route, then correct the smallest underlying assumption.
Add targeted diagnostics
Print() can display a message in-game and in UEFN’s Output Log. Use distinct messages before and after an event, reference lookup or state change so you can tell which branch ran. Epic also documents log channels for less intrusive output and PrintCallStack() for tracing the route to a problem.
Separate missing references from wrong logic
If the first diagnostic never appears, check that the placed Verse device is active and subscribed to the event you are triggering. If the first message appears but the second does not, inspect the reference or condition between them. If both appear but the player sees no change, verify the target device’s editor configuration and whether the visible result is actually controlled by the code path.
Use runtime-error reports when available
Epic documents a Verse tab in the Content Service Portal with runtime-error categories and call stacks. The service retains up to 30 days of runtime-error reports; that is a retention limit, not a measure of AI accuracy. Use the report to identify the failing call, then reproduce it in a session after applying a focused fix.
What are the limits of AI-assisted Verse testing?
AI is useful for translating a clear mechanic into code and for explaining diagnostics, but it cannot remove the project-specific parts of UEFN testing. Device placement, editable-reference assignment, event timing, player state and multiplayer behavior all depend on the actual level and session.
- Generated code can assume the wrong API. The compiler exposes that problem; supply its exact diagnostic rather than paraphrasing it.
- A build can miss wiring errors. A class can compile while its placed instance has no assigned reference.
- An agent can report an action without proving the outcome. Watch the Fortnite client and logs yourself.
- Beta tooling can be interrupted. UEFN MCP may hitch the editor during calls, and unsupported tools may fail to operate.
- Automation is not a complete test suite. Keep prompts and edits narrow, and repeat the relevant in-game interaction after every change.
What is a complete AI-to-playtest workflow?
For a small round-start log change, the full sequence looks like this:
- Create or open the Verse Device file from Verse > Verse Explorer.
- Ask Epic Developer Assistant, or a configured UEFN MCP agent, to add one round-start
Print()message and explain the changed lines. - Inspect the class, imports, event subscription and any editable properties.
- Save and run Verse > Build Verse Code.
- Fix only the compiler diagnostic that UEFN reports, then rebuild.
- Place the compiled Verse device in the level and assign any required references in Details.
- Choose Launch Session, then Start Game.
- Start the round and confirm the exact message appears in the in-game Log or Output Log.
- If you edit only Verse, build and choose Push Verse Changes; if you edit placed devices or their properties, choose Push Changes.
- Repeat the round-start test and inspect the logs again.
This sequence gives each claim its own evidence: code review for intent, Build Verse Code for compilation, Details for wiring, and a Fortnite session for runtime behavior.
What should you remember when using AI with Verse?
Start with a narrow, observable change and provide the project context the assistant cannot safely guess. Choose Epic Developer Assistant for guidance or UEFN MCP when you need a configured, editor-connected agent. In every case, build in UEFN, place and wire the device, launch a Fortnite session, trigger the mechanic and inspect the logs. Treat compilation and agent reports as intermediate evidence—not as proof that the player-facing behavior works.
Frequently Asked Questions
Can an AI agent test Verse without opening the Fortnite client?
No. A compiler can check code, and an editor-connected agent can perform supported operations, but the gameplay result must be observed in a Fortnite play session. Launch Session and Start Game provide the runtime context where player events and device behavior occur.
Do I need UEFN MCP to use AI for Verse?
No. Epic Developer Assistant is the simpler route for explanations, drafts and guided instructions. UEFN MCP is optional and intended for projects where a compatible agent needs editor and session access after additional setup.
How long are Verse runtime-error reports available?
Epic documents retention of up to 30 days for runtime-error reports in the Content Service Portal. The period is a storage limit, not a score or success rate for AI-generated code.
Can I use any MCP server with UEFN?
No. Epic’s UEFN integration has its own compatibility limits, and the documentation does not promise support for every general Unreal MCP toolset. Check the UEFN-specific compatibility information before connecting an agent.