Erst planen, dann ändern — der Plan-Modus für KI-Agenten in der Spieleentwicklung

Ein KI-Agent ist schnell, und genau deshalb kann eine große Aufgabe rasch schiefgehen: Er beginnt mit dem Bearbeiten von Code, bevor man sich darauf geeinigt hat, was er tun soll. Der Plan-Modus in AI Game Developer dreht das um. Der Agent liest das Projekt und schreibt einen Plan, jede Änderung wird verweigert, bis man sie genehmigt, und erst dann beginnt er zu arbeiten.

Zusammen mit klärenden Fragen, einer Nachrichten-Warteschlange und Karten mit Code-Review-Befunden gibt der Plan-Modus ein einfaches Mittel an die Hand, einen KI-Agenten durch eine größere Aufgabe in der Spieleentwicklung zu steuern. In diesem Beitrag setzen wir alles davon in einer einzigen Session aus unserem Demo-Spiel Skyward Keep ein: Der Spielercharakter bekommt einen Gleitflug. Das Video ist eine echte Aufzeichnung der App: Die Antworten des Agenten sind für die Demo geskriptet, und jeder Tool-Aufruf darin lief wirklich.

Warum erst planen, bevor der Agent etwas ändert

Kleine Anfragen wie „mach den Sprung höher“ brauchen keinen Plan. Größere schon. Eine neue Bewegungsfähigkeit berührt den Player-Controller, die Eingabe, die Tuning-Werte, die Dokumentation und oft auch das Audio. Wenn der Agent sich bei einem davon falsch entscheidet, macht man am Ende Änderungen über viele Dateien hinweg rückgängig.

Ein Plan löst drei Probleme auf einmal:

• Man sieht den Umfang, bevor sich etwas ändert: welche Dateien, welche Systeme, in welcher Reihenfolge.
• Missverständnisse kommen früh heraus, solange es nur einen Satz kostet, sie zu korrigieren.
• Der genehmigte Plan wird zur Checkliste, mit der man das Ergebnis prüft.

Schritt 1: Den Plan-Modus einschalten

Der Plan-Modus ist ein Schalter pro Session im Eingabefeld. Man schaltet ihn ein, bevor man die Aufgabe sendet. Im Plan-Modus kann der Agent Dateien lesen und das Projekt sowie seine Notizen durchsuchen, aber jede Änderung wird verweigert, bis er einen Plan vorlegt.

Dann beschreibt man das Ziel, nicht die Schritte. Die Demo-Anfrage ist kurz:

„Füge einen Gleitflug hinzu: Halte in der Luft den Sprung gedrückt, um mit Wrens Umhang zu gleiten.“

Der Agent beginnt damit, den Player-Controller und die Notizen des Projekts zu den Fähigkeiten des Spielers zu lesen.

Schritt 2: Die Fragen des Agenten beantworten

Ein guter Plan braucht ein paar Entscheidungen, die nur man selbst treffen kann. Der Agent kann eine Frage mit Auswahlmöglichkeiten stellen, die sich über dem Eingabefeld ausklappt. In der Demo stellt er vor dem Schreiben des Plans eine Design-Frage, „Wie lange kann Wren gleiten?“, mit drei Optionen:

• 3 Sekunden Ausdauer, die bei der Landung wieder aufgefüllt wird, was das gemütliche Tempo erhält.
• Unbegrenzt, solange der Sprung gedrückt gehalten wird.
• Upgradefähig, beginnend bei 1,5 Sekunden und durch Umhang-Upgrades verlängerbar.

Hat der Agent mehrere Fragen, werden sie zu einer bearbeitbaren Umfrage: Man kann jede Frage anklicken, um zu ihr zurückzukehren, eine frühere Antwort ändern oder vorausspringen, und die Antworten werden erst gesendet, wenn jede Frage eine hat. Das Beantworten dauert eine Minute und spart später eine Runde Nacharbeit. Wenn das Projekt eine Wissensdatenbank hat, liest der Agent die dort bereits festgelegten Konventionen und stellt weniger Fragen.

Schritt 3: Den Plan prüfen

Der Agent legt den Plan mit einer Bestätigungskarte vor, die zwei Möglichkeiten bietet: Genehmigen und ausführen oder Weiter planen. Der Demo-Plan hat vier Punkte:

1. Ein neues Skript für den Gleitflug: Solange man in der Luft ist und fällt, begrenzt gehaltenes Springen die Fallgeschwindigkeit auf 2,5 m/s.
2. Ausdauer von 3 Sekunden, die Antwort auf die Frage, die beim Gleiten verbraucht und bei der Landung wieder aufgefüllt wird.
3. Der Player-Controller ruft den Gleitflug nach der Schwerkraft auf, ohne Änderung an Jump-Buffering oder Coyote Time.
4. Die Regeln des Gleitflugs werden der Notiz Player abilities in der Wissensdatenbank hinzugefügt.

Außerdem merkt er an, dass die Eingabe-Bindings nicht geändert werden müssen, weil bereits eine Aktion für den Gleitflug existiert.

Man liest den Plan so, wie man die Design-Notiz eines Teamkollegen lesen würde. Berührt er nur die Dateien, die er berühren sollte? Ist die Reihenfolge sinnvoll? Fehlt etwas? Wenn etwas nicht stimmt, wählt man Weiter planen und tippt ein, was sich ändern soll; der Agent überarbeitet den Plan und zeigt ihn erneut. Wenn er passt, genehmigt man ihn, und der Agent beginnt mit der Arbeit.

Schritt 4: Nachrichten einreihen, während er arbeitet

Während der Agent arbeitet, fallen einem Dinge ein. Man muss nicht mehr warten oder unterbrechen. In der Demo wird während der Umsetzung des Gleitflugs eine Nachfrage getippt und eingereiht:

„Spiele außerdem ein leises Rauschen ab, wenn der Gleitflug beginnt.“

Nachrichten, die während eines laufenden Turns gesendet werden, warten in einem eingereihten Panel über dem Eingabefeld. Man kann eine sofort senden oder sie zurück ins Eingabefeld ziehen, um sie zu bearbeiten. Drückt man Stop, wird der laufende Turn abgebrochen und der eingereihte Text kehrt ins Eingabefeld zurück, sodass eine zurückgezogene Nachricht niemals noch ausgeführt werden kann. Der Agent schließt zuerst den genehmigten Plan ab und nimmt sich dann die eingereihte Anfrage vor.

Anfragen für Tool-Berechtigungen erscheinen im selben Panel, und die Session zeigt eine Wartet-auf-dich-Markierung, solange eine Rückfrage offen ist, sodass man auf einen Blick sieht, welche Sessions einen brauchen.

Schritt 5: Das Ergebnis mit Code-Review-Karten prüfen

Bevor der Agent die Arbeit übergibt, prüft er seine eigene Änderung. Die Ergebnisse des Code-Reviews erscheinen als Finding-Karten, jede mit einem Urteil, Datei und Zeile, einer Kategorie, einer kurzen Zusammenfassung und einem Fehlerszenario, das erklärt, wie sich das Problem im Spiel zeigen würde. Wird nichts gefunden, sagt die Karte das deutlich.

In der Demo zeigen die Review-Karten zwei Befunde:

• Bestätigt und behoben: Die Ausdauer wurde bei der Landung nie wieder aufgefüllt. Drei Sekunden gleiten, landen, erneut springen – und der zweite Gleitflug startet nie.
• Plausibel und zur Entscheidung überlassen: Der Gleitflug liest den Bodenkontakt aus dem vorherigen Frame, sodass eine Landung auf einer beweglichen Plattform bei gehaltenem Sprung für einen Frame Gleitflug-Geschwindigkeit auf dem Boden erzeugen könnte.

Man behandelt die Karten wie eine To-do-Liste: den Agenten bitten, die Befunde zu beheben, denen man zustimmt, und sagen, warum man die anderen überspringt. Dann den genehmigten Plan Punkt für Punkt abhaken und das Spiel spielen. Ein Gleitflug, der im Code korrekt ist, kann sich beim Spielen trotzdem falsch anfühlen.

Lange Sessions gesund halten

Große Aufgaben füllen den Kontext des Agenten. Wenn eine lange Session kurz davor ist, eine unabhängige neue Aufgabe zu übernehmen, bietet das Eingabefeld an, neu zu starten, was das Limit schont. Das Angebot erscheint nur, wenn der Agent im Leerlauf ist und der Kontext groß ist, und man kann stattdessen jederzeit in der aktuellen Session weiterarbeiten. Ein guter Rhythmus ist eine Session pro Feature: planen, bauen, prüfen, dann das nächste Feature in einer frischen Session beginnen.

Ein Workflow, den man wiederverwenden kann

Für jede Aufgabe, die mehr als ein paar Dateien berührt:

1. Plan-Modus einschalten und das Ziel beschreiben.
2. Die Fragen des Agenten beantworten.
3. Den Plan prüfen und weiter planen, bis er passt.
4. Genehmigen und Folgegedanken einreihen, statt zu unterbrechen.
5. Die Änderungen mit Finding-Karten prüfen, dann playtesten.

Plan-Modus und Agenten-Fragen kamen mit Release 0.25.0, die Nachrichten-Warteschlange und die Finding-Karten mit 0.25.8 (https://ai-game.dev/releases/0.25.8). Die Best Practices für jede Engine unter ai-game.dev/docs/best-practices gehen weiter darauf ein, wie man Aufgaben für einen KI-Agenten zuschneidet. Die App lässt sich unter ai-game.dev/download herunterladen – probieren Sie den Plan-Modus beim nächsten Feature aus.