Créer un jeu avec l’IA : de Phaser à Godot

Le moyen le plus simple de créer un jeu avec l’IA est de demander à un agent de code d’écrire un petit jeu navigateur en canvas HTML ou avec Phaser, de jouer chaque modification dans le navigateur aussitôt, et de régler vous-même la « sensation » du jeu, car c’est la partie que l’agent ne peut pas juger. Pour des projets 2D ou 3D plus gros, Godot est une bonne étape suivante. Une fois terminé, vous pouvez mettre le jeu sur itch.io et le partager en quelques minutes.

Cet article mène un premier jeu d’un dossier vide à une page publiée : l’outil que je choisis et pourquoi, le premier prompt donné à l’agent, la boucle de jeu, les visuels et le son (licences comprises), le réglage du game feel, les tests joueurs et itch.io.

Pourquoi les jeux se prêtent si bien au vibe coding

Les jeux font partie des choses les plus amusantes et les plus instructives à construire en vibe coding. Les résultats sont immédiats : changez un nombre et le personnage saute plus haut. Un petit jeu ne compte que quelques fichiers, l’agent peut donc tout garder en contexte.

Il y a toutefois un piège. « Ça tourne » et « c’est agréable à jouer » sont très éloignés. L’agent peut vérifier que le code fonctionne ; il ne peut pas vérifier que le jeu est amusant. Cette partie vous revient.

Quel outil : canvas, Phaser, Godot ou Unity

Pour un premier jeu, je recommande Phaser. Le canvas pur marche aussi, mais faire écrire à l’agent les collisions, l’animation de sprites et la gestion des entrées à partir de zéro prend du temps ; Phaser vous les offre. Et tout est un fichier texte qui tourne dans un navigateur : aucun éditeur que l’agent ne puisse voir.

Passez à Godot quand le jeu grossit : beaucoup de scènes, un level design complexe, de la 3D ou une version desktop. Les fichiers de scène (.tscn) et de ressources (.tres) de Godot sont du texte lisible, l’agent peut donc les modifier. Je compose malgré tout les scènes moi-même dans l’éditeur et je laisse le GDScript à l’agent ; une petite erreur dans un fichier de scène modifié à la main peut empêcher l’éditeur de l’ouvrir.

Unity est puissant mais l’option la plus malcommode à piloter avec un agent. L’agent écrit sans souci des scripts C# ; les scènes, prefabs et réglages de l’inspecteur vivent dans l’éditeur. Si vous connaissez déjà Unity, utilisez-le ; pour un premier jeu, ce n’est pas mon choix.

Étape 1 : mise en place

Ce qu’il vous faut :

• Node.js et un gestionnaire de paquets
• Un agent de code : Claude Code, Codex, Gemini CLI, opencode ou équivalent
• Git, pour pouvoir toujours revenir à « ça marchait hier »

Démarrez un projet avec Vite et ajoutez Phaser :

npm create vite@latest cactus-run -- --template vanilla-ts
cd cactus-run
npm install
npm install phaser
git init && git add -A && git commit -m "initial scaffold"
npm run dev

npm run dev affiche une adresse locale ; ouvrez-la pour voir le jeu, et la page se recharge à mesure que l’agent modifie les fichiers.

Étape 2 : le premier prompt

Le premier prompt compte beaucoup pour les jeux, car « fais un jeu » vous donne le jeu que l’agent imagine. Gardez un périmètre petit et concret :

This is a Vite + TypeScript project with Phaser installed. We're
building a simple endless runner.

Game:
- The player runs left to right and jumps with space or a tap.
- Cacti come in from the right; touching one ends the game.
- Score increases over time and shows in the top right.
- On game over, show "Press space to restart".

Rules:
- Use coloured rectangles instead of art for now.
- Put every tunable number (gravity, jump velocity, game speed,
  cactus spacing) in a single object in src/config.ts.
- Use Arcade physics.
- The game is 800x400 and scales to fit the screen.
- npx tsc --noEmit must pass.
- When done, explain the file structure and the values in config.ts.

La règle la plus précieuse ici est config.ts. Vous réglerez la sensation en jouant avec les nombres de ce fichier ; s’ils sont éparpillés dans le code, chaque ajustement oblige à repasser par l’agent.

La règle « rectangles au lieu de visuels » compte aussi. Réussissez d’abord le gameplay, embellissez ensuite. Un prototype magnifique mais pas amusant est le pire résultat.

Étape 3 : comprendre la boucle de jeu

Au cœur de chaque jeu, il y a une boucle : lire les entrées, mettre à jour le monde, dessiner l’écran, recommencer, des dizaines de fois par seconde. Phaser l’exécute pour vous et appelle le update(time, delta) de votre scène à chaque frame. Avec un canvas pur, vous l’écrivez vous-même :

let last = performance.now()

function loop(now) {
  const dt = (now - last) / 1000 // seconds since the last frame
  last = now
  update(dt)
  draw()
  requestAnimationFrame(loop)
}

requestAnimationFrame(loop)

Le seul concept à connaître est dt : déplacez les objets en fonction du temps écoulé, pas par frame. Les agents écrivent parfois x += 5, et le jeu tourne alors plus vite sur un écran à fréquence de rafraîchissement élevée. Si vous ne voyez pas dt dans le code de déplacement, interrogez l’agent à ce sujet.

Étape 4 : jouer, itérer, commiter

La boucle :

1. Jouez une minute.
2. Décrivez ce que vous avez ressenti, concrètement : « Le saut reste trop longtemps en l’air ; esquiver les cactus est trop facile. »
3. Laissez l’agent modifier, puis rejouez.
4. Commitez chaque version agréable.

Collez tel quel les erreurs de la console du navigateur (F12) dans l’agent. Pour les problèmes visuels, envoyez une capture d’écran.

Un avertissement : ne faites pas grossir la logique du jeu d’un seul coup. « Ajoute des power-ups, un combat de boss et un système de niveaux » emmêle les trois. Une mécanique à la fois.

Étape 5 : le game feel

Ce qui rend un jeu agréable, ce ne sont généralement pas les grosses fonctions mais les petits détails. Les agents ne les ajoutent pas spontanément, mais les implémentent bien quand on les demande :

• Coyote time : autoriser un saut un bref instant après avoir quitté un rebord.
• Jump buffering : mémoriser un saut pressé juste avant l’atterrissage.
• Hauteur de saut variable : couper la vitesse ascendante quand le bouton est relâché.
• Screen shake et hit stop : se figer quelques frames à l’impact.
• Tweens : le score qui « pop », un ennemi qui vacille en disparaissant.
• Son : un court son de saut change la sensation plus que n’importe quoi à l’écran.

Voici le genre de prompt que j’utilise :

Improve the jump feel:
- Add 100 ms of coyote time and a 100 ms jump buffer.
- If space is released early, halve the upward velocity.
- On collision, add an 80 ms hit stop and a light screen shake.
Put all durations in config.ts. Don't change any other behaviour.

Jouez ensuite vous-même avec les nombres de config.ts. Cette partie ne peut pas être confiée à une IA ; on ne ressent quelques millisecondes d’écart qu’en jouant.

Étape 6 : visuels, son et licences

Une fois le gameplay bon, remplacez les rectangles par de vrais visuels. Le seul point où il faut être prudent, ce sont les licences.

Packs prêts à l’emploi :

• De nombreux packs de sources comme Kenney sont en CC0, utilisables sans même mentionner l’auteur.
• Sur OpenGameArt, chaque fichier a sa propre licence (CC0, CC‑BY, CC‑BY‑SA, GPL…). CC‑BY exige une attribution ; CC‑BY‑SA peut vous obliger à partager les œuvres dérivées sous la même licence. Lisez la licence de chaque fichier.
• Les packs d’assets payants et gratuits sur itch.io ont chacun leur licence ; vérifiez si l’usage commercial est autorisé.

Tenez un CREDITS.md ou un écran de crédits dans le jeu qui liste la source et la licence de chaque asset.

Les visuels générés par IA sont rapides et tentants, mais avec quelques réserves :

• Le statut du droit d’auteur du contenu généré par IA varie selon les pays et certaines questions restent ouvertes.
• Chaque outil d’image a ses propres conditions d’utilisation ; vérifiez l’usage commercial.
• Certaines boutiques de jeux demandent de signaler le contenu généré par IA.
• C’est aussi délicat techniquement : cohérence de style, disposition des spritesheets et correspondance des frames d’animation demandent souvent un nettoyage manuel.

Mon approche : des packs sous licence ouverte pour le prototype ; pour la sortie, des visuels que j’ai faits moi-même ou dont je connais la licence avec certitude.

Il y a un travail d’assets que l’agent fait bien : charger une spritesheet dans Phaser, définir les animations, brancher les fichiers sonores. Donnez-lui les noms de fichiers et la taille des frames plutôt que de le laisser deviner.

Étape 7 : tests joueurs

La personne qui a construit le jeu en est le pire testeur ; elle sait déjà quoi faire. Il en va de même pour l’agent. Que faire :

• Donnez le jeu à quelqu’un sans rien expliquer. Observez en silence où cette personne bloque.
• Prenez des notes : où elle est morte, où elle s’est ennuyée, ce qu’elle a mal compris.
• Transformez ces notes en tâches pour l’agent : « Les joueurs touchent toujours le premier cactus ; pas de cactus pendant les 5 premières secondes. »

De petites parties de la logique du jeu (score, règles de collision) peuvent se vérifier avec des tests unitaires ; demandez à l’agent de les écrire. La sensation ne se teste qu’en jouant.

Étape 8 : publier sur itch.io

Mettre un jeu navigateur sur itch.io prend quelques minutes :

npm run build
cd dist && zip -r ../cactus-run.zip . && cd ..

Créez ensuite un nouveau projet sur itch.io, réglez son type sur HTML, envoyez le zip et marquez-le comme jouable dans le navigateur. Définissez la taille du viewport (800×400, par exemple) et le bouton plein écran. Le zip doit avoir index.html à sa racine ; avec Vite, il faudra peut-être base: './' dans vite.config.ts pour des chemins relatifs, ce que l’agent peut vérifier pour vous.

Dans Godot, installez le template d’export Web, exportez en HTML5 et envoyez de la même façon. Si vous mettez à jour souvent, l’outil en ligne de commande butler d’itch.io automatise les envois.

Ce que les agents font souvent de travers dans les jeux

• Ils ne voient pas le jeu. L’agent écrit du code mais ne sait pas ce qu’il y a à l’écran. Les captures d’écran ou une description de ce que vous voyez sont indispensables.
• Les nombres magiques. Les valeurs s’éparpillent dans le code. Répétez la règle config.ts à chaque nouvelle mécanique.
• Un déplacement dépendant des frames. Sans dt, le jeu tourne à des vitesses différentes selon l’écran.
• Des API obsolètes. Phaser et Godot ont changé d’API entre versions majeures, et l’agent peut écrire du code pour l’ancienne. Indiquez-lui la version : « On est sur Godot 4, n’écris pas de syntaxe Godot 3. »
• Tout dans un seul fichier. À mesure que le jeu grandit, demandez de séparer scènes, entités et réglages en fichiers distincts.
• Ignorer les performances. Avec des centaines de projectiles ou d’ennemis, le jeu ralentit. Demandez un object pooling.

Sécurité

Un jeu paraît inoffensif, mais les mêmes règles s’appliquent :

• Si vous ajoutez un classement ou un backend multijoueur, gardez les clés dans .env et ajoutez .env à .gitignore.
• Tout ce qui est dans un jeu navigateur peut être lu par le joueur ; les clés secrètes ne vont jamais dans le code client.
• Ne collez pas de clés API dans le chat ; dites à l’agent quelle variable d’environnement lire.
• Lisez les commandes que l’agent exécute avant de les valider, surtout les installations de paquets et les suppressions.
• Ne faites pas confiance aux scores envoyés par le client ; tricher sur un classement en ligne est facile.

Le faire avec AgentVera

Tout cela marche avec un terminal et un navigateur. Sur les projets de jeux, j’aime faire tourner quelques agents côte à côte et voir le résultat dans la même fenêtre, c’est pourquoi j’utilise AgentVera :

• Des expériences séparées dans des worktrees séparés. Un agent travaille sur la sensation du saut dans un worktree git pendant qu’un autre ajoute un nouveau type d’ennemi dans un second ; abandonnez l’expérience qui ne vous plaît pas. Le panneau Git montre les branches.
• Le navigateur d’agent. Avec le navigateur d’agent, l’agent peut ouvrir le jeu via Playwright et prendre des captures pendant que vous regardez l’onglet en direct. Cela règle en partie « l’agent ne voit pas le jeu » ; pas la sensation.
• Terminal et éditeur. npm run dev reste ouvert dans un panneau et vous modifiez config.ts vous-même dans l’éditeur.
• Revue et tokens. La revue de code contrôle chaque tour avant la fusion, et la consommation de tokens est visible par panneau.

AgentVera n’est pas un moteur de jeu ; il ne remplace ni l’éditeur Godot ni itch.io.

Checklist rapide

• Le premier jeu est petit : une mécanique, un écran
• Les nombres réglables vivent dans config.ts
• Les déplacements utilisent dt
• Le gameplay d’abord avec des rectangles, les visuels ensuite
• La source et la licence de chaque asset sont notées
• Au moins une personne y a joué sans explication
• Le zip itch.io a index.html à sa racine

Pour conclure

Créer un jeu avec l’IA est l’un des usages les plus plaisants du vibe coding. Commencez petit avec Phaser dans le navigateur, gardez les nombres dans un seul fichier, réussissez le gameplay avec des rectangles, réglez la sensation de vos propres mains et surveillez les licences. L’agent écrit le code ; c’est vous qui le rendez amusant. Pour mener des expériences avec plusieurs agents, voir les agents de code en parallèle ; pour choisir un outil, voir les meilleures CLI de code IA.