rewind a écrit 3413 commentaires

Haaa ! Rien n'empêche de faire ça dans deux systèmes séparés qu'on va exécuter à la suite sur l'ensemble des entités. Comme exemple typique, je vois la gestion de la durée de vie d'une entité. Tu ne vas jamais détruire une entité dans un système, tu vas simplement ajouter (ou modifier) le composant Lifetime en indiquant que l'entité doit mourir et dans le système adéquat, tu détruis l'entité. Donc oui, ça, ça peut se faire et ça se fait. Je dirais même que c'est assez naturel en fait comme fonctionnement (ça fait des systèmes qui font peu de choses mais qui le font bien).

It's not a bug, it's a feature!

Vraiment, ce n'est pas un problème. Dans un des articles en lien, l'auteur dit (traduction perso) : «Est-ce que les caméras peuvent tuer les gens ? Est-ce que les balles peuvent accepter une entrée utilisateur ? Non ? Et bien… est-ce que vous avez déjà joué à Unreal Tournament ?» Oui, les systèmes à entités permettent plein de choses. Mais c'est justement pour ne pas être bridé par la technique.

le système d'entités me fait grandement penser au duck typing

C'est du duck typing dynamique si on veut.

Je suis d'accord avec toi sur le principe mais, désolé, je ne le vois pas dans ton implémentation.

C'est tout à fait vrai !

Je ne sais pas ce qu'il en est avec la norme du C++11 mais à ma connaissance rien ne garantie que les données d'une map soient stockées de manière linaire.

Tout à fait, mais ici, l'idée de la map, c'est de retrouver le composant en ayant l'entité, pas de stocker le composant. La manière de stocker le composant est laissée à l'utilisateur.

Si c'était le cas, le système ne parcoure pas dans l'ordre des composants mais dans celui des entités. Pour un exemple simple, il se peut que le parcours des composants se fasse dans l'ordre, mais dans un cas concret avec surpression/ajout d'entités, il y a de fortes chances que ça soit pas le cas. Qui plus est, ça casse quand même le cache vu que tu recharges ton conteneur des entités pour passer à la suivante.

Oui, l'ordre des entités n'est pas le même que l'ordre des composants. Mais globalement, actuellement, avec un set ordonné, l'ordre des entités sera l'ordre des composants (tant qu'on n'a pas détruit une entité). Si je prend un set non ordonné, là ça va poser des problèmes. J'avais trouvé un très bon article qui parlait de ce problème et qui proposait une solution (assez complexe) mais je n'ai pas réussi à remettre la main dessus au moment d'écrire l'article. Dès que je le retrouve, je le mets ici.

Tu parles de Boost.Pool dans ton tuto, c'est une bonne solution pour éviter les allocations dynamiques mais je pense que c'est à la bibliothèque de gérer ce problème de mémoire et de garantir que la mémoire est alignée. (Ce point là est discutable, je l'accorde)

Perso, je préfère laisser l'utilisateur faire ce qu'il a envie. S'il doit régler un problème de mémoire, il aura la main dessus. Et si jamais il n'y a pas de problème, et bien pas besoin de solution.

Dans ton exemples tu pourrais réunir les composants Coords et Look en un seul. À ce moment, le système Render peut parcourir directement les composants "GraphicalInfo" de manière linéaire sans passer par les entités. Par contre je n'ai pas de solution évidente pour ce qui est des systèmes "transverses" du type Graphics et Physics: vu que tu travailles sur deux composants en même temps, tu es obligé de passer par les entités. (Peut être que la littérature sur le sujet apporte une solution)

Ce cas où un système va traiter plusieurs composants est assez courant je pense. Après, rien n'empêche d'optimiser pour le cas où un système s'occupe d'un unique composant. Mais du coup, on retombe sur le problème d'avant : si c'est la bibliothèque qui alloue, c'est ok, sinon c'est foutu pour l'optimisation. Et puis le deuxième problème, c'est qu'il faut l'entité associée au composant et si tu parcoures les composants tels quels, tu auras du mal à savoir quelle est l'entité correspondante.

On peut voir le système d'entités/composants comme un système qui associe à un même nom (l'entité) différentes valeurs (les composants) selon "l'espace" dans lequel on regarde (les types des composants). La map dans ton Store (ou le deuxième vecteur dans ma proposition d'implémentation) étant le traducteur entre l'espace commun et les espaces spécifiques.

Oui, si je comprends bien ce que tu dis, c'est bien ça. Et je ne pense pas qu'il y ait une solution unique. J'en propose une, qui est sans doute très imparfaite mais qui m'ira bien jusqu'à ce que j'ai des problèmes de perfs. Et vu la machine sur laquelle je code, je pense que je les verrai assez vite les problèmes de perfs s'il y en a.

Qui plus est le code est propre et il y a de la doc.

J'ai fait des efforts ;)

je viens de voir que la modification du système se fait entité par entité.

Oui, je ne vois pas bien comment modifier plusieurs entités en même temps.

Ca peut être suffisant pour des jeux simples, mais ça peut conduire à des bugs bizarres: dans un RTS, une unité peut en tuer une autre alors qu'elle vient de mourir…

Effectivement. Mais ça ne va quasiment pas se voir puisque ça se résoudra à la passe suivante, donc 1/60è de seconde après voire moins.

il est donc possible d'appeler tous les composants (…) comme ça l'ordre est déterministe.

Oui c'est possible mais c'est ce que je disais, tu as une dépendance envers l'exécution de ton code. Et si tu supprimes un composant, tu es mal.

et l'exemple qui va passer cette fois-ci

Dans entityx, il y a une référence du Manager dans l'entité, du coup, ils peuvent faire ça. Chez moi, c'est juste un entier, du coup, même encapsulé, c'est plus difficile, à moins d'avoir un singleton, mais les singletons saimal (enfin, dans ce cas là, saimal, on pourrait vouloir deux managers). Et puis bon, ce n'est pas si différent de ma syntaxe ;)

J'inverse l'ordre des questions ;)

Est-ce que des entités peuvent être référencé dans les composantes ?

Oui, évidemment. C'est l'équivalent d'un pointeur sauf que ça se sérialise directement.

Comment tu fais un arbre d'entité ?

Tu définis un composant Arbre avec une entité fils droit et une entité fils gauche qui auront chacun un composant Arbre s'ils ont des fils ou pas si ce sont des feuilles.

Dans les faits, ce n'est pas forcément faux : une classe héritant d'une classe virtuelle pure DOIT implémenter les méthodes virtuelles pures qu'elle définit, ce qui revient au principe même de l'implémentation d'une interface. Ma question : m'a-t-on appris n'importe quoi ? Je suis curieux.

Oui oui, c'est bien ça, une classe non-virtuelle doit implémenter toutes les méthodes virtuelles. Si tu en oublies une, normalement tu ne pourras pas l'instancier (le compilateur va gueuler).

De même, l'héritage multiple existe en C++, et on m'a souvent indiqué qu'à partir du moment où une classe doit hériter de plus d'une classe (abstraite ou pas), alors il y a un défaut de conception.

Oui et non. Parfois, dans des cas très rares, ça se justifie. Mais très souvent, c'est mal utilisé.

Et j'entends trop souvent dire que "si on code bien tout de suite, les Design Patterns sortent tout seul sans avoir à suivre un schéma" : ceux-là, je les mets au défi. AMHA, je doute que n'importe qui soit capable de produire "comme ça, d'un coup" quelque chose qui a nécessité des semaines de reflexion à leurs auteurs

Quand tu connais bien les design pattern, au moment de la conception, tu sais reconnaître le bon pattern et du coup, tu l'appliques. Mais ça demande de l'entraînement et une très bonne connaissance des design pattern. Personnellement, je reconnais assez bien le pattern visiteur, mais pour les autres, souvent c'est plus difficile.

Par ailleurs, on parle dejà de conception technique (au sens de la préparation du code) au premier tutoriel pour la création d'un jeu vidéo? Etonnant, j'aurais vu en premier lieu une reflexion sur les idées, scénarios, gameplay, game design, etc avant… Mais comme je l'ai dit je n'ai pas encore tout lu, aussi je m'excuse par avance de cette remarque.

Il faut bien ménager le suspense :P Non mais j'ai découvert ça cet été et ça m'a bouleversé (sérieusement) donc je voulais en faire part à la linuxfrosphère. Après, pour le reste, ça va venir. J'ai déjà quelques idées qui sont bien fixées et d'autres qui demandent encore à être travaillé. Donc pour l'instant, je met en place la technique avant de lancer le grand spectacle :D

OO en C: il va falloir m'expliquer comment avoir la liaison dynamique, les génériques, le polymorphisme en C de manière propre. Ou alors ça s'appelle le C++.

Hint: GObject. Après, entre le dogme (le paradigme) et la manière dont c'est implémenté, il y a toujours des compromis à faire. L'orienté objet et ses diverses variantes suivant les langages montrent bien que la «propreté» dépend vraiment des gens. Personnellement, je n'aime pas GObject mais j'aime beaucoup C++. J'aime bien Ruby aussi dans un tout autre style d'orienté objet.

Je n'aime pas trop le fait de devoir spécifier l'id unique de chaque composant (static const es::ComponentType type = 3;), dans entityx, il utilise un système d'attribut statique qui dépend d'un template.

Je trouve qu'indiquer le type directement évite les problèmes. Par exemple, quand on va sauvegarder, on pourra l'utiliser sans risquer qu'il change à la prochaine exécution (parce qu'avec leur système, ça dépend du code et dans quel ordre sont créées les choses, ça crée une dépendance à l'exécution que je trouve inutile et même dangereuse).

cependant, moi j'ai envie de manipuler les composants des entités comme cela par exemple :

Il manque pas des choses dans ton exemple ?

Dernier point, une des caractéristique intéressante en C++11 est les pointeurs partagés, je pense que ce serait pas mal de les utiliser dans ton code.

Oui, pour l'instant, c'est pas très clean à ce niveau, ça pourrait être mieux. Mais il faut que je réfléchisse au calme avant de trouver le meilleur compromis.

Non, c'est un paradigme. Il n'y a pas de relation un à un entre les paradigmes et les langages. Certaines langages implémentent plusieurs paradigmes, d'autres un seul. Certains paradigmes peuvent être utilisés dans des langages sans que ces derniers n'offrent d'aide (exemple : l'orienté objet en C).

C'est pour ça que je veux faire un club plutôt qu'une option. Et que j'en fais des projets semestriels aussi : ils ont le choix de prendre les projets pas fun de mes collègues :P

C'est un des autres avantages des systèmes à entités effectivement. Les données sont partagées entre les dev et les créateurs de contenu, le comportement c'est le domaine exclusif des dev.

Dans des projets que je fais en solo, je ne trouve pas très utile de séparer données et comportements, et j'en reviens plus souvent à des modèles de programmation par traits.

Oui je pourrais faire la même chose mais j'avais envie d'essayer ce paradigme pour voir ce qu'il donne dans la vraie vie.

Le problème n'est pas un problème de langage, les systèmes à entités peuvent s'implémenter de différentes manières suivant le langage. C'est un paradigme suffisamment générique pour être utilisé où on en a besoin, dans n'importe quel langage.

Tu peux générer un tableau de pointeur vers les composants et les index vers chaque type de composants. Quand un composant est inactif, il est à null. Avec quelques templates bien placés, tout ça peut être calculé à la compilation et bien compact.

Ça me paraît complexe comme tu le dis. Il faut que j'y réfléchisse plus calmement. De toute façon, avec l'implémentation actuelle, ça marche assez bien pour l'instant. J'optimiserai mes structures quand ce sera nécessaire. Dans l'immédiat, je peux remplacer quelques std::set par des std::unordered_set ou des boost::flat_set, ça ne coûte rien.

En effet, selon l'architecture proposée (certes ce n'est qu'un exemple, mais quand même), un Avion ne roule pas. Or, c'est faux. Si on assume qu'un véhicule a forcément des roues, on peut du coup facilement considérer que la classe Véhicule définit une méthode roule() qui peut être abstraite ou non (si on suppose qu'une voiture ne roule pas comme une moto).

C'est un exemple pédagogique. J'aurais pu prendre le traditionnel Forme/Rectangle/Losange avec le Carré qui vient jouer le trouble-fête.

Pour le problème de rendre un véhicule volant, pourquoi ne pas utiliser une interface "Volant" (avec une méthode vole()) qu'implémente chaque classe concernée ? Avion devient un Véhicule (roulant) implémentant l'interface Volant, on a réglé le problème de façon propre.

En C++, il n'y a pas d'interface. Donc tu es obligé dans ce cas de faire de l'héritage multiple. En plus, tu verras en lisant la suite de l'article qu'ici, on va plutôt placer les données au centre du jeu, et pas les comportements (ce qu'est une interface).

Intéressant. Tu enseignes où ? :)

Si tu cliques sur le bon lien dans la dépêche, tu trouveras facilement ;)

Personnellement j'ai l'approche inverse, je pense qu'on devrait penser au jeu vidéo pour les projets, justement parce que les problèmes n'y sont pas spécifiques et qu'on y retrouve pas mal de problèmes qui existent ailleurs. Et en plus de ça, c'est fun, ça motive les étudiants.

Ce n'est pas contradictoire. Je donne déjà pas mal de projet de jeux vidéos pour les projets semestriels au niveau licence 3. Dans mes souvenirs de ces dernières années, mes étudiants ont déjà fait : les Colons de Catane, Doodle Jump, Loups garous de Thiercelieu (sur IRC), Rampart et j'en oublie sans doute un ou deux.

Quand c'est un projet semestriel en binôme, on n'a pas le temps de bien approfondir les choses et donc on reste cantonné à des jeux assez simples. Avec un club, on peut faire un plus gros jeu avec une grosse équipe (ce qui implique l'utilisation de certains outils) et sur toute une année plutôt qu'un semestre.

Ça tombe bien, dès l'introduction je dis : «on va commencer par un peu de technique et parler des systèmes à entités. C'est un nouveau paradigme de programmation»

Après, c'est pas moi qui ai décidé de l'appeler «système à entités». Personnellement, j'aurais trouvé un nom plus rigolo genre «paradigme des petits pois carottes» : pour faire une entité (le plat), on juxtapose plusieurs composants (petits pois et carottes) et on peut en ajouter dynamiquement des composants (steak haché et moutarde) et on a des systèmes (digestifs) qui permettent de transformer tout ça.

C'est exactement ce que j'ai appelé la mauvaise manière d'implémenter les systèmes à entités ;)

Mais oui, on peut faire comme ça. Mais non, je ne ferai pas comme ça.

Sans compter qu'un tableau de composants, et de la composition, pour ma part, c'est différent.

Les entity systems sont une variante du pattern role model!

Ça ressemble mais je pense que ce n'est pas pareil. Déjà dans la présentation, les role model sont présentés comme un pattern orienté objet. Je pense réellement que les systèmes à entités forment un nouveau paradigme, ce n'est pas juste un pattern de plus.

Une remarque à propos de l'implémentation: les "stores" pourraient être optimisés en utilisant des tableaux associatifs moins dynamiques ( http://www.boost.org/doc/libs/1_54_0/doc/html/container/non_standard_containers.html par exemple) puisque avant le lancement du jeu, on connaît tous les composants qu'une entité pourra avoir.

Oui mais pendant le jeu, on va créer et détruire des entités assez souvent, donc il faut voir si le coût d'insertion et de suppression est prohibitif ou pas. Bon, c'est vrai qu'en utilisant std::set, j'ai pris le premier truc qui m'est tombé sous la main et qu'en fait, on n'a pas besoin d'ordre donc un std::unordered_set serait sans doute plus adapté. Après, il y en a plusieurs qui ne jouent pas tous le même rôle donc à voir. C'est vrai qu'à certains endroits en y repensant, on pourrait utiliser autre chose. Je vais y réfléchir ;)

En tant qu'enseignant-chercheur en informatique, je trouve qu'une option jeux vidéos, c'est trop. Et d'ailleurs, j'exècre les formations d'informatique orienté jeux vidéos, ce sont des attrape-nigauds. Parce que finalement, on retrouve dans les jeux vidéos tous les problèmes qu'on a ailleurs, il y en a assez peu qui sont spécifiques aux jeux vidéos. Le jeu vidéo permet en revanche une immersion assez rapide dans la partie «métier», parce qu'en développant un jeu vidéo, on doit forcément s'intéresser à tout un tas d'autres disciplines (comme tu le soulignes), chose qu'on fait rarement normalement.

En revanche, avoir un club gamedev, ça oui, je pense que c'est une bonne idée (et je l'envisage de plus en plus sérieusement pour là où j'enseigne), parce que ça permet un excellent complémente de formation tout en s'amusant et en n'ayant pas la sanction de la note à la fin. Et oui, on peut associer d'autres disciplines : je n'ai qu'à traverser la rue pour être à l'école des beaux arts ;)

N’est-ce pas là le cas typique où il faut appliquer le principe de « composition plutôt qu’héritage » ?

Oui et non. Tu peux regarder What is an entity system framework for game development? qui montre comment on passe d'un truc orienté objet à un système à entité. Au milieu, ça ressemble à «composition plutôt qu'héritage». À mon sens, la simple composition ne suffit pas. À un moment, tu voudras ajouter un composant dynamiquement à ton entité et si tu utilises de la composition, tu ne pourras pas. Par exemple, imagine un composant Lifetime qui dit combien de temps il reste à vivre à une entité. Le héros n'a pas ce composant par défaut. Mais s'il se fait empoisonner, on peut lui ajouter dynamiquement un composant Lifetime et hop, c'est bon.

Mais, effectivement, contrairement au système à entités présenté ici, de par l'essence de la POO, l'accent est toujours mis sur le comportement (les messages), alors que, apparemment, d'après ton article, la programmation des jeux nécessiteraient plus une approche centrée sur les données.

Oui, dans un jeu, l'important, c'est le contenu, et ça paraît assez logique que ça se retrouve dans le paradigme. Disons pour être plus précis que dans la POO, les données et le comportement sont définis au même endroit (dans une classe) alors qu'avec un système à entités, on sépare bien les deux : les données dans les composants, les comportements dans les systèmes. Ce qui permet de décorréler les deux et donc de ne plus subir la hiérarchie de classe comme expliqué au début. Mais du coup, ça donne une plus grande importance aux données, parce qu'on va définir nos entités par leurs composants, donc leurs données, et plus par leur comportement, leurs méthodes.

Du coup les données qu'un système utilise sont prédéfinies au moment de la conception du jeux ?

Oui, il vaut mieux.

Ma question reviens à demander comment on fait de la "généricité" ?

Tout dépend ce que tu appelles de la généricité. Mais je dirais que dans le cadre d'un jeu où tout est à peu près connu et borné, on n'en a pas réellement besoin.

Pour quelles raisons ? Tu connais déjà le langage ? Certaines librairies sont plus faciles d'accès (j'entends dans le choix du système à entités).

Oui je connais déjà le langage, et sa version 2011 est vraiment sympa à utiliser. Dès qu'on commence, on peut difficilement s'en passer. Ensuite, le C++ étant le langage dominant pour les jeux vidéos, il existe tout un tas de bibliothèque plutôt bien foutu pour tout un tas d'usage (j'aurai l'occasion d'en reparler dans les prochains épisodes). Et puis même pour les trucs génériques, il y a du choix genre Boost. Donc, ça ne se discute même pas, je n'ai même pas réfléchi à utiliser un autre langage, c'est C++ et rien d'autre.

Maintenant, pour les systèmes à entités, il existe des implémentations dans plusieurs langages dont Java, ActionScript, Ruby, C#, et sans doute d'autres que je ne connais pas.

Ok, je me suis mal exprimé. Tu dis que 51 ne devraient pas avoir raison contre 49 (ce qui est le cas dans un référundum), ce qui est bien l'argument auquel je répond.