Erstelle ein 2D-Plattformspiel mit Godot MCP: Bewegung, Level und Gegner

Ein spielbares 2D-Plattformspiel braucht normalerweise: einstellbares Bewegungs-/Sprunggefühl, ein kollidierbares Level, mindestens ein Gegnerverhalten und ein Titel-/HUD, das mit Spielfunktionen verbunden ist. Arbeite in dieser Reihenfolge. Standard-Setup: Cursor (oder Claude Code) steuert ein Godot-4-Projekt über Godot MCP.

Installation: Godot MCP Installationsanleitung.

Lege einen minimalen spielbaren Umfang fest

Erster Meilenstein:

1. Bewegen, landen, Sprunghöhe variabel (optional Doppelsprung / Dash)
2. Ein Level mit Boden, Plattformen, Stacheln oder Fallgruben
3. Ein patrouillierender Gegner, der Schaden zufügt oder zurückstößt
4. Einfaches HUD: Gesundheit oder Neustart

Grafik kann aus farbigen Platzhaltern bestehen. Wenn Menüs/HUD gestaltet aussehen sollen, verwende den Canvas-Schritt unten.

Spieler: CharacterBody2D mit einstellbarem Gefühl

Vorgeschlagenes Grundgerüst:

Player (CharacterBody2D)
├── CollisionShape2D
├── AnimatedSprite2D / Sprite2D
└── Coyote / Jump-Buffer als Skript-Timer (Baum schlank halten)

Weise MCP mit Physik- und Eingabe-Einschränkungen an:

Erstelle res://scripts/player.gd auf einem CharacterBody2D: A/D oder Pfeiltasten zum Bewegen; variable Sprunghöhe (Sprung bei Loslassen abbrechen); kurze Coyote-Zeit; nach move_and_slide() Sprunganzahl mit is_on_floor() zurücksetzen.

Danach einstellen:

Max. Geschwindigkeit ~180, Beschleunigung ~900, Sprunggeschwindigkeit ~-320 (an deine Pixel anpassen); Staub beim Bodenkontakt anzeigen.

Überprüfen: stabile Bodenprüfung, Luftsteuerung, Doppelsprung nicht auslösen, solange am Boden. Das Gefühl ist wichtiger als “Skript generiert”.

Level: TileMap-Kollision und Checkpoints

Halte die Level-Logik in der Engine:

• Solide und Gefahren-Ebenen trennen
• Bewegliche Plattformen über AnimatableBody2D oder Pfadverfolgung
• Checkpoints / Fallgruben-Area2D für Respawn

Baue ein Level aus dem vorhandenen Tileset: Sprung lehren → bewegliche Plattformen → Stachelkorridor; geheimer Heilraum hinter dem Wasserfall. Stacheln: Area2D body_entered verursacht Schaden.

Tausche Platzhalter-Tiles später gegen erstellte Grafiken aus.

Gegner: ein kleiner Zustandsautomat

Drei Zustände reichen: Idle → Patrol → Chase.

Gegner-GDScript: zwischen zwei Punkten patrouillieren; innerhalb von 120px jagen; 1,5s nach Verlust des Spielers zur Patrouille zurückkehren; body_entered verursacht Schaden mit kurzen Unverwundbarkeitsphasen.

Füge AnimationPlayer hinzu, wenn du Frames hast; andernfalls Sprite für Blickrichtung spiegeln.

UI: AI Studio einsetzen, wenn du fertige Bildschirme brauchst

Bis das Gameplay funktioniert, Platzhalter-Label / ProgressBar über MCP:

Binde das health_changed-Signal des Spielers an die HUD-Leiste; bei Tod zeige Neustart und reload_current_scene() an.

Wenn Titel-/Einstellungs-/Inventar-UI designreif sein soll (PSD/Figma, NL-generierte Panels, Ebenenaufteilung, Godot-bereiter Export), verwende VberAI Studio:

1. Menüs/HUD in Studio generieren oder importieren
2. Export nach z.B. res://ui/
3. Buttons/Signale mit Cursor + Godot MCP verbinden

Harte Ausschnitte → Super Matting, dann Studio. Canvas besitzt die UI-Struktur; MCP besitzt Gameplay-Bindungen – erwarte kein vollständiges player.gd vom Canvas.

Vorgeschlagene Reihenfolge

MCP: Spieler-Gefühl → ein kollidierbares Level → ein Gegner → Platzhalter-HUD
        ↓ (optional)
AI Studio: fertiges Titel-/HUD → Export
        ↓
MCP: fertige UI an Gesundheit / Pause / Neustart binden

Vor größeren Änderungen committen; MCP auf localhost halten.

Abnahmekriterien

• Kurzer vs. langer Sprung fühlt sich unterschiedlich an
• Fallgrube/Stacheln geben klares Fehler-Feedback
• Gegner-Patrouille kollidiert nicht mit Wänden
• HUD oder Neustart funktioniert nach dem Tod
• (Optional) Studio-UI hat Platzhalter ersetzt

Nächste Schritte

1. Godot MCP Installation
2. “Bewegung + ein Level + ein Gegner” ausliefern
3. AI Studio nur öffnen, wenn du fertige UI brauchst

Auch: Godot MCP vs. manuelles Skripting.