Giving an AI Agent a Map of Your Unreal Project's C++ and Blueprints

Why AI agents navigate Unreal projects blind

Drop an AI coding agent into a mature Unreal project and watch it flounder. The codebase is a sprawl of C++ modules, header soup, generated reflection glue, and a parallel universe of Blueprints that inherit from native classes the agent cannot see by reading source alone. A general-purpose agent treats the repository as a flat bag of text files, greps for a symbol, and hopes the first hit is the one that matters. On a small project that is survivable. On a real game, with hundreds of source files and Blueprint hierarchies several layers deep, it produces confident edits in the wrong place.

The core problem is that an Unreal project is not just files. It is a graph: modules depend on other modules through their build rules, classes inherit from classes across that module boundary, and Blueprint assets sit on top of native C++ parents that only the editor truly knows about. If you want to help an AI understand a large Unreal codebase, you cannot just hand it the folder. You have to hand it the structure — a repo map for UE5 that tells the agent which files matter, how the modules connect, and where each Blueprint actually comes from.

This is exactly the orientation problem MythicDevAssist (MDA) was built to solve. MDA is an agent-native editor bridge for Unreal Engine 5: it runs inside the editor process as an Engine Subsystem, exposes a loopback HTTP server, and gives external agents like Claude Code, Cursor or Codex a way to ask the editor structured questions instead of guessing. Among its action routes is repo_map, a ranked, structured source map designed to be the first thing an agent reads before it edits anything. The rest of this article walks through what a useful map actually contains and how MDA assembles one.

Start with the module map from .Build.cs dependency graphs

Before an agent reasons about a single class, it needs to know the shape of the project at the module level. In Unreal, every module declares its dependencies in a .Build.cs file — the PublicDependencyModuleNames and PrivateDependencyModuleNames lists are the ground truth for what links against what. Parsing those files yields a directed dependency graph: which of your modules depend on the engine's, which depend on each other, and where the natural seams of the codebase are.

That graph is enormously valuable to an agent because it constrains where a change can legally live. If a class belongs in a module that does not depend on Niagara, the agent should not reach for a Niagara type there. If two of your gameplay modules are siblings with no dependency edge between them, the agent knows not to introduce a direct include across that boundary. MDA builds its module map from exactly these .Build.cs dependencies, so the agent inherits the same mental model a senior engineer carries: the project as a small set of connected modules, not an undifferentiated pile of cpp files.

Practically, you want the module map first because it scopes everything that follows. Once the agent knows the modules and their edges, file ranking and Blueprint resolution both become questions asked within a module rather than across an entire repository.

Rank the source files by UCLASS, USTRUCT and UFUNCTION weight

A flat file listing tells an agent nothing about importance. A header that declares a central gameplay UCLASS deserves far more attention than a one-off utility with a couple of free functions, yet on disk they look the same. The trick is to rank source files by the density and kind of Unreal reflection declarations they contain, so the most structurally significant files float to the top of the map.

MDA's repo_map does this with a PageRank-style weighting over the reflection markers it parses from your source. Each declaration carries a weight that reflects how architecturally load-bearing it tends to be. A UCLASS is weighted 10 — it is the heaviest signal, because a class declaration usually anchors a meaningful unit of behaviour. A USTRUCT or UINTERFACE is weighted 8. A UENUM is weighted 6. A UFUNCTION is weighted 2, a UPROPERTY is weighted 1, and a class that inherits from another contributes 3 for the inheritance relationship itself. Summing those weights per file gives a score that ranks files by how much real structure they hold rather than by line count or filename.

The payoff is focus. Instead of the agent reading files in alphabetical or directory order, it reads them in order of structural relevance: the headers that define your core actors, components and interfaces first, the leaf utilities last. When an agent has a limited context window — and they all do — spending it on the ten highest-ranked files in the relevant module is a far better bet than reading the project front to back. This is how you help an AI understand a large Unreal codebase without drowning it in tokens.

Because the ranking is built from the reflection system Unreal already relies on, it stays meaningful as the project grows. The files that accumulate the most UCLASS, USTRUCT and UFUNCTION declarations are, almost by definition, the ones a developer keeps coming back to — and now the agent comes back to them too.

Resolve the Blueprint hierarchy from the Asset Registry

Source ranking covers the C++ half of the project. The other half — for most teams the larger half by volume of gameplay logic — lives in Blueprints, and Blueprints are invisible to anything that only reads text. A Blueprint asset is a binary uasset; its parent class, the native C++ class it ultimately derives from, and its place in an inheritance chain are not sitting in a header for the agent to grep. They live in the editor's Asset Registry, the same index the Content Browser uses to know what exists in your project.

MDA closes this gap by querying that Asset Registry directly. For a Blueprint, its hierarchy lookup returns the parent_class and native_parent_class chains — so the agent can see that BP_Enemy derives from a Blueprint base which in turn derives from a native ACharacter subclass, and trace that lineage all the way down to C++. That is the missing link between the Blueprint world and the source map: it lets the agent connect a Blueprint it has been asked to modify back to the exact native class it should read in the ranked source list.

The same Asset Registry backing powers MDA's mda_asset search, which runs queries against the registry with parent-chain and dependency information attached. Because it is the very index the Content Browser reads, the results reflect what the editor actually believes exists — not a stale offline scrape that drifts the moment someone reparents a Blueprint. An agent oriented this way understands both halves of your project: the C++ it can read, and the Blueprints it cannot, joined by their shared inheritance chains.

Putting the map to work before the agent edits

The three pieces compose into a single orientation pass. The module map from .Build.cs gives the agent the territory. The ranked source files tell it which C++ to read first within that territory. The Asset Registry hierarchy connects every Blueprint back to its native parent so nothing in the project is opaque. Run that pass before any editing task and the agent stops guessing about where code lives.

MDA exposes repo_map as one of its HTTP action routes inside the editor, alongside structured search for actors and assets, so the curated MCP tool surface and a direct HTTP integration both reach it. In practice an agent asks for the map once at the start of a session, uses it to decide which files and classes are relevant, and only then proposes changes — the same way a careful human reads themselves into an unfamiliar codebase before touching it.

If you are wiring an AI agent into a UE5 project, start here: give it the map, not the maze. Enable MythicDevAssist, point your agent's MCP client at the bridge, and have it pull a repo map before its first edit. The orientation it gains — modules, ranked source, Blueprint lineage — is the difference between an agent that edits with intent and one that edits with hope.

Reflection-declaration weights in the ranked repo map

Per-file scores sum these weights to rank source files by structural significance, heaviest signal first.

FAQ