Bienvenue dans ce deuxième devlog consacré à Embers Tactics ! Juin a été un mois chargé, avec beaucoup de réflexions, de tests, et surtout un premier aperçu plus avancé de ce que donne une vraie carte de combat en 3D.
Je n’ai pas avancé dans toutes les directions à la fois. Ce mois-ci, le gros sujet a plutôt été de comprendre comment produire les cartes du jeu proprement, sans me retrouver avec un workflow lourd ou fragile. Pour un tactical RPG comme Embers Tactics, c’est un point absolument central.
Créer les cartes de combat
Dans Embers Tactics, qui est très inspiré par Final Fantasy Tactics, presque tout se déroule soit dans des menus, soit sur des cartes. Même certaines scènes uniquement de dialogues prendront place sur des cartes. Elles ne serviront pas toutes au combat, mais elles seront toujours une partie très visible de l’expérience.
Le coeur du jeu se joue donc sur ces cartes: certaines seront surtout là pour poser une ambiance, illustrer une scène ou soutenir un dialogue, et d’autres seront de vrais terrains de combat. Il fallait alors trouver un processus solide pour les créer, les tester, les adapter, puis les améliorer sans friction.
Le problème du workflow
Je voulais éviter de dépendre d’une suite d’outils éparpillés. Il me fallait un système pratique, qualitatif, facile à modifier, et suffisamment souple pour revenir sur une carte si elle manque de relief, si elle est trop vaste, trop plate, mal équilibrée ou simplement moins intéressante que prévu.
Godot propose bien un système de tilemap 3D. Sur le principe, on peut placer des blocs comme on placerait des tiles dans un jeu de plateforme 2D. C’est intéressant, mais pour mon usage, je ne le trouve pas assez complet ni assez intuitif pour personnaliser les cartes comme je le souhaite.
J’ai cherché une autre solution, et celle qui me convient le mieux est finalement assez simple: puisque je suis à l’aise avec Blender, et puisque toutes les cartes sont en 3D, autant créer les cartes directement dans Blender.
Deux couches: gameplay et visuel
La question était alors de savoir comment rendre une scène Blender réellement exploitable en jeu. La réponse que j’ai mise en place repose sur deux composantes: une partie gameplay et une partie visuelle.
La partie gameplay est composée de cubes placeholder invisibles en jeu, de différentes hauteurs. Ils servent à reconstruire une carte purement fonctionnelle: quelles cases existent, quelles cases sont jouables, à quelle hauteur elles se trouvent, et comment Godot doit les comprendre. Le code côté Godot est déjà prêt pour ça grâce à l’implémentation du mois dernier. Il me reste surtout à faire le pont proprement entre les assets Blender de gameplay et le fichier de données d’une carte.
La partie visuelle, elle, vient se greffer par-dessus. C’est elle que le joueur voit réellement. Elle sert uniquement au décor et n’a pas d’interaction directe avec le joueur. Grâce à cette séparation, je peux construire une carte comme une vraie scène 3D, avec beaucoup plus de liberté, tout en gardant une structure claire pour le gameplay.
Un export en un clic
Pour rendre ce système vraiment utilisable, j’ai créé un petit plugin Blender. Son rôle est simple: exporter la scène visuelle et convertir les données de gameplay dans un format lisible par Godot. Tout se fait automatiquement, en un clic.
Concrètement, je peux ouvrir Godot et voir ma carte directement, bien compartimentée entre ce qui sert au gameplay et ce qui sert au visuel. C’est exactement le genre de workflow dont j’avais besoin: fluide, rapide, et facile à corriger.
Le processus ressemble maintenant à ça:
- J’imagine une carte ou j’en dessine un croquis.
- Je crée le blocking visuel dans Blender pour poser les volumes, les fondations et la lisibilité générale.
- J’avance sur le visuel tout en adaptant le gameplay en parallèle. Si la carte est trop plate, trop vaste, pas assez resserrée ou manque d’éléments, je peux corriger sans bloquer tout le reste.
- Quand je veux tester dans Godot, ou quand je suis satisfait d’une version, j’exporte et tout se met à jour.
Ce point est important pour la suite. Si, plus tard, des retours montrent qu’une carte manque de quelque chose, fonctionne mal ou pose des problèmes d’équilibrage, je pourrai revenir dessus facilement. Pour un jeu tactique, c’est presque obligatoire.
Premiers assets 3D et rendu
Une fois ce setup en place, j’ai commencé à créer des assets 3D. J’ai fait un choix très pragmatique: partir sur un style low-poly en flat design.
En 3D, il y a beaucoup d’étapes entre l’idée d’un objet et son intégration propre en jeu. Selon le style choisi, il faut parfois faire du dépliage UV manuel, du texturing détaillé, de la modélisation high-poly, du baking, et pas mal d’autres choses. Avec le style que je vise, je n’ai pratiquement qu’une seule étape, la modélisation en low-poly.
C’est à la fois une contrainte artistique et une contrainte de production. Je gagne énormément de temps, ce qui est indispensable pour un projet solo. En contrepartie, ce style ne permet pas d’exprimer un rendu ultra détaillé ou très poussé. Il faut donc que les formes, les couleurs et surtout la lumière fassent beaucoup de travail.
L’importance de la lumière
Des objets 3D, même réussis, peuvent vite paraître très pauvres sans un bon rendu. À l’inverse, une excellente lumière peut faire des miracles, même avec des assets low-poly assez simples. C’est donc un sujet essentiel pour Embers Tactics.
Le problème, c’est qu’un jeu vidéo doit tourner en temps réel, sur des configurations parfois modestes. Je cible notamment la Switch 2, donc je dois rester attentif aux performances. Dans un rendu Blender ou dans un film d’animation, sortir une seule image prend plusieurs minutes, parfois des heures, parce que l’ordinateur calcule de nombreux rebonds de lumière. Dans un jeu c’est différent, comme tout est en temps réel, il faut que le rendu final de chaque image se fasse extrêmement rapidement.
Après pas mal de recherches et de tentatives, j’arrive à un premier résultat non définitif, mais déjà convaincant et peu gourmand. L’idée est de ne pas utiliser une lumière entièrement dynamique en temps réel. À la place, je bake une lumière précalculée, compactée dans un fichier de plusieurs dizaines de Mo.
Au lancement d’une carte, les lumières sont donc déjà connues et calculées. C’est beaucoup moins coûteux que de tout recalculer constamment. La limite, c’est que je ne peux pas modifier facilement la lumière dans la scène, ni la faire interagir dynamiquement avec le joueur. Pour Embers Tactics, ce compromis me convient très bien: je préfère obtenir un rendu joli et stable plutôt que de faire trop de concessions visuelles ou de performance.
L’aboutissement le plus concret de ce mois est donc un premier aperçu WIP, non définitif, d’une carte avec des assets 3D assemblés et jouable dans Godot. Je ne suis pas encore satisfait du rendu final, et tout le décor n’est pas terminé. Les arbres, les buissons et l’eau, notamment, restent encore trop brouillons. Mais la direction commence à prendre forme.
Aëlis et le concept art
En parallèle de tout ça, j’ai commencé à travailler avec une concept artist. Dans presque tous les RPG, lorsqu’un personnage parle, on voit son portrait. C’est encore plus important dans un jeu avec des personnages en pixel art et un roster composé de compagnons uniques. Si je veux que l’on s’attache à eux, ils doivent avoir une vraie illustration, pas seulement un petit sprite en jeu.
Comme je ne suis pas bon en illustration 2D, il fallait que je trouve quelqu’un capable de réaliser ces portraits. Et au-delà du portrait, j’avais besoin d’un vrai concept art de personnage: une base claire pour présenter le personnage, mais aussi pour créer ensuite son pixel art.
Trouver le bon style
J’ai passé pas mal de temps à chercher des artistes sur ArtStation. Je voyais beaucoup de personnes très talentueuses, mais je n’avais pas encore le coup de coeur. J’avais déjà une idée de ce que je voulais: quelque chose qui rappelle un peu Ankama, avec un style coloré, un peu cartoonisé, typé manga sans basculer dans le manga japonais, et en même temps quelque chose d’un peu plus sérieux et mature, plus rough et peint à la main, comme Arcane.
Ce mélange n’est pas si courant. On trouve souvent l’un ou l’autre, rarement les deux dans le même style. Puis je suis tombé sur Celestra, qui réalise de magnifiques illustrations, exactement dans la direction que je cherchais.
Je l’ai contactée, et nous avons commencé à travailler ensemble sur le design du personnage principal, Aëlis. Après plusieurs allers-retours et quelques semaines de travail, le design d’Aëlis a commencé à vraiment prendre forme.
Le résultat final sert maintenant de base au portrait intégré en jeu et à la suite du travail sur le personnage. Pour voir davantage de son travail, et l’illustration complète, je vous invite à aller voir l’ArtStation de Celestra.
Cette collaboration a été très fructueuse, donc nous allons continuer à travailler ensemble. Dans les prochains mois, nous travaillerons sur de nouveaux portraits pour les autres personnages.
Adapter le pixel art
Recevoir ce nouveau design d’Aëlis m’a aussi permis de reprendre le pixel art initial que j’avais créé un peu à l’imagination, sans support solide. C’est exactement pour ça qu’un concept art complet est utile: il donne une référence claire, cohérente, et beaucoup plus facile à traduire ensuite en sprite.
La suite pour le mois de juillet
Ce mois de juin a donc surtout été un gros morceau de design, et c’est une partie qui me tient particulièrement à coeur. Je n’ai pas vraiment avancé sur beaucoup d’autres sujets, mais j’ai posé des bases importantes pour la production des cartes, le rendu 3D et l’identité visuelle des personnages.
Pour juillet, je pense continuer dans cette direction: développer davantage la carte, ajuster la lumière, affiner le style visuel du jeu, et continuer à transformer ces premiers tests en quelque chose de plus stable.
Cela étant dit, merci d’avoir lu ce deuxième devlog. Vous pouvez toujours me contacter par email (contact@embers-tactics.com) pour toute demande ou question. À bientôt !