OpenClaw Game Dev : pipeline autonome pour creer des jeux educatifs

Un parent voulait creer un portail de jeux safe, sans pubs, sans dark patterns, pour ses enfants. Le portail etait facile. Le vrai probleme etait de le remplir avec des dizaines de jeux educatifs coherents (0 a 15 ans) sans equipe de developpeurs.

La solution a ete de transformer OpenClaw en "Game Developer Agent" : un agent discipline qui suit une queue de production, genere les fichiers HTML/CSS/JS, enregistre le jeu dans un registre central, met a jour la doc, gere git et priorise les bugs avant toute nouvelle feature.

Ce guide vous montre comment reproduire ce pipeline, et comment l'adapter a votre propre projet.

---

Le probleme : produire 40+ jeux en solo

Creer des jeux pour enfants impose des contraintes tres specifiques :

• Volume : un portail utile demande beaucoup de jeux (formes, couleurs, chiffres, memoire, logique).
• Cohérence : chaque jeu doit respecter les memes regles UX (cibles tactiles, feedback, retour).
• Performance : chargement rapide, offline si possible, pas de dependances externes.
• Maintenance : plus vous avez de jeux, plus les bugs s'accumulent.

Sans systeme, vous finissez par avoir 10 jeux "a peu pres" et 30 idees qui ne sortent jamais.

---

La solution : un agent developpeur avec une politique "bugs first"

Le pipeline repose sur une regle non negociable :

1. L'agent regarde d'abord le dossier bugs/
2. S'il y a un bug, il corrige uniquement le premier fichier (ordre alphabetique)
3. S'il n'y a pas de bug, il prend le prochain jeu marque [NEXT] dans development-queue.md

Puis il execute un cycle complet :

• synchronisation git
• creation de branche
• implementation
• enregistrement dans le registre central
• mise a jour du changelog et des plans
• commit conventionnel
• push

---

Skills requis

Ce use case est puissant car il demande peu d'integrations :

• acces fichiers (lecture/ecriture)
• commandes shell
• git

Pas besoin d'API externe. Le pipeline est "local-first".

Pour comprendre la logique des skills et de l'orchestration, voir : Guide des skills OpenClaw.

---

Setup pas a pas

Etape 1 : definir une structure de repo rigide

Exemple de structure :

my-game-portal/
  public/
    games/
      color-match/
        index.html
        style.css
        game.js
    js/
      games-list.json
  bugs/
  game-design-rules.md
  development-queue.md
  master-game-plan.md
  games-backlog/
  CHANGELOG.md

La rigidite aide l'agent a etre coherent.

Etape 2 : ecrire game-design-rules.md

Votre fichier de regles est votre contrat.

Points recommandes :

• HTML5/CSS3/JS vanilla, pas de frameworks
• mobile-first, events tactiles
• pas de CDN externes
• accessibilite de base (contraste, focus)
• tailles minimales de boutons
• feedback correct/incorrect
• bouton retour visible

Ajoutez aussi des standards code (noms de fichiers, commentaires en anglais, etc.).

Etape 3 : creer la queue development-queue.md

# Development Queue

## Next Games
- [NEXT] color-match (age: 3-5)
- shape-sorter (age: 0-3)
- number-count (age: 3-5)

## Completed
- (none)

Etape 4 : ecrire les specs dans games-backlog/

Chaque jeu doit avoir un spec clair.

Exemple :

• description
• mecanique
• regles UX
• assets
• conditions de victoire
• niveau de difficulte

Plus le spec est clair, plus le taux de reussite est eleve.

Etape 5 : mettre en place le registre central

Le fichier public/js/games-list.json est la source de verite.

Regles :

• l'agent doit enregistrer chaque nouveau jeu
• le format doit etre strict
• si un champ manque, le jeu n'apparait pas

Etape 6 : template de bug report (critique)

La politique bugs-first marche si les bugs sont reproductibles.

Template bugs/YYYY-MM-DD-short-title.md :

• Game ID :
• Device/browser :
• Steps to reproduce :
• Expected :
• Actual :
• Capture (optionnel) :

Etape 7 : prompt systeme pour l'agent

Utilisez un prompt structure (resume ici) :

Agis comme un expert en web game dev et UX enfant.

Priorite 1 : dossier bugs/.
S'il y a des fichiers, corrige uniquement le premier.

Sinon, lis development-queue.md, prends le jeu [NEXT].
Lis game-design-rules.md et la spec dans games-backlog/.
Implemente dans public/games/[game-id]/.
Enregistre dans games-list.json.
Mets a jour CHANGELOG.md, master-game-plan.md, development-queue.md.
Commit conventionnel et push.

---

Aller plus loin : tests, CI et controle qualite

Ajouter une etape de review (PR)

Dans un pipeline totalement autonome, la merge automatique peut etre trop agressive. Pattern recommande :

1. l'agent cree une branche feature/[game-id] ou fix/[bug]
2. il push
3. il ouvre une Pull Request
4. il poste un resume dans Discord (ou email)
5. un humain valide et merge

Prompt :

Apres chaque game/bugfix :
- ne merge pas automatiquement
- cree une PR avec :
  - description
  - checklist des regles respecteées
  - instructions de test
- attends mon ✅ avant merge

Tests simples (meme sans framework)

Vous pouvez ajouter des tests "low tech" :

• verif qu'une page se charge (headless)
• verif que les assets existent
• linter JS
• check taille totale des fichiers

Exemple de checklist automatique :

• index.html present
• style.css present
• game.js present
• aucun lien CDN externe
• taille < 500KB

Politique de regression

A partir de 20 jeux, les regressions deviennent reelles. Ajoutez un fichier smoke-tests.md que l'agent execute a chaque release :

• ouvrir 5 jeux aleatoires
• verifier bouton retour
• verifier responsivité

Documentation vivante

Le vrai gain vient aussi de la doc.

• master-game-plan.md doit toujours refléter l'etat
• CHANGELOG.md doit etre lisible
• development-queue.md doit etre a jour

L'agent doit traiter ces fichiers comme des sources de verite, pas comme des notes.

Resultats attendus

Ce pipeline a ete utilise pour produire des dizaines de jeux educatifs avec :

• coherences UX
• cadence reguliere
• priorisation automatique de la qualite via bugs-first
• historique git propre

Le gain majeur n'est pas seulement la vitesse, mais la reduction de charge mentale.

---

Adaptations utiles

Ajouter une etape de review humaine

Pour plus de securite, remplacez la merge automatique par une PR :

• l'agent push la branche
• l'agent cree une PR avec checklist
• un humain valide

Ajouter des tests simples

Sans frameworks, vous pouvez quand meme ajouter :

• une page de test manuelle
• un linter
• une verification "game loads" via headless browser

Pour une equipe

Discord peut servir de cockpit :

• #bugs pour remonter les issues
• #releases pour les changelogs
• #review pour valider les PR

---

Comment ClawRapid s'integre

Un pipeline autonome beneficie d'un agent toujours disponible. Avec ClawRapid, vous hebergez OpenClaw en continu et vous laissez l'agent avancer sur la queue pendant que vous dormez, avec un historique clair des commits.

---

FAQ

Le code est-il suffisamment bon pour la prod ?

Pour des jeux HTML5 simples et bien specifies, oui. Les regles et les specs reduisent fortement le risque.

Que faire si l'agent introduit un bug ?

Creez un fichier dans bugs/. Au prochain cycle, l'agent le corrige avant de faire un nouveau jeu.

Puis-je utiliser React/TypeScript ?

Oui, mais vous augmentez la complexite et donc les erreurs. Le pattern original prefere du vanilla pour la robustesse.

Comment tester avant de publier ?

Ajoutez une branche staging et une etape de review avant merge.

Combien de jeux par session ?

Souvent 5 a 8 avant de devoir relancer ou repartir en sessions courtes. Les cron jobs/heartbeats peuvent redemarrer le cycle.

Ce pattern marche pour d'autres projets ?

Oui. Tout workflow repetitif (pages, docs, features) beneficie d'une queue + regles + enregistrement + git.

---

A lire ensuite

• 30+ Cas d'usage OpenClaw
• Guide des skills OpenClaw
• OpenClaw + n8n