Sviluppo giochi Godot con AI

Definisci il confine del progetto prima delle modifiche

Parti da una directory di progetto di tua proprietà e da un elenco scritto delle modifiche consentite. Inventaria scene, script, asset e plugin esistenti, così l'agente può estendere la struttura corrente invece di creare una seconda implementazione. Mantieni recuperabile lo stato iniziale e registra quale binario dell'engine lo apre.

Scegli una porzione giocabile modesta con transizioni esplicite. Per esempio, una schermata titolo che porta a una stanza e torna indietro dopo vittoria o sconfitta offre un test ripetibile. Decidi chi rivede composizione visiva e controlli, perché né un parser riuscito né il messaggio di completamento del modello dimostrano che l'esperienza sia coerente.

Identifica l'eseguibile e gli argomenti supportati

La documentazione CLI stabile di Godot fornisce i comandi seguenti. GODOT_BIN e PROJECT sono variabili shell scelte per questo esempio, non impostazioni Godot; sostituisci i percorsi placeholder con eseguibile e progetto esistenti. Il percorso del progetto deve contenere project.godot.

Cattura versione e output help prima di aggiungere flag allo script. Eviti così di dare per scontato che un comando presente nella documentazione online corrente esista nella build installata. Registra l'identità del binario con i risultati di test successivi e mantienila stabile mentre indaghi un errore. Questi comandi illustrativi usano le forme CLI documentate.

GODOT_BIN="/absolute/path/to/godot"
PROJECT="/absolute/path/to/project"
"$GODOT_BIN" --version
"$GODOT_BIN" --help
"$GODOT_BIN" --headless --path "$PROJECT" --import

Separa import, parsing e gioco reale

Un import headless controlla un confine di elaborazione degli asset. Un controllo del parser esamina uno script. Un avvio normale raggiunge il gioco e può rivelare cablaggio delle scene e problemi runtime. Mantieni separati questi esiti nel record di revisione invece di riassumerli tutti come test superati.

Il percorso dello script illustrativo deve già esistere nel progetto. Un controllo del parser è intenzionalmente limitato: non dimostra collisioni funzionanti, input reattivo o persistenza corretta. Dopo una modifica, riproduci il comportamento che cambia e la transizione immediatamente prima e dopo. Spesso è più informativo che creare numerosi controlli isolati per funzioni helper generate.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --script res://scripts/player.gd --check-only
"$GODOT_BIN" --path "$PROJECT" --debug

Scegli consapevolmente strumenti CLI o MCP

Un agente capace di shell può eseguire una sequenza CLI revisionata. Godot MCP è un'interfaccia aggiuntiva gestita dal progetto, con setup descritto nella pagina dedicata. In entrambi i casi, l'operatore deve sapere quale progetto è target prima di approvare una scrittura o l'avvio di un processo.

Mantieni separate le impostazioni del provider del modello dell'agente dagli strumenti dell'engine. Una connessione locale funzionante non dimostra che un determinato modello sia disponibile o che l'agente supporti ogni funzione di un gateway compatibile. Stabilisci prima la lettura minima consentita, poi una modifica di scena reversibile e solo dopo un ciclo di gameplay completo in un esperimento autorizzato.

Dai ai fallimenti sufficiente contesto di scena

Quando un'interazione fallisce, cattura albero della scena, script, azione d'input e primo errore runtime significativo. Spiega la transizione attesa e lo stato osservato. Un report secondo cui il giocatore non si muove dovrebbe dire se il gioco ha il focus, se l'input viene rilevato e se cambia la posizione del giocatore.

Richiedi una correzione proposta piccola con una spiegazione legata a quelle prove. Dopo averla applicata, ripeti la stessa azione e controlla regressioni in riavvio e transizioni di scena. Non accettare una riparazione solo perché l'errore è scomparso: disabilitare la funzione interessata può rimuovere un errore lasciando insoddisfatto il requisito originale.

Prepara esplicitamente i prerequisiti dell'export

Un export richiede un preset coerente e template di export installati. Rivedi export_presets.cfg e inclusione delle risorse prima della build. Mantieni private le credenziali d'export. Il nome del preset nell'esempio è illustrativo e deve corrispondere al progetto; la directory di output deve già esistere.

Tratta template o preset mancante come problema d'ambiente, non come prova che la logica di gioco generata sia errata. Conserva log dell'export e hash dell'artefatto, così i rilievi della piattaforma target si riferiscono a una build precisa. Un export riuscito è un checkpoint importante, ma non dimostra che il player distribuito avvii o completi un round.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --export-release "Windows Desktop" "/absolute/existing-build-dir/game.exe"

Esegui un miniflow di delivery sul target

Avvia il gioco esportato sul sistema operativo che intendi supportare. Testa avvio, input, round completo, riavvio, impostazioni e persistenza dopo il rilancio. Per ogni risultato conserva identità dell'artefatto, contesto del dispositivo ed esito osservato. Un export creato su macOS non verifica da solo il comportamento Windows.

Per un target web, ispeziona anche caricamento del browser ed errori runtime ed esercita il canvas con input reale. Verifica che il contenuto sia visibile e si muova quando previsto. Testa la configurazione di hosting prevista, senza presumere che un run locale dell'editor copra caricamento delle risorse nel browser e restrizioni della piattaforma.

Un progetto sorgente e una cattura nativa da ispezionare

L'esempio locale Switchyard offre un puzzle Godot a tre stanze, controlli di gameplay automatici, controlli di riapertura del salvataggio, log grezzi, uno ZIP sorgente e un PCK Godot. Le sue catture native mostrano il progetto reale in esecuzione a due dimensioni di viewport. Ripetere i comandi documentati è una verifica più forte che giudicare il progetto da un solo screenshot.

Il progetto ha usato Godot 4.5.1 in un run Codex in cui il modello di generazione esatto non è stato verificato. Dimostra quindi un workflow locale dell'engine, non un benchmark Astra. L'export browser era bloccato dalla mancanza dei template di export e il PCK non è un eseguibile Windows autonomo. Questi confini sono registrati con la fonte, così il prossimo sviluppatore sa cosa resta da testare.

Chiudi il loop con una consegna rivedibile

La consegna dovrebbe nominare scope giocabile, identità della sorgente, versioni dell'engine e dei template, istruzioni di build, risultati accettati e difetti irrisolti. Includi catture autentiche dell'artefatto testato e provenienza degli asset distribuiti. Conserva tentativi di riparazione e interventi manuali invece di presentare solo un dump finale di codice generato.

Quando il loop di base è accettato, aggiungi asset e localizzazione attraverso i rispettivi controlli d'import e gameplay prima di considerare la submission alla piattaforma. Questo workflow si basa sulla documentazione dell'engine; applicalo alla versione installata e conserva risultati reali. Mantieni una breve lista di problemi irrisolti con passi di riproduzione, così la sessione successiva parte dallo stesso stato noto.

Domande frequenti