Re: Systèmes-Entités-Composants

Je voyais les systèmes un peu comme des modules, un truc assez simple : un système de combat, un système de mouvement, ... Avec quelque chose pour enchaîner tout ça. Est-ce l'enchaînement qui est difficile par exemple, parce qu'on a des actions de différentes natures mêlées et que du coup on sort vite de l'exemple "je lance le système de mouvement qui fait bouger tout le monde, puis le système de combat qui fait tous les combats, puis le système de rendu..." ?
Ou avec des systèmes plus fins (juste des fonctions permettant de traiter différents aspects des objets animés, en mouvement, ...) est-ce qu'il est trop compliqué de construire des fonctions pour traiter les entités ayant tel ou tel composant plutôt que les considérer globalement ? Par exemple pour savoir comment déplacer un personnage j'ai besoin de ses infos de mouvements mais aussi assez souvent d'autres données qui sont dans un autre composant, ça ne se résumé pas à "telle fonction qui s'applique à n'importe quelle entité possédant ce composant" ?

Je vais donner quelques exemples.

Quand on a une boucle de jeu traditionnelle, on voit bien comment on récupère les entrées (clavier/souris/manettes). Mais dans un système à entités, c'est plus compliqué. Parce qu'il y a plusieurs entités qui peuvent être manipulées par les entrées : le héros, l'interface graphique, une carte, etc. Et du coup, on ne sait pas très bien où récupérer les entrées, et comment les dispatcher vers la bonne entité. Au début, j'avais mis ça dans un système qui mettait à jour un composant du joueur. Mais après, j'ai vu la limite. Donc j'ai mis la récupération des entrées dans un système Player qui mettait à jour le joueur directement, sans passer par un composant. Mais même là, ce n'était pas très satisfaisant pour les raisons précédentes. Et j'étais vraiment bloqué (et je le suis toujours) pour ce mécanisme d'entrée qui peut piloter plusieurs éléments.

Autre exemple, l'affichage. Au début, c'est simple, tu as un système Render qui affiche toutes les entités qui doivent être affichées. Sauf que pour certains trucs, c'est un peu plus complexe. Genre une grande carte d'un monde ouvert, tu veux optimiser l'affichage et n'afficher que les tuiles qui sont à proximité du héros. Une solution, c'est de considérer que chaque tuile est une entité et de faire un système spécial qui va optimiser l'affichage. Sauf que tout n'est pas une tuile. Et puis après, il y a les éléments d'interface (la barre de vie, toussa) qui s'affichent toujours. La vraie solution, c'est d'utiliser plusieurs systèmes de Render qui vont avoir chacun leur caractéristique et qui vont afficher chacun une partie de la scène. Mais du coup, ça complexifie énormément, parce qu'on va avoir des composants différents pour chaque système. Et ces composants sont loin d'être simples. Par exemple, afficher un texte ou afficher une minimap, est-ce le même composant ? Ou deux ? Est-ce le même système qui gère les deux ou deux systèmes différents ?

En vrai, je pense qu'un RPG contient beaucoup trop de diversité et de logique de jeu pour que ce soit faisable dès le premier coup avec un système à entités. Si on part d'un truc existant à transformer, c'est peut-être faisable mais ça demande d'avoir une vision globale de tous les mécanismes et de leurs interactions. Et même après ça, ce ne doit pas être si évident.

Pour répondre à Nicolas Boulay sur le rôle d'un système de gestion d'événements, j'en avais dit quelques mots dans un épisode précédent. Je continue à croire que la gestion des événements est le grand impensé des systèmes à entités. Un système de gestion d'événements est indispensable mais son interaction avec le système à entités n'est jamais explicité et c'est un grand oubli.