Example 3 — PIE Test Automation

Difficulty: Intermediate  ·  Time: 10–15 minutes  ·  What you’ll learn: Using Claude Code to run a Play-In-Editor smoke test, inspect what’s really in a level, and answer “is this safe to commit?” — all from natural language, without touching the editor UI.

Prerequisites

Overview

A quick pre-commit gut-check you can run before saving your work:

  1. Smoke-test the level in PIE (does it load and play without errors?)
  2. Inventory what is actually in the level
  3. Capture a clean screenshot
  4. Get a plain yes/no on whether it is safe to commit

Step 1 — Smoke-test in PIE

Save the level, run it in Play-In-Editor to confirm it loads and plays, then stop.

Claude drives the PIE lifecycle as discrete calls:

  1. level.save_current_level — never PIE on unsaved changes
  2. pie.start — begins the session (the editor shows the orange PIE border)
  3. pie.is_active — confirms it actually came up
  4. pie.execute_console_command (e.g. stat unit) — proves the live world is ticking
  5. pie.end — clean shutdown

Why discrete calls and not a single recipe? pie.start returns immediately, but PIE becomes active a moment later. Driving the steps as separate calls gives PIE time to spin up between them, so pie.is_active reports truthfully. If a level fails to load (Blueprint compile error, missing asset), pie.is_active comes back false and Claude reports the failure instead of a green light.

Step 2 — Inventory the level

Show me everything that's actually in this level.

Claude calls level.list_actors, and can also read the live wb://level/actors resource directly — the plugin exposes the level as a resource Claude can read at any time:

Read the wb://level/actors resource and confirm there's a PlayerStart.

This is how Claude reports the real contents (props, lights, a valid spawn point) from the running editor rather than from memory.

Step 3 — Capture a clean screenshot

Switch to game view, take a high-res screenshot, and read it back.

Claude enables Game View (hides editor gizmos), positions the camera, runs console.execute_command with HighResShot 1920x1080 filename="<abs path>", forces a redraw, polls for the file, and reads the image back inline so it can see the result.

Tip: if the editor is backgrounded and the shot never appears, run Slate.bAllowThrottling 0 once — a backgrounded editor throttles rendering and defers the capture.

Step 4 — The verdict

Given all that, is this level safe to commit? Give me a plain yes/no.

Claude synthesises the run — saved cleanly, PIE started and ran, expected actors present (including a working PlayerStart), screenshot captured — into a clear answer, flagging anything it noticed. It has only checked the level; committing stays your call (Claude won’t run git unless you ask).

What just happened

Tools & recipes used

Tool / recipe Description
pie.start / pie.is_active / pie.end Drive the PIE lifecycle as discrete, reliable steps
pie.execute_console_command Run a console command inside the live PIE world
level.list_actors + wb://level/actors Inventory the level (command and live resource)
pie-with-cleanup One-call PIE-a-command-then-clean-up when you don’t need a separate active check

Going further