Facilitez vous la création de jeux vidéo !

Ça fait un moment que je n'avais pas fait le point ici, et pour cause : j'avais la tête dans le code ! Depuis la v0.6.0, Dina Game Engine a littéralement changé de dimension. On est passé d'un éditeur qui posait ses bases à un outil qui commence vraiment à ressembler à ce que j'avais en tête dès le départ. Couleurs, polices, menus configurables, composants de scène, plan de tests… il y a eu du boulot. Je vous résume tout ça.

Sommaire

1. Les fondations : couleurs et polices — v0.7.0 – v0.8.0
2. Premier composant de scène : Text — v0.9.0 – v0.9.1
3. Le MenuManager : des menus configurables visuellement — v0.10.0 – v0.10.7
4. Badge de scène de démarrage et plan de tests — v0.11.0 – v0.11.1
5. Fiabiliser avant d'avancer — v0.12.0
6. L'ombrage arrive : ShadowColor et ShadowText — v0.12.1 – v0.13.1

 

En bref

 

Depuis la v0.6.0, l'éditeur s'est structuré autour de deux axes : enrichir les fonctionnalités et fiabiliser ce qui existe. Les premières briques incontournables ont été la gestion des couleurs (centralisées dans une classe dédiée PaletteColors pour harmoniser l'ensemble du projet) et la gestion des polices, qui repose dans DinaCSharp sur un système de clés (Key) géré par le FontManager. L'éditeur s'est ensuite doté de ses premiers composants : Text, MenuManager, ShadowText ainsi que d'une interface homogène grâce à des UserControls partagés. Sans oublier un plan de tests structuré qui a débouché sur plusieurs vagues de corrections significatives. En quelques semaines, l'éditeur est passé d'une base fonctionnelle à un outil cohérent, fiable et de plus en plus expressif.

1. Les fondations : couleurs et polices (v0.7.0 – v0.8.0)

Avant de pouvoir créer des composants visuels, il fallait poser les fondations : savoir gérer les ressources partagées d'un projet. C'est exactement ce que règlent les versions v0.7.x et v0.8.0.

Pour les couleurs, j'ai opté pour une classe dédiée (PaletteColors) qui centralise toutes les couleurs du projet. L'idée est simple : plutôt que de disperser des valeurs hexadécimales dans tout le code, on définit une palette une fois pour toutes et on y fait référence par nom. Depuis l'éditeur, on peut ajouter, modifier et supprimer des couleurs, et le fichier PaletteColors.Designer.cs est régénéré automatiquement.

Liste des couleurs disponible

Pour les polices, le système repose sur le FontManager de DinaCSharp, qui centralise le chargement des polices via un système de clés typées (Key). Depuis l'éditeur, on configure ses polices, et le moteur génère les fichiers SpriteFont à plusieurs résolutions ainsi que le fichier FontKeys.Designer.cs qui expose toutes les clés. La police Roboto est même embarquée dans les templates pour démarrer sans rien configurer. Fini les allers-retours manuels dans Visual Studio.

Fenêtre de création d'une nouvelle police avec recopie automatique du fichier .ttf dans le projet

 

Cette version inclut aussi une refactorisation architecturale importante — la hiérarchie ItemViewModel/EditorViewModel — qui clarifie la séparation des responsabilités dans l'éditeur et qui servira de socle pour tous les composants à venir.

 

2. Premier composant de scène : Text (v0.9.0 – v0.9.1)

La v0.9.0 est une petite étape symboliquement grande : le premier composant d'une scène éditable visuellement. Il s'agit du composant Text, qui permet d'afficher du texte dans le jeu avec le code de génération correspondant.

La v0.9.1 lui ajoute ses propriétés configurables — position, police (issue de la palette définie en v0.8.0), contenu, couleur (issue de PaletteColors) — directement depuis le panneau de propriétés de l'éditeur. C'est le début d'un système de composants qui va s'étoffer rapidement.

 

Composant Text sélectionné et son panneau de propriétés.

 

3. Le MenuManager : des menus configurables visuellement (v0.10.0 – v0.10.7)

C'est la fonctionnalité la plus dense de cette série de versions, et probablement celle dont je suis le plus content. L'objectif : pouvoir configurer un menu principal de jeu entièrement depuis l'éditeur, sans écrire une seule ligne de code.

La v0.10.0 pose les bases avec le composant MenuManager et ses MenuItems — les entrées cliquables du menu. Derrière cette interface simple se cache un système de génération de code précis : chaque modification régénère les sections ciblées du Scene.Designer.cs grâce à un système de zones balisées, sans jamais toucher au code utilisateur.

Les v0.10.2 à v0.10.4 finalisent les propriétés des MenuItem et renforcent la robustesse des générateurs de code pour les rendre fiables en conditions réelles.

La v0.10.5 ajoute les propriétés du MenuManager lui-même, et introduit une bibliothèque de UserControls partagés — LabeledTextBox, LabeledComboBox, LabeledCheckBox, Vector2InputView — réutilisables dans tous les panneaux de propriétés de l'éditeur. La v0.10.6 migre l'ensemble des vues existantes vers ces nouveaux contrôles, homogénéisant l'interface de bout en bout.

Enfin, la v0.10.7 finalise les MenuTitles — les titres de section qui structurent visuellement les menus — avec leurs propres propriétés configurables.

MenuManager avec titre et items

 

4. Badge de scène de démarrage et plan de tests (v0.11.0 – v0.11.1)

La v0.11.0 apporte quelque chose de concret et d'immédiatement utile : la sélection de la scène de démarrage depuis la vue ProjectHome. Un badge visuel identifie clairement quelle scène se lancera en premier, et un simple clic suffit pour en changer. L'information est persistée dans le dina.project.json.

📸 Vue des scènes avec la scène Main Menu comme scène de démarrage (badge "startup").

 

Mais l'apport le plus structurant de cette version est peut-être invisible à l'écran : la mise en place d'un plan de tests structuré. Tester un éditeur qui génère du code, c'est particulièrement délicat — il faut vérifier l'interface ET l'exactitude de chaque fichier généré. Ce plan pose les bases d'une validation rigoureuse pour toutes les versions à venir. La v0.11.1 en est la première récolte : un lot de corrections ciblées sur les problèmes identifiés.

 

5. Fiabiliser avant d'avancer (v0.12.0)

J'aurais pu continuer à ajouter des fonctionnalités, mais j'ai préféré m'arrêter pour corriger en profondeur. La v0.12.0 est entièrement dédiée à la qualité :

• Le bouton Apply met maintenant correctement à jour les MenuItem et Title dans le Scene.Designer.cs
• La sélection/désélection d'un projet récent fonctionne de façon fiable
• Un bug dans la génération des titres d'un MenuManager produisant du code incorrect a été corrigé
• La gestion du badge de scène de démarrage a été entièrement refondée
• Les messages parasites à la compilation dans Visual Studio sur les projets générés ont été supprimés

 

Ce genre de version est moins spectaculaire à annoncer, mais c'est elle qui fait la différence entre un outil qu'on utilise avec confiance et un outil qu'on utilise en croisant les doigts.

 

6. L'ombrage arrive : ShadowColor et ShadowText (v0.12.1 – v0.13.1)

La v0.12.1 enrichit le MenuManager avec la prise en charge de la couleur d'ombrage des titres (ShadowColor). Un détail visuel qui change vraiment le rendu des menus générés, et qui illustre bien la direction prise : configurer de plus en plus finement l'apparence du jeu depuis l'éditeur, sans toucher au code.

Les v0.13.0 et v0.13.1 vont plus loin avec un composant entièrement nouveau : ShadowText. Même principe que Text, mais avec une ombre portée configurable en position, couleur et opacité. La v0.13.0 pose les bases du composant, la v0.13.1 y ajoute la fenêtre d'ajout dédiée (AddShadowTextWindow) et corrige la suppression de ce type de composant depuis l'éditeur.

Composant ShadowText et ses propriétés

 

Comme toujours, vos retours sont les bienvenus : que ce soit pour signaler un bug, proposer une idée, ou simplement dire ce que vous en pensez !

Cela fait un moment que Dina Game Engine avance en coulisses, et il est temps de montrer où en est le projet. Voici un premier aperçu concret de l'interface telle qu'elle existe aujourd'hui.

 

Démarrage et projets récents

À l'ouverture, l'éditeur affiche la liste des projets récents, organisés par période (hier, la semaine dernière, ce mois-ci). Chaque entrée indique le nom du projet, son chemin sur le disque, et la date de dernier accès. Deux actions sont disponibles : créer un nouveau projet ou en ouvrir un existant.

 

Création d'un projet en deux étapes

Le wizard de création est volontairement simple. La première étape demande un nom de projet et un emplacement. Le chemin de création final est calculé et affiché en temps réel, ce qui évite les mauvaises surprises.

 

La deuxième étape, appelée Markers validation, permet de vérifier et d'ajuster les trois valeurs clés avant génération :

• le nom de la solution (__SolutionName__),
• le nom du projet C# (__GameProjectName__),
• et le namespace racine (__RootNamespace__).

Ces marqueurs sont ceux utilisés dans les templates pour générer la structure de la solution Visual Studio.

 

L'éditeur principal

Une fois le projet ouvert, l'éditeur présente un panneau gauche regroupant les grandes catégories du projet : Localisation, Polices, Images, Sons/SFX, Couleurs, Contrôles, et Paramètres par défaut. La zone centrale liste les scènes du projet, chacune affichant son nom, sa clé textuelle (par exemple GameScene), et le nombre de composants qu'elle contient.

 

Gestion des couleurs

La vue Couleurs permet d'ajouter et de gérer une palette nommée pour le jeu. Chaque couleur est identifiée par une clé textuelle (par exemple MainMenu_Title), accompagnée d'un aperçu visuel. Ces couleurs sont ensuite générées dans le code C# du projet.

 

Éditeur de scène

L'éditeur de scène s'ouvre dans un onglet dédié. Il propose un panneau gauche pour les composants, une zone centrale noire représentant la surface de jeu, et un menu contextuel accessible via le bouton + pour ajouter des composants. Le composant Text est d'ores et déjà visible dans ce menu, mais il est encore en cours de développement et n'est pas finalisé à ce stade.

 

Roadmap

Les fonctionnalités suivantes sont prévues pour les prochaines versions :

• Ajout de polices — intégration de fichiers SpriteFont avec variantes de résolution personnalisées
• Composants UI — placement et configuration visuelle des éléments d'interface dans une scène
• Éditeur de scène — canvas visuel pour placer et configurer les composants d'une scène
• Mise à jour automatique (DinaGameEngine.Updater)
• Wiki GitHub

 

Contributions

Les contributions, signalements de bugs et suggestions de fonctionnalités sont les bienvenus. N'hésitez pas à ouvrir une issue ou à soumettre une pull request.

Les contributions de traduction sont particulièrement appréciées - l'éditeur supporte actuellement le français et l'anglais, et chaque nouvelle langue ne nécessite qu'un fichier .resx.

Le code source est disponible sur GitHub.

Après plusieurs mois de développement en parallèle de DinaCSharp, je suis heureux de vous présenter Dina Game Engine, un éditeur visuel 2D pour créer et gérer des projets de jeux basés sur MonoGame et DinaCSharp.

Pourquoi un éditeur ?

En travaillant sur mes propres jeux, je me suis rendu compte que je passais beaucoup de temps à recréer la même structure de projet à chaque fois : les mêmes fichiers de configuration, les mêmes scènes de base, les mêmes gestionnaires à initialiser...

L'idée de Dina Game Engine est simple : automatiser tout ce travail répétitif pour se concentrer sur ce qui compte vraiment — le gameplay.

Ce que j'ai essayé avant

Avant de me lancer dans le développement du moteur, j'ai cherché des solutions existantes pour automatiser la création d'une solution multi-projets.

• CMake — puissant, mais la courbe d'apprentissage est vraiment abrupte et l'intégration avec un workflow C#/MonoGame n'est pas évidente.
• Les templates de projet Visual Studio — c'était la piste la plus naturelle, mais les templates natifs de Visual Studio ne supportent pas la création d'une solution multi-projets. On peut créer un template pour un projet unique, pas pour une solution complète avec 6 projets interdépendants.

 

Faute de solution satisfaisante, j'ai décidé de construire le mien. Et tant qu'à faire, autant en profiter pour aller plus loin qu'un simple générateur de fichiers.

Ce que ça fait concrètement

En quelques secondes, le moteur génère une solution Visual Studio complète et fonctionnelle contenant :

• Un menu principal avec Play, Options et Quit
• Un écran d'options (résolution, plein écran, volumes)
• Une scène de jeu prête à accueillir votre gameplay
• La gestion de la localisation dès le départ
• L'intégration automatique de DinaCSharp — pas besoin de configurer la DLL manuellement

Et le tout compile et se lance immédiatement sans toucher une seule ligne de code.

Une architecture qui respecte votre code

C'est le point sur lequel j'ai le plus travaillé. Le moteur génère des fichiers Designer.cs qu'il gère lui-même, et des fichiers .cs qui vous appartiennent entièrement. Le moteur ne touchera jamais à votre code.

Concrètement, quand vous ouvrez MyGame.cs dans Visual Studio, vous ne voyez que l'essentiel :

• OnInitialize() — configuration de départ
• OnSetStartupScene() — quelle scène lancer en premier
• BackgroundColor — la couleur de fond
• RegisterAdditionalScenes() — vos scènes personnalisées

Tout le reste (initialisation des gestionnaires, boucle de jeu, rendu...) est géré automatiquement dans MyGame.Designer.cs.

C'est encore en développement

Le moteur est fonctionnel mais loin d'être complet. Les prochaines étapes prévues :

• Ajout de scènes depuis l'éditeur
• Composants visuels : Text, Button, Checkbox, Slider
• Gestion des polices par résolution

Le code est disponible sur GitHub : DinaGameEngine

 

Vos retours sont les bienvenus ! 🚀

Je suis heureux d'annoncer la sortie de DinaMenuDesigner, un éditeur visuel de menus pour DinaCSharp.

À quoi ça sert ?

Concevoir un menu directement dans le code peut rapidement devenir fastidieux, surtout quand il s'agit de positionner précisément les éléments à l'écran.
DinaMenuDesigner permet de créer visuellement vos menus sur un canvas 1920x1080, puis de générer automatiquement le code C# à intégrer dans votre projet.

Fonctionnalités

• Création et positionnement des titres et items par drag & drop
• Aperçu en temps réel
• Édition des propriétés (texte, couleur, police, taille, ombre...)
• Sauvegarde et chargement de projets en JSON
• Génération du code C# prêt à intégrer

 

Je progresse sur mon RPG au tour par tour sans magie.

Ce qui tourne déjà :

• Système d'Équipement : Le joueur et les ennemis peuvent déjà s'équiper d'armes et d'armures influençant directement les statistiques de combat.

• Boucle de Jeu : J'ai validé la transition fluide entre l'exploration (GameScene) et l'arène (BattleScene).

• États de match : La victoire et le Game Over (retour au menu) sont opérationnels. C'est basique pour l'instant, mais la mécanique est là pour être raffinée.

Prochaine étape technique : implémenter l'EnemyFactory pour gérer plus facilement la diversité des monstres de la tour sans dupliquer de code.