Construire un jeu comme projet secondaire tout en travaillant comme développeur senior pendant la journée est un exercice de choix délibérés. Chaque décision d'outil a des conséquences composées : le mauvais moteur ou le mauvais langage vous coûtera des centaines d'heures sur la durée de vie d'un projet. J'ai passé environ trois mois à rechercher et prototyper avant de m'engager sur Godot 4 avec C# pour mon RPG tactique, et je veux documenter ce processus de décision honnêtement, incluant ce qui m'a surpris, tant positivement que négativement. Les chiffres de cet article sont un instantané pris en février 2026 : 123+ scripts, 334+ tests répartis entre les suites unitaires, d'intégration et de performance, et 28 shaders.
La décision du moteur : Unity vs Unreal vs Godot
Quand j'ai commencé ce projet, j'ai évalué sérieusement trois moteurs : Unity, Unreal Engine 5 et Godot 4. Je n'ai pas évalué GameMaker ou d'autres moteurs orientés 2D parce que mon jeu a une vue isométrique 3D avec un volume significatif de travail de shaders personnalisés, et j'avais besoin d'un moteur avec un pipeline 3D solide.
Unity était le candidat évident. Il a le plus grand écosystème, le plus de tutoriels, le plus de contenu asset store, et une communauté massive. Mais j'ai investigué Unity alors que la saga des frais de runtime était encore fraîche : annoncés en septembre 2023, adoucis en quelques semaines, et annulés en septembre 2024. Même une fois les frais disparus, l'incident a révélé quelque chose que je ne pouvais pas ignorer : Unity est une société cotée en bourse avec des obligations envers les actionnaires qui peuvent entrer en conflit avec les intérêts des développeurs.
Unreal Engine 5 est réellement impressionnant du point de vue technologique. Nanite, Lumen, le nouveau système d'animation : l'ingénierie est extraordinaire. Mais UE5 est conçu pour des équipes avec des artistes techniques à temps plein, des animateurs spécialisés et plusieurs programmeurs. La surcharge de complexité pour un développeur solo construisant un RPG tactique est énorme.
Godot 4 a été le choix sur lequel je me suis engagé, et les raisons étaient : il est entièrement open source sous licence MIT (pas de soucis de licence, pas de changements de politique qui peuvent m'affecter rétroactivement), il est architecturalement bien adapté au type de jeu que je construis, et la release 4.0 a apporté des améliorations significatives spécifiquement au pipeline 3D et à l'intégration C#.
Pourquoi C# plutôt que GDScript
Le langage de scripting natif de Godot est GDScript, et il est excellent pour beaucoup de cas d'usage. Il est proche de Python en syntaxe, profondément intégré au moteur, et l'outillage s'est amélioré substantiellement dans Godot 4. Si je construisais un jeu 2D casual comme premier projet de jeu, j'utiliserais probablement GDScript.
Pour mon projet, C# était le bon choix pour plusieurs raisons spécifiques à mon background et à la complexité de ce que je construis.
Premièrement : la sécurité de type à grande échelle. Un RPG tactique a beaucoup de systèmes interagissant : un système de combat, un système de mouvement, un système de calcul de stats, un arbre de décision IA, un système d'inventaire, un système d'équipement, un système de compétences, un système de progression d'unités. Quand ces systèmes interagissent, les erreurs de type sont une source majeure de bogues. C# avec son typage statique fort attrape des catégories entières de bogues à la compilation que GDScript ferait émerger au runtime.
Deuxièmement : l'outillage. Je travaille dans JetBrains Rider, qui a un support C# de première classe. Refactoring, navigation de symboles, recherche d'usages, documentation inline : ces outils fonctionnent à pleine capacité pour C#.
Troisièmement : les patterns transférables. Mon background est TypeScript et Angular. C# est syntaxiquement proche de TypeScript et partage beaucoup de patterns : generics, LINQ est similaire aux méthodes de tableau, async/await, interfaces, concepts de dépendance. La courbe d'apprentissage était gérable parce que j'apprenais les patterns de Godot, pas un paradigme de programmation entièrement nouveau et un nouveau langage simultanément.
// Example: A typed unit stat system in C#
public sealed partial class UnitStats : Resource
{
[Export] public int BaseHealth { get; set; } = 100;
[Export] public int BaseAttack { get; set; } = 10;
[Export] public int BaseDefense { get; set; } = 5;
[Export] public int BaseMovementRange { get; set; } = 4;
[Export] public int BaseActionPoints { get; set; } = 2;
public int ComputeEffectiveHealth(IReadOnlyList<StatModifier> modifiers)
{
var total = (float)BaseHealth;
foreach (var modifier in modifiers.Where(m => m.Stat == StatType.Health))
{
total = modifier.Type == ModifierType.Flat
? total + modifier.Value
: total * (1f + modifier.Value / 100f);
}
return Mathf.RoundToInt(total);
}
}Ce qui m'a surpris dans Godot 4
Il y a des choses sur Godot auxquelles je m'attendais et d'autres qui m'ont réellement surpris. Je m'attendais au système de scènes. Je m'attendais aux nodes et aux signaux. Je m'attendais à un moteur plus léger qu'Unity ou Unreal. Voici ce que je n'avais pas prévu.
Le langage de shaders est excellent. J'ai écrit 28 shaders pour ce projet, incluant des shaders de terrain procéduraux, des effets de contour d'unité, des overlays de surbrillance de tuiles, une implémentation de brouillard de guerre, et divers shaders d'effets visuels. Le langage de shaders de Godot est un dialecte GLSL bien documenté et bien comporté. Je suis arrivé en m'attendant à ce que le développement de shaders soit une partie pénible du projet. Ça a été l'une des parties les plus agréables.
Le système de Resources est plus puissant qu'il n'y paraît au premier abord. Les Resources dans Godot sont des conteneurs de données qui peuvent être sérialisés, référencés à travers les scènes, et étendus avec un comportement personnalisé. Une fois que j'ai compris comment utiliser les Resources typées comme objets de configuration, essentiellement du game design data-driven, ça a débloqué un pattern qui a rendu le jeu dramatiquement plus maintenable.
L'intégration C# est bonne, mais elle a des aspérités. Le fait que GDScript et C# coexistent dans le même projet signifie qu'il y a des points de friction d'interopérabilité occasionnels. Les signaux fonctionnent à travers la frontière des langages mais nécessitent une syntaxe différente selon de quel côté on est. Certaines fonctionnalités Godot qui sont de première classe en GDScript sont accessibles via des APIs légèrement maladroites en C#. L'aspérité qui contraint réellement la décision, c'est le support des plateformes : Godot 4 ne peut pas du tout exporter un projet C# vers le web, et l'export C# vers Android et iOS est encore expérimental. Si une version navigateur fait partie de votre plan, GDScript est la seule option aujourd'hui. Je vise le bureau, donc j'ai accepté ce compromis en connaissance de cause, mais c'est la première chose à vérifier avant de s'engager sur la voie C#.
Le choix du genre RPG tactique
Je veux expliquer pourquoi j'ai choisi de construire un RPG tactique spécifiquement, parce que le choix du genre a des implications significatives pour la complexité d'ingénierie du projet.
Je suis fan du genre depuis Final Fantasy Tactics quand j'étais enfant puis la découverte de Fire Emblem, Disgaea et Into the Breach. Les RPG tactiques sont un genre où la profondeur de design vient de l'interaction des systèmes plutôt que du volume de contenu. Un RPG tactique bien conçu peut fournir des centaines d'heures de gameplay significatif à partir d'un ensemble de contenu relativement petit, parce que l'espace combinatoire des unités, compétences, ennemis et terrain génère de la complexité émergente.
Du point de vue ingénierie, les RPG tactiques sont des jeux lourds en systèmes. Ils nécessitent : un système de mouvement sur grille avec pathfinding et calcul de portée de mouvement, un système d'ordre de tour, un système de calcul de combat avec plusieurs variables interagissant, un système de décision IA pour les unités ennemies, un système de compétences et capacités avec des effets divers et interagissant, un système de progression d'unités, et un système d'inventaire et d'équipement. Tous ces systèmes doivent interagir correctement entre eux. C'est exactement le type de problème que je trouve réellement intéressant du point de vue conception logicielle.
État actuel du projet
En février 2026, le projet a 123+ scripts, 334+ tests répartis entre les suites unitaires, d'intégration et de performance, et 28 shaders. Ce nombre de tests est quelque chose sur lequel je veux commenter explicitement : j'écris des tests pour la logique de jeu, et je suis convaincu que c'est la bonne approche pour un projet de jeu complexe même si ce n'est pas la norme de l'industrie pour les jeux indépendants.
Calculs de combat, résultats de pathfinding, empilement de modificateurs de stats, calculs d'ordre de tour : tout ça est de la logique déterministe qui peut et devrait être testée. Chaque fois que je modifie le système de combat, ma suite de tests me dit immédiatement si j'ai cassé quelque chose ailleurs. Dans un jeu où chaque classe d'unité, chaque capacité et chaque type de terrain peut interagir avec tous les autres, la complexité combinatoire des tests manuels n'est pas gérable. Les tests automatisés ne sont pas optionnels à cette échelle : c'est ainsi que je maintiens la confiance dans le système à mesure qu'il grandit.
Deux frameworks couvrent cette suite, et la ligne entre les deux, c'est le moteur. La logique pure, les classes qui ne touchent jamais à un noeud, une scène ou une Resource, tourne sous xUnit simple sans aucun processus Godot, ce que fait le test ci-dessous. Tout ce qui touche au moteur tourne sous GdUnit4 dans Godot.
// Movement range calculation, pure logic suite (xUnit, no Godot runtime)
public class MovementRangeCalculatorTests
{
private readonly MovementRangeCalculator _calculator;
private readonly InMemoryGrid _testGrid;
public MovementRangeCalculatorTests()
{
// InMemoryGrid implements the same IGridQuery interface as the
// GridMap-backed service the battle scene uses at runtime
_testGrid = GridMapFactory.CreateFlat(10, 10);
_calculator = new MovementRangeCalculator(_testGrid);
}
[Fact]
public void GetReachableTiles_BasicMovement_ReturnsCorrectDiamond()
{
var origin = new Vector2I(5, 5);
var movementRange = 3;
var result = _calculator.GetReachableTiles(origin, movementRange);
Assert.Equal(25, result.Count); // Diamond with range 3
Assert.Contains(new Vector2I(5, 8), result); // North
Assert.Contains(new Vector2I(8, 5), result); // East
Assert.DoesNotContain(new Vector2I(5, 9), result); // Out of range
}
[Fact]
public void GetReachableTiles_WithObstacle_ExcludesBlockedTiles()
{
_testGrid.SetCellTerrain(new Vector2I(5, 6), TerrainType.Impassable);
var origin = new Vector2I(5, 5);
var result = _calculator.GetReachableTiles(origin, movementRange: 3);
Assert.DoesNotContain(new Vector2I(5, 7), result); // Behind obstacle
}
}L'évaluation honnête après des mois de développement
Godot 4 avec C# est un choix réellement excellent pour un développeur solo construisant un jeu complexe et lourd en systèmes. La nature open source supprime une catégorie réelle de risque à long terme. Le moteur est capable, s'améliore rapidement, et bien adapté au type de développement que je fais. L'outillage C# me donne l'infrastructure de productivité dont j'ai besoin pour gérer un projet de cette complexité.
Ce que j'ai sous-estimé : le temps requis pour construire un outillage de jeu robuste. Le jeu lui-même nécessite des plugins d'éditeur personnalisés pour des choses comme l'édition de cartes, le placement d'unités et la configuration de rencontres. Construire ces outils comme scripts d'éditeur C# prend du temps réel et n'est pas quelque chose qu'un tutoriel vous prépare adéquatement à faire. L'outillage représente au moins 20 % de l'effort total du projet, et c'était plus proche de 10 % dans mes estimations initiales.
Choisir un moteur, c'est choisir un ensemble de contraintes. La question n'est pas quel moteur est le meilleur : c'est quelles contraintes vous pouvez accepter et lesquelles s'alignent avec ce que vous essayez de construire.
Si vous êtes un développeur venant du web ou du logiciel d'entreprise qui envisage le développement de jeux, Godot 4 avec C# est un point d'entrée accessible et puissant pour les jeux sur bureau. Les patterns sont différents du développement web mais pas étrangers, surtout si vous êtes déjà à l'aise avec TypeScript et les architectures basées sur les composants. L'investissement d'apprentissage est réel, mais il est tractable, et le retour créatif de construire un jeu de zéro est différent de tout ce que j'ai vécu dans le développement logiciel professionnel.
Références
- Godot MIT license. https://godotengine.org/license/
- Godot C# documentation. https://docs.godotengine.org/en/stable/tutorials/scripting/c_sharp/index.html
- Godot 4.5 release notes. https://godotengine.org/releases/4.5/
- Exporting for the web. C# projects cannot be exported to the web in Godot 4. https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_web.html