Histoires de monstres
Publié le
Au départ, je voulais apprendre à faire un petit jeu avec Godot. Monstres Papillons est devenu un terrain d’expérimentation pour le design, les agents de code… et même la musique.
Un souvenir de Windows 3.1
J’ai commencé à penser à ce jeu il y a un peu plus d’un an. J’avais envie d’apprendre à faire un jeu avec Godot, un moteur de jeu 2D et 3D open source. Je cherchais une idée assez simple pour démarrer et découvrir les mécaniques, le langage de script, les sprites, le travail du son…
J’ai commencé par les excellents tutoriels de Godot, tout à la main, pour avoir une vue d’ensemble. Et pendant ce temps, une idée me trottait dans la tête :
Il me faudrait un petit jeu simple, pour mobile. Tiens, et si je refaisais une version de ce vieux jeu sur Windows 3.1 auquel je jouais avec mon beau-frère quand j’étais gamin ?
Je ne me rappelais plus du tout son nom : c’était JezzBall. Mais je me souvenais bien de sa mécanique. Des boules se déplacent sur une grille ; on lance des coupes verticales ou horizontales pour réduire le terrain, sans qu’une boule vienne frapper une coupe en cours de construction. Un jeu de patience, avec lequel on s’amusait bien à se lancer des défis.
Une mécanique simple, des mouvements assez basiques : ça me semblait parfait pour expérimenter avec Godot. Faire bouger les boules de façon fluide au fil des mises à jour du moteur, calculer les angles de rebond dans une zone rectangulaire, puis trouver les zones à retirer après chaque coupe… J’avais de quoi apprendre.
Février 2026 : les premiers essais
Tout en me formant doucement à Godot, le soir ou le week-end quand j’avais le temps, j’ai commencé à discuter avec Le Chat de Mistral pour explorer l’approche, notamment visuelle. Mes premiers essais n’étaient franchement pas très beaux. :D
J’explorais aussi les algorithmes pour gérer les coupes et calculer les zones. L’IA m’aidait à écrire de petits bouts de script et à tester des approches, comme le flood fill : un parcours des cases voisines qui permet de repérer une zone après une coupe.
L’idée faisait son chemin. Sur mobile, j’avais envie d’un jeu amusant, avec un peu plus de caractère que de simples boules.
Mais je n’ai pas été plus loin à ce moment-là. J’ai laissé le sujet en suspens pendant plusieurs mois.
Fin août : reprendre avec Codex
J’ai passé une bonne partie de l’été à jouer avec Codex. À partir de quelques propositions open source, je me suis fabriqué des skills : des ensembles de consignes pour travailler avec l’agent sur le design à deux, l’exploration d’idées, les spécifications ou l’expérience utilisateur.
Une petite panoplie pour avancer par étapes concrètes, tout en suivant un fil rouge précis. À force de répéter la démarche, j’ai trouvé une méthode qui fonctionne bien pour moi :
- Partir d’une idée générale et demander des maquettes.
- Itérer sur les visuels pour préciser la direction.
- Définir le périmètre d’un petit prototype.
- Rédiger des spécifications limitées à ce premier essai.
- Faire implémenter le prototype, puis le tester.
Pour ce projet, Codex s’est montré très à l’aise avec Godot et ses contraintes. Il m’a aussi permis de produire de petits visuels que je pouvais adapter et utiliser comme sprites. À moi de choisir la direction artistique, de travailler les mécaniques du jeu et d’orienter le développement.
Un atelier dans l’atelier
Pour faire un bon jeu, il faut une progression régulière, des objectifs atteignables mais qui demandent de relever un défi, du fun… Bref, pas mal d’ingrédients assez difficiles à réunir. On ne peut pas y arriver du premier coup. Une idée qui paraît bonne au départ peut très bien s’avérer être une impasse quand on la met en œuvre et qu’on essaie de jouer.
Pour fabriquer les niveaux et tester toutes mes (trop nombreuses!) idées , j’ai construit un atelier de conception de niveaux dans Godot. Il me permet de tester les mécaniques, de composer les niveaux et de vérifier s’ils sont jouables et amusants.
En pratique, c’est toujours le même cycle : idée => un prototype => tests => évaluation => corrections… puis abandon de la piste, intégration au jeu ou une nouvelle idée (les idées viennent en faisant, en confrontant l'intuition à du concret). Et on recommence. Le test de jouabilité et de fun finit par trancher.
J’avais pensé à plein de petites choses : un monstre qui casse les murs, des bonus à récupérer, des terrains avec du relief… Certaines idées sont simplement remises à plus tard ; d’autres sont complètement abandonnées.
J’ai aussi exploré des idées de mise en récit, notamment toute une aventure autour d’un robot solitaire qui doit terraformer une planète… Bon, j’y reviendrai peut-être plus tard. :)
Déléguer le code, garder la direction
Au départ, j’avais franchement l’ambition de coder moi-même en Godot. Mais, en pratique, j’ai assez vite laissé cette partie aux agents de code pour me concentrer sur mes points forts : les choix de design, la planification et les priorités.
C’est moi qui porte l’intention. L’IA peut proposer des pistes et les mettre en œuvre ; c’est à moi de décider où je veux aller, puis de vérifier ce que donne le résultat en jouant.
Aujourd’hui, je travaille aussi bien avec Codex qu’avec Mistral Vibe. Codex m’accompagne surtout sur le design, le brainstorming et la planification. Pour l’implémentation et la correction de bugs, je travaille plutôt avec Mistral Vibe.
J’ai notamment eu une très bonne session de refonte du moteur du jeu avec Mistral Vibe et GLM 5.3, pour optimiser les performances. Sur ce type de travail, cette combinaison s’est montrée redoutablement efficace : analyse du code, mesures de performance (benchmarks), audit et optimisation. C’est un exemple concret de ces moments où je reviens sur les choix techniques pour faire évoluer le jeu.
Sur Monstres Papillons, j’ai fini par déléguer toute l’écriture du code. Cette expérience m’a convaincu que c’était possible pour ce projet, à condition de conserver quelques garde-fous :
- Concevoir et valider l’architecture. Garder une vue d’ensemble, même quand on n’écrit pas chaque ligne.
- Exiger des tests. Vérifier les comportements au fur et à mesure de leur implémentation.
- Documenter en continu. Avant et après l’implémentation, pour garder une trace des intentions et des décisions.
- Rester sur des boucles courtes. Limiter chaque étape pour pouvoir tester moi-même tout ce qui vient d’être ajouté.
- Revenir régulièrement sur l’architecture et les performances. À mesure que le jeu grandit, le code peut se dégrader et certains choix doivent être repris.
Après trois semaines d’affilée de travail quotidien, j’étais très content du résultat.
Et la musique dans tout ça ?
Je suis prêt à utiliser l’IA pour à peu près tout. Mais le son et la musique, ça m’amuse vraiment de les faire moi-même.
Je voulais une ambiance arcade à l’ancienne, un son un peu « Nintendo ». J’ai commencé par pianoter pour trouver un motif qui fonctionne bien, puis j’ai écrit la partition dans Noteflight pour passer au MIDI et obtenir cette régularité un peu robotique que je suis incapable de tenir en jouant moi-même.
J’ai tout de même eu envie de tenter une expérience avec l’IA. Je suis très lent à écrire une partition. Puisque le thème était déjà composé, est-ce que ChatGPT pouvait m’aider à écrire les différentes parties de basse, de batterie et de cuivres à partir d’un export MIDI de ma première version ?
Eh bien, ça marche plutôt bien ! J’ai gagné un peu de temps et, surtout, testé un procédé que je réutiliserai probablement : donner des instructions assez précises pour obtenir un fichier MIDI proche de ce que j’ai en tête, puis l’écouter et le retravailler.
Bon, en pratique, j’ai modifié pas mal de choses derrière, et j’aurais pu m’en passer. Mais ça reste une expérience intéressante !