Bonjour. J’ai récemment créé seul un jeu mobile intitulé « Sumbi ». C’est un roguelike vertical inspiré de la plongée des haenyeo de Jeju. Le joueur plonge en mer en une seule respiration pour récolter des fruits de mer, et doit décider s’il veut se montrer plus gourmand ou remonter tout de suite.
J’ai commencé la conception le 2 juillet, mis en ligne une première build sur Google Play le 9 juillet, puis continué à corriger les points qui me semblaient insuffisants en jouant ; le 19 juillet, j’ai uploadé jusqu’à la build v1.1 en production.
Ce qui m’intéressait dès le départ n’était pas simplement de savoir « à quelle vitesse l’IA peut coder ». Je voulais tester jusqu’où il était possible d’aller pour créer un jeu réellement publiable en attribuant des rôles différents à plusieurs modèles d’IA, comme s’ils formaient une équipe de développement.
De quel type de jeu s’agit-il ?
« Sumbi » tire son nom de « sumbisori », le souffle semblable à un sifflement que les haenyeo expirent en remontant à la surface après leur plongée.
Une partie dure environ 10 à 30 secondes. D’une seule main, on déplace la haenyeo pour descendre plus profondément ou récolter les fruits de mer alentour. Comme il faut atteindre la surface sain et sauf pour conserver l’intégralité de sa collecte, on pèse sans cesse le pour et le contre entre pousser un peu plus loin et remonter maintenant. Une fois remonté, on comptabilise la récolte, on améliore sa capacité pulmonaire, ses palmes, son filet et son sens de l’observation, puis on replonge.
J’y ai ajouté un draft roguelike où l’on choisit à chaque partie l’une de trois capacités, une encyclopédie de 60 espèces de fruits de mer, de l’équipement et un arbre de progression, des promotions de rang pour la haenyeo, ainsi qu’un gouffre sous-marin qui descend jusqu’à 100 m. Les contrôles restent simples, mais plus on enchaîne les plongées, plus les records visés et les builds changent.
Je n’ai pas utilisé l’IA comme un développeur universel unique
Quand un seul modèle prend en charge à la fois la conception, l’implémentation et sa propre vérification, il a tendance à traiter ses propres prémisses comme des réponses correctes. J’ai donc réparti les rôles ainsi.
- Fable 5 : structure du jeu, spécification des fonctionnalités, objectifs d’équilibrage économique, conception des critères de complétion
- Opus 4.8 : implémentation Flutter·Flame, écriture des tests, débogage
- Fable 5 : comparaison entre les spécifications initiales et le résultat implémenté pour vérifier les oublis et les régressions
- Codex GPT-5.5 : revue indépendante du code et des changements, signalement des cas limites
Le déroulé du travail était globalement : conception → implémentation → revérification par le concepteur initial → revue de code indépendante → tests automatisés et jeu en conditions réelles.
À l’usage, il s’est avéré plus important de définir d’abord des critères de complétion vérifiables que de rédiger de beaux prompts. Au lieu de demander « rends la progression satisfaisante », j’ai fixé des chiffres : nombre d’achats dans les 10 premières minutes, temps nécessaire jusqu’à la première promotion, absence de longues périodes où l’on ne peut rien acheter dans chaque phase de progression, etc. Ensuite, j’ai vérifié tout cela avec un simulateur économique et des tests.
Les tests automatisés sont actuellement au nombre de 627 et passent tous. L’analyse statique Flutter passe également sans erreur sur le code de l’app, les tests et les outils.
Des cas où l’IA se trompait de façon plausible
La première conception n’a pas donné immédiatement un jeu amusant.
Dans la version initiale, il n’y avait que 5 à 9 cibles récoltables par partie. Pour un jeu de collecte, la mer paraissait vide. Après l’avoir essayé moi-même, j’ai abandonné cette structure. J’ai modifié le jeu pour que le terrain devienne plus dense à mesure que l’on progresse, et que les fruits de mer repoussent aux emplacements déjà récoltés. Avec certains builds de progression, on peut en récolter environ 40 en une partie.
L’arbre de progression posait un problème similaire. Il comptait bien 290 nœuds, mais le gameplay réel était presque linéaire. L’IA avait satisfait l’exigence des « 290 nœuds », mais n’avait pas pour autant créé le plaisir du choix. J’ai finalement réorganisé la structure en trois voies de spécialisation et des nœuds permanents.
L’IA produit beaucoup de code rapidement, mais elle ne garantit ni le fun ni les bonnes priorités. Jouer soi-même et trancher franchement — « ce n’est pas amusant », « il y a beaucoup de fonctionnalités, mais le prochain objectif n’est pas visible » — reste une responsabilité humaine.
J’ai aussi créé mon propre pipeline pour l’image et le son
Les principaux assets visuels, comme le personnage de haenyeo, les fruits de mer, l’équipement et les icônes de cartes, ont été créés avec l’API de génération d’images de GPT. Je n’ai pas utilisé les spritesheets générées telles quelles : je les ai passées dans un pipeline de correction comprenant suppression du fond vert, alignement des frames, uniformisation des tailles et quantification des pixels, puis je les ai vérifiées. Les arrière-plans, les bulles et les rayons de lumière ont pour la plupart été dessinés en code.
Pour le son, au lieu de rassembler des assets externes, j’ai synthétisé des WAV en code Dart. Le sumbisori que l’on entend à la fin d’une plongée a été conçu comme le son central où le nom du jeu rejoint la fin d’une partie.
Ce que j’en pense après l’avoir créé
On dit souvent que « l’IA est performante quand on sait bien lui demander ». Cette fois, j’ai surtout appris qu’« il faut une structure capable de détecter ses erreurs ».
J’ai séparé les rôles de concepteur, d’implémenteur et de vérificateur, et fait en sorte que d’autres modèles examinent de manière critique le plan et le code. Le jugement final revenait aux chiffres, aux tests et au jeu réel. Cette méthode s’est révélée bien plus stable que de confier tout le travail à une longue conversation avec un seul modèle.
Même avec une IA plus rapide, les goulots d’étranglement du développement solo n’ont pas disparu. Ils se sont simplement déplacés du codage vers la prise de décision. Déterminer ce qu’il faut garder ou jeter, et pourquoi ce n’est pas amusant à un moment donné, a été ce qui a pris le plus de temps.
Google Play
https://play.google.com/store/apps/details?id=com.kinderia.sumbi
C’est encore un jeu fait en solo, donc il a beaucoup de lacunes. J’aimerais avoir vos avis : est-il amusant, le menu de progression est-il trop complexe ? N’hésitez pas aussi à laisser des questions sur la méthode de développement ou la répartition des rôles entre les modèles.
Aucun commentaire pour le moment.