Rédiger des exigences de mini-jeux pour l'IA : scènes, nœuds, composants et interactions

Vous demandez à l’IA de « faire une fonction de saut », et elle vous renvoie un tas de fragments de code inutilisables. Vous voulez créer un niveau de jeu complet, mais vous ne savez pas comment expliquer clairement la structure de l’arborescence des nœuds — l’IA génère une hiérarchie chaotique.

Le problème ne vient pas des capacités de l’IA. Un prompt vague, c’est comme cuisiner avec une recette sans liste d’ingrédients : l’IA improvise, et le résultat ne correspond pas du tout à ce que vous aviez en tête.

Les exigences de développement de jeux peuvent en réalité être standardisées. Scène, nœud, composant, interaction — ces quatre concepts clés ont chacun un modèle de description correspondant. Cet article partage une méthodologie éprouvée en conditions réelles : la méthode en quatre éléments pour les scènes, le format JSON pour l’arborescence des nœuds, le modèle de description des composants, la formule en cinq éléments pour les interactions, plus 5 modèles de prompts directement copiables.

Si vous développez des mini-jeux avec Cocos Creator et que vous voulez gagner en efficacité grâce à l’IA sans échouer à chaque fois, vous devriez trouver ici ce qu’il vous faut.

Pourquoi les exigences de jeu doivent être décrites de façon standardisée

La description floue des exigences est le premier ennemi du développement de jeux avec l’IA. J’ai essayé de dire simplement « aide-moi à faire une fonction de saut » — l’IA m’a renvoyé du code player.y += 10 : pas de système physique, pas de détection de collision, pas de transition d’animation. En exécution, le personnage se téléporte directement dans le ciel.

Ce type de problème présente trois symptômes typiques.

Premier problème : l’IA ne comprend pas la hiérarchie des nœuds. Dans Cocos Creator, vous créez un nœud Player avec un sous-nœud HealthBar pour afficher la barre de vie. Mais si vous dites seulement « créer un joueur », l’IA ne saura pas que HealthBar doit exister en tant que sous-nœud — elle risque de le placer comme nœud indépendant à la racine de la scène. En exécution, la barre de vie ne suivra pas le joueur.

Regardez la comparaison :

❌ "Créer un joueur"
✅ "Créer le nœud racine Player, avec un composant Sprite pour afficher le sprite du personnage, sous-nœud HealthBar pour la barre de vie, position relative (0, 32)"

La deuxième version clarifie la relation parent-enfant — l’IA ne générera plus de code avec une hiérarchie confuse.

Deuxième problème : relations entre composants chaotiques. L’architecture centrale de Cocos Creator repose sur « nœud + composant » — le nœud est une coquille vide, les composants apportent les fonctionnalités. Un nœud Player peut porter quatre composants : Sprite (affichage), RigidBody2D (corps physique), Collider (détection de collision), PlayerScript (logique personnalisée). Si vous dites seulement « faire bouger le personnage », l’IA peut ne vous donner qu’un script de déplacement, sans composants physiques — le personnage traverse les murs sans aucun retour de collision.

La description correcte doit lister les composants :

❌ "Faire bouger le personnage"
✅ "Nœud Player avec composant RigidBody2D (type: dynamic), sous-nœud avec composant Collider (tag: 'player'), plus PlayerScript pour gérer la saisie clavier"

Troisième problème : logique d’interaction fragmentée. Vous dites « cliquer sur le bouton pour sauter », l’IA vous donne un code d’écoute d’événements tactiles — mais combien de temps dure le saut, quelle hauteur, peut-on resauter en plein saut, comment restaurer l’état après le saut ? Rien de tout cela n’est traité. En exécution, le personnage bouge bien au clic, mais l’animation saccade, l’état se bloque, et les clics répétés provoquent des bugs.

Une description d’interaction complète doit contenir cinq éléments : condition de déclenchement, type d’événement, objet cible, comportement de réponse, changement d’état. Nous y reviendrons plus loin ; retenez d’abord la formule :

Description d'interaction = condition de déclenchement + type d'événement + objet cible + comportement de réponse + changement d'état

La racine des descriptions floues est l’absence de pensée structurée. L’IA a besoin d’un contexte explicite, d’instructions concrètes et de conditions limites claires. Le cadre CREATE de l’ingénierie des prompts, initialement une bonne pratique générale en programmation, s’applique tout aussi bien au développement de jeux :

Champ	Application au développement de jeux
C - Context	Fournir la version du moteur (Cocos Creator 3.8), la structure du projet, le style de code existant
R - Role	Préciser que l’IA est « expert en développement Cocos Creator »
E - Example	Donner un exemple de format JSON attendu pour l’arborescence des nœuds
A - Action	Clarifier ce qu’il faut faire (créer un nœud, attacher un composant, écouter un événement)
T - Tone	Spécifier le style de code (TypeScript + API Cocos Creator)
E - Edge	Indiquer les contraintes (FPS ≥ 60, nombre de nœuds ≤ 50)

La logique centrale de ce cadre : décomposer « quoi faire » en « dans quelles conditions », « avec quels outils », « selon quels critères ». Les quatre sections suivantes appliquent le cadre CREATE aux dimensions scène, nœud, composant et interaction, avec des modèles reproductibles.

La méthode en quatre éléments pour décrire une scène

La scène est le concept de plus haut niveau en développement de jeux. Une description complète comprend quatre éléments : type, style, éléments, points d’interaction. Remplissez ces quatre champs, et l’IA pourra générer un niveau avec une structure cohérente.

Définitions des quatre éléments :

Élément	Définition	Méthode de description
Type de scène	Niveau de jeu / interface / menu	« Une scène de type {type}, contenant {éléments} »
Style visuel	2D / 3D, pixel / réaliste	« Style artistique {style}, référence {nom du jeu} »
Éléments clés	Joueur, ennemis, objets, UI	« {quantité} objets de type {type}, position {coordonnées} »
Points d’interaction	Zones cliquables / collision	« Définir {quantité} zones d’interaction, déclenchant {événement} »

L’idée centrale : d’abord fixer le « squelette » de la scène (type + style), puis remplir le « contenu » (éléments + points d’interaction). Comme construire une maison : d’abord le plan, ensuite les meubles.

Exemple concret. Vous voulez créer un niveau de jeu de pousser des caisses — comment le décrire ?

【Description de scène】

Type de scène : un niveau de jeu de pousser des caisses
Style visuel : style géométrique épuré, fond uni, grille 64x64

Éléments clés :
  - 1 nœud Player (position : ligne 1, colonne 1)
  - 3 nœuds Box (positions : ligne 2 colonne 2, ligne 3 colonne 4, ligne 5 colonne 2)
  - 3 nœuds Target (positions cibles, affichés comme cases creuses)
  - Nœuds de mur (autour des limites de la scène)

Points d'interaction :
  - Player peut pousser Box, détection de collision déclenche le déplacement
  - Box atteint Target déclenche la détection de victoire
  - Collision avec les limites de la scène déclenche le blocage

【Contraintes techniques】

Moteur : Cocos Creator 3.8
Langage : TypeScript
Performance : FPS ≥ 60, nombre de nœuds ≤ 50

Cette description couvre les quatre éléments. Type : « niveau de pousser des caisses » ; style : « géométrique épuré » ; éléments : Player, Box, Target, murs avec positions précises ; points d’interaction : pousser, victoire, blocage aux limites. Les contraintes techniques sont listées séparément pour que le code généré respecte les exigences de performance.

Un détail : les positions des éléments clés sont décrites en « ligne N, colonne N » plutôt qu’en coordonnées pixel directes. Avantage : l’IA convertit automatiquement selon la taille de grille (64x64) — ligne 1 colonne 1 = (64, 64). Le code reste flexible ; changer la taille de grille ne nécessite pas de recalculer toutes les coordonnées.

Voici un modèle directement copiable :

## Modèle de description de scène

【Informations de base】

- Nom de la scène : {sceneName}
- Type de scène : {type : combat / menu / écran de fin}
- Style visuel : {description du style}

【Liste des éléments clés】

1. {nom du nœud} : {quantité}, position initiale ({x}, {y})
2. {nom du nœud} : {quantité}, description de la fonction
3. ...

【Définition des points d'interaction】

- {nom du point} : condition de déclenchement {condition}, comportement {comportement}
- {nom du point} : ...

【Exigences techniques】

- Version du moteur : {version}
- Langage : {TypeScript / JavaScript}
- Indicateurs de performance : {FPS / nombre de nœuds / mémoire}

Ce modèle convient à la plupart des scènes de mini-jeux 2D. Une fois les quatre éléments remplis, l’IA génère un squelette de niveau structuré. Le chapitre suivant explique comment développer la « liste des éléments clés » en format JSON d’arborescence de nœuds, pour que l’IA comprenne les relations hiérarchiques.

Format standard pour décrire l’arborescence des nœuds

L’arborescence des nœuds est la structure de données centrale d’une scène Cocos Creator. Chaque nœud peut avoir des sous-nœuds qui héritent de la position du parent (coordonnées relatives), formant un arbre. Pour décrire l’arborescence à l’IA, le format JSON est le plus clair.

Pourquoi le JSON ? Parce qu’il est structuré, analysable, et l’IA le comprend directement. Avec un JSON, l’IA sait quel est le nœud racine, quels sont les sous-nœuds, quels composants sont attachés, quelles sont les propriétés. Lors de la génération de code, l’IA crée les nœuds couche par couche selon la hiérarchie JSON, sans mélanger les relations parent-enfant.

Voici une structure JSON standard :

{
  "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()"
        }
      }
    }
  }
}

Ce JSON décrit une scène de combat simple. Nœud racine Scene, trois nœuds de premier niveau : Player, Enemies (conteneur d’ennemis), UI (interface). Player a deux sous-nœuds : HealthBar et Weapon. L’IA sait que HealthBar doit être créé comme sous-nœud de Player, position relative (0, 32).

Trois points clés à retenir pour décrire l’arborescence.

Premier point : la relation parent-enfant doit être explicite. La position d’un sous-nœud est un décalage relatif au parent. HealthBar à (0, 32) signifie 32 pixels au-dessus de Player. Si Player se déplace à (200, 300), HealthBar suit automatiquement à (200, 332). Ce mécanisme garantit que la barre de vie reste collée au joueur.

Si HealthBar est à la racine de la scène plutôt qu’en sous-nœud de Player, il ne suivra pas le joueur. J’ai fait cette erreur : l’IA plaçait tous les éléments UI à la racine — en exécution, la barre de vie et le joueur se séparaient. Depuis que j’utilise le format JSON, la hiérarchie générée est correcte.

Deuxième point : composition de composants plutôt qu’héritage. Le design de Cocos Creator repose sur « le nœud est l’entité, les composants apportent les fonctionnalités ». Un nœud sans composant n’a aucun comportement : Sprite pour afficher une image, RigidBody2D pour la physique, Script pour la logique personnalisée. Cette composition est plus flexible que l’héritage — Player peut porter Sprite + RigidBody + Script, Enemy peut porter Sprite + RigidBody + EnemyScript, partageant certains composants avec des scripts distincts.

Le JSON utilise un tableau components pour lister les composants. L’IA les attache dans l’ordre ; les propriétés peuvent être complétées dans properties.

Troisième point : nommage des nœuds cohérent. CamelCase (Player, Enemy, HealthBar) ; nœuds fonctionnels avec underscore (bg_sprite, ui_canvas). Des noms clairs garantissent des noms de variables cohérents dans le code généré.

Exemple concret : arborescence d’un jeu de tir. Ce JSON peut être envoyé directement à l’IA :

{
  "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": "Conteneur de pool de balles, création dynamique de nœuds Bullet"
    },
    "UI": {
      "children": {
        "ScoreLabel": {"components": ["Label"], "content": "Score: 0"},
        "RestartButton": {"components": ["Button"], "onClick": "restartGame()"}
      }
    }
  }
}

Quelques détails :

• Sous Player, BulletSpawnPoint à (32, 0) — point de tir des balles, décalé de 32 pixels
• Enemies est un conteneur listant plusieurs sous-nœuds Enemy en tableau
• Bullets est le pool de balles ; le champ description indique qu’il sert de parent à la création dynamique
• RestartButton sous UI a une propriété onClick liée au nom de la fonction callback

À envoyer à l’IA avec les contraintes techniques :

Créez une scène Cocos Creator selon l'arborescence JSON ci-dessus.

Exigences :
1. Utiliser l'API Cocos Creator 3.8
2. Code TypeScript avec annotations de type
3. Composants script avec décorateur @ccclass
4. Écoute d'événements via node.on()

L’IA génère le code complet de création de scène : création de nœuds, attache de composants, configuration des propriétés. Il ne reste qu’à compléter la logique des scripts — le squelette de la scène est prêt.

Modèle de description des composants

Les composants portent les fonctionnalités des nœuds. Pour décrire un composant à l’IA, quatre champs sont essentiels : fonction, propriétés, dépendances, configuration d’exemple. Ce modèle convient à tous les composants intégrés et scripts personnalisés de Cocos Creator.

Définition des quatre champs :

Champ	Obligatoire	Description
Fonction	Oui	Ce que fait le composant (en une phrase)
Propriétés	Oui	Paramètres de configuration (type + description)
Dépendances	Non	Propriétés requises du nœud / autres composants
Config. d’exemple	Recommandé	Valeurs de configuration typiques

La logique : d’abord l’usage (fonction), puis les paramètres (propriétés), enfin les prérequis (dépendances). L’IA génère le code d’attache selon cette structure, avec les valeurs d’exemple.

Exemple : description du composant Sprite.

## Nom du composant : Sprite

**Fonction** : Afficher une image sprite, composant de rendu le plus courant en jeu 2D

**Propriétés** :

- spriteFrame : SpriteFrame - ressource image | défaut : null
- sizeMode : SizeMode - mode de taille (CUSTOM / RAW / TRIMMED) | défaut : TRIMMED
- type : SpriteType - type de rendu (SIMPLE / SLICED / TILED / FILLED) | défaut : SIMPLE

**Dépendances** :

- Nœud requis : propriété size (quand sizeMode = CUSTOM)

**Configuration d'exemple** :

spriteFrame: assets/player.png
sizeMode: RAW

L’IA génère un code du type :

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

Exemple physique : RigidBody2D.

## Nom du composant : RigidBody2D

**Fonction** : Corps rigide 2D, propriétés physiques (gravité, collision)

**Propriétés** :

- type : RigidBodyType - type de corps (STATIC / DYNAMIC / KINEMATIC) | défaut : STATIC
- gravityScale : number - coefficient de gravité | défaut : 1.0
- linearVelocity : Vec2 - vitesse linéaire | défaut : (0, 0)

**Dépendances** :

- Autre composant requis : Collider2D (détection de collision)

**Configuration d'exemple** :

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

Le champ dépendances indique que RigidBody2D nécessite Collider2D pour la détection de collision. L’IA ajoutera Collider2D sur le même nœud.

Piège courant : j’ai demandé « donner des propriétés physiques au personnage » — l’IA n’a attaché que RigidBody2D, sans Collider. Le personnage tombait sous la gravité mais traversait le sol. Avec le modèle incluant les dépendances, le code inclut RigidBody2D + Collider2D.

Format standard du modèle :

## Nom du composant : {ComponentType}

**Fonction** : {description en une phrase}

**Propriétés** :

- {nom} : {type} - {description} | défaut : {default}
- {nom} : {type} - {description} | défaut : {default}

**Dépendances** :

- Nœud requis : {propriété Node} (ex. : size, anchor)
- Autre composant requis : {nom Component} (ex. : RigidBody2D)

**Configuration d'exemple** :

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

**Exemple de code** :

```typescript
// Obtenir le composant
const sprite = this.node.getComponent(Sprite);
sprite.spriteFrame = newSpriteFrame;

Ce modèle convient à tous les composants intégrés (Sprite, Label, Button, RigidBody2D, Collider2D, etc.) et aux scripts personnalisés. Pour PlayerScript :

## Nom du composant : PlayerScript

**Fonction** : Logique personnalisée de déplacement, saut et réponse aux collisions du joueur

**Propriétés** :

- moveSpeed : number - vitesse de déplacement | défaut : 200
- jumpHeight : number - hauteur de saut | défaut : 100
- health : number - points de vie actuels | défaut : 100

**Dépendances** :

- Composant requis : RigidBody2D (déplacement physique)
- Composant requis : Collider2D (détection de collision)

**Configuration d'exemple** :

moveSpeed: 300
jumpHeight: 150
health: 100

L’IA génère une classe PlayerScript TypeScript complète : propriétés @property, méthodes de cycle de vie onLoad / start / update, méthodes move / jump / takeDamage. Il ne reste qu’à compléter la logique concrète.

Formule de description des interactions

L’interaction est le cœur de la logique de jeu. Clic sur un bouton, collision joueur-ennemi, impact balle-cible — ce sont toutes des interactions. La formule en cinq éléments est la plus claire :

Description d'interaction = condition de déclenchement + type d'événement + objet cible + comportement de réponse + changement d'état

Signification des cinq éléments :

• Condition de déclenchement : dans quelle situation (collision, clic, saisie clavier)
• Type d’événement : nom précis (TOUCH_START, onCollisionEnter)
• Objet cible : quel nœud / composant répond
• Comportement de réponse : quelle méthode / fonction exécuter
• Changement d’état : comment évoluent données et visuel

Cette formule garantit une description complète en boucle fermée. Manquer un élément, et le code généré aura des bugs.

Exemple. « Cliquer sur le bouton pour sauter » — l’IA ne donne que l’écoute tactile, sans hauteur, durée ni restauration d’état. Résultat : animation saccadée, verrouillage d’état, bugs aux clics répétés.

La description correcte couvre les cinq éléments :

## Nom de l'interaction : Saut au clic

【Condition de déclenchement】

- Mode : toucher / clic
- Objet : nœud JumpButton
- Moment : TOUCH_END (doigt quitte l'écran)

【Écoute d'événement】

- Nœud écouté : JumpButton
- Type : Node.EventType.TOUCH_END
- Callback : onJumpButtonClicked

【Comportement de réponse】

- Méthode : PlayerScript.jump()
- Paramètres : height = 100, duration = 0.3

【Changement d'état】

- Données : Player.position.y += 100
- Visuel : animation jump sur Player (scale: 1.0 → 1.2 → 1.0)
- État : Player.isJumping = true (pendant 0,3 s)

【Implémentation】

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

L'IA génère l'écoute complète avec callback, paramètres et gestion d'état.

Exemple de collision :

```markdown
## Nom de l'interaction : Détection de dégâts par collision

【Condition de déclenchement】

- Mode : détection de collision
- Objets : Collider de Player + Collider de Enemy
- Moment : onCollisionEnter (début de collision)

【Écoute d'événement】

- Composant écouté : Collider du nœud Player
- Type : Collider2D.onCollisionEnter
- Callback : onPlayerHitEnemy

【Comportement de réponse】

- Méthode : PlayerScript.takeDamage(amount)
- Paramètres : damage = 10

【Changement d'état】

- Données : Player.health -= 10
- Visuel : flash blanc sur Player (0,1 s)
- État : Player.isHurt = true (pendant 0,2 s)

【Implémentation】

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

Détail : deux Colliders déclenchent onCollisionEnter. L'IA écoute sur le Collider de Player et vérifie tag === 'enemy'.

Piège courant : « collision avec ennemi, perte de vie » — l'IA donne `health -= 10` sans retour visuel ni verrouillage d'état. Avec la formule en cinq éléments, le code inclut flash blanc et isHurt.

Modèle standard :

```markdown
## Nom de l'interaction : {description}

【Condition de déclenchement】

- Mode : {toucher / clavier / collision}
- Objet : {nom du nœud}
- Moment : {TOUCH_START / TOUCH_END / onCollisionEnter}

【Écoute d'événement】

- Nœud écouté : {nom du nœud}
- Type : Node.EventType.{type d'événement}
- Callback : {nom de la fonction}

【Comportement de réponse】

- Méthode : {script}.{méthode}
- Paramètres : {liste}

【Changement d'état】

- Données : {variable} = {nouvelle valeur}
- Visuel : {animation / couleur / position}

Ce modèle convient aux interactions tactiles, de collision et clavier. Cocos Creator propose quatre types d’événements tactiles :

Type d’événement	Moment de déclenchement
TOUCH_START	Doigt pose sur l’écran
TOUCH_MOVE	Doigt glisse sur l’écran
TOUCH_END	Doigt quitte l’écran
TOUCH_CANCEL	Toucher annulé par le système (ex. appel entrant)

Écoute via node.on(Node.EventType.{type}, callback, target). Destruction avec node.off() pour éviter les fuites mémoire.

5 modèles de prompts prêts à l’emploi

Les quatre méthodes (scène, arborescence JSON, composants, interactions) se concrétisent en prompts standardisés. Voici 5 modèles copiables : création de scène, création de nœud, implémentation d’interaction, création de script, optimisation des performances.

Modèle 1 : Créer une scène complète

【Rôle】Vous êtes expert en développement Cocos Creator, maîtrisant TypeScript et l'architecture nœud-composant.

【Tâche】Créer le code complet de la scène de jeu suivante.

【Description de scène】

Type de scène : {type}
Style visuel : {style}
Éléments clés : {liste de nœuds}
Points d'interaction : {liste d'interactions}

【Structure de l'arborescence】

```json
{JSON de l'arborescence}

【Exigences techniques】

• Moteur : Cocos Creator 3.8
• Langage : TypeScript, décorateur @ccclass
• API : API officielle Cocos Creator (node.getComponent, node.on, etc.)

【Format de sortie】

1. Code de scène (logique complète de création de nœuds)
2. Code de scripts (annotations de type et commentaires)
3. Code d’écoute d’événements (logique d’interaction)

### Modèle 2 : Créer un nœud et attacher des composants

【Rôle】Développeur Cocos Creator TypeScript

【Tâche】Créer le nœud {nom du nœud} et attacher les composants {liste}

【Propriétés du nœud】

• Nom : {nodeName}
• Position : ({x}, {y})
• Taille : {width}x{height}
• Ancrage : ({anchorX}, {anchorY})

【Configuration des composants】

1. {nom du composant} :
   • {propriété} : {valeur}
2. {nom du composant} :
   • {propriété} : {valeur}

【Format de sortie】

• Code TypeScript avec annotations de type
• API Cocos Creator 3.8
• Commentaires en français expliquant chaque ligne

### Modèle 3 : Implémenter une logique d'interaction

【Rôle】Expert du système d’événements Cocos Creator

【Tâche】Implémenter la logique d’interaction suivante

【Description de l’interaction】

Condition de déclenchement : {condition}
Type d’événement : {type}
Objet cible : {nom du nœud}
Comportement de réponse : {nom de la méthode}
Changement d’état : {description}

【Contraintes techniques】

• Écoute via node.on
• Types d’événements via l’énumération Node.EventType
• Callback avec paramètre event
• node.off à la destruction pour annuler l’écoute

【Format de sortie】

• Code TypeScript
• Logique complète d’écoute, callback et destruction
• Gestion d’erreurs (nœud absent, composant manquant)

### Modèle 4 : Créer un composant script

【Rôle】Expert en scripts Cocos Creator

【Tâche】Créer le composant script {nom du script}

【Fonction du script】

{description de la fonction}

【Définition des propriétés】

@property({type})
{nom} : {type} = {valeur par défaut}

【Liste des méthodes】

1. {nom}({paramètres}) : {type de retour}
   • Fonction : {description}
2. {nom}({paramètres}) : {type de retour}
   • Fonction : {description}

【Cycle de vie】

• onLoad : {logique d’initialisation}
• start : {logique de démarrage}
• update(dt) : {logique par frame}

【Format de sortie】

• Code TypeScript avec décorateurs @ccclass et @property
• Méthodes de cycle de vie complètes
• Annotations de type et commentaires en français

### Modèle 5 : Optimiser les performances de l'arborescence

【Rôle】Expert en optimisation des performances Cocos Creator

【Tâche】Optimiser les performances de l’arborescence suivante

【Arborescence actuelle】

{JSON de l'arborescence}

【Problèmes de performance】

• Trop de nœuds : {quantité}
• DrawCall trop élevé : {nombre}
• Mémoire excessive : {taille}

【Objectifs d’optimisation】

• FPS : ≥ 60
• DrawCall : ≤ 20
• Mémoire : ≤ 100 Mo

【Stratégies d’optimisation】

1. Fusion de nœuds : {plan}
2. Pool de nœuds : {plan de réutilisation}
3. Optimisation des composants : {plan}

【Format de sortie】

• JSON d’arborescence optimisé
• Code TypeScript d’optimisation
• Données comparatives (avant vs après)

Ces cinq modèles couvrent le flux complet : scène, nœuds, interactions, scripts, performance. Chacun suit le cadre CREATE : Context (rôle), Action (tâche), Edge (contraintes), Example (JSON d'arborescence).

Copiez le modèle, remplacez le contenu entre `{}`. Par exemple, modèle 2 pour Player : `{nodeName}` → `Player`, `{liste}` → `Sprite, RigidBody2D, PlayerScript`. L'IA génère le code complet — vous gagnez du temps sur la rédaction du prompt.

## Résumé

Quatre méthodes et cinq modèles pratiques. Points clés :

**Quatre éléments pour la scène** : type, style, éléments, points d'interaction. Fixez d'abord le squelette, puis le contenu — l'IA génère un niveau structuré.

**Format JSON pour l'arborescence** : racine → sous-nœuds → composants → propriétés → position. Format structuré pour la hiérarchie — l'IA crée couche par couche sans mélanger parent et enfant.

**Quatre champs pour les composants** : fonction, propriétés, dépendances, configuration d'exemple. Usage, paramètres, prérequis — l'IA génère le code d'attache en conséquence.

**Cinq éléments pour les interactions** : condition, type d'événement, objet cible, comportement, changement d'état. Boucle fermée complète — pas d'oubli dans le code généré.

Cinq modèles pratiques : scène, nœud, interaction, script, performance. Cadre CREATE, copiez et remplacez `{}`.

La prochaine fois que vous décrivez un besoin de jeu à l'IA, essayez le JSON pour l'arborescence et la formule en cinq éléments pour les interactions. Comparez : description floue → code fragmenté, hiérarchie confuse, interactions incomplètes ; description standardisée → structure complète, hiérarchie claire, boucle d'interaction fermée. Le gain d'efficacité est concret.