AI-gegenereerde games debuggen
Updated 2026-09-05
Vind de eerste grens die faalt, geef de agent een reproduceerbaar symptoom en test dezelfde spelersactie opnieuw. Begin met de engine en build die je werkelijk uitvoert.
Classificeer de fout voordat je om een fix vraagt
Identificeer de vroegste falende stap: projectdiscovery, import, parsing of compilatie, scenestart, spelersinput, gameplaystatus, export of starten op het doel. Latere symptomen kunnen gevolgen zijn van die eerste fout. Bewaar engineversie, projectrevisie, target en exacte reproductie samen.
Een scene die nooit start kan bijvoorbeeld niet laten zien of de restartknop werkt. Een browser die het gamepakket niet kan ophalen, kan de controller niet testen. Stuur de fout naar de juiste grens voordat je code wijzigt; zo verzamelt een reparatielus geen niet-gerelateerde patches terwijl het oorspronkelijke vereiste stuk nog kapot is.
| Symptoom | Eerst inspecteren | Resultaat opnieuw testen |
|---|---|---|
| Project opent niet | Pad, versie, dependencies | Verwacht project laadt |
| Lege scene | Startuperrors, scene, camera, zichtbaarheid | Verwachte content verschijnt |
| Input heeft geen effect | Focus, action mapping, status, handlers | Actie wijzigt gamestatus |
| Export mislukt | Preset- of targetvereisten | Artefact wordt gemaakt |
| Build faalt alleen op target | Gepackagede resources en platformlogs | Target voltooit dezelfde loop |
Leg de eerste betekenisvolle enginefout vast
Gebruik in Godot het debuggerpaneel en de relevante runtime-output. Inspecteer in Unity compilatie- en runtimefouten afzonderlijk en wacht tot de editor klaar is voordat je speelresultaten interpreteert. Bewaar de stack of locatie die het falende script en de bewerking die het activeerde identificeert.
Stuur de agent een gericht fragment plus de relevante scene- of objectcontext. Vermijd een enorme ongedifferentieerde log die de eerste fout verhult, maar bewaar het volledige record lokaal voor latere inspectie. Redigeer credentials en persoonsgegevens. Een bruikbaar rapport zegt wat de speler deed, wat er had moeten gebeuren en wat de engine werkelijk meldde.
Verklein de reproductie zonder de eis te wijzigen
Begin vanuit een herstelbare projectstatus en isoleer de kleinste scene of actie die het defect nog vertoont. Behoud de echte controller, collisionregel of savegrens die bij het probleem hoort. Het volledig verwijderen van het falende systeem kan een schone run opleveren terwijl het benodigde gedrag verdwijnt.
De brief hieronder is een origineel diagnostisch template. Vul hem met waargenomen details in plaats van het model een oorzaak te laten aannemen. Vraag om één voorgestelde verklaring en een nauw begrensde wijziging. Voeg na voltooiing van de test de volledige spelersreis weer samen, zodat de lokale reparatie geen kapotte sceneovergang verbergt.
Project revision: <record actual revision>
Engine and target: <record actual environment>
Steps: launch -> start round -> perform the failing action
Expected state: <specific result>
Observed state: <specific result>
First engine error: <relevant error and location>
Inspect the referenced scene and script before editing.
Propose one cause, make a scoped fix, then repeat these steps.
Preserve the required behavior and report any remaining failure.Onderzoek een leeg scherm in lagen
Bepaal eerst of de engine is gestart en de bedoelde scene is geladen. Inspecteer daarna camerakeuze, viewportafmetingen, objectzichtbaarheid, posities en een overlay die de scene kan bedekken. Gebruik enginestatus en een echte capture samen: een afbeelding alleen laat mogelijk niet zien of de scene gepauzeerd, buiten beeld of leeg is.
Dien input in en observeer of status verandert, ook wanneer niets zichtbaar is. Als de positie verandert maar het beeld niet, richt je op rendering of scenereferenties. Als geen van beide verandert, onderzoek startup en input voordat je artwork aanpast. Koppel elke hypothese aan een observatie zodat de agent niet zonder noodzaak beide systemen herschrijft.
Volg input door de gameplayovergang
Volg de actie van focus en mapping naar de handler en vervolgens naar de status die zou moeten veranderen. Controleer pauzestatus en UI-interceptie voordat je bewegingsberekeningen de schuld geeft. Een restartfout kan een ontbrekende handler, verouderde scenereferentie of status zijn die nooit is gereset.
Test de actie na reparatie vanuit meerdere relevante statussen: eerste launch, na winst en na verlies wanneer dat van toepassing is. Controleer dubbele handlers of verouderde objecten die pas na herhaalde rondes verschijnen. Een kleine complete miniflow kan deze lifecycledefecten beter lokaliseren dan de knop steeds geïsoleerd testen.
Scheid browserladen van gamelogica
Inspecteer bij een Godot-webexport eerst browsernetwerk en consolepanelen voordat je gameplaycode bewerkt. Bevestig dat geëxporteerde HTML, JavaScript, WebAssembly en gamepakket vanaf de bedoelde locatie laden. Vergelijk hostinginstellingen met de officiële webexportdocumentatie, inclusief vereisten van de gekozen threadconfiguratie.
Houd namen van geëxporteerde companionbestanden consistent en test het artefact in plaats van een mix van oude en nieuwe bestanden. Als het verkeerde project verschijnt, inspecteer service-worker-cache in de testbrowser. Bedien daarna input en controleer bewegende content. Een niet-blank canvas is een eerste renderingcontrole en geen bewijs dat de gameloop werkt.
Controleer exportspecifieke fouten op het target
Vergelijk startup-sceneselectie, opgenomen resources, configuratie en targetlogs wanneer de editor werkt maar de gedistribueerde build faalt. Bewaar de exacte artefacthash zodat een latere re-export de reproductie niet ongeldig maakt. Test met een schone beginstatus voordat je op bestaande saves of editorcaches vertrouwt.
Wijzig de kernmechanic niet om een ontbrekend gepackaged bestand op te lossen. Herstel de packaginggrens en speel hetzelfde acceptatiepad opnieuw in de doelbuild. Gebruik voor desktopartefacts het echte besturingssysteem en voor browserartefacts de bedoelde browser en hostingsetup. Alleen cross-exporteren stelt doelgedrag niet vast.
Sluit een reparatie af met een voor-en-naresultaat
Bewaar de mislukte reproductie, de begrensde diff en de herhaalde actie die nu de verwachte status oplevert. Voeg een regressiecontrole toe op de grens die het defect veroorzaakte en speel daarna de omliggende gameloop opnieuw. Leg handmatige correcties vast en ook requests die door mislukte reparaties zijn verbruikt.
De voorbeelden hier zijn diagnostische procedures en geen gepubliceerde case van fout en oplossing. Gebruik ze om vanuit je project een concreet rapport te maken. Wanneer hetzelfde symptoom na herhaalde voorstellen blijft bestaan, stop dan de automatische loop en verzamel de ontbrekende observatie in plaats van zonder nieuw bewijs naar een brede herschrijving op te schalen.
Veelgestelde vragen
De agent zegt dat de game is gerepareerd, maar het scherm is leeg. Wat nu?
Reproduceer het symptoom en inspecteer startuperrors, actieve scene, camera en inputrespons. Het voltooiingsbericht is geen runtimeobservatie.
Moet ik het hele project opnieuw genereren?
Isoleer eerst de vroegste falende grens en bewaar de werkende status. Een gerichte reproductie is meestal eenvoudiger te reviewen dan een vervanging die veel systemen wijzigt.
Waarom toont de browser een oudere game?
Controleer artefactidentiteit, geserveerde bestanden en de service-workercache in de testbrowser. Verifieer dat de huidige export werkelijk wordt geladen.
Bewijzen geslaagde scriptcontroles speelbaarheid?
Ze dekken de uitgevoerde controles. Scene-wiring, input, rendering, statustransities en persistentie vereisen runtimebewijs.
Wat hoort in een bruikbaar bugrapport?
Project- en engine-identiteit, target, stappen, verwachte en waargenomen status, eerste relevante fout en de kleinste scene of bestanden om te reproduceren.