Développement / Godot / UML états

One Dog Army.
Un laboratoire de création.

Faire évoluer un jeu existant avec une assistance IA : conserver sa logique, tenir des décisions d’architecture et formaliser les mécaniques avant de les coder.

Cadre: Projet personnel
État: Prototype jouable · intégration 3D réalisée
Outils: Godot · GDScript · Git

Un terrain exigeant

One Dog Army est un prototype de jeu d’action où le joueur dirige une escouade de cinq personnages qu’il alterne en cours de partie. La migration vers Godot 3D a progressé jusqu’à l’intégration de cinq personnages détaillés avec squelettes. Combat, positions, projectiles, collisions, contrôles et interface forment un ensemble à faire évoluer sans régression.

Niveau de test de One Dog Army, avec les cinq membres de l’équipe en bas de l’écran — Capture réelle d’une étape du prototype : interface d’équipe et niveau de test. Le projet continue d’évoluer.

Une mécanique centrale : le relais

Chaque personnage remplit une condition qui génère un bonus. Ce bonus n’est utile que si le joueur change de personnage à temps : il s’applique alors au suivant. La mécanique a été décrite comme deux machines à états avant d’être implémentée, ce qui a permis de trancher des questions de conception — le bonus voyage-t-il entre personnages ? (non : il reste sur son receveur).

Le processus documenté

Le système de relais

UML 2 · machines à états

← Faire défiler le schéma →

À gauche, le générateur propre à chaque personnage ; à droite, le cycle de vie du bonus produit. p désigne la progression de la condition, de 0 à 1.

Règles de gestion

Les décisions qui tiennent le code.

DA-01Générateur et produit sont séparés : le générateur ignore si son personnage est actif ou en réserve.
DA-02Le bonus reste sur son receveur jusqu’à expiration ; il ne voyage pas entre personnages.
DA-03Les camps sont gérés par la physique (couches de collision), jamais par des tests de type d’équipe.
DA-04Joueur et ennemi ne fusionnent pas : le joueur a une escouade, un curseur et des changements d’arme.
DA-05Un commit par changement logique : correction, renommage et refonte ne se mélangent pas.

Transposer la démarche à l’entreprise

Faire évoluer un existant impose de comprendre ses contrats, de limiter les changements et de vérifier les régressions. Écrire les décisions d’architecture évite qu’un assistant IA, ou un nouveau développeur, les défasse sans le savoir.

L’outil en images

Un parcours visible.

**Retrouver les cinq membres de l’équipe**Capture historique du prototype 3D, datée du 26 septembre 2026 : un héros actif et quatre en réserve. Elle précède l’intégration des personnages plus détaillés ; ce n’est pas une capture d’une version finale.

État au 13 octobre 2026

Une réalisation, un périmètre précis.

Ce qui est réalisé

Prototype jouable sous Godot 3D, combat, équipe dynamique et cinq personnages détaillés avec squelettes intégrés le 28 septembre.

Ce qui a été vérifié

Des vérifications de scènes et l’intégration des cinq personnages sont documentées dans l’historique. Le jeu n’a pas été relancé pour cette revue.

Limites actuelles

Animations, tenue des armes, coût des modèles, contenu et équilibrage restent à améliorer. Le jeu de cartes et les courts métrages sont encore des pistes distinctes.

Prochaine étape

Stabiliser un parcours de jeu représentatif, corriger les animations et mesurer les performances avec l’escouade complète.

Exemples de critères de recette

Ces critères décrivent le résultat attendu. Ils ne constituent pas, à eux seuls, des tests réussis.

Passer successivement entre les cinq personnages dans la scène de test conserve contrôles, collisions, caméra et état de l’escouade.
Un bonus de relais s’applique au personnage receveur puis expire selon la règle ; un changement suivant ne le transmet pas à un troisième personnage.

Parlons de votre projet

Un besoin concret.
Une première discussion.

Un processus trop manuel, une donnée peu fiable ou une idée à tester ? Commençons par clarifier ce qui vous serait vraiment utile.

Échanger avec Loïc