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

Ein Spiel mit KI zu schreiben ist eine andere Fahigkeit 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, einschliesslich 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 Uberblick uber KI-Spieltools mochtest, vergleicht die Ubersichtsanleitung zwanzig davon. Dieser Beitrag setzt voraus, dass du dich entschieden hast, ein Spiel zu schreiben, und es gut machen mochtest.

{/* 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 grossten 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 tatsachliche Eingabe normales Deutsch. Du schreibst, was das Spiel tun soll, die KI schreibt die Skripte, baut die Szene auf, platziert die Nodes und fuhrt das Spiel aus. Dann schreibst du, was als nachstes geandert werden soll.

Das ist eine echte Verschiebung darin, wer das tun kann. Der Engpass war friiher das Wissen uber 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 gehort, 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 veroffentlichbaren 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 grosses Briefing.

Bevor du irgendetwas offnest, schreibe einen Satz, der die kleinstmogliche Version deiner Idee beschreibt, die trotzdem Spass macht, auf einen Knopf zu drucken:

• "Ein Quadrat, das uber Rohre springt und stirbt, wenn es eines beruht."
• "Eine Figur aus der Vogelperspektive, die durch einen Raum lauft und Munzen einsammelt, bevor die Zeit ablauft."
• "Eine Karte, die sich umkehrt, wenn ich sie anklicke, und einen zufalligenWert zeigt."

Jedes davon ist ein vollstandiger Spielkern, den du an einem Nachmittag ins Dasein schreiben, ausprobieren und weiterentwickeln kannst. Die grosse Version bleibt in deinem Kopf als Ziel. Der Satz oben ist das, was du tatsachlich 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 nachsten Vorlage und schreibe dann Anderungen

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 fur einen fruhen Fehler, um den du nicht gebeten hast. Das Starten mit einer Vorlage, die sich bereits bewegt und lauft, beseitigt dieses Risiko, bevor du eine einzige Anderung schreibst.

Wahle 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 weisst, dass der Ausgangszustand funktioniert. Von hier aus ist jeder Prompt eine kleine Bearbeitung von etwas, das bereits lauft, was fur 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 Anderung.

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, weisst du immer genau, was die letzte Anderung bewirkt hat.

Vergleiche diese zwei Arten, dieselbe Absicht zu schreiben:

• Vage: "Lass den Spieler sich bewegen und gut anfuhlen 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 fur fast jeden Mechanik-Prompt:

1. Das Ding. Welcher Node oder welches Objekt: der Player, der Enemy, die Coin.
2. Der Ausloser. 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 Anderung 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, Ausloser, Ergebnis, Feedback. Wenn du eine grussere Sammlung dieser Muster mochtest, fuhrt 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 Uberspringen des mittleren ist der Weg, wie Projekte still und leise kaputtgehen.

Schreibe eine Anderung. Spiele das Spiel und beobachte genau das, worum du gebeten hast. Schreibe die nachste Anderung erst, nachdem du bestatigt hast, dass die letzte funktioniert hat.

Nach jedem Prompt auf Spielen zu drucken fuhlt sich zehn Minuten lang langsam an und rettet dir dann den Nachmittag. Wenn du funf Mechaniken schreibst und das Spiel erst dann startest, konnte ein Fehler in jeder der funf 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 Anderung 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 blossen 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 grunen Schleim-Feindes und verwende ihn fur den Enemy."
• "Fuge 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."
• "Fuge 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 uberprufen. Das Genre andert 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 fur dich erledigt

Eine ehrliche Zeile, weil der Hype sie uberspringt: Die KI schreibt das Spiel, hat aber keinen Geschmack. Sie baut genau die Schwierigkeitskurve, den Umfang und das Spielgefuhl, das du beschreibst, einschliesslich eines langweiligen, und sie sagt dir nicht, dass das Spiel keinen Spass macht. Diese Urteile gehoren 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 fur 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, einschliesslich 3D, Multiplayer und einem echten Export zum Teilen oder Verkaufen, mit einem kostenpflichtigen Plan nur fur intensivere KI-Nutzung und Team-Funktionen. Godot ist vollstandig 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. Prufe das, bevor du etwas schreibst, das du veroffentlichen mochtest.

Fang an zu schreiben

Die gesamte Kompetenz passt in ein paar Zeilen. Schreibe ein Ein-Satz-Briefing. Starte mit der nachsten Vorlage. Schreibe pro Prompt eine kleine, testbare Mechanik, benenne das genaue Ding, den Ausloser, das Ergebnis und das Feedback. Drucke nach jeder Anderung auf Spielen. Wenn etwas bricht, schreibe, was du gesehen hast, nicht was du fur die Ursache haltst. Behalte die Designentscheidungen fur dich.

Das erste Spiel, das du schreibst, wird klein sein, und das ist richtig. Schreibe zuerst das Quadrat, das uber Rohre springt. Dann schreibe das nachste.

Summer Engine offnen und deine erste Zeile schreiben.