Build a 3D RPG with Unity MCP: Third-Person Control, Combat, and Quests
A practical Unity MCP walkthrough for a playable 3D RPG prototype—third-person movement, real-time melee, enemy state machines, and quest wiring in Cursor or other MCP AI IDEs. Polish UI later when you need it.
- Unity MCP
- 3D RPG
- Unity
- combat
- AI game development
A demo-ready 3D RPG prototype usually needs these pieces first: tunable third-person move and camera, one real-time melee loop, one enemy with a small state machine, one triggerable quest or dialogue, and a HUD that shows health or quest progress. This guide follows that build order. Assume you drive an open Unity project from Cursor, Claude Code, Codex, or another MCP-capable AI IDE through Unity MCP—reading and writing scenes, GameObjects, and C#, not only pasting files onto disk.
Install and connect: Unity MCP install guide. Supported editor versions follow the product page (commonly Unity 2022.3+ / Unity 6).
Scope a minimum playable slice
Ship v1 only if you can accept:
- WASD move, mouse look, jump; ground and gentle slopes feel stable
- One melee attack (placeholder anim OK) that hits a collider and deals damage
- One enemy: patrol → detect player → chase / attack; disable or destroy on death
- One NPC: approach to talk or accept a quest; objective “defeat that enemy,” then update the log
- Simple HUD: health bar + one quest line
Block out art with primitives if needed. Treat main menu, inventory grids, polished HUD as a later UI pass (see below).
Project and MCP readiness
Before gameplay prompts:
- Unity project open; target scene can enter Play
- Unity MCP Server running; the AI IDE can list Hierarchy roots (read-only smoke)
- Baseline commit done; commit again before large edits
Read-only check:
List root GameObjects in the active scene. Do not change anything.
Only then write. Keep the bridge on localhost—do not expose the port publicly. Prompt craft: Unity MCP with Claude Code and Cursor.
Player: third-person control first
Minimal skeleton (rename to match your project):
Player
├── CharacterController or Rigidbody + CapsuleCollider
├── CameraPivot (yaw)
│ └── CameraArm (pitch) → Main Camera
└── AttackHitbox (trigger, off by default)
Be explicit about input, camera, and paths:
Create
Assets/Scripts/Player/PlayerController.cs: third-person; WASD relative to camera forward; mouse yaw/pitch (pitch clamp −30°–60°); Space to jump; attach to Player. Ground via CharacterController.isGrounded or equivalent.
Then tune feel:
Move speed ~5 with light acceleration smoothing; jump ~1.2 m; slight camera follow damping—no whip-pan.
Review slopes, air steer, and camera clipping before celebrating “script generated.”
Combat: one acceptable melee loop
Skip skill trees in v1. Goal: press attack → enable hitbox for N frames → damage → refresh HUD.
Add
PlayerCombat.cs: LMB attack, 0.6 s cooldown; enableAttackHitboxduring the window; deal 15 damage toIDamageable. Enemies implementIDamageableand current HP.
Optional still-simple upgrades:
Lock movement briefly on attack; short hitstun on enemies; 0.4 s i-frames with blink after player damage.
Raise health changes as events/callbacks so HUD binding stays clean—avoid UI scripts Find-ing the world.
Enemies: Idle / Patrol / Chase / Attack
No behavior tree required. Four states cover a field mob:
Idle → Patrol → Chase → Attack
↑________________↓ (lost target)
Create
Assets/Scripts/Enemy/EnemyAI.cs: two-point patrol; enter Chase within 12 m; Attack within 2 m (1.2 s cooldown, 8 damage); return to Patrol 3 s after losing the player; on 0 HP play death orSetActive(false).
Prefer NavMeshAgent if you already bake; otherwise simple seek/face motion so week one is not blocked on navigation. Animator optional—facing and color feedback are enough early.
Quests and NPCs: one mainline thread
“Quest feel” is trigger → track → complete, not a full quest editor.
Keep data plain:
QuestId, title, description, progress count, completed flag- NPC
Interact(E or trigger) opens dialogue andStartQuest - Enemy death calls
QuestManager.NotifyKill(enemyId)
Create a
QuestManagersingleton: acceptslay_wolf_01(defeat 1 Wolf); advance on Wolf death; update quest log copy when done. Wizard NPC: player enters trigger, press E to start that quest.
TMP/Text is fine for v1 dialogue; branches later.
HUD: placeholders first, polished UI later
While gameplay is unfinished, wire engine Slider / TMP_Text:
Bind player
OnHealthChangedto the HUD bar; bindQuestManagercurrent title to a top-screen TMP line.
When menus, inventory, or skill bars need design-grade UI (layered PSD/Figma, NL-generated panels, split and export as Unity prefabs), use a canvas workflow such as AI Studio:
- Generate or import RPG HUD / menu
- Componentize and export to e.g.
Assets/UI/ - Return to the AI IDE + Unity MCP to bind buttons, bars, and quest text to existing gameplay events
Handle hard cutouts for alpha first if needed. Structure can come from the canvas; bindings and combat logic stay in Unity via MCP—do not expect the canvas tool to author a full combat FSM.
Import detail: Figma to Unity UI.
Suggested build order
MCP: player control → one melee loop → one enemy FSM → one quest + NPC
↓
MCP: placeholder HUD wiring (HP / quest line)
↓ (optional)
Canvas tool: polished menu / HUD → export to Unity
↓
MCP: bind polished UI to existing events
Feel, numbers, AI, navigation → keep using Unity MCP.
Full-screen visual hierarchy, reskins, re-exported prefabs → return to the canvas tool.
Prompt boundaries that actually help
Vague prompts waste cycles. Pin:
- Paths and attach points — which folder, which object
- Acceptance — e.g. “within 10 s of Play, kill one wolf and see quest complete”
- Out of scope — e.g. “do not rebuild the whole input stack; do not delete the camera”
- One concern per prompt — control, then combat, then enemy
Always Play-test yourself. MCP removes repetitive clicking; it does not replace design judgment.
Acceptance checklist
- Third-person move/camera stays controllable for ~2 minutes without obvious clipping/loss of control
- Melee hits reliably; cooldown is noticeable
- Patrol vs chase is readable; death has clear feedback
- Quest can be accepted and completed; HUD copy updates
- Health changes reach the UI (placeholders OK)
Next steps
- Finish the Unity MCP install guide and a read-only smoke test
- Ship “movement + one enemy + one quest” in that order
- Add polished UI export only when the HUD must look finished
Also: Unity MCP with Claude Code / Cursor, Figma to Unity UI.
Keep reading
More guides you might like
AI Game Development in 2026: Unity and Godot MCP Without Leaving the Editor Loop
A practical map of AI-assisted Unity and Godot workflows—when MCP helps, when humans stay in charge, and how multi-engine teams share one prompting habit.
- ai-game-development
- unity-game-development
- godot-game-engine
- unity-mcp
Godot MCP vs Manual Scripting: When AI Engine Control Makes Sense
A practical decision guide: use VberAI Godot MCP for prototypes and boilerplate, keep hand-written GDScript for hot paths—grounded in Godot scene and signal practices.
- godot-mcp
- vberai
- comparison
- GDScript
Unity MCP Install Guide: Add Package from Disk and Connect an AI IDE
Install VberAI Unity MCP Pro step by step—Package Manager Add package from disk, activate your account, start the local MCP Server (default port 6589), and verify the connection in Cursor, Claude, Codex, or other MCP-capable AI IDEs.
- unity
- mcp
- cursor
- tutorial