Godot AI-gameontwikkeling

Definieer de projectgrens vóór wijzigingen

Begin in een projectdirectory die je beheert en met een geschreven lijst toegestane wijzigingen. Inventariseer bestaande scenes, scripts, assets en plugins zodat de agent de huidige structuur uitbreidt in plaats van een tweede implementatie te maken. Houd de eerste projectstatus herstelbaar en noteer welke enginebinary hem opent.

Kies een bescheiden speelbaar onderdeel met expliciete overgangen. Een titelscherm dat bijvoorbeeld naar één kamer leidt en via winst of verlies terugkeert, geeft je een herhaalbare test. Bepaal wie visuele compositie en controls reviewt, want noch een geslaagde parser noch een voltooiingsbericht van een model bewijst dat de ervaring coherent aanvoelt.

Identificeer het uitvoerbare bestand en ondersteunde argumenten

De stabiele CLI-documentatie van Godot levert de opdrachten hieronder. GODOT_BIN en PROJECT zijn shellvariabelen voor dit voorbeeld, geen Godot-instellingen; vervang hun placeholderpaden door je bestaande executable en project. Het projectpad moet project.godot bevatten.

Leg versie en help-output vast voordat je extra flags scriptt. Zo voorkom je dat je aanneemt dat een opdracht uit actuele online documentatie in jouw geïnstalleerde build bestaat. Registreer de binary-identiteit samen met latere testresultaten en houd die stabiel tijdens het onderzoeken van een fout. Deze illustratieve opdrachten gebruiken de gedocumenteerde CLI-vormen.

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

Scheid import, parsing en echt spelen

Een headless import controleert een assetverwerkingsgrens. Een parsercontrole onderzoekt een script. Een normale start bereikt de game en kan scene-wiring en runtimeproblemen zichtbaar maken. Houd die uitkomsten afzonderlijk in het reviewrecord in plaats van ze samen te vatten als drie geslaagde tests.

Het illustratieve scriptpad hieronder moet al in je project bestaan. Een parsercontrole is bewust beperkt: hij bewijst geen werkende collisions, responsieve input of correcte persistentie. Speel na een edit het gewijzigde gedrag opnieuw en ook de overgang direct ervoor en erna. Dat is vaak informatiever dan veel geïsoleerde controles voor gegenereerde helperfuncties maken.

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

Kies bewust tussen CLI-tools en MCP

Een agent met shellmogelijkheden kan een gereviewde CLI-reeks uitvoeren. Godot MCP is een extra, door het project onderhouden toolinterface; de installatie staat op de eigen pagina. In beide gevallen moet de operator weten welk project het doel is voordat een write of processtart wordt goedgekeurd.

Houd de modelproviderinstellingen van de agent gescheiden van enginetooling. Een werkende lokale verbinding bewijst niet dat een bepaald model beschikbaar is of dat de agent elke functie van een compatibele gateway ondersteunt. Voer eerst de kleinst toegestane read uit, daarna een omkeerbare scene-wijziging en pas daarna een complete gameplaycyclus in een geautoriseerd experiment.

Geef fouten voldoende scenecontext

Leg bij een mislukte interactie de relevante scene tree, het script, de inputactie en de eerste betekenisvolle runtimefout vast. Leg de verwachte overgang en de waargenomen status uit. Een rapport dat de speler niet kan bewegen, moet aangeven of de game focus heeft, of input wordt gedetecteerd en of de positie van de speler verandert.

Vraag om een kleine voorgestelde correctie met uitleg die aan dat bewijs is gekoppeld. Herhaal na toepassing dezelfde actie en controleer regressies in opnieuw starten en sceneovergangen. Accepteer een reparatie niet alleen omdat de fout verdween; de getroffen functie uitschakelen kan een fout verwijderen terwijl de oorspronkelijke eis onvervuld blijft.

Bereid exportvereisten expliciet voor

Voor een export zijn een passend preset en geïnstalleerde exporttemplates nodig. Review export_presets.cfg en resource-inclusie vóór het bouwen. Houd exportcredentials privé. De presetnaam in het voorbeeld is illustratief en moet bij je project passen; de outputdirectory moet al bestaan.

Behandel een ontbrekende template of preset als een omgevingsprobleem, niet als bewijs dat de gegenereerde gamelogica fout is. Bewaar exportlogs en de hash van het artefact zodat bevindingen op het doelplatform naar een specifieke build verwijzen. Een geslaagde export is een belangrijk ijkpunt, maar bewijst niet dat de geleverde player start of een ronde voltooit.

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

Voer een leveringsminiflow uit op het doelplatform

Start de geëxporteerde game op het besturingssysteem dat je wilt ondersteunen. Test start, input, een complete ronde, opnieuw starten, instellingen en persistentie na opnieuw openen. Bewaar per resultaat artefactidentiteit, apparaatcontext en waargenomen uitkomst. Een export die op macOS is gemaakt, verifieert Windowsgedrag niet vanzelf.

Controleer voor een webtarget ook browserladen en runtimefouten en bedien de canvas met echte input. Verifieer dat content zichtbaar is en waar passend beweegt. Test de bedoelde hostingconfiguratie in plaats van aan te nemen dat een lokale editor-run browserresources en platformbeperkingen afdekt.

Een bronproject en native capture om te inspecteren

Het lokale Switchyard-voorbeeld levert een Godot-puzzel met drie kamers, geautomatiseerde gameplaycontroles, save-reopen-controles, ruwe logs, een source-ZIP en een Godot-PCK. De native captures tonen het werkelijk draaiende project op twee viewportgroottes. De gedocumenteerde opdrachten herhalen is een sterkere controle dan het project alleen op basis van een screenshot beoordelen.

Het project gebruikte Godot 4.5.1 in een Codex-run waarvan het exacte generatiemodel niet is geverifieerd. Het demonstreert dus een lokale engineworkflow, geen Astra-benchmark. Browserexport werd geblokkeerd door ontbrekende exporttemplates en de PCK is geen zelfstandige Windows-executable. Die grenzen zijn samen met de source vastgelegd zodat de volgende ontwikkelaar weet wat nog getest moet worden.

Sluit de loop met een reviewbare overdracht

De overdracht moet speelbare scope, source-identiteit, engine- en templateversies, buildinstructies, geaccepteerde resultaten en onopgeloste defecten benoemen. Voeg authentieke captures van het geteste artefact en de herkomst van meegeleverde assets toe. Bewaar reparatiepogingen en handmatige interventies in plaats van alleen een laatste gegenereerde codedump te presenteren.

Voeg na acceptatie van de basisloop assets en lokalisatie toe via eigen import- en gameplaycontroles voordat je platformsubmissie overweegt. Deze walkthrough is gebaseerd op enginedocumentatie; pas hem toe op jouw geïnstalleerde versie en bewaar echte resultaten. Houd een korte lijst onopgeloste problemen met reproductiestappen bij, zodat de volgende ontwikkelsessie vanuit dezelfde bekende status begint.

Veelgestelde vragen