Architecture de code pour Forbidden Archives : une présentation de l'approche en 5 couches

Read this devlog in English.

Dans le développement de jeux vidéo avec Unity 3D, l’architecture du code est un élément crucial pour garantir une structure cohérente et faciliter la maintenance et l’ajout de fonctionnalités. Dans ce premier devlog, je vais présenter l’architecture que j’ai choisi pour Forbidden Archives. Il s’agit d’une architecture en 5 couches qui permet de clarifier les responsabilités de chaque composant et de faciliter la communication entre eux.

Pour ce jeu, j’ai décidé de ne pas adopter l’architecture ECS malgré ses performances, car je manque de recul à ce sujet et cela peut ajouter une certaine complexité au projet dont je ne souhaite pas m’encombrer.

La couche Framework est une couche transverse qui contient des fonctionnalités génériques et des classes utilitaires réutilisables dans n’importe quel jeu ou application. Cette couche est indépendante du contexte du jeu et ne contient pas de logique gameplay spécifique. Elle fournit des outils pour la manipulation de fichiers, des fonctions mathématiques, des outils de transformation de données, etc. Les classes dans cette couche sont conçues pour être réutilisables dans d’autres contextes, permettant ainsi de gagner du temps et de l’effort lors du développement de futurs jeux ou applications.

La couche Model joue le rôle de façade pour le jeu, dans le sens du Design Pattern éponyme. Elle fournit une représentation abstraite des données et des fonctionnalités du jeu, sans dépendre des aspects de bas niveau spécifiques à Unity3D. Cette couche ne contient ni implémentation concrète, ni logique, mais fournit une abstraction solide et bien définie qui peut être utilisée par les autres couches pour communiquer entre elles de manière cohérente.

La couche System contient la logique gameplay du jeu. Elle utilise les couches “Framework” et “Model” pour implémenter les mécaniques du jeu. Les systèmes qui doivent maintenir un état héritent de “ScriptableObject”. Ainsi, les systèmes peuvent se référencer les uns aux autres ou être référencé par les éléments d’interface utilisateur et par les instances en jeu.

La couche Data contient les implémentations concrètes des interfaces définies dans la couche “Model”. Les classes de cette couche sont de ScriptableObject et utilisent des types propres à Unity3D pour stocker des données telles que les objets de jeu, les personnages, les niveaux, etc. Elle fournit une représentation concrète des données du jeu qui peuvent être affichée dans l’interface utilisateur. On y trouve aussi certains assets au plus proche des datas qui en ont besoin.

La couche UI englobe tout ce qui doit être affiché à l’écran. Elle contient les interfaces utilisateur ainsi que les prefabs qui seront instanciés et alimentés par les éléments de la couche Data. Cette couche n’héberge pas de logique métier significative, mais fait plutôt la liaison entre les MonoBehaviour et les Systems.

Il est possible que la séparation entre les couches Model et Data rajoute un peu de complexité. J’ai bon espoir que cette séparation permettent de mieux implémenter la couche System, mais je me réserve la possibilité de faire évoluer cela si les bénéfices s’avèrent finalement moins nombreux que les contraintes.

L’architecture en couches permet de séparer les responsabilités des différents composants du jeu et de faciliter leur communication. Chaque couche joue un rôle clair et bien défini, ce qui facilite la compréhension du code et sa maintenance.

L’architecture présentée dans ce devlog est le résultat d’une réflexion sur les besoins du jeu et de son développement actuel. Cependant, comme tout projet, il est susceptible d’évoluer au fil du temps. Si de nouvelles fonctionnalités ou contraintes techniques se présentent, il se peut que cette architecture doive être révisée ou adaptée. Dans ce cas, je publierais un autre post de devlog pour présenter ces changements et expliquer les raisons de ces choix.