rewind a écrit 3434 commentaires

En préliminaire à ces nombreuses questions, je pense qu'il y a une erreur à ne pas commettre : faire rentrer tout dans un système à entité. Et plus particulièrement, je pense qu'il n'est pas possible (ou souhaitable) d'utiliser un système à entité en conjonction avec un moteur de jeu. Parce qu'un moteur de jeu impose souvent une manière de faire qui n'est pas celle des systèmes à entités. Il existe des moteurs de jeu fondés sur les systèmes à entités (comme Unity), et ceux-ci utilisent le concept pleinement. Dans le cas d'Ogre, je crois qu'il va être difficile de le faire entrer dans un système à entité. Ou alors, il faut reprendre quelques classes de bases et refaire les classes haut niveau avec un système à entité, mais tu vas te retrouver à dupliquer du code existant par ailleurs.

Ceci étant dit, je vais essayer de répondre à tes questions.

En premier lieu, comment gérer la surcouche "matérielle" entre les composants de son propre système à entités et une bibliothèque externe ?

Comme indiqué, c'est difficile voire non-souhaitable de le faire, à partir du moment où la bibliothèque externe est assez haut niveau (comme un moteur de jeu complet). En revanche, pour des bibliothèques bas niveau (comme les moteurs physiques, ou les bibliothèques multimédias), c'est un travail d'encapsulation assez classique.

Est-ce que je prends le problème de travers et devrais fusionner ces deux objets ?

Tu prends le problème à l'envers. Il est compliqué de faire rentrer un cube dans un cercle.

Ce serait comme essayer d'appliquer la gravitation à une quête. Peut-on ignorer ce cas de figure, ou est-il raisonnable de penser qu'un composant doit être accompagner d'informations d'antériorité qui doivent être satisfaits pour permettre son existence ? Est-ce hors-sujet pour un système à entités ?

Alors là, je vais te citer un passage d'un article de référence qui dit : «Do Cameras shoot people? Do Bullets accept input from the player? No?» Et en fait, la réponse peut être oui. Donc en gros, les systèmes à entités permettent d'appliquer n'importe quel comportement à n'importe quel entité. Donc pourquoi pas appliquer la gravitation à une quête ? (Bon, ok, dans ton cas, je ne vois pas bien ce que ça voudrait dire). Mais plus concrètement, un object qui a une position n'a pas toujours un corps physique, mais l'inverse n'est pas vrai. Donc évidemment, si une entité a un corps physique, elle doit avoir une position. Et oui, tu peux faire cette supposition. Comme tu le soulignes après, un système n'agit pas sur n'importe quelle entité, il prend en compte le fait qu'une entité possède ou pas un certain nombre de composants.

Mais qui doit s'occuper de la "préparation" de ces cubes, c'est-à-dire notamment créer les objets Ogre à l'intérieur, puis placer correctement tous les cubes selon une scène pré-déterminée d'un fichier de sauvegarde ?

Ça peut être un système, ça peut être à l'initialisation. Généralement, le mot-clef qui va avec ce genre de chose pour les systèmes à entités, c'est «archétype». Un archétype, c'est une fonction qui va générer une entité d'un certain type en lui ajoutant tous les composants qui vont bien. Ces archétypes peuvent être appelé de n'importe où, y compris depuis un système (puisque c'est là que se situe tout le code). Après, la manière dont est créé l'entité dépend du type d'entité. Oui, il faudra peut-être aller lire un fichier de configuration, ça ne change pas grand chose.

Qui doit s'occuper du nettoyage lorsque les composants seront déconstruits (fuite mémoire, notamment) ? Si un composant n'est qu'une structure de donnée sans logique (dans la limite du C++), qui doit s'occuper de ce genre de traitements préparatoires et terminaux ? Un système ? Mais qui l'appellera et quand ? A priori on ne peut pas insérer pareil système préparatoire dans le circuit de la boucle infinie de l'application.

On a vu la naissance, maintenant la fin de vie. C'est un problème différent. Et oui, on peut tout à fait gérer cette fin de vie avec un système spécifique. Dans le tutoriel que j'avais écrit, ça faisait partie des exercices laissés au lecteur. Je conseillais d'ajouter un composant Lifetime avec un booléen indiquant si l'entité est en vie et une fonction à appeler pour détruire l'entité (la fonction inverse de l'archétype). Avec ce composant, on crée un système qui va s'occuper des entités qui possède ce composant. Et à chaque tour, il va appeler les fonctions de destruction sur les entités qui ne sont plus en vie. Après, les autres systèmes vont se contenter d'ajouter un composant Lifetime à une entité s'ils veulent la voir mourir, ou alors il vont positionner le booléen de telle sorte qu'elle meure (cette deuxième possibilité est intéressante dans le cas d'une entité à durée de vie limitée mais dont on connaît la durée de vie à l'avance).

Comment implémenter ce genre de traitement de façon efficace ?

Personnellement, dans ce cas, je ferais appel au moteur physique. C'est lui qui gère les interactions entre entités avec un corps physique. Il sait le faire de façon efficace et normalement, il prévient quand il y a une collision (c'est le cas de Box2D en tout cas).

J'ai du mal à voir comment implémenter le concept de "chose à faire ponctuellement".
Comment dire à un système de modifier un composant *précis *de telle manière *une seule fois ?

Là, le problème est un peu plus large. Et là, ma réponse, c'est que dans toutes les implémentations des systèmes à entités, il y a un systèmes d'événements en parallèle. Ce système d'événements sert justement à «faire une chose ponctuellement». Un système peut alors déclencher un événement et ceux qui sont intéressés par cet événement peuvent alors agir en conséquence.

Le préprocesseur n'a pas été abandonné au profit des templates et const int ce qui rend quasiment impossible l'analyse statique du code et beaucoup de raisonnements élémentaires sur le code source. Résultat: la compilation est très lente dès qu'on sort du cadre d'un projet trivial.

Les compilateurs modernes (dont Clang) savent remonter une erreur jusqu'à l'instruction préprocesseur fautive.

Les références font essentiellement double emploi avec les pointeurs, elles enrichissent le lexique d'un langage déjà touffu pour une sémantique (passage de pointeur sans transfert de propriété) essentiellement dupliquée par les smart pointers.

Les références ne font pas double emploi, au contraire, et elles n'ont pas du tout la sémantique que tu veux leur donner. Et les smart pointers, c'est encore autre chose.

Il est très difficile de tirer correctement parti des champs constants. Bien utiliser l'attribut const nécessite de préparer une vraie stratégie de développement.

C'est une blague ? Il n'y a pas besoin de «stratégie», juste d'un peu de bon sens et normalement, tout se passe bien et les const sont au bons endroits.

Le langage est tellement compliqué qu'il n'y a pas foule de compilateurs implémentant complètement le langage — la dernière fois que j'ai fait des recherches là-dessus il y en avait exactement un. Et puis les implémentations sont boguées! J'ai appris C++ et exactement 3 mois plus tard j'ai découvert un bogue dans le compilateur!

C'est là qu'on voit que tu n'as sans doute pas pratiqué C++ depuis un moment. Certes pour C++98, seul Comeau C++ implémentait la norme complète et en particulier le mot-clef export. Mais celui-ci a été enlevé de C++11 et depuis, Clang et GCC implémente la norme complètement. Après, si tu connais des compilateurs (peu importe le langage) sans bug, dis le, ça va intéresser plein de gens.

En fait, il faut qu'on se cotise pour offrir à devnewton un ordinateur qui gère un truc aussi moderne qu'OpenGl ES 2 pour qu'il arrête de vouloir des bibliothèques qui utilisent encore OpenGL 1 parce que ses cartes graphiques ne gèrent que ça.

Ha tiens, il faudra que je réessaie pour mon jeu. Il y a eu des mises à jour de Mingw-W64, ça va peut-être corriger le bug que j'ai eu la dernière fois.

La réalité, c'est que malgré tout ce que tu racontes, Debian est une des distributions avec le plus de paquets. Dingue, non ?

Ce que tu appelles obstacles, d'autres l'appellent assurance qualité. Et les utilisateurs sont bien contents que cette assurance qualité soit en place et c'est pour cette raison qu'ils ont confiance en Debian.

truc et astuce pour ceux qui utilisent Debian (marche peut-être avec les dérivées) : il suffit de se mettre dans le group staff et plus besoin de passer root pour faire make install, ça marche direct en user normal !

Ça suffit bien !

excellent ta présentation, clair et synthétique en 2 pages !

Il manquerait presque une page expliquant ce qu'est une licence logicielle (pour faire le lien entre les deux premières pages).

url ?

ici

ça n'a l'air de rien, mais mettre tout le monde d'accord sur une licence libre est important, cela devrait être fait au départ (même si c'est un peu pénible, cela fait partie du jeu…).

Entièrement d'accord.

Pour aller plus loin : http://faq.tuxfamily.org/CommunicationLibreGame/Fr (commentaires les bienvenus, il y a quelques poncifs assénés, pouvant demander quelques détails même si c'est complet pour le domaine).

Je vais mettre un lien sur cette page depuis le site du club, ça peut servir ;)

Ouais enfin, déjà avoir des jeux jouables à la fin, ça sera une bonne nouvelle. C'est l'objectif : finir les jeux. Après, si les jeux vivent leur propre vie, très bien. Si les étudiants veulent l'améliorer l'année suivante, pourquoi pas. Bref, on va avancer et voir ce qui se passe.

Attention à la licence !

Ils ont eu droit à une mini-formation sur ça à la première séance (dispo sur le site) ! Après, je vais veiller à ce que tout soit carrés à ce niveau là.

N'hésite surtout pas à nous faire part de ce qui sortira de la Dead Pixel Society, des fois qu'un jeu intéressant mais abandonné par les étudiants soit repris par une communauté ou que le fait de voir que son jeu est appréciés par d'autres pousse les étudiants à continuer.

On a fixé les projets mardi dernier, ça s'annonce bien, les étudiants sont motivés. J'espère que les 5 projets arriveront au bout (et je vais tout faire pour ça). Et oui, j'en reparlerai parce que c'est une expérience très intéressante, même humainement.

tu semble limiter le concept et non pas le pousser à bout, en ayant de choses figées ainsi tu perd l'avantage de la flexibilité des systèmes à entité

J'essaie d'épurer le concept, d'en tirer la substantifique moelle. Je ne pense perdre aucun avantage pour l'instant, mais j'explore une façon de faire qui pourrait au contraire offrir plus de clarté et de possibilités. Je ne dis pas que ça va réussir et que c'est la bonne manière de faire. Peut-être que je vais me planter complètement, mais je pense que ça vaut le coup d'essayer. Et pour l'instant, comme je l'ai dit, je suis mitigé. Dans cette optique, je réfléchis beaucoup aux liens entre les systèmes à entités et la gestion des événements qu'on retrouve dans quasi toutes les implémentations, y compris la mienne. Je me dis que ce n'est pas un hasard, il y a quelque chose à creuser, quelque chose de plus profond que «on ne peut pas tout faire avec un système à entités».

tu met la priorité sur une action qui me semble vraiment de moindre importance. Déjà beaucoup de jeux n'ont pas de sauvegarde, mais aussi, c'est quelque chose qui peut se permettre d'être plus lent. C'est rare les sauvegardes en temps réel, les joueurs accepte généralement bien qu'une sauvegarde ne soit pas instantanée.

Un RPG sans sauvegarde, comment dire… Pour beaucoup de jeux, c'est effectivement soit inutile, soit trivial. Pour un RPG, ça ne l'est pas et c'est même assez central, ça fait aussi parti du gameplay (sauvegarde possible tout le temps ou sur un point de sauvegarde ? ça change la physionomie du jeu). Ce n'est pas la vitesse de sauvegarde qui m'intéresse (si ça met 0.1s ou 2s, ça ne me fait ni chaud ni froid), mais savoir quoi sauvegarder et réfléchir aux liens avec les systèmes à entités.

Tout à fait, ça fait partie des liens que j'ai donné au premier épisode. Mais on n'a sans doute pas la même lecture de ces articles. Et on ne fait peut-être pas les mêmes types de jeu.

Il y a aussi cet article de Richard Lord qui se réfère aussi à ces articles et qui dit :

Another benefit of the component/system architecture is apparent when you want to save and restore the game state. Because the game state is contained entirely in the components, and because these are simple value objects, saving the game state is a relatively simple matter of serialising out the components, and restoring the game state involves just deserialising the data back in again.

Si je ne m'abuse, c'est plus ou moins ce que je m'évertue à dire depuis le début.

Qui dit restauré … dit sauvegarde ?

Non. Elle vient d'une autre source que la sauvegarde, justement. C'est ce que j'ai appelé des données statiques. En l'occurrence, la carte, elle est chargée à partir d'un fichier TMX qui n'existe qu'en un seul exemplaire (et pas un par sauvegarde).

Je ne prétends pas détenir la vérité absolue. J'essaie de pousser un concept au bout. Et le concept, il ne vient pas de moi, il a été décrit par d'autres et j'essaie de m'y tenir. Je ne doute absolument pas qu'on puisse faire autrement et que ça marche. Et je ne doute pas qu'il existe de multiples variantes qui fonctionnent également.

Tu ne sais pas faire la différence entre valeur et pointeur ? À l'extrême, tu vas sauvegarder le nom de l'asset utilisé par l'entité, pas l'asset lui même (qui se trouve déjà dans les ressources de ton jeu). Pousser un raisonnement à l’extrême OK, mais faut un minimum qu'il tienne la route si tu veux convaincre.

OK, prenons une carte à base de tuiles. Pour l'instant, j'ai généré des cartes de taille 512x512 (mais la carte finale sera sans doute plus grande). Pour chaque tuile, tu as besoin des informations suivants : quel est le tileset (je te le fais à un entier, un indice dans un tableau de tileset), et les coordonnées sur ce tileset (deux entiers). Donc trois entiers par tuiles. Mettons que tu optimises le codage et tu t'en sors à 64 bits, donc 8 octets. Tu en as pour 2Mio pour toutes tes tuiles. Tu les mets dans ta sauvegarde ou pas ? Non, bien sûr. Est-ce utile de les mettre dans des composants ? Et bien pour mon jeu, absolument pas. Aucun intérêt. Je peux gérer ma carte à part sans problème (et même ça m'apporte des avantages parce que je peux dessiner les couches dans l'ordre que je souhaite et de manière optimisée).

Donc si j'ai bien compris, ces questions de statique/dynamique/config/entité/etc te bloque au niveau architecture

Non, ça ne me bloque pas, ça me force à penser correctement.

Du coup, je vais poser une question plus directe sans suggestion de réponse pour te laisser élaborer : quel est le problème que tu essayes de résoudre par rapport à la sauvegarde ?

Que la sauvegarde et surtout le chargement soit facile. J'ai un jeu qui va nécessiter de sauvegarder tout un tas de trucs (où en est le perso dans la quête X, quels sont les objets laissés sur place que le perso peut vouloir récupérer plus tard, …) et avoir un système de sauvegarde/chargement facile va aider énormément plutôt que de devoir faire le travail de savoir ce qu'il est nécessaire de sauvegarder ou pas suivant chaque entité et composant.

Les systèmes à entités permettent une sauvegarde facile si on fait attention, pourquoi je me priverais de cet avantage en dérogeant du paradigme parce que ça a l'air plus facile ?

Tu ne réponds pas à ma question. Je me doute bien que tu le fais pour une raison, mais je ne comprends pas laquelle.

Pour l'instant, l'avantage énorme que je vois, c'est que la sauvegarde est triviale à faire si tu as bien séparé avant.

Ensuite je pense que les problématiques de sauvegarde sont secondaires : quelle est le problème de sauvegarder une entité statique ? Si c'est la taille du fichier de sauvegarde, n'importe quel algo de compression te ferait gagner beaucoup.

Oui mais ça veut dire que tu sauvegardes plein de choses inutiles. Si je pousse le raisonnement à l'extrême, tu vas te retrouver à sauvegarder tous les assets du jeu.

Et justement non, utiliser une entité pour afficher le fond de carte ne crée pas d'exception : tout ce qui est visible est une entité avec un composant Affichage.

Ce qui est le plus difficile, ce n'est pas d'afficher un truc, c'est de faire une sauvegarde du jeu.

Je veux bien savoir lequel ?

Il s'agit simplement de mieux modéliser ton application et de mieux comprendre les interactions entre les différentes parties. Si tu comprends mieux ce que tu fais, tu mieux utiliser des paradigmes plus fins et donc plus optimisés.

Ben, tu peux aussi définir tes entités dans un fichier texte

Tu peux. Mais ce n'est sans doute pas la meilleure façon de faire, à mon avis.

Vu d'ici je dirais :
* une entité avec un composant d'affichage pour afficher le fond de cartes
* N entités avec les composants de gameplay pour les tuiles qui en ont besoin (et en option un composant d'affichage)

Ton entité pour le fond de carte, elle ne te sert à rien. Parce que tu ne vas pas la sauvegarder, donc tu vas devoir la traiter de manière particulière parmi toutes les entités. Donc tu crées une exception pour rien puisque tu pourrais traiter le fond de carte à part et traiter toutes les entités de la même manière (on sauvegarde toutes les entités sans exception). Je ne vois pas l'intérêt.

Vraiment pas mal la page et surtout les liens qu'on y trouve. C'est chouette l'idée d'option jeu vidéo à l'université.

Ce n'est pas vraiment une option, c'est un club, donc pas de notes, pas de pression, juste du plaisir. Mais ça fonctionne très bien, mieux qu'espéré ! On attendait entre 15 et 20 étudiants, et on en a plus de 60. Du coup, on va lancer 5 projets de jeu vidéo !

Bon courage pour la suite, ça fait un bout de temps que je n'ai pas compilé Akagoria quand j'aurais re-déménagé je me remettrais à faire des tests ;-)

Prends ton temps, il n'y a pas eu de changement sur Akagoria depuis un moment.

Je ne comprends pas trop pourquoi tu t'embêtes à essayer de séparer arbitrairement ce qui est statique du reste.

Ce n'est pas arbitraire, ça a du sens du point de vue de l'application globale et d'un jeu en particulier.

Le fait que la masse ne change pas n'est pas lié au fait que la propriété 'masse' appartienne au composant 'physique'.

Si. La question c'est : «est-ce que tu vas devoir sauvegarder la masse parce qu'elle change pour chaque entité ou est-ce que l'information de masse va venir d'un fichier de config pour toutes les entités ?» Dans le premier cas, il faut la mettre directement dans le composant, dans le second, elle est dans un fichier de config. Ça change la manière de charger et de sauvegarder si on est dans un cas ou dans l'autre. Et après, tu as l'intermédiaire, c'est-à-dire qu'un type d'entités peut partager un ensemble de configurations possibles que tu vas identifier dans un composant (avec un enum ou un entier par exemple).

La logique que j'utilise pour mes composants c'est simplement d'y mettre toutes les entrées/sorties d'un système - au moins on voit clairement ce que manipule un système.

C'est ce que je fais aussi, mais par exemple, mettre tous les tuiles du fond de cartes dans des composants, c'est con. Outre le fait que c'est sous-optimal pour plein de raisons, ça n'a rien à faire là. Et pourtant, le système qui gère l'affichage, il mange des composants avec des sprites donc il pourrait manger des tuiles.

Ben par définition des composants. Après, j'essaie de creuser les concepts, donc je tâtonne, ce n'est pas toujours évident.

Voir la réponse en bas. Dans mon cas, ça ne change pas pour l'instant, donc c'est statique. Il est évident que pour worms, ça changerait donc ça serait à mettre dans un composant.

Normalement, un composant n'a aucune méthode, c'est juste une structure de données. Tout ce qui relève du code doit se trouver dans un système (ici, un système qui serait en charge du chargement et de la sauvegarde des données).