Spiele im Zeitalter der Superintelligenz entwickeln: ein Plan für die erste spielbare Version

Eine Spielidee kann mehrere Agenten durchlaufen, bevor ein Spieler sie sieht. Ein Agent entwirft ein Level, ein anderer schreibt Code und ein dritter prüft den Build. Entscheidend ist nicht die Zahl der Dateien. Entscheidend ist, ob jemand eine Runde spielen und danach noch eine beginnen möchte.

Beginne mit einer kleinen Vereinbarung: Was wird gebaut und wie wird es geprüft? Das kostenlose Briefing-Tool auf dieser Seite fragt nach Spieleraktion, Ziel, Spielende, Perspektive, Steuerung und erster Plattform. Es exportiert ein Markdown-Briefing zum Teilen und einen JSON-Plan für andere Werkzeuge. Beides ist ein Ausgangspunkt für den Bau des Spiels.

Was „Superintelligenz“ hier bedeutet

Superintelligenz ist eine Möglichkeit für die Zukunft. Ein heutiger KI-Assistent oder Agent kann in einem Spielprojekt arbeiten. Die Bezeichnung „SI-Spiel-Engine“ belegt jedoch nicht, dass ein Produkt allein ein gutes Spiel entwerfen, bauen, testen und veröffentlichen kann. Frage, welche Dateien und Zustände ein Werkzeug lesen und ändern kann, ob es das Spiel ausführt und welche Ergebnisse es nach einer Änderung zeigt.

Heutige Arbeitsabläufe sind konkret. Godot dokumentiert das Starten und Exportieren von Projekten per Kommandozeile, was wiederholbare Build-Tests ermöglicht. Unity dokumentiert das Assistant-Paket: Ask dient zum Nachfragen, Agent kann je nach Berechtigung Szenenobjekte und Assets bearbeiten. Epic dokumentiert Unreal MCP als experimentelle Editor-Funktion für kompatible Agenten; Funktionen und APIs können sich ändern. Das sind heutige Arbeitsweisen, die du an einem laufenden Projekt prüfen kannst.

Die erste spielbare Version festlegen

Beschreibe eine Runde statt aller Funktionen des späteren Spiels. Wer wird gesteuert? Was tut die Person? Wann gewinnt sie, wann endet der Versuch und wie startet sie neu? Wähle einen Ort und eine Zielplattform. Läden, viele Level, Konten, Mehrspieler und eine lange Handlung können warten, wenn sie für die Kernaktion nicht nötig sind.

Schreibe einen umsetzbaren Satz: „Überquere eine Straße, sammle drei Funken und erreiche die Tür, ohne einen Wagen zu berühren.“ Ergänze die Entscheidungen: Seitenansicht, Tastatur, Browser-Build, klare Rückmeldung bei Erfolg und Misserfolg sowie Neustart. Ein visueller Stil hilft, aber der erste Meilenstein ist eine spielbare Runde.

Beispiel: Lantern Run

Lantern Run ist ein kleines Spiel in Seitenansicht. Eine Kurierin läuft über eine regennasse Straße, weicht Pfützen aus und sammelt drei Funken. Mit allen drei Funken an der Tür gewinnt sie. Berührt sie einen fahrenden Wagen, endet die Runde. Für die erste Version reichen eine Straße, eine Figur, drei Funken, ein Wagen, ein sichtbarer Zähler und ein Neustart.

Gib der bauenden Person oder dem Agenten beobachtbare Prüfschritte:

1. Öffne den Browser-Build. Der Spielbereich lädt ohne blockierenden Fehler.
2. Nutze die Tastatur. Die Figur bewegt sich, weicht Pfützen aus und sammelt Funken; der Zähler ändert sich.
3. Erreiche die Tür mit weniger als drei Funken. Das Spiel meldet keinen Sieg.
4. Erreiche die Tür mit drei Funken. Das Spiel zeigt einen klaren Erfolg.
5. Berühre den Wagen. Die Runde endet mit klarer Rückmeldung. Starte neu und spiele eine frische Runde.
6. Öffne den exportierten Build außerhalb des Editors. Bitte eine neue Person, ohne Anleitung eine Runde zu beenden.

Diese Schritte schreiben weder Code noch Engine vor. Sie beschreiben, was im laufenden Spiel stimmen muss. Fehlt ein Ergebnis, ist die nächste Korrektur klar.

Eine Engine für den Build auswählen

Vergleiche Engines anhand dieses Spiels: Perspektive, Eingabe, Zielplattform, Exportweg und Zugriff auf Projektdateien. Teste früh einen kleinen Export, bevor du viel Zeit investierst. Browser und Desktop können andere Einstellungen und Eingaben brauchen. Prüfe die Anleitung für die tatsächlich verwendete Engine-Version.

Wenn du mit Summer bauen möchtest, lies den Leitfaden zur KI-Spiel-Engine, den Leitfaden zum Godot-KI-Agenten und die MCP-Einrichtung. Diese Seiten erklären den Ablauf in Summer. Das Briefing auf dieser Seite eignet sich auch für andere Engines. Bewahre Projektdateien und exportiertes Paket auf, damit andere das Ergebnis prüfen können.

Arbeit übergeben, die ein Agent belegen kann

Gib dem Agenten das Briefing und jeweils eine Aufgabe. „Lass die Kurierin per Tastatur laufen und zeige die laufende Szene“ lässt sich gut prüfen. Bitte um die geänderten Dateien, das Ergebnis des Starts oder Builds und eine kurze Notiz zu offenen Problemen. Spiele nach jeder wesentlichen Änderung selbst.

Führe neben dem Briefing eine Asset-Liste. Halte für jedes Bild, Modell, Geräusch und jede Schrift die Quelle sowie die Lizenz oder Nutzungsbedingungen fest. Wenn Quelle oder erlaubte Nutzung unklar sind, ersetze das Asset vor der Veröffentlichung.

Den getesteten Build prüfen und veröffentlichen

Führe die Prüfschritte im Editor aus und wiederhole die Runde im exportierten Paket auf der Zielplattform. Achte auf fehlerhafte Eingaben, fehlende Dateien, schwer lesbare Rückmeldungen, Tonprobleme und einen Neustart, der alte Zustände behält. Sieh einer neuen Person beim Spielen zu, ohne die Regeln zu erklären. Notiere, was sie zuerst versucht und wo sie stockt.

Wenn der Build scheitert, formuliere eine einzelne sichtbare Korrektur und teste erneut. Besteht er die Schritte, hast du eine erste spielbare Version und eine Grundlage für die nächste Funktion. Künftige KI könnte mehr Arbeit übernehmen. Heute zählt das prüfbare Ergebnis: Jemand öffnet das Spiel, versteht die Aktion, beendet eine Runde und kann noch eine spielen.