Sviluppo giochi Unity con AI

Inizia dal contratto del progetto esistente

Identifica editor Unity, percorso del progetto, piattaforma target, pacchetti e configurazione di rendering selezionati prima di dare all'agente accesso in scrittura. Conserva versione del progetto e lock delle dipendenze nel record dell'esperimento. Conferma che l'operatore possieda accesso all'editor e moduli target necessari: l'accesso al modello non può fornire questi prerequisiti.

Definisci una piccola scena giocabile usando le convenzioni del progetto. Se il team ha già un character controller o un'astrazione dell'input, chiedi all'agente di ispezionarlo prima di proporre una sostituzione. Questo rende rivedibili le modifiche generate e impedisce a un prototipo apparentemente isolato di bypassare sistemi da cui dipende il resto del gioco.

Tratta l'automazione dell'editor come una connessione separata

Il progetto Unity MCP di CoplayDev espone operazioni dell'editor a client compatibili. La guida d'installazione descrive un pacchetto editor e una connessione server. Il servizio modello dell'agente è separato: cambiare le credenziali del modello non ripara un'istanza editor non disponibile.

Inizia con un'ispezione read-only del progetto e conferma quale istanza aperta riceve la richiesta. Limita le approvazioni delle mutazioni a una scena usa-e-getta o a una funzione esplicitamente posseduta. Una risposta positiva dello strumento significa che l'operazione si è completata al proprio confine; la scena risultante può comunque avere riferimenti errati o fallire durante il gioco. La guida MCP dedicata copre controlli di connessione e registrazione delle versioni.

Richiedi modifiche circoscritte con esiti visibili

Dopo ogni errore chiedi una modifica al controller, una transizione del menu o una piccola funzione di persistenza, invece di riscrivere una scena intera. Dichiara cosa deve fare il giocatore, quale stato deve cambiare e come osserverai il risultato. Conserva lo stato funzionante precedente prima di accettare modifiche generate.

Usa il brief illustrativo sotto per definire una modifica limitata e i criteri di revisione. Per scene e prefab, ispeziona riferimenti agli oggetti e stato salvato oltre ai diff degli script; un file sorgente da solo può non contenere la configurazione che determina il gameplay. Chiedi all'agente di identificare gli oggetti interessati prima di modificarli.

Inspect the selected project and its existing input and controller code.
Add one restart transition to the owned gameplay scene.
Keep package versions and rendering settings unchanged.
Report changed scripts, scene references, and the verification performed.
Stop before package downloads, purchases, external uploads, or publishing.

Aspetta la compilazione prima di interpretare il gameplay

Tieni separati compilazione del codice, prontezza dell'editor e gameplay nel log delle osservazioni. Se la compilazione fallisce, cattura il primo errore rilevante e il contesto del sorgente cambiato. Non chiedere di regolare il movimento mentre l'editor non può caricare gli script previsti: produrrebbe altre modifiche su una baseline non valida.

Dopo la compilazione, controlla componenti e riferimenti attesi prima di entrare in Play. Riproduci la stessa azione del giocatore dopo una correzione. Una console senza errori è una prova utile, ma il gioco deve comunque raggiungere lo stato previsto. Modifiche ripetute che non cambiano il sintomo dovrebbero attivare una riproduzione più piccola e non una sostituzione più grande.

Usa deliberatamente il framework di test del progetto

Unity Test Framework documenta selezione dei test da riga di comando e output dei risultati. L'esempio presuppone che il framework sia già configurato e che esista la directory dei risultati. UNITY_BIN e PROJECT sono variabili shell illustrative che puntano a editor e progetto esistenti. Abbina la documentazione alla versione installata del pacchetto.

Esegui controlli EditMode per la logica isolata appropriata e controlli PlayMode per il comportamento che richiede esecuzione. Queste categorie non sostituiscono la revisione pratica dei controlli e della presentazione. Conserva conteggi, fallimenti e file di risultato con la revisione sotto test. Un run che non trova test non dimostra che il gioco passi.

UNITY_BIN="/absolute/path/to/Unity"
PROJECT="/absolute/path/to/project"
"$UNITY_BIN" -batchmode -projectPath "$PROJECT" \
  -runTests -testPlatform EditMode \
  -testResults "/absolute/existing-results-dir/editmode.xml" \
  -logFile "/absolute/existing-results-dir/editmode.log"

Rivedi gli input di build prima di produrre il player

Una build dovrebbe usare selezione delle scene e configurazione target revisionate dal progetto. Non presumere che la scena attualmente aperta nell'editor sia quella inclusa all'avvio. Conserva identità della build e log, così gli errori successivi possono essere associati all'artefatto esatto.

La CLI Unity supporta la chiamata di un metodo statico dell'editor esistente con -executeMethod. Quel flag non crea un'implementazione di build: il progetto necessita di un metodo reale con comportamento di build e gestione dei fallimenti espliciti. Preferisci l'entry point di build esistente del team a metodi d'esempio inventati che sembrano eseguibili ma non esistono nel progetto.

Valida il gameplay fuori dall'editor

Testa il player distribuito sul sistema operativo dichiarato con i controlli previsti e uno stato iniziale pulito. Entra dalla prima schermata, completa un round, riavvia, cambia le impostazioni e rilancia. Confronta persistenza e transizioni con il brief di accettazione, non limitarti a verificare che si apra una finestra.

Registra screenshot autentici e una breve sequenza guidata dall'input da quell'artefatto. Se il run dell'editor passa ma la build fallisce, ispeziona inclusione delle scene, dipendenze delle risorse e comportamento specifico della piattaforma prima di chiedere all'agente di riscrivere il gameplay centrale. Il confine che è cambiato è un indizio utile sulla causa.

Traccia lavoro umano e dipendenze irrisolte

Conserva modifiche manuali nell'Inspector, edit degli asset, istruzioni aggiunte e riparazioni dell'ambiente nel record degli interventi. Fanno parte dello sforzo di produzione anche quando non generano utilizzo del modello. Separa chiamate di coding testuale, generazione d'immagini, lavoro sull'engine e test sul dispositivo target quando rivedi il costo.

Questo walkthrough basato sulla documentazione dovrebbe essere validato rispetto alle versioni di editor e pacchetti scelte. Mantieni nella consegna il workflow completo più piccolo: connessione, modifica, compilazione, play ed export. Quando un altro sviluppatore può ripeterlo, usa quella baseline per la funzione successiva e ripeti il controllo ogni volta che cambiano dipendenza o target di build.

Domande frequenti