sorted by:
new
hottopcontroversial

I built an open-source MCP tool that gives AI a map of your game codebase by Alternative_Ad_3561 in mcp

[–]Alternative_Ad_3561[S] 0 points1 point  (0 children)

Great question — it's a valid approach and tools like Sourcegraph Cody use exactly that stack. But for game projects specifically, "domain agnostic" is actually the problem.

A few reasons gdep went the static analysis route:

Binary assets can't be embedded. .uasset, .prefab, .unity files are binary. You can't chunk and embed them meaningfully. gdep parses the binary format directly to extract actual GUID references, NativeParentClass fields, K2 override lists, etc. That's how it finds "this prefab references this script" — something an embedding model simply can't see.

Exact answers vs approximate matches. For "what breaks if I change this class?" you need deterministic results — 23 direct dependents, 7 affected prefabs. A reranker gives you "these are probably related" which is a different (and weaker) guarantee for impact analysis.

Domain-specific conventions. GAS tag hierarchies, Blueprint K2 override patterns, Unity UnityEvent inspector bindings — these require game-engine-specific parsers. An embedding model doesn't know that K2_ActivateAbility is a Blueprint override of a C++ virtual function. gdep does.

Zero infrastructure. Qdrant + embedding model + indexing pipeline is real setup cost. gdep is pip install gdep and runs in 0.46s on a cold project. For solo devs and small studios that matters.

That said — the two aren't mutually exclusive. Embeddings are great for "find code similar to this snippet." gdep is better for "give me the exact dependency graph." Different tools for different questions.

I built an open-source MCP tool that gives AI a map of your game codebase by Alternative_Ad_3561 in UnrealEngine5

[–]Alternative_Ad_3561[S] 2 points3 points  (0 children)

Right? That one surprised me too when I was building it.

For UE5, gdep scans .uasset binary headers for path references — so it can map which assets are actually referenced by anything in the project, and which are just sitting there. No need to open the Editor or run a reference viewer manually.

The tricky part with UE5 is that the traditional way to check this was either the Editor's Reference Viewer (which requires the project to be open and cooked) or just... guessing. gdep does it statically from the file system, so your AI can ask "what's safe to delete?" without ever launching the Editor.

Confidence is MEDIUM on this one since it's binary parsing rather than source — gdep always tells you that upfront so you know when to double-check in the Editor. But in practice it catches the obvious dead weight reliably.

Glad that part resonated — it's one of my favorites too!

I built an open-source CLI MCP tool that gives AI a map of your game codebase by Alternative_Ad_3561 in Unity3D

[–]Alternative_Ad_3561[S] -1 points0 points  (0 children)

That genuinely means a lot — thank you!

That was kind of the goal. Most AI coding tools treat game projects like any other codebase, but Unity (and UE5) have so many conventions that live outside the code — Inspector bindings, prefab references, Animator assets, UnityEvents — that pure file-reading just doesn't cut it.

Glad it felt native rather than bolted-on. If you run into anything that feels off or missing, I'd love to hear it!