VberAI End-to-End: AI Studio + Engine MCP für ein spielbares Mini-Spiel

Für Indie-Entwickler und kleine Teams ist der Engpass selten „kann keine einzige Zeile Code schreiben“. Meist laufen zwei Aufgaben parallel:

1. UI- und Art-Struktur landet nie sauber in der Engine – Comps zerschneiden, Canvas-/Control-Bäume neu aufbauen, falsche Namen und Hierarchien
2. Gameplay und Skripte sind teuer zu iterieren – Komponenten neu verbinden, Fehler verfolgen, Play starten – Stunden gehen für repetitive Editor-Arbeit verloren

VberAI teilt diese Aufgaben in zwei Ebenen. Es behauptet nicht „ein Knopf, fertiges Spiel“:

Ebene	Produkt	Aufgabe
Canvas → Engine-UI	AI Studio	Spiele-UI aus natürlicher Sprache generieren oder PSD/Figma importieren; zerschneiden, matten, bearbeiten, dann zu Unity, Godot, Cocos Creator synchronisieren/exportieren
Engine ↔ AI-IDE	Engine MCP (Unity / Godot / Cocos)	Den geöffneten Editor aus Cursor, Claude Code, Codex und ähnlichen Clients steuern: Logik, Skripte, Debug, Vorschau

Der Rest dieses Leitfadens ist ein produktionsnaher Weg für einen spielbaren 0–1-Prototyp und für spätere Überarbeitungszyklen.

End-to-End-Pipeline

Gameplay-Ziel / Design-Datei / NL-UI-Brief
        │
        ├─→ AI Studio (generieren · importieren · zerschneiden · matten · komponentisieren · exportieren)
        │         ↓
        │    UI-Hierarchie / Prefabs / Szenen-Assets im Engine-Projekt
        │
        └─→ AI-IDE + Engine MCP (Szene lesen · Skripte schreiben · verdrahten · Play/Debug)
                  ↓
             Demo-fähiger Gameplay-Prototyp → zurück zu Studio oder weiter mit MCP je nach Änderungstyp

Faustregeln:

• UI-Struktur zuerst auf der Canvas richtig machen, bevor tiefe Engine-Verdrahtung beginnt
• Verhalten und Zahlen in der Engine behalten; Menschen bewerten Play-Ergebnisse
• Vor großen Änderungen committen; die MCP-Brücke nur auf localhost laufen lassen

AI Studio: Engine-bereite UI-Assets

AI Studio ist für Spiel-UI / Interface-Struktur – kein generischer Chat-Box, und kein Ersatz für Kampf-Zustandsmaschinen in der Engine.

Pfad 1: UI aus natürlicher Sprache (noch keine Design-Datei)

Hilf mir, ein Chibi-Match-3-Spiel zu designen

Dann auf der Canvas prüfen: Ziele vs. Deko, Namen, an die Skripte binden können, Layout unter Zielauflösungen. Demo unten:

Pfad 2: PSD / Figma / Projekt-Assets importieren (Design existiert)

1. Ebenen-Comps oder vorhandene UI importieren
2. AI-Split in Panels, Listenelemente, Dialograhmen
3. Harte Kanten (Haare, Glow, halbtransparent) bei Bedarf per AI Super Matting, dann zurück zu Studio
4. Komponentisieren und synchronisieren / exportieren nach Unity, Godot oder Cocos Creator

Demo von PSD-/Figma-Import und -Split:

Was dieser Schritt produziert

Produziert	Produziert nicht
Montierbare UI-Hierarchie, Texturen, Prefab-/Szenenstruktur	Vollständige Kampf-FSMs, Netcode-Autorität, Speichersysteme

Tieferes Handoff-Beispiel: Figma zu Unity-UI.

Engine MCP: Dialoggesteuerte Logik und Editor-Arbeit

MCP (Model Context Protocol) erlaubt einer AI-IDE, lokale Tools aufzurufen. VberAIs Engine-Plugins legen den geöffneten Editor dem Client offen: Szenen/Knoten, Skripte, Debug- und Vorschau-Hilfen – nicht nur Dateien ins Repo einfügen.

Je nach Engine auswählen und installieren:

• Unity MCP · Installationsanleitung
• Godot MCP (Open Source) · Installationsanleitung
• Cocos 3.x / 2.x · 3.x-Installation · 2.x-Installation

Vergleich: Godot MCP vs Unity MCP vs Cocos MCP.

Demo: Nach Studio-Export liefert Cursor + Godot MCP ein Chibi-Match-3

Weiter mit Pfad 1: Die UI ist bereits von AI Studio in Godot. Godot MCP in Cursor verbinden und den Editor in natürlicher Sprache steuern – ohne eine einzige Zeile Code von Hand zu schreiben – um das Chibi-Match-3-Gameplay zu implementieren und bis zum spielbaren Zustand zu debuggen. Aufnahme unten:

Gute Anwendungsfälle für MCP

• Testbare Gameplay-Prototypen: Spielersteuerung, einfacher Kampf, Gegnerzustände, Quest-Verdrahtung
• Stapel-Umbenennungen in Hierarchie/Szenenbaum, Komponenten anhängen, Studio-exportiertes HUD an Events binden
• Innerhalb der Plugin-Grenzen: Logs, Auswahlkontext, kleine reversible Änderungen, dann Play

Weniger geeignet

• Ungeprüfte Multiplayer-Autorität oder komplette Render-Pipeline-Umschreibungen
• „Ein Prompt, fertiges kommerzielles Spiel“
• Art Direction und Feel-Entscheidungen ersetzen – das braucht weiterhin Menschen im Play-Modus

Ausgearbeitete Beispiele: 3D-RPG mit Unity MCP, 2D-Plattformer mit Godot MCP.

0–1: Ein minimaler Weg

Ziel ist ein in Stunden demo-fähiger Prototyp, keine Feature-Liste.

1. Prototyp abgrenzen – z. B. „bewegen + ein Gegner + ein HUD“ oder „ein Plattform-Level + Neustart“
2. MCP installieren und Read-only-Smoke – Szenenwurzeln auflisten; bestätigen, dass die AI-IDE verbunden ist
3. Platzhalter-UI oder Gameplay zuerst – Labels/Slider, solange Systeme unfertig sind; AI Studio öffnen, wenn Menüs/HUD fertig aussehen müssen
4. Logik per MCP vorantreiben – ein Anliegen pro Prompt: Steuerung → Schaden → Gegner → Fehl-/Quest-Bedingungen
5. UI bei Bedarf polieren – Studio-Export → MCP bindet Buttons und Wert-Events
6. Play-Abnahme – Feel, Kollision, UI-Refresh; bei Fehlern Prompt eingrenzen und erneut versuchen

Schnelle Iteration: Schleife je nach Änderungstyp wählen

Änderung	Bevorzugt
Feel, Zahlen, KI, Navigation, Skript-Bugs, Knoten-Verdrahtung	AI-IDE → Engine MCP
Vollbild-Visuals, Reskin, Ebenen-Split, Prefab-Re-Export	AI Studio (+ Matting falls nötig)
Immer noch „Comps kommen nicht in die Engine“	Erst Studio-Struktur, dann MCP

Der erwartete Gewinn ist konkret: weniger UI-Neuaufbau von Grund auf im Editor und weniger repetitives Klicken. Es ersetzt weder Design-Urteilsvermögen noch Testen.

Team-Checkliste

• Lizenzierung: Unity-/Cocos-MCP folgen der offiziellen Aktivierung; Godot MCP kann Gewohnheiten per Open Source validieren
• Sicherheit: MCP-Server nur auf 127.0.0.1
• Prompts mit Abnahmekriterien: Pfade, Anbindungspunkte, was Play in ~10 s zeigen soll, Out-of-Scope-Refactorings
• Review: Generierte Skripte und Knoten-Edits immer Play-testen – MCP senkt Betriebskosten, nicht QA

Fazit

VberAIs nützliche Geschichte ist eine Aufteilung hochfrequenter Schmerzpunkte – nicht „Vollautomatisierung“:

• AI Studio: natürliche Sprache oder PSD/Figma → UI-Struktur für Unity / Godot / Cocos
• Engine MCP: natürliche Sprache in einer AI-IDE → In-Editor-Logik, Skripte, Debug, Vorschau

Nutze die richtige Schleife, und 0–1-Prototypen sowie Überarbeitungszyklen laufen schneller. Überschreite die Grenze (Canvas schreibt Kampf-FSMs, MCP zerschneidet ganze UI-Pakete) und du erzeugst Nacharbeit. Übernimm eine Ebene oder beide je nach Projektphase – du brauchst nicht jedes Produkt am ersten Tag.