rewind a écrit 3425 commentaires

Toi, ça fait longtemps que tu n'as pas mis les pieds dans une université. Déjà première chose, les «universitaires» sont généralement ceux qui travaillent à l'université, pas ceux qui y étudient qu'on appelle plutôt «étudiants».

Il reste certes le domaine de la recherche ainsi que celui de l'enseignement, mais voila, il faut être clair la dessus (et être clair qu'il y a moins de places pour le boulot de ce type que de places d'université).

Moi je suis très clair là dessus : l'université fabrique et transmet le savoir, elle n'a pas vocation à former des salariés prêt à l'emploi. Cependant, il y a des filières dites professionalisantes (Licence Pro) qui ont cette vocation (et qui le font plutôt bien). Après, je considère que c'est aussi aux entreprises d'assurer une partie de la formation de leurs salariés, en particulier des jeunes salariés. L'université leur apprend les généralités, les entreprises adaptent les étudiants à leur cœur de métier. C'est une vue de l'esprit assez simpliste de croire que l'université pourrait former à des métiers vu la quantité de métier disponible. Rien qu'en informatique, il y en a une tétrachié. Donc, on donne à nos étudiants une formation qui leur permet par la suite de continuer à se former tout seul ou dans leur entreprise parce qu'on leur aura donné les bases essentielles et la théorie nécessaire pour comprendre la mise en pratique.

bon, il me semble quand même que depuis quelques temps, les IUT et IUP permettent de parler plus de la pratique, ça va mieux la dessus.

Les IUP sont en train de tous disparaître (en gros depuis la réforme LMD) et une grosse majorité des étudiants d'IUT va ensuite… à l'université ou dans des écoles d'ingénieurs. C'est fou hein !

La théorie est essentielle (pour certaines professions), mais ce n'est pas incompatible avec le fait qu'elle soit ennuyeuse. Je ne vois pas pourquoi tu opposes ces deux mots.

Je ne vois pas pourquoi la théorie devrait être ennuyeuse et la manière dont l'expression est employé dans l'annonce a quelque chose de très péjoratif, un peu comme ton discours.

En lisant l'annonce du changement de nom, il y a un passage que je n'ai pas du tout aimé.

L’esprit des cours ne change pas : on doit pouvoir apprendre en s’amusant, sans prise de tête et sans théorie ennuyeuse. C’est absolument essentiel à nos yeux. Nous pensons même que nous sommes capables de faire entrer cet état d’esprit qui vous plaît au sein des écoles et des universités !

La théorie n'est pas ennuyeuse, elle est essentielle si on veut comprendre ce qu'on fait, et pas juste appliquer les recettes du Site du Zéro d'OpenClassrooms. Et les universités n'ont pas besoin qu'on leur apprenne comment transmettre le savoir ! Les écoles non plus. Je n'aime pas du tout cette manière de voir les choses et de dénigrer l'enseignement supérieur.

Ce site constitue pour moi une référence pour apprendre a programmer facilement. Certain critiqueront cette dernière phrase mais pour moi qui ai majoritairement appris par moi-même ce site a été un formidable tremplin.

Je dirais que sur le Site du Zéro, on trouvait tout et son contraire et le pire côtoyait le moyen, voire de temps en temps le bon. Pour un enseignant en informatique, le Site du Zéro, c'est une plaie, c'est la source d'approvisionnement préféré en copier-coller des étudiants feignants.

Il y a d'ailleurs de fortes changes que j'utilise ta librairie ;)

N'hésite pas à faire remonter tes besoins pour l'améliorer !

Je trouve ça quand même dommage, pouvoir passer à un rendu console ou 3D facilement, c'est chouette :)

Oui, mais tu vois, tu n'auras pas les mêmes besoins pour chaque rendu. Entre un ou plusieurs caractères pour le rendu console, un sprite pour le rendu 2D et un modèle 3D pour le rendu 3D, si tu dois définir et sauvegarder les trois en permanence, tu en as deux inutiles en permanence. Et il y a certainement d'autres choses à prendre en compte : les collisions en 2D et en 3D, c'est pas exactement pareil. Donc, ce n'est pas juste une histoire de rendu, ça peut avoir une influence. Après si on reste dans un seul domaine, genre en 2D ou en 3D uniquement, là, on pourrait sans doute faire des choses, mais est-ce bien utile ?

Justement, ça fait pour moi partie du rendu. Et je pensais que c'était pas simple de séparer les deux actions en SFML mais ça fait quelque temps que j'y ai pas touché et tu as l'air sûr de toi donc ça doit être faisable. Juste que ça me parait overkill de séparer le rendu en deux systèmes, j'ai du mal à voir ce que ça apporte.

Pour moi, ce sont deux choses bien séparés. D'ailleurs, typiquement, tu as deux composants pour ce genre de chose et tu peux très bien imaginer des entités qui ont l'un et pas l'autre. Une entité qui a une position dans le monde mais qui est invisible (donc pas de position à l'écran), c'est assez courant. Et à l'inverse, des élements d'interface graphique qui vont avoir des positions sur l'écran mais pas dans le jeu (genre un score, un nombre de vie), ça existe aussi. Les deux sont nécessaires.

Ca va vite dans les jeux: les niveaux de Newton Adventure font 64x64 cases, soit déjà plus 4000 objets, alors qu'on est très loin de la taille des cartes d'un rpg.

Et combien d'objets «bougent», c'est-à-dire ont un mouvement ? Typiquement si tu fais la détection de collision à la main, pas besoin de croiser l'ensemble de 4000 objets (soit 16000000 de tests), il suffit de partir des quelques objets en mouvement (donc un sous-ensemble assez petit des 4000 objets) et de les croiser avec l'ensemble des 4000 objets. Et là, j'ai déjà un algorithme plutôt naïf qui permet de ne pas effondrer les perfs tout de suite.

en ce moment la mode est d'ajouter un éclairage dynamique sur des graphismes 2d classiques

Tu as des liens sur cette question ? Ça m'intéresserait de voir ça.

Tu bases tout sur SFML, ce que je trouve un peu dommage, pour moi un des avantages de ce paradigme c'est de séparer proprement le rendu du reste, pour pouvoir faire plusieurs implémentations du système rendu (Tu pourrais donc avoir une version SDL, une version SFML et une version console des mêmes balles rebondissantes en recodant uniquement le rendu).

Oui, j'utilise des classes de SFML (en fait une seule, Vector2f) par souci de simplicité. Je pourrais en effet recoder cette classe et faire une copie à chaque tour. Mais autant être simple et utiliser le bon type. Il me semble que ça ne sert à rien de se dire qu'on va utiliser plusieurs rendus quand on n'en utilisera qu'un seul. Oui, ça serait possible mais ce n'est pas un exercice qui m'intéresse plus que ça. Du coup, je m'autorise à reprendre des types de SFML.

Je saisi pas bien ce besoin d'avoir un composant avec les coordonnés réels, pour moi c'est interne au rendu, et donc le système rendu devrait directement travailler avec le composant position. En plus en SFML ce genre de chose se gère avec un viewport, ce que tu vas avoir du mal à faire si tu sépare rendu et traduction des coordonnés.

Au contraire, SFML gère très bien la traduction entre coordonnées de l'univers et coordonnées de l'écran grâce à une View. Dans l'exemple, j'ai fait la traduction moi-même mais c'était pour l'exemple. Après, on peut déléguer ça à SFML (il suffit juste de définir la View qui va bien).

Comme dit plus haut c'est triste cet entier à mettre à la main dans toutes les classes :-(

Meunon, ça s'automatise tout ça.

Ha, je pensais que tu utilisais Box2D. Du coup, je me suis trompé.

Ton exemple est un très bon cas d'étude. Il me rappelle un cas similaire sur Bomberman qui a des similitudes avec ton cas et duquel tu pourras sans doute t'inspirer.

Première chose : il n'est pas sûr que ton cas soit idéal pour utiliser un système à entités. Tu pourrais rester dans une conception classique et ça marcherait, je pense. Maintenant, on peut très bien utiliser un système à entité et je vais te dire comment je ferais.

Deuxième chose : tout ne se règle pas à coups de composants. Typiquement, le fond de carte n'est dans aucun composant, tu vas la dessiner en entier et ensuite, tu dessines le reste. Un autre classique, c'est la position du héros qui peut être dans un composant mais qui doit être accessible dans la plupart des systèmes.

Maintenant sur le fond, reprenons.

Du coup, j’ai la tuile (sol, eau ou mur en gros) qui est dessiné en premier, ensuite les mécanismes (interrupteurs, portes, pics qui sortent du sol à intervalle régulières…) et enfin les «objets» (je ne sais pas comment nommer cette catégorie: personnages, monstres, caisses…).

En fait, il n'y a pas vraiment trois couches, il y en a deux, voire une et demie. Tu as ton fond de carte (ce que tu appelles tuile et qui ne change pas normalement donc que tu dessines en une seule fois avant tout le reste, ça compte donc pour un demi). Ensuite, tout le reste, ça fait partie de la même catégorie, celle des objets du jeu, éventuellement avec un composant Collideable qui contient un champ height (comme dans l'exemple ci-dessus) qui va indiquer qu'est-ce qui est à quel niveau, ou level comme tu le dis après, c'est la même idée.

Au début je me disais que seul les objets pouvaient bouger mais maintenant, je veux avoir des mécanismes qui peuvent bouger par exemple. Du coup je me dis qu’un ECS ça pourrait être pratique: un composant «mécanisme», un composant «mouvement», un composant «objet» pour savoir si c’est un objet qui flotte ou non et savoir et une autre propriété du style, etc. Et même avec des spécialisations, genre certains mécanismes ne sont pas à mettre à jour automatiquement ne sont pas à mettre à jour automatiquement (portes et interrupteurs sont déclenchés par l’action du joueur mais les pics qui sortent puis rentrent du sol sont automatiques).

Ton début n'est pas mauvais. Je ne mettrai pas de composant «mécanisme», parce qu'un mécanisme, c'est une entité, pas une partie d'une entité. Il n'y a pas de données dans un mécanisme (sauf peut-être un type mais en fait, chaque type de composant va être défini par ses capacités, pas par un entier qui ne veut rien dire en tant que tel). Idem pour le composant «objet». En revanche, d'après ta description, tes entités mécanisme et objet vont avoir un composant Position. Ceux qui bougent auront un composant Mouvement indiquant l'amplitude du mouvement (on peut se restreindre à un mouvement soit horizontal soit vertical). Et tu auras donc un système qui prend toutes les entités avec une position et un mouvement pour mettre à jour la position en fonction du mouvement. Tu pourrais avoir un composant Ouverture pour l'entité interrupteur qui contient l'entité porte correspondante (ou même plusieurs entités si ça peut ouvrir plusieurs portes). Et donc, un système qui prend toutes les entités avec une position et une ouverture et qui va regarder la position actuelle du héros et ouvre la porte si jamais le héros et sur la même position que l'interrupteur. Pour tes pics, c'est un peu la même idée que pour mouvement, c'est le cas typique de l'animation. Donc tu vas avoir un composant Animation qui indique le nombre d'animation et la frame courante et les durées entre chaque frame. Ce composant, tu pourras le réutiliser pour d'autres mécanismes animés. Et pour les pics, tu peux avoir un composant Danger qui indique le type de danger (destruction, etc) et à quelle frame ils apparaissent. Tu auras un système qui va prendre les entités avec animation et danger pour dire si l'entité est actuellement en mode danger ou en mode pas danger, puis un système qui va prendre les entités avec danger et position, et qui va regarder si le héros est sur un danger ou pas et si ce danger est actif ou pas, et qui peut faire la même chose avec n'importe quel objet en fait et si ça fait mal, tu ajoutes un composant Lifetime (dont j'ai parlé à plusieurs reprises dans ce thread) qui indique que l'entité est morte. Ce dernier système va également fonctionner pour les danger pas animé. Et tu auras un système qui détruit toutes les entités qui sont mortes.

Après, avec cette conception, tu peux avoir des mix intéressants, genre des dangers animés qui servent aussi d'interrupteur (dans ton ancienne conception, je suis certain que tu n'y avais même pas pensé, ici c'est gratuit, il suffit de mettre les bons composants dans l'entité).

Le truc c’est que par exemple une IA (très basique) pour les monstres, c’est une méthode. Or j’avais compris que les composants ne stockaient que les données! Alors où se trouver la logique du jeu?

Non, ce n'est pas une méthode, c'est un système ! Tu auras un composant IA (avec ce qu'il faut pour que ça marche, par exemple fuite ou recherche pour savoir si l'entité fuit le héros ou le recherche) et ton système va prendre tes entités avec un composant IA et une position et va mettre à jour tout ça. Du coup, tu peux ajouter un composant IA à n'importe quel entité, montre ou même interrupteur, ou même porte (une porte qui fuit le héros, ça c'est fun).

Bref, en gros je pensais à un tableau en 3 dimensions pour stocker les tuiles, les mécanismes et les objets. Je mets à jour tout ce beau monde: automatiques + joueur + tout ce qui pourrait avoir été affecté par les précédents → ça évite que pour chaque case d’eau je vérifie si une caisse est au-dessus à chaque tour par exemple (je pense même à ne presque rien mettre en mise à jour auto et n’inscrire les caisses en automatiques que quand il y a déplacement par exemple).

Heu, à moins que tu aies des milliers d'objets (et donc des cartes énormes), je pense que c'est une optimisation prématurée. Quant au tableau, il est parfaitement inutile, sauf pour les tuiles (donc il est à deux dimensions). Tout le reste, ce seront des entités. Et la mise à jour se fait dans des systèmes. Je n'ai pas évoqué tous les systèmes mais tu auras un système pour les collisions par exemple.

Du coup grâce à cette technique je peux les dessiner dans le bon ordre, de sorte que les sprites qui dépassent sur la case du dessus ne soit pas dessinés en-dessous!

La manière dont chaque entité est dessiné et la logique du jeu sont deux choses séparées. Ton système de dessin va effectivement regarder toutes les entités avec un sprite et un level, peut les ordonner au préalable et les dessiner, mais quelque part, peu importe leur type, ça reste des sprites avec une hauteur.

Un entité conteneur de composant vs pas de conteneur et id pour connaitre les entités, quels sont les avantages et les inconvénients? J’aime bien la deuxième méthode mais ça risque de compliquer mon tableau à 3 dimensions! De toute manière, il va falloir faire attention que si un composant «meurt», tous les autres composants de l’entité doivent suivre. C’est pas très compliqué sauf si on fait des listes par composants (est-ce que la vue aurait chaque composant «vue» de chaque entité? Du coup la logique et la partie graphique du jeu auraient une méthode où on passe l’id de l’entité et qui détruit ses composants).

Du coup, tu peux choisir la deuxième, je t'ai donné des pistes pour supprimer ton tableau à trois dimensions. Pour la durée de vie des entités, tu peux regarder le tutoriel dont le parle, je donne une piste à base de composant Lifetime.

Si je modifie un composant j’aimerais bien pouvoir accéder à l’entité pour lui dire de mourir proprement, avec des composants à id on peut faire ça proprement. Ou alors ma super grille ne contient que des int qui sont des id!

Normalement, dans les systèmes, tu modifies des entités et tu accèdes à leurs composants. Donc tu as les entités correspondant aux composants. Et ta super grille, supprime la ! ;)

Pour les composants, j’ai l’impression qu’ils ont forcément une interface commune (au moins une méthode update), mais pas plus?

Non ! Ce sont des données, rien de plus. Le code de ta méthode update, il va dans un système, pas ailleurs.

N’est-il pas plus logique d’avoir un pointeur pour chaque type de composant qui est à null s’il n’en a pas?

Si tu as une entité container de composant, peut-être. Sinon, ça n'arrive pas puisque tu traites dans ton système uniquement les entités qui ont les bons composants.

Notamment parce que je ne vois pas l’intérêt pour mon jeu de rajouter des composants à la volée.

Pour l'instant non. Mais le composant Lifetime, tu peux l'ajouter à la volée, le composant IA, tu peux l'ajouter à la volée (en déclenchant le réveil du monstre avec un interrupteur invisible !). Bref, je vois plein d'extension facile avec les quelques composants que j'ai décrit.

Du coup il va falloir que je fasse de l’héritage sur les composants, j’ai l’impression à lire çà et là des trucs sur les ECS que c’était «mal»!

Oui, saimal ! Si tu hérites tes composants, c'est qu'en fait, tu as deux composants : un avec les données de la classe mère et un avec les données de la classe fille (sans les données de la classe mère). Ou alors, tes composants ne sont pas assez atomiques. Ou alors, tes composants sont mal faits.

Est-ce que je pourrait avoir un exemple très basique d’implantation de mon concept (en pseudo-code ou C++/Java/Python/…)? Parce quand c’est les concepts des autres j’ai du mal à suivre… Là je pense (j’espère) que ça m’aiderait carrément.

J'ai fait ce que j'ai pu, j'espère que ça t'aura éclairé. Je te conseille vraiment d'aller voir l'exemple donné au début (et aussi de suivre le lien donné au début de l'article).

Quand je disais pas trop mal foutu, je pensais en particulier aux VertexArray qui permettent justement ce que tu dis (deuxième point).

En opengl, ce qui coute cher, c'est le changement de contexte[1]. Typiquement changer la texture, le mesh ou le program (shader) courant (Il faut tj se rappeler qu'opengl est une machine à états, qui plus est distante car sur la carte graphique). La difficulté sera d'ordonner les rendus pour limiter ces changements (La vrai difficulté sera quand des objets partageront certaines textures et d'autres partageront certains mesh, le tout de manière non homogène. Faut-il limiter les changements de texture ou les changements de mesh ?).

Je fais confiance à SFML pour ça. Il y a des trucs dans SFML qui me font dire que c'est bien foutu à ce niveau là. Ou plutôt pas trop mal foutu.

Pour le moteur physique ce sera comment gérer l’interaction entre les éléments. Typiquement, pour ton exemple des balles rebondissantes, comment rajouter les collisions entre les balle ? Comment trouver les balles proches de celle actuellement traitée sans parcourir toute la liste ?

Je crois que je vais étendre ce petit tutoriel pour montrer comment on fait : on utilise ce qui marche déjà. En l'occurrence, des moteurs physiques 2D, il n'y en a pas 50 et on tombe très vite sur un qui est très utilisé (je crois d'ailleurs que c'est celui qui est utilisé dans Newton Adventure). Je crois que ça fera partie d'un de mes prochains articles de la série.

Une des optims qui était prévu était de faire le rendu en deux passes :

• Une première classique qui parcourrait les entités dans l'ordre où elles viendraient. Par contre au lieu de faire le rendu directement, elle remplirait une liste de "commande d'affichage" (mesh, program, texture, … à utiliser)
• La deuxième, trierait cette liste pour limiter les changements de contexte et ferait le rendu réelle en parcourent la liste triée.

C'est une technique intéressante, j'y réfléchirai le moment venu.

En tout cas, ça fait plaisir de voir tes commentaires qui mettent un peu la pression ;) N'hésite pas à continuer.

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.