Aus einer Idee einen Test machen statt einer Wunschliste
Ein Spiel mit KI zu erstellen beginnt damit, eine spielbare Kernschleife zu definieren, eine kleine Umsetzung anzufordern und das Ergebnis zu prüfen, bevor weitere Funktionen hinzukommen. Ein Prompt ist eine Eingabe und kein Beleg dafür, dass die gewünschten Funktionen funktionieren. Die entscheidende Frage nach der Generierung lautet nicht „Sieht das wie ein Spiel aus?“, sondern „Kann ein Spieler die Handlung ausführen, das Ziel erreichen, nachvollziehbar scheitern und neu starten?“
Dieser Leitfaden verbindet ein übernommenes, dokumentiertes SEELE-Beispiel mit einer separaten Übungsbeschreibung. Für das Beispiel gibt es einen spielbaren Link und Aufnahmen; die Übungsbeschreibung wurde für diesen Entwurf weder generiert noch getestet. Diese Trennung verhindert, dass ein plausibler Ablauf für einen belegten Erfolg gehalten wird.
Was das dokumentierte Zombie-Survival-Beispiel belegt
Der Ausgangsartikel beschreibt eine SEELE-Generierung aus dem Oktober 2026, bei der ein Zombie-Survival-Spiel in der Ego-Perspektive mit Three.js angefordert wurde. Gewünscht waren unter anderem Bewegung mit Pointer Lock, Schusswaffen, Nachladen, Zielen über die Visierung, Ducken, Sprinten, einsammelbare Gegenstände und eine Minikarte.
Die Beschreibung der Ergebnisaufnahme im Ausgangsartikel nennt eine Waffenansicht aus der Ego-Perspektive, eine HUD-Anzeige für Gesundheit und Munition, eine Minikarte, einen Wellenzähler, Gegner und einen Hinweis zum Einsammeln. Die 21,5 Sekunden lange Spielaufnahme zeigt nur einen Teil der ersten Welle. Diese sichtbaren Elemente belegen weder ein funktionierendes Nachladen und Ducken noch jede Interaktion mit Gegenständen, eine vollständige Sitzung über fünf Wellen oder die Kompatibilität mit anderen Browsern. Das sind die Grenzen des veröffentlichten Beispiels, kein Bericht über einen neuen eigenen vollständigen Test.
Das Bild dokumentiert den promptgesteuerten Prozess dieses konkreten Projekts.
Das vorhandene spielbare Projekt öffnen.
Eine kleinere Aufgabenbeschreibung für den ersten Build übernehmen
Nutze das folgende Übungsbeispiel, wenn ein Shooter für den ersten Versuch zu viele miteinander verknüpfte Systeme enthält:
Übungsbeispiel, kein getesteter Build: Erstelle ein Browser-Spiel auf einem einzelnen Bildschirm namens Signal Run mit Ansicht von oben. Die Spielfigur bewegt sich mit WASD oder den Pfeiltasten, sammelt drei Batterien und erreicht einen sichtbaren Ausgang. Zeige den Batteriestand und die Steuerung an. Ein Hindernis bewegt sich horizontal zwischen zwei festen Punkten. Bei Berührung erscheint ein Niederlagenbildschirm; wird der Ausgang ohne alle Batterien erreicht, erscheint ein Hinweis auf die Voraussetzung. Wer alle drei Batterien einsammelt und den Ausgang erreicht, sieht einen Siegesbildschirm. R startet nach beiden Ergebnissen neu und setzt Spielfigur, Batterien, Zähler und Hindernis zurück. Verwende gut erkennbare Platzhalterformen. Füge keine Gegner, Waffen, Speicherstände, Netzwerkfunktionen, zusätzlichen Level oder Zahlungen hinzu. Erkläre die geänderten Projektkomponenten und nenne Prüfschritte für Bewegung, Einsammeln, Sieg, Niederlage und Neustart.
Die promptgesteuerte Spielerstellung mit SEELE ist beim Schritt von der Aufgabenbeschreibung zum Prototyp relevant. Die angeforderte Steuerung und das Zurücksetzen müssen trotzdem am tatsächlichen Ergebnis geprüft werden; der Wortlaut des Prompts garantiert sie nicht.
Schritt 1: Die erste spielbare Kernschleife prüfen
Starte vor der optischen Überarbeitung den vorgesehenen Build und verwende die darin angezeigte Steuerung. Prüfe die Bewegung in alle Richtungen und ob das Verlassen des Spielfelds verhindert wird. Sammle eine Batterie ein und gehe anschließend über ihre frühere Position: Der Zähler darf nicht zweimal steigen.
Versuche frühzeitig, den Ausgang zu erreichen, und halte die Meldung fest. Sammle anschließend alle Batterien ein und prüfe den Sieg. Berühre das Hindernis absichtlich und prüfe die Niederlage. Starte nach beiden Ergebnissen neu. Wenn das Hindernis zurückgesetzt wird, die Batterien aber nicht, melde genau diesen Unterschied, statt die KI nur zu bitten, „das Spiel zu reparieren“.
Schritt 2: Anhand des Beispiels eine Prüfübersicht erstellen
Halte für jede Funktion vier Felder fest: gefordertes Verhalten, verfügbare Belege, beobachtetes Verhalten und Status. Im Zombie-Beispiel gehört eine sichtbare Minikarte in das Feld für Belege; eine genaue Positionsverfolgung bleibt bis zum Test unbestätigt. Die Anforderung zum Nachladen gehört in die Spezifikation, bis du Änderungen der Munition und den Nachladevorgang aufzeichnen kannst.
Gehe bei Signal Run ebenso vor. „Drei Batterien angefordert“ bedeutet nicht automatisch „drei unterschiedliche Gegenstände korrekt gezählt“. Kennzeichne ungeklärte Punkte als ungeprüft, statt die Lücke mit einer selbstsicheren Bildunterschrift zu füllen. Die Übersicht macht den nächsten Prompt kleiner und liefert Beteiligten eine verlässliche Beschreibung des Builds.
Schritt 3: Eine Regel ändern und die Schleife erneut testen
Speichere eine funktionierende Version und fordere dann nur eine Änderung an: Verringere die Bewegungsgeschwindigkeit des Hindernisses um 20 Prozent, ohne seine Strecke oder die Sammelregeln zu ändern. Wiederhole dieselbe Überquerung vom gleichen Ausgangspunkt, vergleiche die Zeiten und teste beide Endzustände erneut.
Wenn die Bewegung nach einer nicht damit zusammenhängenden visuellen Änderung nicht mehr funktioniert, kehre zur bekannten funktionierenden Version zurück und grenze die Anfrage ein. Gib den genauen Fehler, die Zielumgebung, das erwartete Verhalten und die kürzeste Folge von Schritten zur Reproduktion an. Schichte keine umfangreichen Neufassungen über einen ungeklärten Fehler.
Schritt 4: Die technische Übergabe separat prüfen
Ein spielbarer Link ist keine Übergabe des Quellprojekts. Prüfe vor der weiteren Entwicklung mit einem Tool die Projektzugriffs- und Exportmöglichkeiten des aktuellen Tarifs. Ist das gewünschte Format verfügbar, speichere eine versionierte Kopie und erfasse Einstiegspunkt, Quelldateien, Assets, Abhängigkeitsmanifest, Lockfile und Startanleitung. Kläre, was generiert wurde, was eine Abhängigkeit ist und was einen separaten Dienst benötigt. Veröffentliche keine Zugangsdaten, privaten Endpunkte oder Kontotoken zusammen mit dem Projekt.
Führe in einem separaten leeren Ordner die dokumentierten Installations- und Startbefehle für genau diese Engine oder dieses Framework aus. Halte die Laufzeitversion und fehlende Abhängigkeiten fest. Wiederhole Bewegung, Einsammeln, Sieg, Niederlage und Neustart ohne den gehosteten Arbeitsbereich. Schlägt der lokale Build fehl oder ist kein Export verfügbar, dokumentiere diese Einschränkung; eine gehostete Vorschau schließt diese Beweislücke nicht. Für das übernommene Zombie-Beispiel sind weder ein Quellexport noch ein lokaler Start belegt.
Schritt 5: Eine begrenzte, ehrliche Veröffentlichung vorbereiten
Prüfe vor dem Teilen das Laden in einer sauberen Umgebung, lesbare Steuerungshinweise, gegebenenfalls Audio, Tastaturfokus und Neustart. Prüfe die aktuellen Nutzungsbedingungen für Tool und Assets im Hinblick auf deinen Einsatzzweck. Teste einen zweiten Browser oder ein zweites Gerät, bevor du dafür Unterstützung behauptest. Binde Leistungsaussagen an benannte Hardware und eine dokumentierte Messmethode, nicht an den scheinbar flüssigen Eindruck eines eingebetteten Videos.
Beginne deinen eigenen kleinen Prototyp mit SEELE und der obigen Aufgabenbeschreibung. Sichere den funktionierenden Build, den genauen Prompt und die Testnotizen, bevor du weitere Änderungen anforderst. Der Meilenstein ist eine überprüfte Kernschleife, keine lange Funktionsliste: Neue Spieler können sich bewegen, das Ziel verstehen, beide Ergebnisse erreichen und neu starten. Füge Level und aufwendigere Assets erst hinzu, wenn sich diese Schleife ohne Erklärung der Ersteller demonstrieren lässt. Wenn die Weiterarbeit außerhalb des Arbeitsbereichs wichtig ist, behandle die Quellcode-Übergabe und einen sauberen lokalen Start als separate Abnahmekriterien statt als Annahmen über die Vorschau.
Nachweis- und Abnahmematrix
Diese Matrix ordnet die im Artikel vorgeschlagenen Prüfungen. Sie ist kein Bericht über einen abgeschlossenen Test.
| Aussage oder Aufgabe | Was Quelle oder Aufgabenbeschreibung belegen | Was noch geprüft werden muss |
|---|---|---|
| Aufgezeichnetes Survival-Beispiel | Der Artikel beschreibt eine kurze Spielaufnahme und nennt sichtbare HUD- und Gegnerelemente. | Aus einem kurzen Clip nicht auf den Ablauf einer vollständigen Sitzung oder Browserkompatibilität schließen. |
| Spielbare Kernschleife | Die Übungsbeschreibung schlägt Handlung, Ziel, Niederlage und Neustart vor. | Jedes Verhalten im tatsächlichen Build ausführen und das Ergebnis festhalten. |
| Überarbeitung | Der Ablauf sieht eine einzelne begrenzte Änderung vor. | Die Ausgangsprüfungen nach der Änderung wiederholen. |
| Technische Übergabe | Eine Übergabe ist eine separate Phase des Ablaufs. | Die tatsächlichen Dateien, Einrichtungsanweisungen und erlaubte Nutzung prüfen. |
Häufige Fragen
Kann ein kurzes Spielvideo beweisen, dass das gesamte Spiel funktioniert?
Nein. Es belegt nur, was während des aufgenommenen Zeitraums sichtbar ist. Ein HUD kann erscheinen, ohne dass alle zugrunde liegenden Regeln korrekt funktionieren. Nutze eine Funktionscheckliste, reproduzierbare Eingaben und längere gezielte Aufnahmen, um das Verhalten nachzuweisen. Unterscheide zwischen einem Prozessvideo, einer Vorschau des Erscheinungsbilds und einem abgeschlossenen Spieltest.
Muss ich jede generierte Datei verstehen?
Du musst genug verstehen, um das Spiel zu testen, funktionierende Versionen zu sichern und relevante Änderungen zu finden. Bitte den Assistenten, Komponenten und Annahmen verständlich zu erklären. Sieh bei unbekanntem Engine-spezifischem Verhalten in der aktuellen Engine-Dokumentation nach. Akzeptiere keine umfassende Neufassung des Codes allein deshalb, weil ihre Erklärung technisch überzeugend klingt.
Wann sollte ich Platzhaltergrafiken ersetzen?
Wenn die Kernschleife verständlich und wiederholbar ist. Ersetze Assets in kleinen Gruppen und prüfe Kollisionen, Größe, Kontrast, Ladeverhalten und Nutzungsrechte erneut. Ansprechende Medien können die Darstellung verbessern, aber keine ungeprüfte Mechanik nachweisen. Kennzeichne konzeptionelle Bilder ehrlich, statt sie als Screenshot eines funktionierenden generierten Ergebnisses auszugeben.
Wählen Sie einen Workflow für den nächsten spielbaren Meilenstein
Verwenden Sie einen Game Maker, wenn die nächste Entscheidung in einer im Browser spielbaren Schleife getestet werden kann. Wenn ein Projekt bereits über eine Engine, Assets oder eine Codebasis verfügt, testen Sie einen Assistenten anhand einer begrenzten Änderung in dieser Umgebung. Bewahren Sie neben den Spieltestnotizen eine Export- und Asset-Checkliste auf, damit ein spielbares Ergebnis und ein tragbares Projekt getrennt bewertet werden können.
