Toujours dans le cadre de mes recherches sur l’architecture logicielle d’un jeu vidéo, je vais vous exposer le modèle le plus simple qui est utilisé dans The Great Paper Adventure.
Communément appelé architecture basé sur les entités (entities-based architecture), elle consiste à définir chaque objet du jeu (une arme, un véhicule, un personnage, un décor) comme une entité.
Bien sûr cela s’adapte parfaitement à la programmation objet : une superclasse Entité, et des spécifications de différents comportements qui en hérite.
A première vue très pratique, et elle l’est d’ailleurs clairement, elle est cependant limitée :
- La plupart des langages modernes n’autorisent plus le multi-héritage. Impossible donc de définir une classe héritant d’une superclasse « Entité dommageable » et « Entité déplaçable ».
- Chaque objet dispose donc d’un grand nombre de propriétés, attributs, méthodes, potentiellement inutiles. Une plante verte dans le décor n’a probablement pas besoin des mêmes routines de déplacement, de collision, d’IA, d’affichage que celles de personnages (encore que dans Mario, c’est faux !).
De plus, puisqu’on utilise une classe par objet du jeu, on se retrouve vite avec une grand quantités de classes à gérer, certaines étant probablement très similaires.
Pratique et rapide pour un petit projet (= peu d’objets différents), on pourra donc se pencher vers d’autres architectures pour un projet plus volumineux.
Un exemple d’application de ce pattern.
On voit ici que tous les ennemis doivent bouger. Bien sûr on peut imaginer que leur méthode de déplacement soit « hackée » pour que l’ennemi ne se déplace jamais, mais cela n’enlève rien à la limite de ce modèle.
De même tous les objets ont des points de vie, et une boîte de collision. Encore une fois, certains objets du jeu n’en auront probablement pas besoin et n’utiliserons pas ces propriétés, qui prendront pourtant de la place en mémoire.
Lire la suite : Partie 2 : décomposition du pattern en composants
