Claude Code for Unity Game Development: Practical

Unity MCP: bringing scene operations into the loop

Unity's MCP (Model Context Protocol) server lets Claude Code drive the editor itself. Concretely, it exposes:

• listing GameObjects in the active scene
• creating GameObjects, adding components
• reading and writing Inspector fields, marking as Prefab
• invoking menu commands (e.g., File > Build Settings)
• streaming Console logs

Setup goes through Unity Package Manager:

# 1. Add to Packages/manifest.json:
{
  "dependencies": {
    "com.unity.mcp.server": "1.x.x"
  }
}
 
# 2. Register the bridge in Claude Code:
claude mcp add unity-editor \
  --command "node" \
  --args "/path/to/unity-mcp-bridge/index.js" \
  --env UNITY_PROJECT_PATH=/path/to/your/project

The tool I rely on most heavily is "list scene objects, then read the components on this specific one." Once that exists, the cost of explaining your scene structure to Claude drops to nearly zero.

A real example: "Change the player's move speed from 5.0 to 7.5, and add an accelerometer-based fine adjustment." Claude Code now runs:

1. Calls unity_get_scene_objects to find the Player
2. Reads the existing PlayerMovement script
3. Updates moveSpeed to 7.5
4. Creates a new IAccelerometerInput interface
5. Refactors PlayerMovement to use it
6. Wires up the SerializeField references via Inspector
7. Runs PlayMode tests to confirm behavior

Zero human intervention until step 7's report. In web terms, that's the difference between "AI writes code" and "AI writes code, deploys to staging, and runs smoke tests."

Tactical tips for higher-quality C# generation

Be explicit about MonoBehaviour lifecycle

MonoBehaviour has many entry points: Awake, Start, OnEnable, Update, FixedUpdate, LateUpdate. Claude leans web — it puts everything in Start. Telling it "init in Awake, register listeners in OnEnable, unregister in OnDisable" sharply improves output quality.

Pin down namespaces

A common failure: it writes using UnityEngine; and forgets UnityEngine.UI or UnityEngine.InputSystem. Document which UI and input frameworks the project uses in CLAUDE.md so the imports come out right.

Push values into ScriptableObjects

Game balance numbers (jump force, enemy HP, item duration) hurt later when they're hardcoded. Tell Claude up front: "Tunable parameters belong in ScriptableObjects, not literals."

Closing the loop on builds

Unity MCP's execute_menu_item lets Claude trigger File > Build And Run. Full device deployment still needs Xcode/Android Studio handoff, but whether the build itself succeeds is automatable.

The loop I run looks like:

1. Claude implements the feature
2. Writes a PlayMode test, verifies in-editor
3. Validates Player Settings via unity_execute_menu_item
4. Pulls Console logs on build error, asks Claude to fix
5. Build And Run on success

After this cycle, the only thing I personally check is how the game feels on the device. Knowing that compile errors will be caught and fixed by AI is, on its own, a different developer experience.

Editor extensions: a surprising sweet spot

Custom editor windows — balancing panels, level editors, debug tools — eat real time in Unity work. Claude Code writes them surprisingly well. Ask for "an EditorWindow that lists enemy ScriptableObjects and lets me edit them in place" and you get appropriate SerializedObject and EditorGUILayout usage out of the box. Think of it as the same thing as asking it to scaffold an admin panel in a web app — it's just an internal tool with different APIs.

Things to avoid

A few patterns to keep away from.

Hand-written HLSL shaders are risky. Skip Shader Graph and ask Claude to write raw HLSL, and you'll get pipeline mismatches and version-specific code that doesn't compile. Build the shader in Shader Graph and let Claude write only the Custom Function Node body.

Don't let Claude bulk-edit asset import settings. A request like "compress all textures to ASTC" via AssetImporter can hit assets you didn't intend. Always narrow the scope first.

Don't ask Claude to edit .unity scene files directly. They're YAML, but they are not human-edit-safe. If Claude proposes editing a .unity file, stop and switch to operating through the editor.

Verifying Without Opening the Editor — Unity Batch Mode

The Unity MCP verification in the previous section assumes the Editor is running. But when I want to fold a compile check into an overnight automation, or just confirm the code compiles without opening the GUI, I reach for a different path.

Unity ships a headless -batchmode that launches from the command line with no editor window. Add -runTests and it will run your EditMode tests headlessly too.

# Compile + run EditMode tests headlessly
"/Applications/Unity/Hub/Editor/6000.0.30f1/Unity.app/Contents/MacOS/Unity" \
  -batchmode -quit \
  -projectPath "$PWD" \
  -runTests -testPlatform EditMode \
  -testResults "$PWD/TestResults/editmode.xml" \
  -logFile "$PWD/Logs/unity-batch.log"

With -quit, Unity closes itself once the run finishes. Any compile error lands in -logFile at that point, so there's no need to open the Editor and read the console by eye.

From Claude Code, the practical move is to wrap this in a thin script and let it run after each change. I keep something like this and call it on every implementation pass.

#!/usr/bin/env bash
# run-unity-tests.sh — return only the failures to Claude
set -euo pipefail
UNITY="/Applications/Unity/Hub/Editor/6000.0.30f1/Unity.app/Contents/MacOS/Unity"
"$UNITY" -batchmode -quit -projectPath "$PWD" \
  -runTests -testPlatform EditMode \
  -testResults "$PWD/TestResults/editmode.xml" \
  -logFile "$PWD/Logs/unity-batch.log" || true
 
if grep -q 'result="Failed"' "$PWD/TestResults/editmode.xml" 2>/dev/null; then
  echo "=== FAILED TESTS ==="
  grep -A2 'result="Failed"' "$PWD/TestResults/editmode.xml"
  exit 1
fi
echo "All EditMode tests passed."

Only when this returns exit 1 do I hand the failing cases back to Claude Code to fix. Passing just the failures — rather than the whole log every time — keeps the exchange fast and doesn't burn tokens.

I use the two paths for different jobs: MCP verification for "how does this behave inside the Editor right now," and batch mode for "compile and test the logic without opening the Editor at all." Running the Dolice apps solo as an indie developer, that two-tier split is exactly what holds up in overnight automation.

What to do first

If you only try one thing from this guide, install Unity MCP. Everything else can wait. The moment Claude can see and operate the scene, conversations stop being "let me describe the hierarchy" and become "do the thing." That single shift is what makes AI pair programming in Unity feel real.

After that, fill in CLAUDE.md with your project's actual conventions, libraries, and naming rules. The output quality is roughly proportional to how complete that file is.