Das beste KI-Modell für Spiele

Es gibt nicht das eine beste KI-Modell für Videospiele, denn ein Spiel zu machen ist nicht eine Aufgabe, sondern viele: Spiellogik schreiben, Fehler beheben, Level gestalten, Grafik erzeugen, Sound machen und alles so verbinden, dass es läuft. Verschiedene Modelle sind bei verschiedenen Teilen stärker, und die Ranglisten verschieben sich alle paar Monate, wenn neue Versionen erscheinen.

Statt einem Sieger hinterherzujagen, der schnell überholt ist, konzentrier dich auf das, was Qualität wirklich ausmacht. Sobald du das siehst, kannst du jedes Werkzeug und jedes Modell selbst beurteilen.

Ein rohes Modell sagt Text voraus. Damit aus einem Prompt ein Spiel wird, das läuft, muss das System drumherum planen, Dateien bearbeiten, Code prüfen und Fehler reparieren. Dieses System entscheidet, ob du etwas Spielbares bekommst oder eine Wand aus kaputtem Code.

Zu einem solchen System gehören in der Regel:

• Klare Regeln, die dem Modell die Struktur eines Spiels vorgeben, statt nur einen nackten Prompt weiterzureichen.
• Vorlagen und Startcode, damit das Modell grundlegende technische Bausteine nicht jedes Mal neu erfinden muss.
• Eine Möglichkeit, den generierten Code auszuführen, Fehler zu erkennen und sie zurückzugeben, damit das Modell seine eigenen Fehler beheben kann.
• Grafikgenerierung eingebunden und Sound aus der Bibliothek, sodass die Assets im Spiel laden.
• Codeprüfung plus Spieltest im Browser, wobei ungetestete Ergebnisse als nicht verifiziert markiert werden.

Zwei Produkte können dasselbe zugrunde liegende Modell verwenden und dennoch völlig unterschiedliche Ergebnisse liefern, weil nur eines über ein starkes umgebendes System verfügt. Deshalb sagt der Benchmark-Wert eines isolierten Modells wenig darüber aus, wie gut ein Werkzeug zur Spieleentwicklung funktioniert.

Hier eine grobe Übersicht, wo Modelle helfen, bewusst allgemein gehalten, weil Details schnell veralten:

• Codeerzeugung: Größere, leistungsfähigere Modelle erzeugen oft zuverlässigere Spiellogik und beheben Fehler besser. Hier lohnt sich ein stärkeres Modell am ehesten.
• Kostengünstiges Iterieren: Ein günstigeres Modell kann gut zu einer kleinen, klar umrissenen Änderung passen. Seine Antwortzeit hängt von Aufgabe, Werkzeugen, Denkaufwand und Anbieterauslastung ab; kleiner heißt also nicht immer schneller.
• Grafik und Bilder: Bildmodelle sind eine eigene Familie, getrennt von Textmodellen. Das Textmodell, das deine Spiellogik schreibt, zeichnet nicht deine Sprites.
• Ton und Musik: Auch dafür gibt es eigene Spezialmodelle, aber Ton und Musik stammen aus einer Bibliothek echter Aufnahmen.

In der Praxis beherrscht kein einzelnes Modell all diese Aufgaben gleich gut. Ein ernst zu nehmendes Werkzeug kombiniert deshalb mehrere Modelle, statt alles auf eines zu setzen.

Jeder Artikel, der einen dauerhaften Sieger ausruft, altert schnell. Neue Versionen erscheinen oft, und ein Modell, das in einem Quartal vorn liegt, kann im nächsten zurückfallen. Der Rangliste hinterherzujagen ist ein schwacher Weg, ein Werkzeug fürs Spielemachen auszusuchen.

Dauerhafter hilft es, bessere Fragen zu stellen. Führt das Werkzeug den Code, den es schreibt, aus und testet ihn? Kann es sich von eigenen Fehlern erholen? Liefert es etwas, das du spielen kannst, und nicht einen Schnipsel, den du selbst zusammensetzen musst? Diese Eigenschaften überdauern jede einzelne Modellversion.

OddShed ist um diese Idee herum gebaut. Statt dich ein Anbietermodell auswählen zu lassen, bekommt jedes Konto dasselbe Agenten-Team: Ein Builder schreibt den Code, ein Artist zeichnet die Grafik, ein Sounddesigner wählt Soundeffekte und Musik, und ein QA-Tester probiert jeden Build wenn möglich im Browser aus. Die Modelle dahinter wählt OddShed für dich.

OddShed baut Browserspiele mit Phaser für 2D und Three.js für 3D, und jeder Durchlauf zeigt nach dem Abschluss genau, was er gekostet hat. Im Mittelpunkt steht das System, nicht ein Modellname.

• Es gibt kein einziges bestes Modell. Die Antwort hängt von der Aufgabe ab und ändert sich schnell.
• Für ein spielbares Ergebnis ist das System rund um das Modell wichtiger als dessen Name.
• Stärkere Modelle helfen am meisten bei der Codegenerierung und Fehlerbehebung; leichtere Modelle sind für kleine Änderungen geeignet.
• Beurteil ein Werkzeug danach, ob es seine eigene Ausgabe ausführt, testet und repariert, nicht danach, welches Modell es angeblich nutzt.