Mit KI ein Spiel schreiben (Die Prompt-Kunst, 2026)

Ein Spiel mit KI zu schreiben ist eine andere Fähigkeit als es zu programmieren, und die meisten Anleitungen verfehlen das, indem sie die KI als Code-Automaten behandeln. Es ist eher ein schneller, wortlicher Mitarbeiter, der genau das baut, was du schreibst, einschließlich der Teile, die du nicht gemeint hast. Das Entscheidende, ob du am Ende des Tages ein spielbares Spiel oder ein kaputtes Projekt hast, ist nicht, wie gut du programmierst. Es ist, wie gut du die Anfrage formulierst.

In dieser Anleitung geht es um diese Schreibkompetenz: das Briefing, das du verfasst, bevor du ein Tool anfasst, die Prompt-Muster, die funktionierende Mechaniken erzeugen, und die Bearbeitungsschleife, die aus einem rohen Build etwas Spielenswertes macht. Wenn du zuerst einen Überblick über KI-Spieltools möchtest, vergleicht die Ubersichtsanleitung zwanzig davon. Dieser Beitrag setzt voraus, dass du dich entschieden hast, ein Spiel zu schreiben, und es gut machen möchtest.

{/* IMAGE: Split screen. Left: a written prompt "make the Player jump 400px when I press space and play the jump sound". Right: a running 2D platformer mid-jump. An arrow labeled "you wrote this" points from text to game. 1200x630, clean editor style. */}

"Schreiben" ist jetzt der eigentliche Workflow

Den größten Teil der Geschichte der Spieleentwicklung bedeutete ein Spiel schreiben, Code zu schreiben: Variablen, Funktionen, Engine-APIs, stundenlange Syntax, bevor sich irgendetwas auf dem Bildschirm bewegte. Im Jahr 2026 ist mit einer KI-nativen Engine die tatsächliche Eingabe normales Deutsch. Du schreibst, was das Spiel tun soll, die KI schreibt die Skripte, baut die Szene auf, platziert die Nodes und führt das Spiel aus. Dann schreibst du, was als nächstes geandert werden soll.

Das ist eine echte Verschiebung darin, wer das tun kann. Der Engpass war friiher das Wissen über die Engine. Jetzt ist es, ein Spiel klar genug zu beschreiben, damit ein wortlicher Erbauer es richtig versteht. Designer haben immer Design-Dokumente geschrieben. Das Neue ist, dass das Dokument ausfuhrbar ist: Schreib es gut und es wird zum Spiel.

Summer Engine ist auf diesen Workflow ausgerichtet und kompatibel mit Godot 4, sodass das Spiel, das du schreibst, ein echtes Engine-Projekt ist, das dir gehört, und keine Sitzung, die in einem Browser-Tab eingesperrt ist. Der Rest dieser Anleitung setzt eine solche KI-native Engine voraus, denn das ist das einzige Setup, bei dem das, was du schreibst, ohne Neuaufbau in einem zweiten Tool zu einem veröffentlichbaren Spiel wird.

Schritt 1: Schreibe den Ein-Satz-Brief vor jedem Prompt

Der mit Abstand haufigste Grund, warum KI-Spielprojekte ins Stocken geraten, ist der Umfang, und der Umfang wird in dem Moment festgelegt, in dem du deinen ersten Satz schreibst. "Ein Open-World-RPG mit Crafting und Online-Multiplayer" ist kein Briefing, es ist ein Funfjahresplan, und kein noch so gutes Prompting rettet ein so großes Briefing.

Bevor du irgendetwas öffnest, schreibe einen Satz, der die kleinstmogliche Version deiner Idee beschreibt, die trotzdem Spaß macht, auf einen Knopf zu drucken:

• "Ein Quadrat, das über Rohre springt und stirbt, wenn es eines beruht."
• "Eine Figur aus der Vogelperspektive, die durch einen Raum läuft und Münzen einsammelt, bevor die Zeit ablauft."
• "Eine Karte, die sich umkehrt, wenn ich sie anklicke, und einen zufalligenWert zeigt."

Jedes davon ist ein vollständiger Spielkern, den du an einem Nachmittag ins Dasein schreiben, ausprobieren und weiterentwickeln kannst. Die große Version bleibt in deinem Kopf als Ziel. Der Satz oben ist das, was du tatsächlich zuerst schreibst. Ein prazises Briefing ist der Unterschied zwischen einem Prompt, den die KI trifft, und einem, durch den sie sich raten muss.

Schritt 2: Starte mit der nächsten Vorlage und schreibe dann Änderungen

Ein leeres Projekt zwingt die KI, deinen Spieler-Controller, deine Kamera, dein Eingabe-Setup und deine Physik allein aus deinem Prompt zu erfinden, und jedes erfundene Teil ist ein Ort für einen fruhen Fehler, um den du nicht gebeten hast. Das Starten mit einer Vorlage, die sich bereits bewegt und läuft, beseitigt dieses Risiko, bevor du eine einzige Änderung schreibst.

Wähle die Vorlage, die deinem Briefing am nahesten kommt: ein 2D-Plattformer, ein Top-Down-Mover, eine First-Person-3D-Szene. Drucke einmal auf Spielen, damit du weißt, dass der Ausgangszustand funktioniert. Von hier aus ist jeder Prompt eine kleine Bearbeitung von etwas, das bereits läuft, was für eine KI viel leichter korrekt umzusetzen ist als ein Aufbau aus dem Nichts. Wenn du unsicher bist, was passt, zeigen die 2D-Anleitung und die 3D-Anleitung die ublichen Ausgangspunkte.

Schritt 3: Schreibe pro Prompt eine testbare Mechanik

Das ist die Kernkompetenz, und die Regel ist einfach: ein Prompt, eine kleine, testbare Änderung.

Wenn du ein ganzes System in einer einzigen Nachricht schreibst, muss die KI ein Dutzend Designentscheidungen treffen, die du nie angegeben hast, und wenn etwas falsch ist, kannst du nicht sagen, welche Entscheidung es verursacht hat. Wenn du eine Mechanik schreibst, sie ausfuhrst und bestatigst, weißt du immer genau, was die letzte Änderung bewirkt hat.

Vergleiche diese zwei Arten, dieselbe Absicht zu schreiben:

• Vage: "Lass den Spieler sich bewegen und gut anfühlen und schone Physik haben."
• Prazise: "Lass den Player mit den Pfeiltasten links und rechts mit 300 Pixeln pro Sekunde bewegen und sofort stoppen, wenn ich loslasse."

Der zweite nennt den Node, die Geschwindigkeit, die Tasten und das Stoppverhalten. Es gibt nichts mehr zu raten, also gibt es nichts, das falsch laufen kann. Schreibe deine Prompts wie diesen. Ein guter Prompt nennt ein bestimmtes Objekt und ein bestimmtes, uberprufbares Ergebnis.

Eine zuverlassige Struktur für fast jeden Mechanik-Prompt:

1. Das Ding. Welcher Node oder welches Objekt: der Player, der Enemy, die Coin.
2. Der Auslöser. Was es startet: ein Tastendruck, eine Kollision, ein Timer, der Start des Spiels.
3. Das Ergebnis. Was passieren soll, mit echten Zahlen und Namen, wo sie wichtig sind.
4. Das Feedback. Was der Spieler sehen oder horen soll, damit die Änderung beim Testen sichtbar ist.

"Wenn der Player mit einer Coin kollidiert, entferne die Coin, addiere 1 zum Punktestand und spiele den Einsammel-Ton ab." Das ist das gesamte Muster in einem Satz: Ding, Auslöser, Ergebnis, Feedback. Wenn du eine grussere Sammlung dieser Muster möchtest, führt die Anleitung zu Prompt-Mustern weitere auf.

Schritt 4: Schreiben, spielen, dann wieder schreiben

Die Schleife, die Prompts in ein echtes Spiel verwandelt, hat drei Takte, und das Überspringen des mittleren ist der Weg, wie Projekte still und leise kaputtgehen.

Schreibe eine Änderung. Spiele das Spiel und beobachte genau das, worum du gebeten hast. Schreibe die nächste Änderung erst, nachdem du bestatigt hast, dass die letzte funktioniert hat.

Nach jedem Prompt auf Spielen zu drucken fühlt sich zehn Minuten lang langsam an und rettet dir dann den Nachmittag. Wenn du fünf Mechaniken schreibst und das Spiel erst dann startest, konnte ein Fehler in jeder der fünf stecken, und du ratst wieder. Wenn du nach jeder einzelnen startest, steckt der Fehler immer in der Sache, die du gerade geschrieben hast, und eine kleine, benannte Änderung ist etwas, das die KI in einem weiteren Prompt beheben kann. Behandle das Spielen als Teil des Schreibens, nicht als etwas, das du am Ende machst.

Schritt 5: Schreibe Fehlerberichte, keine Fehlerspekulationen

Wenn etwas nicht stimmt, ist der Instinkt, deine Theorie zur Ursache zu schreiben: "Die Kollisionserkennung ist kaputt, behebe den Physik-Layer." Widerstehe dem. Du kennst die Ursache normalerweise nicht, und eine falsche Vermutung schickt die KI los, das Falsche zu beheben.

Schreibe stattdessen, was du gesehen hast, wie ein Tester, der einen Bericht einreicht:

• Vermutung: "Der Sprung-Code ist kaputt."
• Bericht: "Wenn ich die Leertaste drucke, steigt der Player etwa halb so hoch wie zuvor und fallt dann durch den Boden."

Der Bericht gibt der KI das echte Symptom und lasst sie die eigentliche Ursache finden, die oft nicht dort ist, wo du sie vermutet hattest. Beschreibe, was auf dem Bildschirm passiert ist, wann, und was du stattdessen erwartet hattest. Klare Symptome ergeben saubere Korrekturen. Sichere falsche Theorien fuhren dazu, dass die falsche Datei bearbeitet wird.

Schritt 6: Schreibe die Teile, bei denen KI wirklich gut ist

Sobald dein Spielkern stabil ist, ist Schreiben auch der Weg, das Spiel auszufullen, und hier setzt sich eine KI-native Engine von einem bloßen Chat-Assistenten ab. Dieselbe Alltagssprache, die deine Bewegung aufgebaut hat, kann nach Grafiken, Sound, Levels und UI im selben Projekt fragen:

• "Generiere einen Pixel-Art-Sprite eines kleinen grünen Schleim-Feindes und verwende ihn für den Enemy."
• "Füge einen Titelbildschirm hinzu, der den Spielnamen zeigt, mit einem Start-Button, der das Spiel beginnt."
• "Erstelle drei weitere Plattformen weiter oben, damit es etwas gibt, zu dem man springen kann."
• "Füge einen kurzen, loopenden Hintergrundmusik-Track hinzu, der zu einem ruhigen Waldlevel passt."

Du schreibst weiterhin jeweils eine klare Anfrage und druckst weiterhin auf Spielen, um sie zu überprüfen. Das Genre ändert die Details, aber nicht die Kunst. Der Plattformer-Walkthrough zeigt diese Schleife von Anfang bis Ende an einem Spiel.

Was das Schreiben mit KI nicht für dich erledigt

Eine ehrliche Zeile, weil der Hype sie überspringt: Die KI schreibt das Spiel, hat aber keinen Geschmack. Sie baut genau die Schwierigkeitskurve, den Umfang und das Spielgefuhl, das du beschreibst, einschließlich eines langweiligen, und sie sagt dir nicht, dass das Spiel keinen Spaß macht. Diese Urteile gehören weiterhin dir. Die KI entfernt den langsamen Teil: Code schreiben und verdrahten. Sie entfernt nicht den Designteil: entscheiden, was es wert ist zu bauen, es ausbalancieren und streichen, was nicht funktioniert.

Das ist eine gute Nachricht für den Teil von dir, der von Anfang an ein Spiel machen wollte. Das Schreiben, mit dem du deine Zeit verbringst, ist das Design, nicht der Standardcode.

Kostenlos versus bezahlt, klar gesagt

Du kannst ein Spiel mit KI kostenlos schreiben. Summer Engine ist kostenlos zum Herunterladen und Nutzen, einschließlich 3D, Multiplayer und einem echten Export zum Teilen oder Verkaufen, mit einem kostenpflichtigen Plan nur für intensivere KI-Nutzung und Team-Funktionen. Godot ist vollständig Open Source und lasst sich mit einem kostenlosen ChatGPT- oder Claude-Konto kombinieren, wenn du bereit bist, Code manuell aus einem Chat-Fenster zu kopieren, obwohl du die eingebaute Build-Play-Fix-Schleife verlierst, die den Schreib-Workflow schnell macht.

Der Haken, auf den man in der gesamten Branche achten muss, sind jedes Mal dieselben drei Dinge: Manche Tools begrenzen, wie viele KI-Generierungen du bekommst, manche fugen ein Wasserzeichen zu deinem Build hinzu, und manche sperren den Export hinter einer Paywall. Prüfe das, bevor du etwas schreibst, das du veröffentlichen möchtest.

Fang an zu schreiben

Die gesamte Kompetenz passt in ein paar Zeilen. Schreibe ein Ein-Satz-Briefing. Starte mit der nächsten Vorlage. Schreibe pro Prompt eine kleine, testbare Mechanik, benenne das genaue Ding, den Auslöser, das Ergebnis und das Feedback. Drucke nach jeder Änderung auf Spielen. Wenn etwas bricht, schreibe, was du gesehen hast, nicht was du für die Ursache haltst. Behalte die Designentscheidungen für dich.

Das erste Spiel, das du schreibst, wird klein sein, und das ist richtig. Schreibe zuerst das Quadrat, das über Rohre springt. Dann schreibe das nächste.

Summer Engine öffnen und deine erste Zeile schreiben.