Costruisci un RPG 3D con Unity MCP: Controllo in Terza Persona, Combattimento e Missioni

Un prototipo RPG 3D pronto per la demo di solito richiede prima questi elementi: movimento in terza persona e camera regolabili, un loop di combattimento corpo a corpo in tempo reale, un nemico con una piccola macchina a stati, una missione o dialogo attivabile, e un HUD che mostri salute o avanzamento missione. Questa guida segue questo ordine di costruzione. Supponiamo che tu guidi un progetto Unity aperto da Cursor, Claude Code, Codex, o un altro IDE AI con capacità MCP tramite Unity MCP—leggendo e scrivendo scene, GameObject e C#, non solo incollando file su disco.

Installa e connetti: Guida all’installazione di Unity MCP. Le versioni supportate dell’editor seguono la pagina del prodotto (comunemente Unity 2022.3+ / Unity 6).

Definisci una fetta minima giocabile

Rilascia la v1 solo se puoi accettare:

1. Movimento WASD, look con mouse, salto; terreno e pendenze dolci stabili
2. Un attacco corpo a corpo (animazione segnaposto OK) che colpisce un collider e infligge danno
3. Un nemico: pattuglia → rileva il giocatore → insegue / attacca; disabilita o distruggi alla morte
4. Un NPC: avvicinati per parlare o accettare una missione; obiettivo “sconfiggi quel nemico”, poi aggiorna il registro
5. HUD semplice: barra della salute + una riga di missione

Blocca l’arte con primitive se necessario. Tratta menu principale, griglie di inventario, HUD rifinito come una fase UI successiva (vedi sotto).

Progetto e prontezza MCP

Prima dei prompt di gameplay:

• Progetto Unity aperto; la scena target può entrare in Play
• Unity MCP Server in esecuzione; l’IDE AI può elencare le radici della Hierarchy (smoke test di sola lettura)
• Commit di base fatto; fai un altro commit prima di modifiche grandi

Controllo di sola lettura:

Elenca i GameObject radice nella scena attiva. Non cambiare nulla.

Solo dopo scrivi. Mantieni il bridge su localhost—non esporre la porta pubblicamente. Craft dei prompt: Unity MCP con Claude Code e Cursor.

Giocatore: controllo in terza persona prima

Scheletro minimo (rinomina per adattarlo al tuo progetto):

Player
├── CharacterController o Rigidbody + CapsuleCollider
├── CameraPivot (yaw)
│   └── CameraArm (pitch) → Main Camera
└── AttackHitbox (trigger, disattivato di default)

Sii esplicito su input, camera e percorsi:

Crea Assets/Scripts/Player/PlayerController.cs: terza persona; WASD relativo alla direzione della camera; yaw/pitch del mouse (clamp pitch −30°–60°); Spazio per saltare; attacca a Player. Ground tramite CharacterController.isGrounded o equivalente.

Poi regola la sensazione:

Velocità di movimento ~5 con leggera accelerazione smoothing; salto ~1.2 m; leggero damping della camera—niente whip-pan.

Rivedi pendenze, sterzo in aria e clipping della camera prima di celebrare “script generato”.

Combattimento: un loop corpo a corpo accettabile

Salta gli alberi delle abilità nella v1. Obiettivo: premi attacco → abilita hitbox per N frame → danno → aggiorna HUD.

Aggiungi PlayerCombat.cs: attacco con LMB, cooldown 0.6 s; abilita AttackHitbox durante la finestra; infliggi 15 danni a IDamageable. I nemici implementano IDamageable e HP corrente.

Upgrade opzionali ma semplici:

Blocca brevemente il movimento durante l’attacco; breve hitstun sui nemici; 0.4 s di i-frame con blink dopo il danno al giocatore.

Solleva i cambi di salute come eventi/callback per mantenere pulito il binding HUD—evita script UI che fanno Find del mondo.

Nemici: Idle / Patrol / Chase / Attack

Nessun albero comportamentale richiesto. Quattro stati coprono un mob da campo:

Idle → Patrol → Chase → Attack
         ↑________________↓ (bersaglio perso)

Crea Assets/Scripts/Enemy/EnemyAI.cs: pattuglia a due punti; entra in Chase entro 12 m; Attack entro 2 m (cooldown 1.2 s, 8 danni); ritorna a Patrol 3 s dopo aver perso il giocatore; a 0 HP esegui morte o SetActive(false).

Preferisci NavMeshAgent se già fai il bake; altrimenti semplice movimento seek/face per non bloccare la prima settimana sulla navigazione. Animator opzionale—facing e feedback colore sono sufficienti all’inizio.

Missioni e NPC: una linea principale

La “sensazione di missione” è trigger → traccia → completa, non un editor di missioni completo.

Mantieni i dati semplici:

• QuestId, titolo, descrizione, contatore progresso, flag completato
• NPC Interact (E o trigger) apre dialogo e StartQuest
• Morte nemico chiama QuestManager.NotifyKill(enemyId)

Crea un singleton QuestManager: accetta slay_wolf_01 (sconfiggi 1 Lupo); avanza alla morte del Lupo; aggiorna il testo della missione quando completata. NPC Wizard: il giocatore entra nel trigger, premi E per iniziare quella missione.

TMP/Text va bene per il dialogo v1; rami più tardi.

HUD: segnaposto prima, UI rifinita dopo

Mentre il gameplay è incompleto, collega Slider / TMP_Text del motore:

Collega OnHealthChanged del giocatore alla barra HUD; collega il titolo corrente di QuestManager a una riga TMP in alto.

Quando menu, inventario o barre delle abilità richiedono UI di livello design (PSD/Figma a livelli, pannelli generati da NL, divisi ed esportati come prefab Unity), usa un workflow canvas come AI Studio:

1. Genera o importa HUD / menu RPG
2. Componentizza ed esporta in e.g. Assets/UI/
3. Torna all’IDE AI + Unity MCP per collegare bottoni, barre e testo missione agli eventi di gameplay esistenti

Gestisci prima i ritagli duri per l’alpha se necessario. La struttura può venire dal canvas; i binding e la logica di combattimento restano in Unity tramite MCP—non aspettarti che lo strumento canvas scriva una FSM di combattimento completa.

Dettaglio import: Figma to Unity UI.

Ordine di costruzione suggerito

MCP: controllo giocatore → un loop corpo a corpo → una FSM nemico → una missione + NPC
        ↓
MCP: wiring HUD segnaposto (HP / riga missione)
        ↓ (opzionale)
Strumento canvas: menu / HUD rifinito → esporta in Unity
        ↓
MCP: collega UI rifinita agli eventi esistenti

Sensazione, numeri, AI, navigazione → continua a usare Unity MCP.
Gerarchia visiva a schermo intero, reskin, prefab riesportati → torna allo strumento canvas.

Limiti dei prompt che aiutano davvero

I prompt vaghi sprecano cicli. Fissa:

• Percorsi e punti di attacco — quale cartella, quale oggetto
• Criteri di accettazione — e.g. “entro 10 s da Play, uccidi un lupo e vedi missione completata”
• Fuori scope — e.g. “non ricostruire l’intero stack di input; non cancellare la camera”
• Un solo aspetto per prompt — controllo, poi combattimento, poi nemico

Fai sempre Play-test da solo. MCP rimuove i clic ripetitivi; non sostituisce il giudizio di design.

Checklist di accettazione

• Movimento/camera in terza persona rimane controllabile per ~2 minuti senza clipping evidente o perdita di controllo
• Il corpo a corpo colpisce in modo affidabile; il cooldown è evidente
• Pattuglia vs inseguimento è leggibile; la morte ha feedback chiaro
• La missione può essere accettata e completata; il testo HUD si aggiorna
• I cambi di salute raggiungono la UI (segnaposto OK)

Prossimi passi

1. Completa la Guida all’installazione di Unity MCP e un smoke test di sola lettura
2. Rilascia “movimento + un nemico + una missione” in quest’ordine
3. Aggiungi l’esportazione UI rifinita solo quando l’HUD deve apparire finito