6 mois, 3 projets de jeux, 0 publié

Je voulais écrire ce post il y a quelques semaines. Mais je crois que j'espérais encore qu'au moment de m'asseoir pour l'écrire, au moins l'un des trois jeux que je construisais serait terminé.

Aucun ne l'est.

Donc voilà où j'en suis : 684 commits sur trois projets en six mois, et rien que vous puissiez télécharger, jouer ou envoyer à un ami. Si vous avez déjà appris quelque chose de nouveau en dehors d'un travail à temps plein — quelque chose de vraiment difficile, dans lequel vous n'étiez pas déjà bon — vous connaissez probablement très bien ce sentiment.

Je l'écris quand même, parce que je pense que l'histoire de pourquoi rien n'a été publié est plus utile qu'une annonce bien polie d'un projet terminé.

Le contexte de départ

Pendant 18 ans, j'ai travaillé dans la publicité. C'est un bon métier, exigeant, et je sais le faire. J'ai lancé des campagnes, construit des équipes, écrit des livres, parlé sur scène. Dans ce monde-là, je sais à quoi ressemble "terminé".

Puis fin 2025, j'ai décidé que je voulais apprendre le game development. Pas le game marketing. Pas la game strategy. Construire vraiment des jeux — le code, l'art, les systèmes, la sensation d'un personnage qui bouge à l'écran.

Je n'avais aucune expérience avec les game engines. Je n'avais jamais riggé un modèle 3D. Je ne savais pas ce qu'était une state machine dans le contexte de l'animation. Je code depuis quelques années maintenant, surtout des web apps et des produits AI, mais les jeux sont une discipline entièrement différente. (Corrigez-moi si je me trompe sur quoi que ce soit — je suis encore en train d'apprendre.)

Première chose apprise : publier un jeu est difficile. Deuxième chose : on ne peut pas raisonner son chemin vers un bon game loop depuis un document.

Il faut le voir bouger. Il faut y jouer, ou au moins le faire tourner dans le runtime Godot et observer si le personnage, la caméra, les contrôles et le feedback créent vraiment quelque chose. Ensuite, il faut être prêt à construire, supprimer, couper et reconstruire jusqu'à ce que quelque chose d'intéressant apparaisse.

Voici ce qui s'est passé.

---

Projet 1 : The AI Pet Sanctuary (288 commits)

Décembre 2025 – Février 2026

Le premier projet est parti d'une idée simple : et si vous pouviez avoir un animal de compagnie vivant sur votre ordinateur et qui vous parle avec l'AI ? Pas un chatbot avec un avatar d'animal — un vrai pet avec des comportements, un habitat et une personnalité.

J'ai construit une application full-stack. React côté frontend, FastAPI côté backend, Supabase pour la base de données. J'ai utilisé Gemini pour les conversations et Cloudflare Stream pour la vidéo.

La partie ambitieuse, c'était le système d'animation. Je voulais 18 types de pets répartis en six grandes catégories — chiens, chats, oiseaux, petits animaux, poissons, reptiles. Chacun devait bouger, cligner des yeux, et sembler vivant.

J'ai commencé avec des animations Rive. Elles ne fonctionnaient pas pour ce cas. Je les ai donc remplacées par des animations CSS et JavaScript. Puis j'ai construit une pipeline avec Google Veo 3.1 pour générer du contenu d'animation — de la génération vidéo AI pour les mouvements des pets. Ça marchait, mais c'était fragile. L'API échouait, la lumière était incohérente, l'échelle changeait d'une génération à l'autre. Je passais plus de temps à lutter contre la pipeline de génération qu'à concevoir l'expérience pet elle-même.

J'ai aussi construit un système d'habitat avec des environnements immersifs en plein écran — une pièce appelée "The Study" où vivait le pet. Care screens. Memory screens. Intégration conversationnelle. Un redesign complet "Quiet Luxury" à mi-parcours parce que la première version ressemblait à un prototype. (Parce que c'en était un.)

Puis j'ai pivoté.

288 commits plus tard, j'ai décidé que la web app était la mauvaise plateforme et j'ai commencé à planifier une version native iOS. Je ne sais toujours pas si c'était le bon choix ou juste de l'ennui déguisé en stratégie. Une partie de moi croit qu'un pet sur le téléphone est plus intime qu'un pet dans le navigateur. Une autre partie pense que j'en avais juste assez de React.

Mais si je suis honnête, la vraie raison pour laquelle je ne l'ai jamais publié était plus simple : c'était ennuyeux. J'avais construit tout ça — les habitats, le système d'animation, l'intégration conversationnelle — et quand il a fallu vraiment m'asseoir et interagir avec le pet, j'ai perdu l'intérêt en deux minutes. Rien n'était assez captivant pour retenir mon attention. Je joue aux jeux vidéo depuis le secondaire, donc je fais confiance à cette première réaction, même si je ne sais pas encore toujours comment la corriger. Je joue encore à Mobile Legends avec ma famille et je monte généralement jusqu'à Mystic. Ce n'est pas un jeu que l'on joue pour un confort passif — il demande de la compétence et de l'attention. Ce pet sanctuary ne demandait ni l'un ni l'autre.

Je continuais à me dire que le problème était la plateforme. Une web app ne pouvait pas offrir l'expérience immersive que je voulais. Peut-être qu'iOS serait différent. Mais au fond, je savais que le problème n'était pas React — c'était le design. Aucun changement de plateforme n'allait rendre excitant un game loop inintéressant.

Ce qui n'a pas marché

En regardant le repo, je ne pense pas que la bonne leçon soit "288 commits sans release, c'est mauvais". Si le core loop n'est pas engageant, le shipper plus tôt signifie seulement shipper quelque chose d'ennuyeux plus tôt.

Le vrai problème, c'est que je changeais sans cesse le contenant avant de prouver le loop. Le projet est passé de mécaniques merge/order, à pure companion, à habitats immersifs, à iOS. Chaque pivot avait une raison. Mais la question à laquelle je n'ai pas répondu assez clairement était plus simple : est-ce que j'aurais envie d'ouvrir ça tous les jours ?

J'aurais pu valider cela avec un pet, une pièce, une conversation et une interaction care/play. À la place, j'ai construit 18 types de pets dans 6 catégories animales avec un système complet d'habitat avant d'avoir une réponse runtime à la question la plus importante : est-ce que ce pet est intéressant à retrouver ?

L'animation générée par AI est puissante mais fragile. Quand elle fonctionne, c'est incroyable. Quand elle ne fonctionne pas, on debug des prompts et des erreurs API au lieu du produit. Il faut une pipeline de fallback, et je ne l'ai pas construite assez tôt.

Ce que j'ai appris

La première tâche n'est pas de réduire le scope. La première tâche est de trouver la partie intéressante. Parfois, cela veut dire construire plus. Parfois, cela veut dire supprimer ce que l'on vient de construire. L'erreur n'était pas l'exploration. L'erreur était d'explorer trop longtemps sans preuve jouable indiquant si l'expérience centrale avait de la vie.

---

Projet 2 : Le renard qui est devenu une étape (35 commits)

17 avril – 12 mai 2026

Après le pivot du pet sanctuary vers iOS, j'ai commencé un nouveau projet dans Godot 4.6. Je voulais construire un jeu from scratch dans un vrai game engine, pas une web app qui fait semblant d'être un jeu.

Le concept initial : un Spirit Fox Kit Sanctuary Sim. Un petit renard vit dans une pièce cosy, et vous vous occupez de lui. Simple, chaleureux, contenu.

J'ai mis en place le projet Godot. J'ai essayé de concevoir un personnage de renard avec des hidden tense silhouettes, des twitch animations plus rapides, et des micro-signals de stillness.

Mais cette phrase rend le prototype plus lisible qu'il ne l'était. À l'écran, le renard ne se lisait pas comme un renard. C'était une petite masse ronde. Je ne voyais pas de forme utilisable, encore moins le reste des visuels autour.

J'ai construit un draft room loop avec couverture de tests GUT. Audio placeholder. Hover cues pour les interactables. Room scene layout. Un cold-start playtest harness pour pouvoir vraiment jouer au truc.

Et puis j'y ai joué.

La vérité honnête est plus visuelle que philosophique : le renard échouait dès la première lecture. Le room prototype avait un chemin mécaniquement vérifié, et le repo consigne même un abbreviated solo gate pass pour le build en placeholder art. La stillness, l'emergence beat, la touch distinction et le room problem étaient acceptables à ce stade.

Mais acceptable pour un petit authored beat n'est pas la même chose que visuellement assez fort pour porter un jeu complet. Ce projet dépendait du renard pour porter l'expérience. Si je ne pouvais pas voir sa forme, sa posture et son appeal, le sanctuary loop n'avait pas encore de chance.

Donc le 20 avril — seulement trois jours après le début — j'ai écrit une pivot spec complète. Le fox sanctuary sim est devenu quelque chose de complètement différent : un landscape action-adventure avec un safehouse chaleureux et un territoire hostile à explorer. J'ai mis en pause les plans fox-first et commencé à concevoir une nouvelle direction.

35 commits. Un beat validé. Un pivot. Rien publié.

Ce qui n'a pas marché

Le vrai problème est que j'ai traité les signaux d'animation comme s'ils pouvaient compenser une forme de base illisible. Ils ne le pouvaient pas. Un twitch ne sert à rien si le corps en dessous n'a pas de silhouette.

Le pivot n'était pas la preuve que le premier travail était perdu. Il en a fait une fondation. Ce que je n'avais toujours pas, c'était la preuve que la direction Hearthkeeper plus large fonctionnerait, ou que je pouvais rendre son personnage central assez lisible pour qu'on s'y attache.

Ce que j'ai appris

Le playtesting précoce révèle ce qu'un prototype prouve vraiment. Le room prototype a prouvé le ton, le rythme et un relationship beat. Il n'a pas prouvé un jeu entier, et il a immédiatement exposé le problème de lisibilité visuelle. C'est une information utile, mais elle indique une autre prochaine étape : résoudre la lecture du personnage et construire le plus petit loop safehouse -> run -> return avant de repolir le renard.

Game 1 m'a appris qu'un loop techniquement complet peut quand même être ennuyeux. Game 2 m'a appris qu'un concept de personnage documenté et testé peut échouer visuellement en quelques secondes. Ces deux échecs expliquent en partie pourquoi Game 3 fait des progrès plus réels : je fais beaucoup plus attention à la readability, au motion, au weapon feel et au fait que le playable slice fonctionne à l'écran.

Pivoter depuis des preuves n'est pas la même chose que dériver. Le renard ne se lisait pas dans le runtime, donc changer de direction n'était pas automatiquement un manque de discipline. Ce que je dois améliorer, c'est la feedback loop : mettre la question visuelle ou gameplay la plus risquée à l'écran plus vite, puis décider avec des preuves au lieu de rester en concept mode.

---

Projet 3 : Celui où la pipeline a commencé à fonctionner (361 commits)

21 avril – 13 mai 2026

C'est le projet sur lequel je travaille encore. C'est aussi celui où les apprentissages des deux premiers projets ont enfin commencé à se renforcer.

C'est un jeu de mech tactics. Vous contrôlez une squad de mechs en combat, et après chaque bataille, un LLM analyse ce qui s'est passé et vous donne un debrief. Pensez à une analyse post-match, mais écrite par une AI qui a accès à tout le game state.

Le repo a trois tracks, mais ils ne sont plus égaux :

Track A — The LLM Debrief System : C'était le track de validation AI initial. Il m'a aidé à tester des structured debriefs, mais ce n'est plus le principal chemin produit.

Track B — The 2D Phone Prototype : C'est là que j'ai enfin trouvé une pipeline viable pour une expérience joueur 2D relativement immersive. Le runtime Godot réel a un lane-match combat loop, touch joystick, shop/modules, hero XP, ability cooldowns, VFX motifs lisibles sur téléphone, enemy punish zones, neutral relay objective, HUD feedback et flow iOS export/testing. L'art pipeline a commencé à fonctionner aussi : Nano Banana 2 (Gemini 3.1 Flash Image) a généré des images initiales utilisables de héros et de personnages, puis un workflow de pixel cleanup basé sur MCP et Aseprite a transformé les candidats curés en sprites propres, animation frames et sheets prêts pour Godot. Ce n'est pas un jeu terminé, et la phone acceptance est encore en attente, mais c'est beaucoup plus proche de "ça ressemble à un jeu" que les deux premiers projets.

Track C — The Campaign and 3D Path : C'est la direction produit actuelle. Elle garde les leçons utiles de Track B, ajoute une campaign memory loop, et déplace le production combat vers la 3D/2.5D. C'est un problème beaucoup plus dur que la pipeline 2D. En 2D, je peux contrôler la lisibilité avec des sprite sheets, du HUD tuning, des procedural VFX et des phone captures. En 3D, chaque décision touche au modeling, rigging, animation, camera, lighting, GLB export, weapon sockets, hit anchors, action timing et runtime performance.

J'ai aussi intégré Blender pour du custom rigging work, importé des données mocap Rokoko pour la locomotion, et construit le personnage hero mech avec full rig, animation tree et weapon socket integration.

361 commits en trois semaines. Une vraie pipeline 2D. Une expérience 3D beaucoup plus difficile. Encore en territoire prototype.

Ce qui n'a pas marché

Voici ce que je dois admettre : la pipeline 2D commence à fonctionner, mais la pipeline 3D peut avaler tout le projet si je la laisse faire.

Pour Track B, le travail de pipeline n'était pas un faux progrès. Le workflow Nano Banana 2 -> Aseprite, les touch controls, le HUD, les ability motifs lisibles, le module feedback, les phone captures et l'export loop rendaient le produit plus jouable. Ce travail m'a appris ce qu'un joueur doit voir et ressentir d'un moment à l'autre.

Le risque est différent maintenant. Dans Track C, la 3D demande beaucoup de pipeline avant de ressembler à quoi que ce soit : model import, rig quality, animation names, weapon attachment, muzzle position, hit center, camera angle, lighting, movement, jump timing, attack timing, VFX et runtime inspection. Ce ne sont pas des détails optionnels. Si le personnage n'est pas lisible, toute la scène échoue en quelques secondes.

Mais le playable encounter doit continuer à mener. Sinon, je peux passer des semaines à améliorer le weapon fit du hero mech, la jump compression, le left-hand IK et le mocap cleanup sans répondre à la question simple du joueur : est-ce amusant à contrôler ?

Ce que j'ai appris

Le travail de pipeline n'est utile que lorsqu'il continue à servir le playable slice. Track B m'a appris que la bonne pipeline peut créer une expérience 2D plus immersive. Track C m'apprend que la 3D augmente le coût de chaque amélioration. Je dois garder l'acceptance gate concret : le joueur peut-il lire le hero mech, le déplacer, viser, tirer, comprendre le hit, et vouloir recommencer ?

Les tracks ont besoin de gates. Track A a fait son travail. Track B a produit des leçons réutilisables sur le 2D game feel et la presentation. Track C est le pari actuel. Le problème n'est pas d'avoir exploré plusieurs chemins. Le problème est de les rouvrir sans question runtime claire ni règle de décision claire.

Le game development 3D est un énorme skill gap. Rigging, animation, mocap data, asset budgets, weapon sockets, camera framing et readable motion sont des disciplines dans lesquelles je n'ai aucune expérience professionnelle. Je les apprends tout en apprenant Godot, game design et campaign architecture. La courbe d'apprentissage n'est pas raide — elle est verticale. Je crois que c'est la partie qui m'a le plus surpris. En web development, je peux construire quelque chose de fonctionnel en une journée. En 3D game dev, j'ai passé une soirée entière à essayer de faire plier correctement le bras d'un personnage. (C'est le genre de phrase que je n'aurais pas comprise il y a six mois.)

---

Ce que ces trois projets ont en commun

Si je suis honnête avec moi-même — et ce post ne fonctionne que si je le suis — le pattern n'est pas "scope creep". C'est trop facile, et dans ce cas je pense que c'est faux.

Je ne pense pas que les jeux fonctionnent comme des business decks — du moins, c'est ce que ces trois projets m'ont appris. On ne sait pas qu'une idée marche parce que son pitch sonne bien. On le sait quand on peut y jouer, ou au moins la voir tourner dans l'engine et sentir si le personnage, la caméra, l'interaction et le feedback font quelque chose.

1. Le runtime est la vérité

Le pet sanctuary sonnait bien jusqu'à ce que j'interagisse avec le pet et que je m'ennuie. Le renard sonnait bien jusqu'à ce que je le voie dans Godot et que je ne puisse pas lire sa forme. Track B a commencé à fonctionner parce que le loop est entré dans un runtime proche du téléphone : touch controls, HUD, VFX, shop, XP, motifs lisibles et capture feedback.

C'est le vrai pattern. La vérité utile n'est arrivée que lorsque l'idée est devenue visible et jouable.

2. L'exploration est nécessaire, mais elle a besoin de preuves

Je ne pense pas que la bonne leçon soit "arrête d'ajouter des choses". Le game development exige de l'exploration. On construit, on essaie, on supprime, on coupe, on reconstruit et on réessaie parce qu'on cherche la partie intéressante.

La partie qui demande de la discipline n'est pas la quantité de travail. C'est l'evidence loop. Chaque morceau de travail devrait répondre à une question : est-ce que cela rend le jeu plus lisible, plus engageant, plus contrôlable, plus rejouable ?

3. Les pipelines sont bonnes quand elles rendent le jeu plus jouable

Le workflow Nano Banana 2 -> MCP cleanup -> Aseprite n'était pas une distraction. Il m'a aidé à intégrer de meilleurs personnages 2D et animations dans le jeu. Le travail HUD et VFX de Track B n'était pas un faux progrès non plus. Il a rendu le runtime plus clair.

Le risque apparaît quand la pipeline cesse de répondre à une question côté joueur. Dans Track C, le tooling 3D est nécessaire, mais il doit toujours revenir à une chose : le joueur peut-il lire le hero mech, le déplacer, tirer, comprendre le hit, et vouloir recommencer ?

4. Le gap n'est pas le coding skill. C'est le playable judgment.

Je peux construire une application full-stack avec Supabase, FastAPI et React. Je peux rigger un modèle 3D, écrire des tests GUT et construire des custom debugging tools. Ce que j'apprends encore, c'est à juger si quelque chose est réellement intéressant comme jeu. Track B m'a rapproché en 2D. Track C me montre à quel point cela devient plus difficile quand motion, camera, lighting, weapons et animation doivent fonctionner ensemble.

Je pense que c'est la chose la plus importante que j'ai apprise. Le code est la partie dans laquelle je suis bon. La partie difficile est de décider ce qu'est vraiment le jeu, de le rendre intéressant, puis d'avoir la discipline de revenir à l'évidence runtime jusqu'à ce qu'il vaille la peine d'être publié.

---

Ce que j'ai appris au total

Si j'essaie de distiller six mois en quelque chose d'utile — pour moi, ou pour quelqu'un dans la même position — voici ce que je pense savoir maintenant et que je ne savais pas en décembre :

1. La première version doit répondre à la question la plus risquée dans le runtime. Mon pet sanctuary avait besoin d'une interaction pet qui me donne envie de revenir. Mon jeu de renard avait besoin d'une silhouette lisible dans une pièce vide avant que je m'inquiète des micro-signals. Mon jeu de mechs s'est rapproché avec Track B parce que je pouvais voir et sentir le loop à l'écran.

2. Le playtesting n'est pas optionnel, et la runtime review compte. Au moment où j'ai vu le renard comme une masse sans forme, j'ai su que le projet ne fonctionnait pas encore. Ce furent les 30 minutes les plus précieuses du projet entier. J'aurais dû atteindre cette vérité visuelle plus tôt.

3. L'apprentissage est un résultat valable, même si ce n'est pas celui que vous aviez prévu. Je voulais construire des jeux. Je n'ai pas publié de jeux. Mais j'ai appris Godot, LLM prompt engineering, Nano Banana 2 pour character ideation, Aseprite animation cleanup, 2D phone readability, HUD and VFX feedback, animation pipelines, 3D rigging, mocap data, game feel, camera systems, visual readability et la différence entre construire des outils et construire des produits. Ce n'est pas rien. C'est aussi pour cela que Game 3 est meilleur que Game 1 et Game 2, même s'il n'est toujours pas publié.

4. Je dois encore définir une finish line honnête. Une partie de moi veut pousser ce projet jusqu'au bout pour pouvoir dire que j'ai publié un jeu. Une autre partie pense que l'apprentissage était le produit et que je devrais l'accepter. Les deux réponses sont honnêtes. Je crois que la vérité est quelque part entre les deux : publier un slice focalisé qui respecte ce que j'ai appris au lieu de repartir de zéro.

La suite

Je travaille encore sur le projet de mech tactics. Le concept de LLM debrief est intéressant, et je pense qu'il y a quelque chose de vraiment nouveau dans l'idée d'une analyse post-match alimentée par AI pour un tactics game.

Mais j'essaie de changer mon approche : runtime proof d'abord, polish ensuite, et ne publier quelque chose qu'une fois que le playable slice a une raison d'exister. Les deux premiers projets n'ont pas été perdus. Ils ont changé ce que je regarde dans Game 3 : est-ce que le personnage se lit, est-ce que le mouvement est bon, est-ce que l'arme se sent juste, et est-ce que quelqu'un peut comprendre l'encounter sans que j'explique l'architecture ?

Si je commençais un nouveau jeu aujourd'hui, je ne commencerais pas avec un gros architecture plan. Je commencerais avec la preuve runtime la plus rapide capable de répondre à la question qui m'importe vraiment. Pour Game 3 maintenant, la même discipline doit s'appliquer à l'intérieur du projet : un personnage, une arme, un encounter, un acceptance test clair.

Je ne sais pas encore si je pousserai l'un de ces projets jusqu'à la fin ou si j'accepterai que l'apprentissage était le produit. Je peux me tromper sur la timeline, mais je pense que le pattern compte plus qu'un projet en particulier.

Une question pour vous

Je veux poser la question sincèrement, pas de manière rhétorique : est-ce que vous êtes déjà passé par là ? (Je soupçonne que plus de builders l'ont vécu que nous ne l'admettons d'habitude.)

Avez-vous passé des mois à construire quelque chose qui n'a jamais été publié ? L'avez-vous terminé finalement, ou êtes-vous parti ? Et si vous êtes parti — était-ce la bonne décision, ou y pensez-vous encore ?

J'ai publié des choses dans ma carrière. Des campagnes, des plateformes, des produits. Mais c'était dans un domaine où j'avais 18 ans d'expérience. Le game development est nouveau, et l'écart entre "je peux techniquement construire ceci" et "ceci est un bon jeu" est beaucoup plus large que je ne l'attendais.

Si vous avez traversé cet écart, j'aimerais beaucoup savoir ce qui vous a empêché de pivoter encore une fois. Vous pouvez me répondre sur LinkedIn ou m'écrire directement — je suis vraiment curieux.

---

C'est tout pour moi. J'aimerais vraiment connaître votre avis — surtout si vous êtes passé par la même chose. N'hésitez pas à me contacter sur LinkedIn ou à m'envoyer un message directement.

À bientôt,

Chandler