Spielentwicklungs-Anforderungen für KI: Szene, Knoten, Komponenten und Interaktionen beschreiben

Wenn Sie der KI sagen „Implementiere eine Sprungfunktion“, erhalten Sie einen Haufen nicht lauffähiger Codefragmente. Sie möchten ein vollständiges Spiellevel erstellen, wissen aber nicht, wie Sie die Node-Tree-Struktur erklären sollen – die von der KI generierte Hierarchie ist chaotisch.

Das Problem liegt nicht an den Fähigkeiten der KI. Ein vager Prompt ist wie Kochen nach Rezept ohne Zutatenliste – die KI muss improvisieren, und das Ergebnis weicht stark von Ihrer Vorstellung ab.

Spielentwicklungs-Anforderungen lassen sich tatsächlich standardisieren. Szene, Knoten, Komponenten und Interaktion – zu diesen vier Kernkonzepten gibt es passende Beschreibungsvorlagen. Dieser Artikel stellt eine praxiserprobte Methodik vor: die Vier-Elemente-Methode für Szenen, das Node-Tree-JSON-Format, Komponenten-Beschreibungsvorlagen, die Fünf-Elemente-Formel für Interaktionen – plus 5 Prompt-Vorlagen zum direkten Kopieren.

Wenn Sie mit Cocos Creator Mini-Spiele entwickeln und die KI zur Effizienzsteigerung nutzen möchten, aber immer wieder scheitern, finden Sie hier die Antworten.

Warum Spiel-Anforderungen standardisiert beschrieben werden müssen

Vage Anforderungsbeschreibungen sind der größte Feind bei der KI-gestützten Spieleentwicklung. Ich habe einmal einfach gesagt „Hilf mir, eine Sprungfunktion zu implementieren“ – die KI lieferte Code mit player.y += 10: kein Physiksystem, keine Kollisionserkennung, keine Animationsübergänge. Beim Ausführen teleportierte sich der Charakter direkt in den Himmel.

Diese Probleme haben drei typische Symptome.

Erstes Problem: Die KI versteht die Node-Hierarchie nicht. In Cocos Creator erstellen Sie einen Player-Knoten mit einem HealthBar-Unterknoten für die Lebensanzeige. Sagen Sie aber nur „Erstelle einen Spieler“, weiß die KI nicht, dass HealthBar als Unterknoten existieren muss – sie platziert HealthBar möglicherweise als eigenständigen Knoten im Szenen-Root. Beim Ausführen folgt die Lebensanzeige dem Spieler nicht.

Ein Vergleich:

❌ „Erstelle einen Spieler"
✅ „Erstelle Player-Root-Knoten, Sprite-Komponente für Charakter-Textur, Unterknoten HealthBar für Lebensanzeige, relative Position (0, 32)"

Die zweite Version macht die Eltern-Kind-Beziehung klar – die von der KI generierte Hierarchie bleibt ordentlich.

Zweites Problem: Chaotische Komponenten-Kombinationen. Die Kernarchitektur von Cocos Creator ist „Knoten + Komponenten“ – der Knoten selbst ist eine leere Hülle, Komponenten verleihen Funktionen. Ein Player-Knoten kann Sprite (Textur), RigidBody2D (Physik), Collider (Kollision) und PlayerScript (eigene Logik) tragen. Sagen Sie nur „Lass den Charakter sich bewegen“, liefert die KI vielleicht nur ein Bewegungsskript ohne Physik-Komponenten – der Charakter läuft durch Wände, ohne Kollisionsfeedback.

Die richtige Beschreibung listet die Komponenten auf:

❌ „Lass den Charakter sich bewegen"
✅ „Player-Knoten mit RigidBody2D (type: dynamic), Unterknoten Collider (tag: 'player'), plus PlayerScript für Tastatureingabe"

Drittes Problem: Fragmentierte Interaktionslogik. Bei „Klick auf Button zum Springen“ liefert die KI Event-Listener-Code – aber Sprungdauer, Sprunghöhe, ob während des Sprungs erneut gesprungen werden kann, und wie der Zustand danach zurückgesetzt wird, fehlen. Der Charakter bewegt sich zwar, aber Animationen ruckeln, Zustände blockieren, Doppelklicks verursachen Bugs.

Eine vollständige Interaktionsbeschreibung enthält fünf Elemente: Auslösebedingung, Event-Typ, Zielobjekt, Reaktionsverhalten und Zustandsänderung. Details folgen später – merken Sie sich die Formel:

Interaktionsbeschreibung = Auslösebedingung + Event-Typ + Zielobjekt + Reaktionsverhalten + Zustandsänderung

Die Wurzel vager Beschreibungen ist fehlendes strukturiertes Denken. Die KI braucht klaren Kontext, konkrete Anweisungen und eindeutige Randbedingungen. Das CREATE-Framework aus dem Prompt-Engineering – ursprünglich Best Practice für allgemeine Programmierung – funktioniert auch in der Spieleentwicklung:

Feld	Anwendung in der Spieleentwicklung
C - Context	Engine-Version (Cocos Creator 3.8), Projektstruktur, bestehender Codestil
R - Role	KI als „Cocos-Creator-Entwicklungsexperte” definieren
E - Example	Beispiel für erwartetes Node-Tree-JSON-Format
A - Action	Klarstellen, was zu tun ist (Knoten erstellen, Komponenten mounten, Events abhören)
T - Tone	Codestil angeben (TypeScript + Cocos-Creator-API)
E - Edge	Randbedingungen (FPS ≥ 60, Knotenanzahl ≤ 50)

Die Kernlogik: „Was tun” in „unter welchen Bedingungen”, „mit welchen Werkzeugen” und „nach welchem Standard” zerlegen. Die folgenden vier Kapitel setzen das CREATE-Framework für Szene, Knoten, Komponenten und Interaktion in kopierbare Vorlagen um.

Die Vier-Elemente-Methode für Szenenbeschreibungen

Die Szene ist das oberste Konzept in der Spieleentwicklung. Eine vollständige Szenenbeschreibung enthält vier Elemente: Typ, Stil, Elemente und Interaktionspunkte. Sind diese vier Punkte klar, generiert die KI ein strukturell vollständiges Level.

Definition der vier Elemente:

Element	Definition	Beschreibungsmethode
Szenentyp	Spiellevel / Interface / Menü	„Eine {Typ}-Szene mit {Elementen}“
Visueller Stil	2D / 3D, Pixel / realistisch	„{Stil}-Kunststil, Referenz: {Spielname}“
Kernelemente	Spieler, Gegner, Items, UI	„{Anzahl} {Typ}-Objekte, Position {Koordinaten}“
Interaktionspunkte	Klick- / Kollisionsbereiche	„{Anzahl} Interaktionsbereiche, lösen {Event} aus”

Die Methode: Zuerst das „Gerüst” der Szene (Typ + Stil), dann den „Inhalt” (Elemente + Interaktionspunkte). Wie beim Hausbau – zuerst der Grundriss, dann die Möbel.

Praxisbeispiel: Ein Sokoban-Level – wie beschreiben?

【Szenenbeschreibung】

Szenentyp: Ein Sokoban-Spiellevel
Visueller Stil: Minimalistischer Geometriestil, einfarbiger Hintergrund, Rastergröße 64x64

Kernelemente:
  - 1 Player-Knoten (Position: Zeile 1, Spalte 1)
  - 3 Box-Knoten (Position: Zeile 2 Spalte 2, Zeile 3 Spalte 4, Zeile 5 Spalte 2)
  - 3 Target-Knoten (Zielpositionen, als Vertiefungen dargestellt)
  - Wand-Knoten (Szenenrand)

Interaktionspunkte:
  - Player kann Box schieben, Kollision löst Verschiebung aus
  - Box erreicht Target → Siegprüfung
  - Szenenrand-Kollision → Blockierung

【Technische Randbedingungen】

Engine: Cocos Creator 3.8
Sprache: TypeScript
Performance: FPS ≥ 60, Knotenanzahl ≤ 50

Alle vier Elemente sind abgedeckt. Typ: Sokoban-Level. Stil: minimalistische Geometrie. Elemente: Player, Box, Target, Wände mit Positionen. Interaktionspunkte: Schieben, Siegprüfung, Randblockierung. Technische Randbedingungen separat für Performance.

Ein Detail: Positionen als „Zeile N, Spalte N” statt Pixelkoordinaten. Die KI rechnet anhand der Rastergröße (64x64) automatisch um (Zeile 1, Spalte 1 = (64, 64)) – flexibler bei Rasteränderungen.

Kopierbare Vorlage:

## Szenenbeschreibungs-Vorlage

【Grundinformationen】

- Szenenname: {sceneName}
- Szenentyp: {Typ: Kampfszene / Menüszene / Ergebnis-Szene}
- Visueller Stil: {Stilbeschreibung}

【Kernelemente-Liste】

1. {Knotenname}: {Anzahl} Stück, Startposition ({x}, {y})
2. {Knotenname}: {Anzahl} Stück, Funktionsbeschreibung
3. ...

【Interaktionspunkte】

- {Name}: Auslösebedingung {Bedingung}, Reaktion {Verhalten}
- {Name}: ...

【Technische Anforderungen】

- Engine-Version: {version}
- Sprache: {TypeScript / JavaScript}
- Performance: {FPS / Knotenanzahl / Speicher}

Die Vorlage eignet sich für die meisten 2D-Mini-Spiel-Szenen. Nach den vier Elementen generiert die KI ein strukturell vollständiges Level-Gerüst. Kapitel 3 zeigt, wie die Kernelemente-Liste als Node-Tree-JSON mit Hierarchie erweitert wird.

Standardformat für Node-Tree-Beschreibungen

Der Node Tree ist die zentrale Datenstruktur einer Cocos-Creator-Szene. Jeder Knoten kann Unterknoten haben; Unterknoten erben die relative Position des Elternknotens und bilden einen Baum. Am klarsten beschreiben Sie ihn der KI im JSON-Format.

Warum JSON? Strukturiert, parsebar, direkt verständlich für die KI. Aus dem JSON erkennt sie Root-Knoten, Unterknoten, Komponenten und Eigenschaften – und erstellt Knoten schichtweise ohne Hierarchie-Chaos.

Standard-Node-Tree-JSON-Struktur:

{
  "rootNode": "Scene",
  "tree": {
    "Player": {
      "components": ["Sprite", "RigidBody2D", "PlayerScript"],
      "position": {"x": 100, "y": 200},
      "properties": {
        "size": {"width": 64, "height": 64},
        "anchor": {"x": 0.5, "y": 0.5}
      },
      "children": {
        "HealthBar": {
          "components": ["ProgressBar"],
          "position": {"x": 0, "y": 32}
        },
        "Weapon": {
          "components": ["Sprite"],
          "position": {"x": 48, "y": 0}
        }
      }
    },
    "Enemies": {
      "components": [],
      "children": {
        "Enemy1": {
          "components": ["Sprite", "EnemyScript"],
          "position": {"x": 300, "y": 150}
        },
        "Enemy2": {
          "components": ["Sprite", "EnemyScript"],
          "position": {"x": 400, "y": 250}
        }
      }
    },
    "UI": {
      "components": [],
      "children": {
        "ScoreLabel": {
          "components": ["Label"],
          "content": "Score: 0"
        },
        "PauseButton": {
          "components": ["Button"],
          "onClick": "pauseGame()"
        }
      }
    }
  }
}

Dieses JSON beschreibt eine einfache Kampfszene. Root: Scene, drei Top-Level-Knoten: Player, Enemies (Container), UI. Player hat HealthBar und Weapon als Unterknoten. Die KI erstellt HealthBar als Player-Unterknoten an relativer Position (0, 32).

Drei Schlüsselpunkte für Node-Tree-Beschreibungen:

Erster Punkt: Eltern-Kind-Beziehung muss eindeutig sein. Die position eines Unterknotens ist der Offset relativ zum Elternknoten. HealthBar bei (0, 32) liegt 32 Pixel über Player. Bewegt sich Player nach (200, 300), folgt HealthBar nach (200, 332) – die Lebensanzeige bleibt am Spieler.

Ist HealthBar am Szenen-Root statt unter Player, folgt sie nicht mit. Ich bin in diese Falle getappt: Die KI platzierte UI-Elemente am Root – Lebensanzeige und Spieler trennten sich. Mit JSON-Beschreibung stimmte die Hierarchie.

Zweiter Punkt: Komponenten-Kombination statt Vererbung. Cocos Creator: „Knoten sind Entitäten, Komponenten verleihen Funktion.” Ohne Sprite keine Grafik, ohne RigidBody2D keine Physik, ohne Script keine eigene Logik. Flexibler als Vererbung – Player mit Sprite + RigidBody + Script, Enemy mit Sprite + RigidBody + EnemyScript, geteilte und eigene Komponenten.

Im JSON beschreibt das components-Array die Liste. Die KI mountet in Reihenfolge; Eigenschaften ergänzen Sie in properties.

Dritter Punkt: Einheitliche Knotenbenennung. CamelCase (Player, Enemy, HealthBar); funktionale Knoten optional mit Unterstrich (bg_sprite, ui_canvas). Klare Namen → konsistente Variablen in generiertem Code.

Praxisbeispiel: Node Tree für ein Shoot-‘em-up – dieses JSON können Sie direkt an die KI senden:

{
  "rootNode": "GameScene",
  "tree": {
    "Player": {
      "components": [
        "Sprite(贴图路径: assets/player.png)",
        "RigidBody2D(type: dynamic, gravityScale: 0)",
        "Collider(tag: 'player')",
        "PlayerScript"
      ],
      "position": {"x": 200, "y": 400},
      "properties": {"size": {"width": 64, "height": 64}},
      "children": {
        "BulletSpawnPoint": {"position": {"x": 32, "y": 0}}
      }
    },
    "Enemies": {
      "children": [
        {
          "Enemy1": {
            "components": ["Sprite", "Collider(tag: 'enemy')"],
            "position": {"x": 600, "y": 200}
          }
        },
        {
          "Enemy2": {
            "components": ["Sprite", "Collider(tag: 'enemy')"],
            "position": {"x": 700, "y": 300}
          }
        }
      ]
    },
    "Bullets": {
      "components": [],
      "description": "Bullet-Pool-Container, dynamische Bullet-Knoten"
    },
    "UI": {
      "children": {
        "ScoreLabel": {"components": ["Label"], "content": "Score: 0"},
        "RestartButton": {"components": ["Button"], "onClick": "restartGame()"}
      }
    }
  }
}

Beachtenswerte Details:

• BulletSpawnPoint unter Player bei (32, 0) – Schussausgang, 32 Pixel versetzt
• Enemies als Container mit Array mehrerer Enemy-Unterknoten
• Bullets als Pool-Container; description erklärt dynamische Erstellung
• RestartButton mit onClick-Callback

Mit technischen Randbedingungen an die KI senden:

Bitte erstelle eine Cocos-Creator-Szene anhand des obigen Node-Tree-JSON.

Anforderungen:
1. Cocos Creator 3.8 API
2. TypeScript mit Typannotationen
3. Script-Komponenten mit @ccclass-Dekorator
4. Event-Listener mit node.on()

Die KI generiert vollständigen Szenenerstellungs-Code: Knoten, Komponenten, Eigenschaften. Sie ergänzen nur die Script-Logik – das Gerüst steht.

Komponenten-Beschreibungsvorlage

Komponenten tragen die Knotenfunktionen. Beschreiben Sie vier Felder: Funktion, Eigenschaften, Abhängigkeiten, Beispielkonfiguration. Gilt für alle Cocos-Creator-Built-in- und Custom-Script-Komponenten.

Vier-Felder-Definition:

Feld	Pflicht	Beschreibung
Funktion	Ja	Was die Komponente tut (ein Satz)
Eigenschaften	Ja	Konfigurationsparameter (Typ + Beschreibung)
Abhängigkeiten	Optional	Erforderliche Knoteneigenschaften / andere Komponenten
Beispielkonfiguration	Empfohlen	Typische Konfigurationswerte

Logik: Zweck (Funktion), Parameter (Eigenschaften), Voraussetzungen (Abhängigkeiten). Die KI generiert Mount-Code entsprechend.

Praxisbeispiel: Sprite-Komponente.

## Komponentenname: Sprite

**Funktion**: Zeigt Bildtexturen an – häufigste Render-Komponente in 2D-Spielen

**Eigenschaften**:

- spriteFrame: SpriteFrame – Bildressource | Standard: null
- sizeMode: SizeMode – Größenmodus (CUSTOM / RAW / TRIMMED) | Standard: TRIMMED
- type: SpriteType – Rendertyp (SIMPLE / SLICED / TILED / FILLED) | Standard: SIMPLE

**Abhängigkeiten**:

- Knoten benötigt: size-Eigenschaft (wenn sizeMode = CUSTOM)

**Beispielkonfiguration**:

spriteFrame: assets/player.png
sizeMode: RAW

Die KI generiert etwa:

const sprite = node.addComponent(Sprite);
sprite.spriteFrame = assets.player;
sprite.sizeMode = SizeMode.RAW;

Physik-Beispiel: RigidBody2D.

## Komponentenname: RigidBody2D

**Funktion**: 2D-Physik-Rigidbody – verleiht Physikeigenschaften (Gravitation, Kollision)

**Eigenschaften**:

- type: RigidBodyType – Typ (STATIC / DYNAMIC / KINEMATIC) | Standard: STATIC
- gravityScale: number – Gravitationsfaktor | Standard: 1.0
- linearVelocity: Vec2 – Lineargeschwindigkeit | Standard: (0, 0)

**Abhängigkeiten**:

- Benötigt: Collider2D (Kollisionserkennung)

**Beispielkonfiguration**:

type: DYNAMIC
gravityScale: 0.5
linearVelocity: (100, 0)

Abhängigkeitsfeld: RigidBody2D braucht Collider2D. Die KI mountet Collider2D mit oder erinnert daran.

Typische Falle: Bei „Charakter soll Physik haben” nur RigidBody2D ohne Collider – Gravitation wirkt, aber der Boden wird durchdrungen. Mit Abhängigkeitsfeld in der Vorlage: RigidBody2D + Collider2D.

Standardformat der Komponenten-Vorlage:

## Komponentenname: {ComponentType}

**Funktion**: {Ein-Satz-Beschreibung}

**Eigenschaften**:

- {Name}: {Typ} – {Beschreibung} | Standard: {default}
- {Name}: {Typ} – {Beschreibung} | Standard: {default}

**Abhängigkeiten**:

- Knoten benötigt: {Node-Eigenschaft} (z. B. size, anchor)
- Benötigt Komponente: {Component-Name} (z. B. RigidBody2D)

**Beispielkonfiguration**:

{property}: {value}
{property}: {value}

**Code-Beispiel**:

```typescript
// Komponente abrufen
const sprite = this.node.getComponent(Sprite);
sprite.spriteFrame = newSpriteFrame;

Die Vorlage gilt für alle Built-in-Komponenten (Sprite, Label, Button, RigidBody2D, Collider2D usw.) und Custom Scripts. Für PlayerScript:

```markdown
## Komponentenname: PlayerScript

**Funktion**: Bewegung, Sprung und Kollisionsreaktion des Spielers

**Eigenschaften**:

- moveSpeed: number – Bewegungsgeschwindigkeit | Standard: 200
- jumpHeight: number – Sprunghöhe | Standard: 100
- health: number – Aktuelle Lebenspunkte | Standard: 100

**Abhängigkeiten**:

- Benötigt: RigidBody2D (Physikbewegung)
- Benötigt: Collider2D (Kollisionserkennung)

**Beispielkonfiguration**:

moveSpeed: 300
jumpHeight: 150
health: 100

Die KI generiert eine vollständige PlayerScript-TypeScript-Klasse mit @property, onLoad/start/update und move/jump/takeDamage – Sie füllen nur die Logik aus.

Formel für Interaktionsbeschreibungen

Interaktion ist der Kern der Spiellogik: Button-Klick, Kollision mit Gegner, Treffer durch Projektil. Am klarsten mit der Fünf-Elemente-Formel:

Interaktionsbeschreibung = Auslösebedingung + Event-Typ + Zielobjekt + Reaktionsverhalten + Zustandsänderung

Bedeutung der fünf Elemente:

• Auslösebedingung: Wann (Kollision, Klick, Tastatur)
• Event-Typ: Konkreter Event-Name (TOUCH_START, onCollisionEnter)
• Zielobjekt: Welcher Knoten / welche Komponente reagiert
• Reaktionsverhalten: Welche Methode / Funktion ausgeführt wird
• Zustandsänderung: Wie sich Daten / Darstellung ändern

Die Formel schließt die Beschreibung ab – fehlt ein Element, entstehen Bugs im generierten Code.

Beispiel: „Klick auf Button zum Springen” liefert nur Touch-Listener ohne Sprunghöhe, -dauer oder Zustandsrücksetzung – Animation ruckelt, Zustand blockiert, Doppelklicks problematisch.

Korrekt mit allen fünf Elementen:

## Interaktionsname: Klick-Sprung

【Auslösebedingung】

- Auslösung: Touch-Klick
- Objekt: JumpButton-Knoten
- Zeitpunkt: TOUCH_END (Finger hebt ab)

【Event-Listener】

- Knoten: JumpButton
- Event-Typ: Node.EventType.TOUCH_END
- Callback: onJumpButtonClicked

【Reaktionsverhalten】

- Methode: PlayerScript.jump()
- Parameter: height = 100, duration = 0.3

【Zustandsänderung】

- Daten: Player.position.y += 100
- Visuell: jump-Animation (scale: 1.0 → 1.2 → 1.0)
- Zustand: Player.isJumping = true (0,3 Sekunden)

【Code-Implementierung】

```typescript
jumpButton.on(Node.EventType.TOUCH_END, (event) => {
  const playerScript = player.getComponent(PlayerScript);
  playerScript.jump({ height: 100, duration: 0.3 });
}, this);

Alle fünf Elemente abgedeckt – vollständiger Touch-Listener mit Callback, Parametern und Zustandsverwaltung.

Kollisions-Beispiel:

```markdown
## Interaktionsname: Kollisionsschaden

【Auslösebedingung】

- Auslösung: Kollisionserkennung
- Objekte: Player-Collider + Enemy-Collider
- Zeitpunkt: onCollisionEnter

【Event-Listener】

- Komponente: Collider am Player-Knoten
- Event-Typ: Collider2D.onCollisionEnter
- Callback: onPlayerHitEnemy

【Reaktionsverhalten】

- Methode: PlayerScript.takeDamage(amount)
- Parameter: damage = 10

【Zustandsänderung】

- Daten: Player.health -= 10
- Visuell: Weißblitz-Animation (0,1 s)
- Zustand: Player.isHurt = true (0,2 s)

【Code-Implementierung】

```typescript
onCollisionEnter(self: Collider2D, other: Collider2D) {
  if (other.tag === 'enemy') {
    const playerScript = this.node.getComponent(PlayerScript);
    playerScript.takeDamage(10);
    this.flashWhite(0.1);
  }
}

Detail: Zwei Collider, onCollisionEnter – die KI hört am Player-Collider ab, prüft tag 'enemy', führt Schadenslogik aus.

Typische Falle: Zustandsänderung unklar. „Kollision mit Gegner → Schaden" lieferte nur `health -= 10` ohne visuelles Feedback (Weißblitz) und Sperre (isHurt) – kein Feedback, wiederholte Kollisionen töten sofort.

Mit der Fünf-Elemente-Formel: Weißblitz und Zustandssperre – vollständige Interaktion.

Standard-Interaktionsvorlage:

```markdown
## Interaktionsname: {Beschreibung}

【Auslösebedingung】

- Auslösung: {Touch / Tastatur / Kollision}
- Objekt: {Knotenname}
- Zeitpunkt: {TOUCH_START / TOUCH_END / onCollisionEnter}

【Event-Listener】

- Knoten: {Knotenname}
- Event-Typ: Node.EventType.{Typ}
- Callback: {Funktionsname}

【Reaktionsverhalten】

- Methode: {Script}.{Methode}
- Parameter: {Liste}

【Zustandsänderung】

- Daten: {Variable} = {Neuer Wert}
- Visuell: {Animation / Farbe / Position}

Geeignet für Touch (Klick, Wischen), Kollision (Spieler/Gegner, Projektil/Ziel) und Tastatur (Pfeiltasten, Leertaste). Mit fünf Elementen generiert die KI vollständigen Event-Listener-Code.

Cocos Creator Touch-Events:

Event-Typ	Auslösezeitpunkt
TOUCH_START	Finger berührt Bildschirm
TOUCH_MOVE	Finger bewegt sich
TOUCH_END	Finger hebt ab
TOUCH_CANCEL	Touch vom System abgebrochen (z. B. Anruf)

Listener: node.on(Node.EventType.{Typ}, callback, target). Beim Zerstören node.off() – Speicherlecks vermeiden.

5 praxiserprobte Prompt-Vorlagen

Die vier Methoden (Szenen-Vier-Elemente, Node-Tree-JSON, Komponenten-Vorlage, Interaktions-Fünf-Elemente) brauchen ein Prompt-Format. Hier fünf kopierbare Vorlagen: Szene, Knoten, Interaktion, Script, Performance.

Vorlage 1: Vollständige Szene erstellen

【Rolle】Sie sind Cocos-Creator-Entwicklungsexperte, versiert in TypeScript und Node-Komponenten-Architektur.

【Aufgabe】Erstellen Sie vollständigen Code für folgende Spielszene.

【Szenenbeschreibung】

Szenentyp: {Typ}
Visueller Stil: {Stil}
Kernelemente: {Knotenliste}
Interaktionspunkte: {Interaktionsliste}

【Node-Tree-Struktur】

```json
{Node-Tree-JSON}

【Technische Anforderungen】

• Engine: Cocos Creator 3.8
• Sprache: TypeScript, @ccclass-Dekorator
• API: Offizielle Cocos-Creator-API (node.getComponent, node.on usw.)

【Ausgabe】

1. Szenencode (vollständige Knotenerstellung)
2. Script-Code (Typannotationen und Kommentare)
3. Event-Listener (Interaktionslogik)

### Vorlage 2: Knoten erstellen und Komponenten mounten

【Rolle】Cocos-Creator-TypeScript-Entwickler

【Aufgabe】Erstellen Sie {Knotenname}-Knoten und mounten Sie {Komponentenliste}

【Knoteneigenschaften】

• Name: {nodeName}
• Position: ({x}, {y})
• Größe: {width}x{height}
• Anker: ({anchorX}, {anchorY})

【Komponenten-Konfiguration】

1. {Komponentenname}:
   • {Eigenschaft}: {Wert}
2. {Komponentenname}:
   • {Eigenschaft}: {Wert}

【Ausgabe】

• TypeScript mit Typannotationen
• Cocos Creator 3.8 API
• Kommentare zu jeder Zeile

### Vorlage 3: Interaktionslogik implementieren

【Rolle】Cocos-Creator-Event-System-Experte

【Aufgabe】Implementieren Sie folgende Interaktionslogik

【Interaktionsbeschreibung】

Auslösebedingung: {Bedingung}
Event-Typ: {Typ}
Zielobjekt: {Knotenname}
Reaktionsverhalten: {Methodenname}
Zustandsänderung: {Beschreibung}

【Technische Randbedingungen】

• Events mit node.on abhören
• Node.EventType-Enum
• Callback mit event-Parameter
• node.off beim Zerstören

【Ausgabe】

• TypeScript-Code
• Vollständige Listener-, Callback- und Cleanup-Logik
• Fehlerbehandlung (Knoten fehlt, Komponente fehlt)

### Vorlage 4: Script-Komponente erstellen

【Rolle】Cocos-Creator-Script-Entwicklungsexperte

【Aufgabe】Erstellen Sie {Scriptname}-Script-Komponente

【Script-Funktion】

{Funktionsbeschreibung}

【Eigenschaftsdefinition】

@property({Typ})
{Eigenschaftsname}: {Typ} = {Standardwert}

【Methodenliste】

1. {Methodenname}({Parameter}): {Rückgabetyp}
   • Funktion: {Beschreibung}
2. {Methodenname}({Parameter}): {Rückgabetyp}
   • Funktion: {Beschreibung}

【Lifecycle】

• onLoad: {Initialisierung}
• start: {Startlogik}
• update(dt): {Frame-Update}

【Ausgabe】

• TypeScript mit @ccclass und @property
• Vollständige Lifecycle-Methoden
• Typannotationen und Kommentare

### Vorlage 5: Node-Tree-Performance optimieren

【Rolle】Cocos-Creator-Performance-Optimierungsexperte

【Aufgabe】Optimieren Sie die Performance folgender Node-Tree-Struktur

【Aktueller Node Tree】

{Node-Tree-JSON}

【Performance-Probleme】

• Zu viele Knoten: {Anzahl}
• DrawCall zu hoch: {Anzahl}
• Speicher zu groß: {Größe}

【Optimierungsziele】

• FPS: ≥ 60
• DrawCall: ≤ 20
• Speicher: ≤ 100 MB

【Optimierungsstrategie】

1. Knoten zusammenführen: {Plan}
2. Node Pool: {Wiederverwendung}
3. Komponenten optimieren: {Plan}

【Ausgabe】

• Optimierter Node-Tree-JSON
• TypeScript-Optimierungscode
• Performance-Vergleich (vorher vs. nachher)

Die fünf Vorlagen decken den KI-Spielentwicklungs-Workflow ab: Szene, Knoten, Interaktion, Script, Performance. Jede folgt CREATE: Context (Rolle), Action (Aufgabe), Edge (Randbedingungen), Example (Node-Tree-JSON).

Kopieren, `{}`-Platzhalter ersetzen – z. B. bei Vorlage 2 `{nodeName}` → `Player`, `{Komponentenliste}` → `Sprite, RigidBody2D, PlayerScript`. Die KI liefert vollständigen Code ohne Prompt von Grund auf.

## Zusammenfassung

Vier Methoden und fünf Praxisvorlagen – die Kernpunkte:

**Szenen-Vier-Elemente**: Typ, Stil, Elemente, Interaktionspunkte. Erst Gerüst, dann Inhalt – strukturell vollständiges Level.

**Node-Tree-JSON**: Root → Unterknoten → Komponenten → Eigenschaften → Position. Strukturierte Hierarchie, schichtweise Erstellung ohne Chaos.

**Komponenten-Vier-Felder**: Funktion, Eigenschaften, Abhängigkeiten, Beispielkonfiguration. Zweck, Parameter, Voraussetzungen – sauberer Mount-Code.

**Interaktions-Fünf-Elemente**: Auslösebedingung, Event-Typ, Zielobjekt, Reaktionsverhalten, Zustandsänderung. Vollständiger Kreislauf ohne Lücken.

In fünf Prompt-Vorlagen umgesetzt: Szene, Knoten, Interaktion, Script, Performance – CREATE-Framework, `{}` ersetzen und loslegen.

Beim nächsten Mal: Node Tree als JSON, Interaktionen mit der Fünf-Elemente-Formel. Der Unterschied ist spürbar – vage Prompts liefern Fragmente und chaotische Hierarchien; standardisierte Beschreibungen liefern vollständige, klare Strukturen mit geschlossenen Interaktionen. Der Effizienzgewinn ist real.