What makes Unreal different
Unreal splits a project across C++ source modules, configuration files and a content directory of binary assets. Levels, Blueprints, materials and most gameplay data live in those binary files. They cannot be diffed or edited as text.
Builds are heavy. Compiling, cooking and packaging run through Unreal's own build tooling and can take a long time on large projects. Automation tests run inside the engine. None of this can happen on a machine without the engine installed.
This puts a hard edge on what any AI tool can do from the outside. Source code and configuration are reachable. Anything in the content directory is reachable only through the editor.
Where agents fit in an Unreal codebase
C++ gameplay modules, plugins, build scripts and configuration are good targets. An agent can implement a component or subsystem against written acceptance criteria, refactor a module, or fix a defect, and deliver it as a diff for review.
Read-only work is useful too. An agent can map modules and their dependencies from build files, summarize the architecture for a new team member, or turn a design document into a structured list of mechanics and tasks.
Blueprint logic is the gap. Since Blueprints are binary assets, an agent working on files cannot read or change them. Teams with Blueprint-heavy gameplay should expect less from file-based automation than teams with gameplay in C++.
Editor operations and their risks
To work on levels and assets, an agent needs tools that run inside the Unreal editor: list levels, inspect actors and their properties, set a property inside an editor transaction, spawn an actor, save the level. Paths should be confined to the project's content root and types checked before a write.
Each of these should be a separately granted tool. Inspection is low risk. Modification changes shared binary files that cannot be merged, so it should be granted deliberately and its calls recorded.
Builds and automation tests add cost. They need a provisioned engine worker with the right engine version, and they are slow enough that budgets and time limits matter. Ask what a tool has run on a real Unreal installation before trusting claims here.
Where PWR stands on Unreal
PWR discovers Unreal projects from the project file, module build files, engine configuration and content directory counts. It never opens level or asset payloads. The result is a profile with suggested validation settings.
Agents can change C++ source and configuration through the PWR pull request workflow, with independent review and human approval. PWR does not compile the project or run Unreal automation tests.
An Unreal editor plugin implementing the bridge is written, and the PWR side of the protocol is tested against a simulated bridge. The plugin has never been loaded by an Unreal editor. Level edits, automation tests, builds and screenshots through Unreal are upcoming. Frame-time sampling is not wired at all.
- Today: discovery, validation profile, C++ and config changes as reviewed pull requests, planning
- Upcoming: editor plugin, automation tests, build and cook, screenshots