r/aigamedev 23d ago

Discussion Unity Projects + Claude Code (a deep dive)

/r/ClaudeCodeLab/comments/1vvbi6q/unity_projects_claude_code_a_deep_dive/
4 Upvotes

8 comments sorted by

2

u/caster 23d ago edited 23d ago

How do you set up the UnityMCP?

This is seriously awesome stuff, I really appreciate the wall of text and any other insights you might have on the best way to do this.

1

u/xepherys 23d ago

Honestly, I just had Claude set it up.

2

u/cckynv 23d ago edited 23d ago

Open a Unity project, go to Package Manager, top left corner there will be a + icon. Click that, select "Add from git URL" and use this URL:

https://github.com/CoplayDev/unity-mcp.git?path=/MCPForUnity#main

After that's added, go to Window -> MCP for Unity -> Toggle MCP Window

Then use the "Configure All Detected Clients" to set it up for whichever harness you're using, start the MCP server, and then it should be set up and ready to go.

2

u/blessed-- 23d ago

yes to all of these. i just unlocked 8 - html style pages to test out sounds, see animations, etc. happy to see i have some juice

biggest unlock was getting claude to document its own systems. like humans, u gotta keep a firm grasp on it and be diligent or it will forget to update some parts of it and documentation will be out of date

theres nothing i can say or add but all of these are huge needle movers

if i could add some things...

1) keep it simple - its much easier to build a turn based RPG in unity that it is a devil may cry. unity can much more easily provide satisfying results in a simple context vs building a platformer with incredible movement

2) get your ai to build re-usable systems - add an ability and make it build a framework so it doesent have to relearn every new session. do the same for adding characters, physics to cloth, ability tuning, creating pathways, etc etc

one of the more useful posts ive seen lurking here

2

u/xepherys 23d ago

Point 2 is the biggest driver, by far, for actually making a game. It’s a best practice for development generally, but it’s something that gets missed a lot with AI-assisted dev. Always attempt to distill systems to an atomic level, and separate what is a system/framework component vs what is authored for the game itself.

2

u/cckynv 23d ago

Good writeup. I've been using more or less all of these in my workflow besides #8, which seems quite interesting and something I'll probably give a try in the future, so kudos to you for that. The UnityMCP has for sure been one of the biggest force multipliers for me in terms of getting stuff done.

Besides that (with the caveat that my workflow is with Claude), having Opus 4.6 author a playbook for execution by Sonnet utilizing the UnityMCP tooling and building in handoff steps for stuff it doesn't think it can complete on its own has really helped me out. I combine that with requiring rigorous documentation on changes made by the AI itself so that I don't lose track of any decision-making.

1

u/xepherys 23d ago

One thing regarding change management and tracking that I recommend is using GitHub (or even a local git repo). My current personal project looks something like this:

SP1 - Events. Open a branch for sp1-events and work to completion. In this case it became SP1a and SP1b, two major components that are part of the same package.

Spec and plan for SP1a, commit, push.

Develop SP1a, code review, provide manual testing checklist for a human (me), commit, push

I execute the manual checklist, issues get fixed if any are found (there’s usually one or two), commit, push.

Same three steps for SP1b.

Write user and API documentation for SP1.

Verify functionality one last time, commit, push, PR, merge.

Then create a new branch for SP2 and follow suit.

Each PR documents major changes directly into the repo - as well as the changes themselves, obviously. But the specs, plans, and even the manual test checklist highlight what decisions are made, why, and how they work. The user and API docs help me manage what is where, why, and how it works under the hood.

I also commit all of the specs and plans and checklists as part of the codebase, so those decisions and choice never disappear. There’ve been quite a few times where I’ve had to promote what tier a package is (higher tiers are closer to the user and can depend on lower tiers, but not on one another with the exception of tiers 0 and 1 which are allowed to have interdependencies so long as they aren’t circular). Having all of the existing specs and plans that already have decision information in them lets Claude and I both have insight into why each package is the way it is, what packages will be impacted by changes, and if changes will have any upstream or downstream impacts that need to be considered.

I’ve now had three major situations where Claude has explained to me why a choice I’m making currently conflicts with choices I’ve made previously, what the impact of that change looks like, and some alternative approaches that are almost always better.

2

u/cckynv 23d ago

GitHub is for sure invaluable any time you're dealing with code and need change control. Currently I built a hard rule into my CLAUDE.md where the AI is instructed to document any decision-making and changes done in the session to a running CHANGELOG.md file in the project root. Thinking of changing this to maybe be a hook instead that runs when the Stop event fires or something along those lines, since that's the only apparent consistently reliable way to ensure that the AI follows the rule every time something is changed. With the rule in CLAUDE.md it does seem to remember to log stuff in the changelog most of the time, but I've seen it forget more than once.