Spiel mit KI erstellen: ohne Programmieren zum fertigen Browserspiel

Du kannst ein Spiel mit KI erstellen, ohne eine Zeile Code zu schreiben: Beschreibe deine Idee als Text, und Zugo baut daraus in etwa einer Minute ein lauffähiges 2D-Spiel. Jeder Build läuft vorher durch eine Sandbox — „geprüft" heißt hier, dass das Spiel wirklich geladen und gerendert hat. Danach verfeinerst du es mit kurzen Textanweisungen und veröffentlichst es per Klick auf dein-spiel.zugo.run. Gratis-Credits, keine Kreditkarte.

Das ist die ganze Schleife. Der Rest dieses Leitfadens ist die praktische Fassung: welche Genres einen Textprompt überleben, die konkreten Schritte in Zugo, wie aus einem korrekten Build ein Spiel wird, das sich gut anfühlt — und die ehrliche Liste dessen, was noch nicht geht.

Welche Genres funktionieren mit einem Textprompt wirklich?

Nicht jede Idee kommt beim ersten Versuch spielbar zurück. Das Muster ist simpel: 2D-Spiele auf einem Bildschirm mit klaren Regeln funktionieren, alles was 3D, streamende Welten oder Live-Netcode braucht, nicht. Unten steht, was wir dem Builder pro Genre mitgeben und was du prüfst, sobald der Build lädt.

Diese fünf funktionieren, weil jedes einen kleinen, prüfbaren Regelsatz hat. Wenn du „Tod bei Selbstkollision" schreibst, gibst du der KI eine Bedingung, die sie programmieren und die Sandbox testen kann. Vage Prompts wie „mach es spaßig" haben nichts, wogegen sich prüfen ließe. Fang konkret an, Geschmack kommt später.

Wie erstellt man Schritt für Schritt ein Spiel in Zugo?

Der Ablauf ist für jedes Genre gleich. Fünf Schritte, die meisten davon ohne dein Zutun.

1. Formuliere die Idee in ein bis zwei Sätzen. Nenne Genre, Ziel und Verlustbedingung. „Ein Snake-Spiel auf einem 20-mal-20-Raster, Punkte pro Futter, du stirbst wenn du deinen Schwanz triffst, Steuerung mit den Pfeiltasten." Mehr braucht es nicht. Du schreibst keine Spezifikation, du gibst dem Modell etwas Prüfbares.

2. Schalte den Plan-Modus ein. Bevor Zugo Code schreibt, legt der Plan-Modus offen, was gebaut werden soll: Mechaniken, Screens, Sieg- und Verlustzustände. Lies das. Hier ist der billigste Ort, ein Missverständnis zu fangen — eine Zeile im Plan zu ändern kostet nichts, einen fertigen Build zu reparieren kostet einen Rebuild. Steht dort „endlos", du wolltest aber Level, sag es jetzt.

3. Verfolge Live-Log und Checkpoints. Während des Bauens zeigt das Live-Log, was Zugo gerade tut, und Checkpoints sichern das Projekt an jeder sinnvollen Stelle. Bricht eine spätere Änderung etwas, springst du auf einen Checkpoint zurück statt neu anzufangen. Du starrst nicht auf einen Spinner, du siehst das Spiel entstehen.

4. Hol dir einen Sandbox-geprüften Build. Zugo lässt jeden Build in einer Sandbox laufen, bevor du ihn bekommst, und markiert ihn erst als „geprüft", wenn er tatsächlich geladen und gerendert hat. Genau diesen Teil überspringen die meisten Text-zu-Spiel-Demos. Ein Build, der kompiliert, ist nicht dasselbe wie ein Build, der läuft: „geprüft" heißt hier, das Spiel ist gestartet und hat sein erstes Bild gezeichnet. Spiel es in der Vorschau an, um das Gefühl zu prüfen.

5. Veröffentliche per Klick. Wenn es sich richtig anfühlt, drückst du auf Veröffentlichen, und das Spiel liegt live auf dein-spiel.zugo.run. Diesen Link kannst du teilen — kein Build-Schritt, kein Hosting-Setup. Mit Pro zeigst du stattdessen eine eigene Domain darauf.

Wenn du lieber von etwas Fertigem ausgehst: In der Showcase-Galerie liegen Projekte, die du öffnen und umbauen kannst, dazu 25 Vorlagen in 5 Kategorien.

Wie macht man aus einem korrekten Spiel ein gutes?

Ein erster Build spielt korrekt, fühlt sich aber meist flach an. „Juice" ist die Rückmeldeschicht, die dieselben Mechaniken befriedigend macht, und du fügst sie mit einfachen Textanweisungen hinzu — eine nach der anderen.

Die Regel „eine nach der anderen" ist wichtig. Wenn du Partikel, Sound und eine neue Schwierigkeitskurve in einer Nachricht verlangst und das Ergebnis sich falsch anfühlt, weißt du nicht, welche Änderung schuld war. Kleine Schritte halten jeden Checkpoint diagnostizierbar.

Gute erste Änderungen, in dieser Reihenfolge:

• Partikel und Bildschirm-Feedback. „Lass Partikel spritzen, wenn der Ball einen Stein zerstört" oder „blitze den Bildschirm rot auf, wenn der Spieler getroffen wird." Wucht liest sich sofort.
• Sound. „Füge einen kurzen Ton beim Fressen hinzu und einen tieferen bei Game over." Selbst einfache Töne verändern das Spielgefühl stärker als die meisten optischen Anpassungen.
• Schwierigkeitskurve. „Lass Gegner alle 30 Sekunden 15 Prozent schneller spawnen" oder „füge alle fünf Runden eine Boss-Welle hinzu." Zahlen stellst du ein, indem du sie direkt nennst.

Nach jeder Änderung: nochmal spielen. Ist es schlechter, springst du auf den letzten Checkpoint zurück und formulierst anders. In dieser Schleife wird aus einem generischen Build dein Spiel.

Was lässt sich mit KI noch nicht bauen?

Die ehrlichen Grenzen, denn so zu tun als gäbe es sie nicht, verbrennt nur Credits. Zugo baut 2D-Spiele, die im Browser laufen. Drei Kategorien liegen bewusst außerhalb:

• 3D-Ego-Shooter. Sie brauchen eine 3D-Engine, Asset-Pipelines für Modelle und Texturen und ein Leveldesign, das kein einzelner Prompt gut beschreibt. Zugos Ausgabe ist 2D, ein Doom-Klon steht nicht auf der Karte.
• Offene Welten. Große streamende Karten, Persistenz über Sitzungen hinweg und hunderte ineinandergreifende Systeme sind mehr, als ein schneller KI-Build erzeugen und prüfen kann. Ein kleines begehbares Level ja, ein Kontinent nein.
• MMOs und Echtzeit-Multiplayer. Live-Netcode, autoritative Server, Matchmaking und Moderation sind laufende Infrastruktur, keine einmalige Generierung. Eine gemeinsame Bestenliste ist realistisch, synchrones Echtzeitspiel zwischen Fremden nicht.

Fällt deine Idee in einen dieser Töpfe, ist ein Text-zu-Spiel-Builder die falsche Werkzeugklasse dafür: Diese Arbeit gehört in eine echte Spiel-Engine mit einer Entwicklerin oder einem Entwickler, und das ist ein anderer Beruf. Diese Grenze offen zu benennen ist besser, als sie nach drei gescheiterten Builds selbst zu entdecken.

Wie finden Spieler das Spiel, und wie tritt man gegeneinander an?

Das Veröffentlichen gibt dir eine öffentliche Adresse, damit ist das Teilen erledigt. Wettbewerb braucht einen Ort für die Punktestände.

Für eine einfache Bestenliste ist Zugo Cloud die eingebaute Datenbank. Du bittest um eine Highscore-Tabelle, die Punkte landen in Cloud, und alle, die deinen Link öffnen, sehen dieselbe Liste. Dafür brauchst du keinen externen Account.

Für echte Spielerkonten, bei denen Leute sich anmelden und ihren Fortschritt geräteübergreifend behalten, nimmst du den Supabase-Connector. Er bringt eine vollständige Datenbank plus Anmeldung, sodass du Speicherstände hinter einem Login schützen und dauerhafte Profile bauen kannst. Das ist eine Stufe mehr Komplexität — bau es ein, wenn das Spiel selbst steht, nicht vorher. Und wenn du dem Builder eines Tages entwächst, gibt dir der GitHub-Export ein echtes Repository mit src, package.json und vite.config, mit dem jede Entwicklerin weiterarbeiten kann.

Was kostet der Einstieg?

Zum Ausprobieren nichts. Zugo gibt Gratis-Credits ohne Kreditkarte, genug für ein erstes Spiel samt Veröffentlichung. Wenn du mehr willst, kostet Pro 25 US-Dollar im Monat für 200 Credits. Abgerechnet wird pro Aktion — eine Änderung 1, ein frischer Build 6, eine mehrseitige Plattform 12 —, 200 Credits sind also 33 schnelle Builds, 16 volle Plattformen oder 66 Änderungen, dazu eigene Domains. Business liegt bei 99 US-Dollar im Monat mit 800 Credits. Die Details stehen auf der Preisseite.

Am schnellsten verstehst du das alles, indem du es laufen lässt. Öffne Zugo, tippe einen Satz über ein Snake- oder Arcade-Spiel und sieh dir den ersten geprüften Build an. Wenn du danach etwas anderes bauen willst: Es gibt begleitende Anleitungen zum Erstellen einer Website mit KI und zum App-Bau ohne Programmieren.