Il y a un peu moins de deux jours est sorti The Girl Near The Window. Ce jeu n'avait pas pour but d'être publié et me servait principalement à tester mon moteur de jeu : NutshellEngine. Au final, l'étendue du projet a été augmentée au point où il était utile de le partager car il comporte des mécaniques qui me semblent plutôt intéressantes à explorer.
Créer un jeu est, selon moi, une étape extrêmement importante dans la création d'un moteur de jeu indépendant, puisqu'elle permet de vérifier que celui-ci est effectivement utilisable par un utilisateur et de trouver les points à améliorer.
NutshellEngine est un moteur de jeu très jeune, puisque sa conception a débuté fin Septembre 2022 et son développement a démarré début Octobre 2022. Il a la particularité d'être modulaire, cross-plateforme, et de fonctionner grâce à un cœur qui peut charger des modules. Il est développé en C++17.
Il existe 4 types de modules :
Ces modules sont sous la forme de bibliothèques dynamiques (.dll sur Windows, .lib.so sur Linux) à mettre dans un dossier modules à côté de l'exécutable de l'application.
Ces bibliothèques n'exposent que deux fonctions : createModule, qui alloue le module et retourne son adresse mémoire, et destroyModule qui s'occupe de libérer la mémoire du module. Dans les cas les plus simples, createModule se contente de faire un new et destroyModule un delete mais il est possible d'utiliser des allocateurs personnalisés.
Des interfaces communes sont implémentées par les modules et utilisées par le cœur et, même si ce n'est pas montré sur le graphique pour des raisons de lisibilité, les modules. Ce qui signifie que chaque module peut appeler les fonctions des autres modules, ce qui sert par exemple à créer une surface de rendu dans le module graphique à partir d'un handle de fenêtre renvoyé par le module de fenêtrage. Le cœur peut évidemment lui aussi appeler les fonctions de chaque module, ce qui est aussi le cas pour chaque Script, ce qui permet par exemple de jouer des sons et lire les entrées clavier et souris quand on développe un jeu avec NutshellEngine.
Il y a le cœur du moteur de jeu. Celui-ci charge les modules et récupère leurs pointeurs mais gère aussi l'ECS (Entity Component System) et le manager des ressources, ou Assets manager, (images, sons, modèles 3D, ...). Il gère aussi le système de Scripting, qui actuellement n'est pas un module à part entière, et qui sert à scripter les entités, donc à leur donner des comportements. Pour l'instant, le scripting est natif seulement, donc en C++, mais le passage du système de Scripting vers un module de Scripting pourrait potentiellement permettre de supporter plus de langages et de méthodes de scripting, comme le Lua, supporté par mon précédent moteur de jeu, NeigeEngine, Python, et bien d'autres.
L'application utilise le cœur et définit le jeu. Par exemple, The Girl Near The Window est une application NutshellEngine.
Les modules utilisés dans The Girl Near The Window sont disponibles dans le dossier modules :
Utiliser des bibliothèques dynamiques permet de les compiler à part, et permet donc de compiler l'application beaucoup plus rapidement. L'autre avantage consiste à pouvoir remplacer les modules dans le dossier modules pour avoir des comportements différents :
Ici, le module graphique utilisé de base dans The Girl Near The Window est remplacé par un module graphique qui rend les maillages en wireframe.
On peut donc utiliser des modules créées spécialement pour le debug ou qui sont simplement présents en tant que placeholder le temps que les vrais modules soient développés. NutshellEngine permet donc de travailler sur des moteurs graphiques, physiques, ou autre, temporaires, le temps que les versions définitives soient développées, sans qu'il ne soit nécessaire de retravailler ni même de recompiler le jeu lui-même.
Le cœur du moteur est inclut dans chaque application. Comme expliqué plus haut, celui-ci charge les modules ainsi que l'ECS et l'Assets manager. Il gère aussi le système de Scripting. Le cœur s'occupe aussi de faire passer l'ECS, l'Assets manager et les modules à :
Les modules et les scripts peuvent donc appeler les fonctions des modules et de l'Assets manager.
L'Assets Manager s'occupe des ressources utilisées par l'application, donc tout ce qui est images, sons, modèles 3D et autres. Il est possible de charger des fichiers ou de créer des ressources vides. Toutes ces ressources sont dans un format interne à NutshellEngine (exemple pour les images (NtshEngn::Image) et les modèles 3D (NtshEngn::Model)) et sont ensuite utilisées par les modules qui en ont besoin et qui vont les convertir en leur propre format interne si besoin.
Dans le cas de The Girl Near The Window, aucun fichier n'est lu pour les ressources. À la place, j'ai développé des scripts Python me permettant de convertir des images et des sons en code utilisable directement dans l'application. Les modèles 3D sont définis à la main car très simples. Cette méthode permet d'expliquer la taille très faible du jeu sur le disque.
L'ECS est basé sur A Simple Entity Component System de Austin Morlan avec de grandes modifications pour l'adapter à mes besoins. Y est notamment ajouté un système de callbacks permettant de notifier au module quand une entité obtient un Component utilisé par le module. C'est de cette façon que le module graphique peut directement charger le modèle et les textures de la nouvelle entité dans la mémoire GPU.
Les applications NutshellEngine sont les exécutables. C'est ici que les scènes sont définies et que les scripts sont écrits. Si on récupère le template d'application NutshellEngine sur GitHub, les scripts sont des fichiers headers (.h) à mettre dans un dossier scripts. Un GLOB permet de tous les récupérer lors de la compilation sans devoir les ajouter manuellement au fichier CMake. Comme exemple de script, nous pouvons retrouver un script permettant de contrôler la caméra dans camera-simple.
NutshellEngine n'a pas encore d'éditeur GUI, tout se fait actuellement en code C++. Un éditeur est cependant prévu.
Développer The Girl Near The Window m'a montré qu'il était effectivement possible de développer un jeu avec NutshellEngine. Quelques défauts ont pu être identifiés et corrigés.
C'était donc une vue d'ensemble de NutshellEngine. Le moteur étant encore au début de son développement, de nombreux éléments risquent donc de changer.
Did you like this post? Tell us
Leave a comment
Log in with your itch.io account to leave a comment.