C'est vrai, au lieu d'avoir une grande "game loop", on se retrouve avec une liste de systèmes appelés les uns après les autres. Pour autant, ça dépend vraiment de comment tu fais ta game loop. Si elle se résume à une suite d'appels vers d'autre fonctions, alors ça revient un peu au même que d'utiliser des système, la flexibilité en moins. Si une bonne partie du code du jeu se retrouve dans la game loop, alors je te dirai qu'il faut peut-être revoir la structure de ton jeu.
Mais ça dépend aussi de la taille du jeu. Pour un petit jeu, il vaut peut-être mieux utiliser une architecture plus simple qu'un ES. A l'origine l'architecture ES est faite pour supporter des jeux avec des millions d'objets différents du style des MMORPG où les données sont stockées dans des bases de données, et où des centaines de personnes travaillent en même temps sur le jeu. (Ce qui ne l'empêche pas de marcher pour des plus petits jeux évidemment)
Maintenant c'est vrai que le code est éparpillé mais ce n'est pas fait n'importe comment et l'architecture permet de s'y retrouver et de limiter les erreurs si on respecte les règles.
Pour le code path lors d'un débug, tout n'est pas mélangé car chaque système ne va toucher qu'à un nombre restreint de composants (souvent 1 ou 2). Dans le brouillon de l'API, chaque système doit exposer quels composants il va toucher avant d'être initialisé, puis lorsqu'il est initialisé, il va recevoir uniquement des références vers les composants qu'il a demandé. En plus de permettre d'optimiser l'utilisation des composants pour chaque système, cela permet d'inspecter quel système touche quel composant, ce qui simplifie le débogage.
Ensuite, mon idée est d'avoir des groupes de système avec la possibilité de les hiérarchiser. Par exemple les groupes: update, update.AI, update.environement, update.physics, render, render.images, … Ensuite on ajoute les systèmes au bon groupe, et tout peut s'exécuter à la suite. Tu peux regarder l'objet ExecutionHandler dans le brouillon, qui permet de faire des groupes d'exécution. (Et qui va optimiser l'exécution en gardant à jour une liste de systèmes à exécuter dans l'ordre.)
L'intérêt c'est qu'on peut faire des "méta opérations" sur les systèmes comme par exemple mettre en pause un groupe ou calculer le temps d'exécution d'un système ou processus de façon simple et intégrée au navigateur. Voir pourquoi pas lors du développement, insérer des fonction avant/après l'exécution d'un système pour vérifier des conditions spécifiques.
[^] # Re: Objection
Posté par jlgrall . En réponse au journal entity.JS - un "Entity System" en JavaScript. Évalué à 6. Dernière modification le 15 mars 2013 à 13:33.
Merci pour ce retour.
C'est vrai, au lieu d'avoir une grande "game loop", on se retrouve avec une liste de systèmes appelés les uns après les autres. Pour autant, ça dépend vraiment de comment tu fais ta game loop. Si elle se résume à une suite d'appels vers d'autre fonctions, alors ça revient un peu au même que d'utiliser des système, la flexibilité en moins. Si une bonne partie du code du jeu se retrouve dans la game loop, alors je te dirai qu'il faut peut-être revoir la structure de ton jeu.
Mais ça dépend aussi de la taille du jeu. Pour un petit jeu, il vaut peut-être mieux utiliser une architecture plus simple qu'un ES. A l'origine l'architecture ES est faite pour supporter des jeux avec des millions d'objets différents du style des MMORPG où les données sont stockées dans des bases de données, et où des centaines de personnes travaillent en même temps sur le jeu. (Ce qui ne l'empêche pas de marcher pour des plus petits jeux évidemment)
Maintenant c'est vrai que le code est éparpillé mais ce n'est pas fait n'importe comment et l'architecture permet de s'y retrouver et de limiter les erreurs si on respecte les règles.
Pour le code path lors d'un débug, tout n'est pas mélangé car chaque système ne va toucher qu'à un nombre restreint de composants (souvent 1 ou 2). Dans le brouillon de l'API, chaque système doit exposer quels composants il va toucher avant d'être initialisé, puis lorsqu'il est initialisé, il va recevoir uniquement des références vers les composants qu'il a demandé. En plus de permettre d'optimiser l'utilisation des composants pour chaque système, cela permet d'inspecter quel système touche quel composant, ce qui simplifie le débogage.
Ensuite, mon idée est d'avoir des groupes de système avec la possibilité de les hiérarchiser. Par exemple les groupes: update, update.AI, update.environement, update.physics, render, render.images, … Ensuite on ajoute les systèmes au bon groupe, et tout peut s'exécuter à la suite. Tu peux regarder l'objet ExecutionHandler dans le brouillon, qui permet de faire des groupes d'exécution. (Et qui va optimiser l'exécution en gardant à jour une liste de systèmes à exécuter dans l'ordre.)
L'intérêt c'est qu'on peut faire des "méta opérations" sur les systèmes comme par exemple mettre en pause un groupe ou calculer le temps d'exécution d'un système ou processus de façon simple et intégrée au navigateur. Voir pourquoi pas lors du développement, insérer des fonction avant/après l'exécution d'un système pour vérifier des conditions spécifiques.
J'espère avoir répondu un peu à ta question.
PS: Tu peux voir ici un exemple de relations entre les systèmes et les composants dans un jeu: System-Component Dependencies tiré de l'article The Components and Systems of Morgan's Raid.