AI-gameontwikkeling

Begin met een complete kleine gameloop

Een nuttig eerste doel is één activiteit met een observeerbaar begin en einde: start een ronde, beweeg of kies, kom een uitdaging tegen, bereik winst of verlies en begin opnieuw. Specificeer wat de speler bij elke overgang ziet voordat je een agent vraagt bestanden te schrijven. Een gepolijst titelscherm bewijst niet dat de loop werkt.

Kies één doelplatform en een kleine set invoerapparaten. Beschouw extra levels, networking en procedurele content als latere scope. Zo blijft een mislukt prototype te diagnosticeren: je kunt een kapotte collisionregel onderscheiden van een onafgemaakte functie in plaats van de prompt steeds verder uit te breiden.

Kies de workflow en daarna de engine

Begin bij een origineel klein 2D-project met het evalueren van Godots gedocumenteerde CLI voor een inspect-edit-run-loop. Unity is een nuttig startpunt wanneer een bestaand project of team al afhankelijk is van de editorworkflow. Je vermogen om het resultaat te onderhouden moet de keuze net zo sterk sturen als het eerste prototype.

Vergelijk het werk dat nodig is om een fout op jouw machine te reproduceren. Het beste startpunt is de route waarvan je projectstructuur, buildvereisten en fouten kunt uitleggen. Een agent neemt de verantwoordelijkheid voor engine-upgrades of third-party packages niet weg.

Houd modeltoegang gescheiden van enginetools

De agent heeft twee verschillende verbindingen: een modelservice die redeneringen en wijzigingen produceert en lokale tools die het project inspecteren of bedienen. Godot MCP en Unity MCP horen aan de toolkant. Installatie van een van beide kiest geen modelprovider en bewijst geen gateway-integratie.

Kies de modelverbinding in je agentclient en de engineverbinding in de toolinstellingen. Verifieer elke verbinding afzonderlijk met een kleine bewerking. Wanneer een lokaal projectpad fout is, herstel dat pad; het modelendpoint wijzigen laat de bedoelde scene niet verschijnen.

Maak de eerste brief testbaar

Benoem de vereiste scenes, spelersacties, statustransities en persistentiegedrag. Vraag om de kleinste implementatie die aan die eisen voldoet en om een expliciete lijst van onopgeloste beslissingen. Gebruik de illustratieve brief hieronder als startpunt en vervang de scope door de game die je echt wilt maken.

Bewaar de eerste brief ongewijzigd. Label een nieuwe eis als scopewijziging. Label een uitleg van een fout of een bestand dat je zelf bewerkt als interventie. Zo blijft het verschil zichtbaar tussen één eerste prompt en de vele model- en tooliteraties die kunnen volgen.

Deliver one original 2D room with start, play, win/loss, and restart states.
Use project-owned placeholder art. Preserve the chosen engine version.
Record each edit, tool result, failed check, and human intervention.
Stop before downloads, purchases, uploads, or publishing.
Report unfinished requirements with their reproduction steps.

Werk in reviewbare wijzigingen

Vraag na de eerste scaffold om één gedrag tegelijk: eerst beweging, dan collision, dan de overgang aan het einde van de ronde. Review de gewijzigde bestanden en doorloop na elke wijziging dezelfde acceptatieroute. Bewaar een bekende werkende projectstatus voordat je externe packages toevoegt of importinstellingen wijzigt.

Een agent moet de relevante fout, scenecontext en het waargenomen gedrag ontvangen, niet alleen het verzoek harder te proberen. Wanneer hetzelfde symptoom na herhaalde wijzigingen blijft bestaan, stop dan en isoleer de grens. Een ontbrekende geïmporteerde resource en een verkeerde nodereferentie vragen verschillende oplossingen, ook als beide een lege scene opleveren.

Behandel assets en lokalisatie als productie-input

Houd een assetmanifest bij met bron, toestemming, auteur of toolidentiteit, wijzigingen en beoogd gebruik. Review sprites op gameplay-schaal, inclusief transparantie, frame-uitlijning, contrast en collision-fit. Een plausibele afbeelding is niet automatisch een bruikbare spritesheet.

Maak strings die spelers zien adresseerbaar met stabiele identifiers. Lever vertaalcontext aan en bescherm formatteerargumenten. Afbeeldingen, audio, fonts en vertaalde tekst hebben elk een review nodig vóór distributie. Registreer uitgaven voor beeldgeneratie afzonderlijk van codewerk met het tekstmodel; een assetlicentie of enginelicentie geeft geen rechten op elk bestand in een project.

Bewijs elke leveringsstatus afzonderlijk

Voor een speelbare demo moet iemand de bedoelde loop kunnen voltooien. Een export vereist een gegenereerd artefact. Een geteste export vereist bovendien dat je dat artefact op het doelplatform start. Steam-submissie en release zijn latere platformstatussen. Gebruik die labels precies wanneer je voortgang deelt.

Bewaar buildidentiteit, testinputs, screenshots van echte gameplay en resterende fouten. Een browsercapture moet gameplay na input laten veranderen, niet alleen een laadscherm tonen. Een Windows-executable die op een ander OS is geëxporteerd, heeft nog steeds Windows-verificatie nodig. Zie de Steam-gids voor afzonderlijke account- en planningsvereisten.

Wat het Playco-voorbeeld laat zien over de workflow

OpenAI's klantverhaal van 3 september 2026 beschrijft Playco dat Astra gebruikt in Playbot, een IDE die met game-engines is verbonden. Het team iterereerde op een grey-box-fundament voordat het prototypes met thema maakte. Dit is een door de leverancier gepubliceerd klantverhaal, geen APIsRouter-benchmark.

De praktische les is de vorm van de workflow: leg eerst de speelbare mechanica vast en varieer daarna de presentatie terwijl je een gedeelde baseline behoudt. Houd creatieve voorkeuren gescheiden van foutreparaties, zodat je ziet wat elke iteratie heeft bereikt. Lees het oorspronkelijke verhaal voor de gerapporteerde uitkomsten in plaats van ze als voorspelling voor je eigen game te behandelen.

Inspecteer een lokaal Godot-prototype

Switchyard is een kleine circuitpuzzel met drie kamers, gemaakt tijdens een lokale Codex-developmentrun. Het bronproject bevat personagebeweging, schakelaars, deuren, verzamelbare cellen, kamercomplete, verlies en opnieuw starten, instellingen en opgeslagen voortgang. Geautomatiseerde enginecontroles doorliepen de gameloop en een apart proces opende de save opnieuw. De screenshot hieronder is een echte Godot-viewportcapture, geen conceptart.

De geregistreerde run gebruikte Godot 4.5.1. Modelidentiteit en API-facturering waren niet waarneembaar, dus dit wordt niet gepresenteerd als Astra-performance- of kostenbenchmark. De downloadbare source en PCK tonen het lokale project; voor de PCK is Godot nodig. Een zelfstandige Windows-build, browserexport, menselijke playtest en Steam-release blijven afzonderlijk werk. Dit voorbeeld laat zien welke concrete artefacten je een agent moet laten opleveren voordat je een leveringsclaim doet.

Kies de volgende gids op basis van je knelpunt

Begin met enginekeuze als je omgeving nog niet vaststaat, met de MCP-instellingspagina's als tooldiscovery faalt, of met de debug-gids als het project opent maar verkeerd werkt. Gebruik de kostengids wanneer herhaalde reparaties het grootste deel van de uitgaven vormen; scope verkleinen kan belangrijker zijn dan van model wisselen.

Deze gidsen bieden brononderbouwde workflows en illustratieve voorbeelden, geen gemeten engine-ranglijst. Het gekoppelde Astra-experiment legt uit welk bewijs voor zijn specifieke case nodig is. Kies voor je eigen project de volgende stap die een concreet blokkerend probleem oplost en bewaar het resultaat voordat je de game uitbreidt.

Veelgestelde vragen