Illustration de couverture d'Embers Tactics

Devlog 4 · Septembre 2026

Cutscenes, interfaces et combat

Godot · Cutscenes · Gameplay tactique

Eh bien, nous revoilà après deux mois d’absence sur ces devlogs ! Comme évoqué dans le précédent, je n’ai pas consacré mon mois d’août à Embers Tactics, mais j’ai bien travaillé sur le jeu durant septembre, même si j’avais aussi un autre projet en parallèle. Et pour compenser cette attente, ce devlog sera très fourni et rempli de visuels. Au programme : les premières cutscenes, des interfaces retravaillées, une boucle de combat complète et quelques systèmes propres au jeu. Alors, c’est parti !

Quelle place pour l’IA dans Embers Tactics

Avant de vous dévoiler les avancées sur le jeu, j’aimerais faire un aparté important sur l’utilisation de l’IA dans la création d’Embers Tactics. Déjà, je ne suis pas anti-IA, loin de là, mais ça ne veut pas dire pour autant que je suis prêt à franchir toutes les limites avec.

De l’aide au développement aux agents de code

Depuis l’arrivée de ChatGPT fin 2022, j’ai trouvé l’outil fascinant et suivi son évolution de très près. Au départ, je l’utilisais surtout comme une aide au développement : trouver rapidement une solution à un problème plutôt que fouiller pendant des heures dans des forums. Un énorme gain de temps, mais ça restait avant tout un outil.

Petit à petit, les modèles sont devenus capables de produire du code de meilleure qualité et de résoudre des problèmes de plus en plus complexes. Puis, à partir de fin 2025, j’ai commencé à voir un vrai changement en utilisant des agents comme Claude Code, puis Codex, capables d’accéder directement aux fichiers d’un projet et de travailler avec une bien plus grande autonomie que dans leur interface de chatbot classique.

Pendant longtemps, il fallait malgré tout rester constamment derrière eux : relire le code, tester, vérifier, surtout sur les parties sensibles. Au fil des mois, j’ai expérimenté sur plusieurs projets et appris à mieux utiliser ces agents, à mettre en place de bonnes méthodes de travail et à les paramétrer correctement.

Aujourd’hui, les IA sont tellement performantes et mon système si bien paramétré que j’en suis arrivé à un point où je ne relis plus le code ligne par ligne. Je valide surtout le résultat à travers des tests réels, le comportement que j’attends du jeu, le feeling souhaité, etc. La quantité de code produite est devenue aberrante, et sa qualité est supérieure à ce que je pourrais produire moi-même dans le même temps. Je préfère donc consacrer mon attention au résultat.

Au début, ça m’a rendu un peu triste, comme beaucoup de développeurs : je perdais l’envie de coder moi-même puisqu’un outil pouvait faire mieux et beaucoup plus vite. Mais en travaillant sur Embers Tactics, et sur d’autres projets avant lui, ma vision a complètement changé.

Déjà, le gain de temps est considérable, bien au-delà d’un x2 ou x3 dans mon cas. Beaucoup de limites techniques qui auraient pu bloquer le projet auparavant ne sont aujourd’hui plus des obstacles. Même les petits détails qu’on aurait autrefois abandonnés parce qu’ils demandaient trop de temps pour trop peu d’intérêt peuvent maintenant être implémentés très rapidement. Et pendant qu’un agent travaille, j’ai même le luxe de parfois avancer sur une autre tâche, plus créative ou tournée vers la réflexion.

Sans l’IA, Embers Tactics n’aurait honnêtement probablement jamais existé sous la forme que je souhaite. Je n’aurais ni eu toutes les compétences techniques nécessaires, ni forcément la patience de me lancer dans un projet aussi ambitieux, et qui le reste pourtant beaucoup !

Garder une intention derrière ce que l’on crée

Par contre, je ne cautionne absolument pas tout ce qui est fait avec l’IA, et mon utilisation a ses limites. Jusqu’ici, je vous ai uniquement parlé de génération de code, qui représente environ 90 % de mon utilisation.

Je déteste ce qui est produit à la va-vite, l’« AI slop », les choses sans réelle valeur générées par des personnes qui ne maîtrisent pas ce qu’elles font ou qui n’ont simplement pas à cœur de bien faire. Il y a une énorme différence entre écrire un prompt et publier directement le premier résultat, et utiliser l’IA en la guidant volontairement, en connaissant la technique, ses subtilités et ses limites, puis ajuster, tester et peaufiner. C’est justement tout ce travail supplémentaire qui fait la différence.

On peut aujourd’hui générer un site web en cinq minutes, mais de mon point de vue, il n’aura ni âme, ni charme, ni subtilité, ni véritable logique humaine. La différence se fera dans les jours ou les semaines supplémentaires passés à revoir les interactions, déplacer des éléments, tester, supprimer ce qui ne fonctionne pas et peaufiner les détails.

Pour moi, c’est la même chose avec les visuels et les musiques générés par IA, mais aussi avec les idées, les mécaniques de gameplay, les histoires ou le feeling général d’un jeu. Sur tout ça, l’IA ne rivalise pas encore, à mes yeux, avec l’humain, et j’espère sincèrement que cela sera toujours le cas.

Ces outils peuvent être très pratiques pour prototyper, s’inspirer, remettre une idée en question ou chercher une direction, mais beaucoup moins pour produire directement quelque chose de définitif et créatif. Au-delà des questions d’éthique et de l’origine des données utilisées, on perd très vite en cohérence, en intention, en subtilité et en tous ces petits détails qui donnent une réelle identité à une œuvre.

C’est pourquoi aucune partie artistique finale d’Embers Tactics, qu’elle soit visuelle ou sonore, ne sera générée par IA. L’idée du jeu, son gameplay et ses personnages viennent également de mes propres idées et de mes expériences vidéoludiques. Je m’efforcerai toujours de travailler avec des personnes talentueuses capables de retranscrire ma vision et d’y apporter leur propre patte artistique. C’est d’ailleurs déjà la direction que j’ai prise avec les trois premières illustrations de personnages réalisées par Celestra.

La génération de code est un cas différent de mon point de vue. Même si je trouve une forme d’art au code, c’est probablement l’un des domaines les plus profondément transformés par l’IA, et en tant qu’entrepreneur, je trouve ça finalement plutôt positif. Un bon développeur saura utiliser l’IA pour aller beaucoup plus loin et beaucoup plus vite, en faisant les choses bien. Un non-développeur pourra lui aussi créer des choses intéressantes qu’il n’aurait jamais pu réaliser auparavant, bien que généralement de moins bonne qualité. Et entre les deux, on continuera tout de même à voir la différence.

Mon utilisation concrète et mes engagements

Concrètement, j’emploie principalement l’IA pour coder. Il m’arrive aussi de lui demander de critiquer mes idées ou de brainstormer avec moi afin d’avoir un autre point de vue et de les ajuster si nécessaire. Je peux également générer ponctuellement quelques assets 2D temporaires comme placeholders, simplement pour prototyper une interface ou tester un placement avant qu’ils soient remplacés par des assets réalisés par un artiste. Cela permet d’aller plus vite et de se focaliser sur les choses essentielles.

Par souci de transparence, lorsqu’un élément artistique montré dans un devlog ou présent dans le prototype aura été généré par IA, je le préciserai. L’objectif reste qu’aucun contenu généré par IA, excepté le code, ne se retrouve dans la version finale. Et si, à la sortie du jeu, vous en trouvez encore un qui m’a échappé : honte à moi !

Sur ce, si vous n’êtes pas déjà parti ou choqué par ma vision de l’IA, c’est parti pour les avancées sur le jeu !

Un éditeur pour mettre en scène les cutscenes

Pour reprendre Embers Tactics au début du mois de septembre, j’avais envie de m’aventurer dans la partie animation. Les bases du gameplay avaient bien avancé, une première version du prototype visuel et fonctionnel de la carte de combat était en place, et j’avais commencé à développer le début de l’histoire par écrit.

Je voulais donc travailler sur les « cutscenes » : ces scènes qui entrecoupent les combats et la navigation dans les menus, généralement avant ou après une bataille, et qui permettent de développer l’histoire.

Une table de montage directement dans Godot

La première idée qui m’est venue en tête, c’est que ce serait trop bien d’avoir un système semblable à un logiciel de montage pour créer moi-même ces scènes : déplacer les personnages sur les cases que je veux, lancer une animation, afficher un dialogue à un moment précis, ajouter une pause, faire apparaître un événement, etc.

Car pour le coup, générer les cutscenes uniquement avec des prompts à l’IA aurait été une folie et une prise de tête sans nom, si ce n’est impossible. Et puis c’est une partie créative tellement importante que je ne voudrais pas la réaliser de cette manière. J’ai donc décidé d’utiliser l’IA pour concevoir ma propre table de montage, intégrée au projet directement dans Godot ! Voici le résultat :

Éditeur de cutscenes dans Godot avec la carte de combat et la timeline des actions

Je peux créer une scène à partir de la carte de mon choix, ajouter les personnages que je veux à l’endroit voulu, les faire se déplacer à différentes vitesses, lancer des dialogues et des animations, ajouter des pauses, bouger la caméra, déplacer et visualiser les éléments dans ma timeline, comme dans un vrai logiciel de montage.

En réalité, la cutscene enregistre simplement des informations dans un fichier de données, en s’appuyant notamment sur les coordonnées des cellules de la carte. Ces données sont ensuite lues en temps réel dans le jeu pour enchaîner les animations de manière logique et structurée. Si demain je change le visuel du jeu en gardant les mêmes coordonnées de carte, la scène fonctionnera à l’identique, sans avoir à la refaire.

Je peux donc facilement modifier une cutscene à souhait si je me rends compte que quelque chose ne va pas. Je suis absolument fan de cet outil, je vais pouvoir me faire plaisir sur les nombreuses cutscenes du jeu ! Leur lecture est maintenant intégrée au déroulement d’un combat, avec également la possibilité de les passer.

Un premier extrait de l’introduction

Je vous propose d’ailleurs d’en apercevoir une petite partie maintenant !

Attention aux spoilers : bien que probablement non définitive, cette cutscene dévoile un passage du début du jeu. Elle ne révèle pas d’événement majeur, mais si vous souhaitez ne rien découvrir avant de jouer, ne regardez pas la vidéo. Certains éléments d’interface visibles sont des placeholders générés par IA, destinés à être remplacés.

Afficher la vidéo de l'introduction en cours de développement

Une caméra plus souple sans perdre en lisibilité

En travaillant sur cet éditeur et cette cutscene, j’ai aussi pris le temps d’améliorer le rendu de la caméra. Je ne voulais pas d’un jeu purement isométrique : puisque je dispose d’un véritable environnement en 3D, autant en profiter.

Je n’aime pas forcément devoir tourner la caméra pour contourner les obstacles visuels dans un tactical RPG, comme dans le FFT classique par exemple. Le joueur ne peut donc pas la faire pivoter librement, mais cela ne m’oblige pas à la figer dans une vue strictement isométrique.

Plutôt qu’une projection orthographique, dans laquelle la distance ne modifie pas la taille apparente des objets, j’ai choisi une projection en perspective avec un rendu presque aussi aplati. Pas complètement, toutefois : je veux laisser entrevoir la perspective du terrain et le relief des éléments, sans casser la lisibilité d’un jeu tactique.

Dans les cutscenes, j’ai également ajouté un léger retard dans le suivi, un petit effet de rebond et une dérive douce à l’arrêt. Je trouve que cela donne un mouvement beaucoup plus agréable et plus joli à la caméra qu’un suivi brut.

Des interfaces plus compactes et plus agréables

En revenant sur le jeu après un mois de pause, je me suis rendu compte que ma première itération d’interface n’était pas bonne, ni assez aboutie pour offrir une sensation agréable, même en tant que prototype. Les éléments étaient surtout trop gros et peu esthétiques.

J’ai donc décidé de la retravailler complètement pour avoir un meilleur feeling. Je souhaite aussi avancer avec Celestra sur cette partie : il fallait absolument que je valide d’abord un prototype agréable et fonctionnel.

Dans le concept actuel de combat, quatre éléments d’interface occupent une place majeure : les dialogues, le menu de commandes, les caractéristiques d’une unité et la prévisualisation des dégâts et effets d’une capacité. Je vais vous montrer et expliquer chacun d’eux.

Bien entendu, tout cela reste un prototype de fonctionnement et de placement, pas le visuel définitif. Certains fonds et assets 2D présentés ici sont générés par IA et seront recréés par la suite.

Les dialogues et leur historique

J’ai créé une interface de dialogue simple, avec un portrait à gauche ou à droite et le nom du personnage qui parle. Il est possible de choisir entre un enchaînement automatique et une validation manuelle des dialogues, ainsi que de consulter l’historique des répliques précédentes de la scène.

Prototype de dialogue avec le portrait d'Aëlis à droite et sa réplique au centre

Un menu de commandes réactif

Ce menu permet de gérer les actions et les déplacements de nos unités en combat. C’est l’une des interfaces au cœur du gameplay : je la voulais jolie et réactive, sans qu’elle prenne trop de place.

Elle flotte sur la droite de l’écran, avec ses menus et sous-menus. Pour chaque action ou déplacement, on aperçoit aussi directement une prévisualisation de la portée. On peut ainsi prévoir son action sans avoir à la sélectionner au préalable.

Menu de commandes de combat avec les entrées Déplacement, Action et Fin du tour

Les informations essentielles sur chaque unité

Le panneau de caractéristiques et la prévisualisation des dégâts sont les deux parties qui m’ont demandé le plus de travail. À la base, j’étais parti sur une interface similaire à celles de FFTA et FFTA2, que j’avais montrée dans le dernier devlog : un bloc assez massif, affiché à gauche ou à droite selon l’unité ciblée, avec toutes ses informations et caractéristiques.

La prévisualisation des dégâts réutilisait deux de ces blocs, en ajoutant le résultat de l’action au centre. Le problème, c’est que cet ensemble prenait énormément de place et masquait une grande partie du jeu. Comme le panneau d’une unité est souvent affiché à l’écran, je trouvais cela assez gênant à l’usage.

En général, je n’aime pas les interfaces trop fournies et je préfère largement quand c’est épuré. Mais dans un RPG tactique, les informations sont essentielles : il ne faut pas non plus trop en retirer. D’autant que je vise une sortie sur console portable et que je dois penser dès maintenant à la lisibilité sur de petits écrans.

Actuellement, je joue à Fire Emblem Fortune’s Weave, mon premier Fire Emblem, que je trouve absolument incroyable. Son interface est justement brillamment pensée. J’ai donc repensé mon panneau de statistiques pour reprendre certaines de ses forces : n’afficher que les informations essentielles dans un bloc plus compact, placé en haut à gauche.

J’ajouterai une option, activable avec une touche, pour afficher ou masquer les informations détaillées de l’unité ciblée. Cela permet de garder une interface générale compacte, tout en laissant la possibilité d’en savoir plus quand on le souhaite.

Panneau compact de Lyss avec son portrait, sa classe, son niveau et ses ressources

Un panneau dédié à la prévisualisation des dégâts

Ce nouveau design implique toutefois que la prévisualisation ne peut plus réutiliser directement la même interface que le panneau de caractéristiques. J’ai donc créé une deuxième interface dédiée : les informations sont réunies dans un grand bloc en bas de l’écran, avec le récapitulatif des dégâts et des effets de l’action au milieu.

Prévisualisation d'une attaque avec les deux unités et l'estimation des dégâts au centre

Compléter la boucle de combat

Après l’ajout d’une cutscene, il manquait encore plusieurs éléments pour obtenir une boucle de gameplay entièrement fonctionnelle et jouable. J’ai donc pris le temps d’implémenter ces étapes, de la préparation jusqu’à la sortie du combat.

Visualiser les prochains tours

L’ordre des tours est une partie importante de la stratégie d’un tactical RPG. Pour ce prototype, je me suis clairement inspiré de FFTA2.

On peut voir en direct les six prochains tours d’unités, avec la couleur de leur camp. Cibler une unité sur le terrain la met aussi en évidence dans l’ordre des tours, et effectuer une action peut modifier cet ordre. Il est également possible de naviguer avec les touches L et R, ce qui cible automatiquement l’unité correspondante sur le terrain.

Aperçu des six prochains tours avec les sprites des unités et la couleur de leur camp

Placer les unités et terminer une bataille

Le système de placement des unités avant le combat est maintenant en place. Chaque carte possède des emplacements définis et chaque combat peut limiter le nombre d’unités à déployer. L’interface de placement, elle, reste purement fonctionnelle : son apparence n’a pas encore été réellement travaillée.

J’ai aussi ajouté des unités ennemies, puisqu’il n’y en avait pas auparavant. Elles utilisent les cases de placement que je définis pour les cartes. Pour l’instant, elles passent leur tour : je n’ai pas encore travaillé sur leur IA autonome. Ce sera un gros chantier, et je préfère d’abord peaufiner les systèmes de gameplay, les compétences et leurs interactions. Cela viendra donc probablement bien plus tard.

Enfin, lorsque toutes les unités alliées ou ennemies sont KO, le combat se termine et l’on quitte la bataille. J’ai également ajouté les récompenses d’XP et d’AP en cas de victoire. Elles sont liées à un système propre à Embers Tactics, l’observation, que je détaille un peu plus loin !

Préparer son équipe depuis la mappemonde

Une première mappemonde permet maintenant de sélectionner une zone et d’engager un combat. J’ai également ajouté un menu d’équipe, accessible depuis cette carte mais aussi pendant le placement des unités avant une bataille, pour pouvoir bien se préparer.

Il permet de voir les personnages que l’on possède, de modifier leur ordre et la composition de l’équipe principale, d’organiser les observateurs et de changer les équipements. Un premier système d’inventaire et d’équipement est donc lui aussi fonctionnel. Le changement de classe et d’autres fonctionnalités sont également prévus dans ces menus, mais restent à intégrer.

Actuellement, ce sont des prototypes très basiques, purement fonctionnels : je n’ai pas encore de visuel suffisamment abouti à vous montrer de ce côté-là.

Trois systèmes pour enrichir les choix tactiques

Bien qu’Embers Tactics s’appuie sur FFTA et FFTA2, je ne veux pas en faire un simple copier-coller, qui n’aurait aucun intérêt. J’ai plein d’idées pour pimenter le jeu et le rendre moins monotone, redondant ou frustrant, des reproches que l’on peut parfois faire aux différents Final Fantasy Tactics.

Je vais donc entrer un peu plus dans le détail de trois systèmes dont les bases sont déjà implémentées.

La foi et le risque de faire monter sa jauge

J’ai imaginé le système de foi pour ajouter un nouvel aspect tactique aux combats, tout en l’inscrivant dans le lore du jeu. La foi est une jauge, au même titre que les MP ou les SP dans les jeux du genre. Sa valeur maximale est une caractéristique, et son remplissage évolue au cours du combat.

L’alignement d’une unité est distinct de cette jauge : il peut être positif, neutre ou négatif, tandis que la quantité de foi reste toujours positive ou nulle. Les dégâts de foi dépendent de l’écart entre les valeurs des deux jauges, auxquelles le jeu applique le signe de leur alignement. Un coefficient tient également compte de la relation entre les deux alignements. Une unité d’alignement positif pourra ainsi infliger des dégâts beaucoup plus importants à une unité d’alignement négatif, et inversement.

Plus la jauge monte, plus elle peut devenir dangereuse pour la cible, mais aussi pour son propre utilisateur. Elle permet de faire de lourds dégâts à une unité de foi opposée, tout en nous exposant davantage aux attaques de foi adverses. C’est donc une ressource délicate à maintenir élevée, pensée pour créer des situations tendues en milieu ou en fin de combat, avec la possibilité de complètement retourner une bataille.

La foi ne se remplit pas toute seule. Je veux qu’elle reste une option tactique dans laquelle on choisit de s’engager. Réussir une attaque contre un ennemi d’alignement opposé permet de remplir cette jauge, initialement vide ; certaines capacités spécifiques pourront aussi intervenir dans ce fonctionnement. On peut donc chercher volontairement à la faire monter, ou adapter ses choix pour éviter de la remplir.

Les observateurs pour faire progresser la réserve

J’ai pensé le système des observateurs à la fois pour ajouter un autre aspect tactique au jeu et pour éviter de laisser certaines unités à la traîne en matière d’XP ou de capacités, sans retirer l’intérêt de les faire participer directement au combat.

Une unité déployée peut avoir des observateurs : des personnages classiques de notre équipe qui restent hors du terrain, mais reçoivent de l’XP et des AP grâce à leur observation lorsque le combat est remporté. Ils peuvent ainsi progresser sans être simplement délaissés dans la réserve.

À terme, ces observateurs apporteront aussi des passifs propres à chaque personnage aux unités qu’ils accompagnent. La progression par observation est déjà en place ; les effets précis de ces passifs restent à définir et à intégrer.

Le scintillement pour saisir une occasion pendant l’action

Le nom est provisoire. À la manière de Sea of Stars, j’ai imaginé un système simple pour pimenter un peu l’action en combat et garder une attention constante.

De temps en temps, lors d’une attaque alliée, un petit scintillement apparaît. En appuyant au bon moment, on peut améliorer la puissance tirée au sort pour l’action : le jeu utilise alors la moitié supérieure de la plage de puissance, plutôt que sa totalité.

Par exemple, avec une arme dont la puissance varie entre 10 et 20, une réussite limite le tirage à une valeur comprise entre 15 et 20. Les dégâts restent ensuite calculés à partir de cette puissance : il ne s’agit pas de garantir directement un nombre de points de dégâts.

Je ne veux pas transformer le jeu en succession de QTE. Le scintillement apparaît occasionnellement et reste complètement optionnel, sans pénalité si on le manque : l’action utilise simplement sa plage habituelle.

Sa fréquence peut aussi faire partie des caractéristiques des personnages et, à terme, devenir un élément de construction d’équipe. Avec des armes très aléatoires, dont la plage de puissance est particulièrement large, miser sur ce scintillement pourrait augmenter les chances d’obtenir de gros dégâts.

Poursuivre les animations et retravailler les décors

Au-delà de tout ça, j’ai aussi créé et retravaillé les sprites en pixel art 2D d’Aëlis, d’Aldric et de Lyss. Les trois personnages disposent maintenant de leur animation de marche de face et de dos. L’animation en pixel art prend quand même beaucoup de temps !

J’aimerais rapidement ajouter de nouvelles animations : le KO, l’attaque à l’arme, la surprise, et même une animation « signature » propre à chaque personnage.

Trouver une végétation avec plus de volume

Le prototype visuel du jeu ne me plaît pas encore, notamment les arbres. Le défaut majeur est que tout est trop petit : les arbres et la végétation ne font pas assez ressortir l’aspect cartoon et chibi que je recherche.

En juillet, puis de nouveau ce mois-ci, j’ai longuement buté sur le design de la végétation. C’est quelque chose que je trouve souvent peu convaincant dans les jeux. Les contraintes techniques conduisent fréquemment à utiliser des textures plaquées sur des rectangles plus ou moins déformés.

Mais les cartes d’Embers Tactics sont fermées et limitées en taille. Je pense donc avoir un peu plus de marge que dans des jeux aux environnements plus vastes et plus gourmands, et pouvoir éviter de simples surfaces planes texturées.

Je cherche encore une bonne solution. J’aime notamment la façon dont la végétation semble être réalisée dans LEGO Horizon, auquel je n’ai jamais joué : de la vraie 3D, avec des feuilles qui ont du volume.

Une nouvelle version de la carte dans Blender

En parallèle, j’avance sur une nouvelle version 3D de la carte de combat. La version actuelle est très cubique et manque de détails comme de volumes. Je travaille aussi sur de nouveaux matériaux plus jolis et, si j’arrive à trouver une solution qui me convient, sur une végétation plus aboutie.

Je ne souhaite pas trop m’avancer ni donner davantage de détails, car le chantier commence à peine. Mais je peux quand même vous montrer un petit aperçu brut dans Blender :

Travail en cours dans Blender sur les rochers, la berge, le pont et les plantes de la carte de combat

Bilan de septembre et suite du développement

Ce mois de reprise a donc été bien rempli ! Entre l’éditeur de cutscenes, la refonte des interfaces et les étapes qui manquaient à la boucle de combat, le prototype devient plus concret. Il reste encore beaucoup de travail, aussi bien pour peaufiner ces systèmes que pour trouver le rendu visuel que je souhaite, mais je suis impatient de continuer à donner vie à tout ça.

À bientôt pour la suite d’Embers Tactics !