KI-Spielentwicklung

Beginnen Sie mit einer vollständigen kleinen Spielschleife

Ein nützliches erstes Ziel ist eine einzelne Aktivität mit beobachtbarem Anfang und Ende: eine Runde starten, sich bewegen oder wählen, eine Herausforderung erleben, gewinnen oder verlieren und neu starten. Legen Sie fest, was der Spieler bei jedem Übergang sieht, bevor Sie einen Agenten bitten, Dateien zu schreiben. Ein ausgearbeiteter Titelbildschirm belegt nicht, dass die Schleife funktioniert.

Wählen Sie eine Zielplattform und eine kleine Zahl von Eingabegeräten. Behandeln Sie zusätzliche Level, Netzwerkfunktionen und prozedurale Inhalte als späteren Umfang. So bleibt ein fehlgeschlagener Prototyp diagnostizierbar: Sie können eine fehlerhafte Kollisionsregel von einer unfertigen Funktion unterscheiden, statt den Prompt wiederholt zu erweitern.

Wählen Sie zuerst den Workflow und dann die Engine

Für ein kleines eigenes 2D-Projekt sollten Sie zunächst Godots dokumentierte CLI für eine Prüfen-Bearbeiten-Ausführen-Schleife bewerten. Unity ist ein sinnvoller Ausgangspunkt, wenn ein bestehendes Projekt oder Team bereits von seinem Editor-Workflow abhängt. Ihre Fähigkeit, das Ergebnis zu pflegen, sollte die Wahl ebenso stark bestimmen wie der erste Prototyp.

Vergleichen Sie den Aufwand, der nötig ist, um einen Fehler auf Ihrer Maschine zu reproduzieren. Der beste Ausgangspunkt ist der, dessen Projektstruktur, Build-Voraussetzungen und Fehler Sie erklären können. Ein Agent nimmt Ihnen die Verantwortung für Engine-Upgrades oder Drittanbieterpakete nicht ab.

Halten Sie Modellzugriff und Engine-Tools getrennt

Der Agent hat zwei unterschiedliche Verbindungen: einen Modelldienst, der Überlegungen und Änderungen erzeugt, und lokale Tools, die das Projekt prüfen oder bedienen. Godot MCP und Unity MCP gehören zur Tool-Seite. Die Installation eines dieser Tools wählt keinen Modellanbieter aus und belegt keine Gateway-Integration.

Wählen Sie die Modellverbindung in Ihrem Agent-Client und die Engine-Verbindung in den Tool-Einstellungen. Prüfen Sie beide unabhängig voneinander mit einer kleinen Operation. Wenn ein lokaler Projektpfad falsch ist, korrigieren Sie diesen Pfad; das Ändern des Modellendpunkts lässt die vorgesehene Szene nicht erscheinen.

Machen Sie das erste Briefing testbar

Benennen Sie erforderliche Szenen, Spieleraktionen, Zustandsübergänge und Persistenzverhalten. Bitten Sie um die kleinste Implementierung, die diese Anforderungen erfüllt, sowie um eine ausdrückliche Liste ungeklärter Entscheidungen. Verwenden Sie das folgende beispielhafte Briefing als Ausgangspunkt und ersetzen Sie seinen Umfang durch das Spiel, das Sie tatsächlich entwickeln möchten.

Bewahren Sie das erste Briefing unverändert auf. Wenn Sie eine Anforderung hinzufügen, kennzeichnen Sie sie als Umfangsänderung. Wenn Sie einen Fehler erklären oder eine Datei selbst bearbeiten, kennzeichnen Sie dies als Eingriff. So bleibt der Unterschied zwischen einem ersten Prompt und den vielen folgenden Modell- und Tool-Iterationen sichtbar.

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.

Arbeiten Sie mit prüfbaren Änderungen

Bitten Sie nach dem anfänglichen Gerüst jeweils um ein Verhalten: zuerst Bewegung, dann Kollision, dann den Übergang am Rundenende. Prüfen Sie die geänderten Dateien und durchlaufen Sie nach jeder Änderung denselben Abnahmepfad. Bewahren Sie einen bekannten funktionierenden Projektzustand auf, bevor Sie externe Pakete hinzufügen oder Importeinstellungen verändern.

Ein Agent sollte den relevanten Fehler, Szenenkontext und das beobachtete Verhalten erhalten und nicht nur eine Aufforderung, es stärker zu versuchen. Wenn dasselbe Symptom nach wiederholten Änderungen bestehen bleibt, stoppen Sie und isolieren Sie die Grenze. Eine fehlende importierte Ressource und eine falsche Knotenreferenz erfordern unterschiedliche Korrekturen, auch wenn beide eine leere Szene erzeugen.

Behandeln Sie Assets und Lokalisierung als Produktionseingaben

Führen Sie ein Asset-Manifest mit Quelle, Berechtigung, Identität von Autor oder Tool, Änderungen und vorgesehener Verwendung. Prüfen Sie Sprites in Gameplay-Größe einschließlich Transparenz, Frame-Ausrichtung, Kontrast und Kollisionspassung. Ein plausibles Bild ist nicht automatisch ein brauchbares Sprite-Sheet.

Halten Sie spielerbezogene Strings über stabile IDs adressierbar. Liefern Sie Übersetzungskontext und schützen Sie Formatargumente. Bilder, Audio, Schriftarten und übersetzter Text benötigen vor der Distribution jeweils eine Prüfung. Erfassen Sie Ausgaben für Bildgenerierung unabhängig von der Textmodell-Programmierarbeit; weder eine Asset-Lizenz noch eine Engine-Lizenz begründet Rechte an jeder Datei eines Projekts.

Belegen Sie jeden Auslieferungsstatus unabhängig

Eine spielbare Demo erfordert, dass eine Person die vorgesehene Schleife abschließt. Ein Export erfordert ein erzeugtes Artefakt. Ein getesteter Export erfordert zusätzlich, dass dieses Artefakt auf seiner Zielplattform gestartet wird. Steam-Einreichung und Veröffentlichung sind spätere Plattformzustände. Verwenden Sie diese Bezeichnungen präzise, wenn Sie Fortschritt teilen.

Bewahren Sie Build-Identität, Testeingaben, Screenshots aus echtem Spiel und verbleibende Fehler auf. Eine Browseraufnahme sollte nach einer Eingabe ein verändertes Gameplay zeigen und nicht nur einen Ladebildschirm. Eine auf einem anderen Betriebssystem exportierte Windows-Datei benötigt weiterhin eine Windows-Prüfung. Die Steam-Anleitung behandelt die separaten Anforderungen an Konto und Terminplanung.

Was das Playco-Beispiel über den Workflow zeigt

Die OpenAI-Kundengeschichte vom 3. September 2026 beschreibt, wie Playco Astra in Playbot verwendet, einer mit Spiel-Engines verbundenen IDE. Das Team iterierte auf einer Greybox-Grundlage, bevor es thematische Prototypen erstellte. Dies ist ein vom Anbieter veröffentlichter Kundenbericht und kein APIsRouter-Benchmark.

Die praktische Erkenntnis ist die Form des Workflows: Etablieren Sie zunächst die spielbaren Mechaniken und variieren Sie anschließend die Darstellung, während eine gemeinsame Basis erhalten bleibt. Halten Sie kreative Präferenzen getrennt von Fehlerkorrekturen, damit sichtbar bleibt, was jede Iteration bewirkt hat. Lesen Sie den Originalbericht wegen seiner berichteten Ergebnisse und behandeln Sie sie nicht als Prognose für Ihr eigenes Spiel.

Prüfen Sie einen lokalen Godot-Prototyp

Switchyard ist ein kleines Rätselspiel mit drei Räumen, das in einem lokalen Codex-Entwicklungslauf entstanden ist. Das Quellprojekt umfasst Figurenbewegung, Schalter, Türen, Sammelzellen, Raumabschluss, Verlust und Neustart, Einstellungen sowie gespeicherten Fortschritt. Automatisierte Engine-Prüfungen durchliefen die Gameplay-Schleife, und ein separater Prozess öffnete den Speicherstand erneut. Der folgende Screenshot ist eine echte Godot-Viewport-Aufnahme und keine Konzeptgrafik.

Der aufgezeichnete Lauf verwendete Godot 4.5.1. Seine Modellidentität und API-Abrechnung waren nicht beobachtbar, daher wird er nicht als Astra-Leistungs- oder Kostenbenchmark präsentiert. Die herunterladbare Quelle und PCK demonstrieren das lokale Projekt; für die PCK ist Godot erforderlich. Ein eigenständiger Windows-Build, Browser-Export, menschlicher Spieltest und Steam-Veröffentlichung bleiben getrennte Arbeiten. Dieses Beispiel zeigt die konkreten Artefakte, die Sie von einem Agenten anfordern sollten, bevor Sie eine Auslieferung behaupten.

Wählen Sie den nächsten Leitfaden nach Ihrem Engpass

Beginnen Sie mit der Engine-Auswahl, wenn Ihre Umgebung noch offen ist, mit den MCP-Einrichtungsseiten, wenn die Tool-Erkennung fehlschlägt, oder mit dem Debugging-Leitfaden, wenn sich das Projekt öffnet, aber falsch verhält. Verwenden Sie den Kostenleitfaden, wenn wiederholte Reparaturen die Ausgaben bestimmen; eine Verkleinerung des Umfangs kann wichtiger sein als ein Modellwechsel.

Diese Leitfäden liefern quellenbasierte Workflows und beispielhafte Fälle, kein gemessenes Engine-Ranking. Das verlinkte Astra-Experiment erläutert die für seinen konkreten Fall benötigten Belege. Wählen Sie für Ihr eigenes Projekt den nächsten Schritt, der einen konkreten Blocker auflöst, und bewahren Sie sein Ergebnis vor einer Erweiterung des Spiels auf.

Häufige Fragen