rewind a écrit 3425 commentaires

En fait, il est sur la branche develop mais je sais pas pourquoi je l'ai pas mis sur la branche master.

https://github.com/jube/libes/tree/develop/src/include/es

Et puis de toute façon, j'ai changé un peu ce code, j'ai remplacé EventHandler et sa fonction virtuelle par un std::function, mais j'ai pas encore pushé sur la branche develop. Si ça t'intéresse, je pushe ça le plus vite possible.

Alors, je te rassure tout de suite, le tileset utilisé pour le fond est un truc bricolé à l'arrache, ce n'est pas le tileset définitif. J'ai un groupe d'étudiants qui travaille sur la génération de carte et ils ont dans leurs objectifs de proposer un tileset plus riche (un peu plus que types de zones). Les couleurs seront un peu plus pastels. Les zones infranchissables seront mieux marquées, pour l'instant ils pensent utiliser des rayures, il faut voir ce que ça donne. A priori, ça sera intégré vers mars je dirais, le temps que je mette mon nez dans leur code et que j'en fasse quelque chose d'exploitable.

Tu as tout à fait raison, je pensais essentiellement au second type. Le premier est traité de manière particulière (via du polling d'ailleurs). Et le troisième n'a pas besoin de réactivité et provoque assez peu d'événements, donc on peut aussi faire du polling via des composants et des systèmes (et ça fait bien partie de l'état du jeu pour le coup).

Je comprend le manque de temps.

En fait, cet épisode est en retard par rapport aux autres ;) Normalement, j'essaie de publier toutes les deux semaines, mais là ça n'était pas possible. Du coup, j'ai retardé d'une semaine. Mais ça m'arrange parce que comme ça, je vais publier le prochain début janvier (parce que pendant les vacances, il n'y aura sans doute pas beaucoup de lecteurs, et j'en profiterai pour avancer)

Attention a l'explosion de la taille des logs!

Pour l'instant, tout va sur stderr et ça reste encore lisible.

Comme un commentaire au dessus, je suis un peu frustre par tes interrogations qui ne sont pas suivies de pistes de reflexion. Je comprends bien que la reflexion est en cours, ou meme pas encore bien definie, mais c'est justement le cheminement qui fait la richesses de cette serie de depeches. Si tu exposes tes reflexions en cours (ou meme tes ebauches de reflexion) avant d'exposer le choix realise, tu vas beaucoup faire beaucoup plus reagir/faire reflechir les lecteurs qu'en leur presentant le resultat final. Si tu ne fais pas ca, je me demande pourquoi tu nous expose tes interrogations. A vrai dire c'est un peu frustrant pour moi. Ceci dit, tu fais comme tu veux bien entendu :) Je suis deja content que tu partages ton experience et de voir la progression de ton jeu.

Je prend note. Je dois dire que j'aurais aimé aller plus loin mais par manque de temps, j'en suis resté là. J'espère ne pas avoir suscité trop de frustration.

Malheureusement, comme signale plus haut, les performances peuvent en patir selon l'implementation. Je pense qu'une implementation correcte et de typer les evenements et de se baser sur un systeme publish/subscribe ou le subscribe s'appuie sur le type de chaque evenement afin de limiter les notifications indesirables et la liste des subsriber a parcourir.

Dans l'implémentation que j'ai faite, le subscribe est bien par type d'événement, pas pour tous les événements, et les événements ont bien un type. L'autre choix majeur, qui simplifie énormément le code et la gestion mémoire, est que les événements doivent être consommés immédiatement, ils ne sont pas mis dans une file d'attente. Je pense que ça simplifiera le debug aussi.

Ce probleme peut etre reduit par l'utilisation de "traces" dans un mode debug qui permettent de comprendre que l'evenement E a ete concomme par le listener L, qui a en retour leve l'evenement F, etc.

Je commençais à avoir des traces, donc j'ai mis en place un système de log pour hiérarchiser l'information un minimum. Je vais assurément m'en servir pour ça aussi.

Merci pour ce retour encourageant !

Tu l'as vu en vrai ou c'est juste le principe ? Et c'est fait avec une lib ES ou c'est juste que ça se rapproche dans l'idée de l'ES ? C'est juste de la curiosité, l'exemple que tu donnes montre que oui, c'est possible dans ce domaine là.

Si tu n'as pas froid au yeux, tu peux regarder par là : git://git.damsy.net/sac.git pour le code du moteur et là pour un de nos jeux qui l'utilise : git://git.damsy.net/sac/heriswap.git :-)

Je vais aller voir ça ;)

en écrivant ça je me dis que c'est vraiment arbitraire comme choix et qu'on pourrait tout aussi bien sauvegarder toutes les entités et donc n'avoir que des entités persistantes :)

Ha, tu vois, tu doutes aussi et finalement, rien n'est clair dans tout ça.

Par contre, utiliser un «système de messages» basé sur des entités a plusieurs intérêts :
* les messages font partie du design E/S
* la synchro de ses entités messages suffit pour implémenter un mode réseau basique :)

Donc, tu ne rejettes pas mes réflexions en bloc ;)
Je crois que tu résumes bien les avantages qu'on peut en tirer.

Dans mon cas un composant fournit une fonctionnalité complète, par exemple : Button, Rendering, Transformation, Sound, Grid, etc

Tu as un dépôt public ? Parce que là, je trouve ça étonnant et ça m'intrigue vraiment.

de sérialiser/désérialiser les entités persistantes pour sauvegarder l'état du jeu et le restaurer plus tard

Tu fais donc une différence entre les entités persistantes et celles qui ne le sont pas, je comprends mieux du coup. J'essaie justement de réduire l'utilisation du système à entités à ce qui est persistant, en enlevant tout ce qui n'a pas à l'être. Mais je suis vraiment curieux de ton approche du coup.

Ha oui, je vois. Mais pour mon jeu, je vais en rester à la 2D. Parce qu'avoir deux vues dans un même jeu, ça peut être déroutant, je préfère en conserver une seule. Et ça n'apporterait pas grand chose à mon avis.

Ha oui, je comprends mieux.

Il me reste à régler le problème concernant ses mise à jour parallèles, cela doit bien exister dans un jeu : la barre de vie qui diminue et le sprite qui change pour montrer les dégâts ?

Et bien c'est là que je mettrais un événement (et donc un listener, enfin deux ici). Ou, comme dit dans l'article et un peu plus bas dans les commentaires, tu peux utiliser des composants pour tes événements et des systèmes pour les traiter.

Très intéressant. Et que penses-tu de mes remarques alors ? Notamment que ces événements ne font pas vraiment partie de l'état du système (d'ailleurs, je suis surpris de voir un composant Button) ?

tu aurais un screenshot ? parce que tout ce que je trouve sur le grand Web, ce sont des screenshot en 2D.

Savoir si les systèmes à entités peuvent servir à autre chose que des jeux vidéos est, pour moi, une question encore ouverte. Mais d'après ce que tu dis (et ce que j'en comprends), la réponse a l'air d'être plutôt oui. Après, j'avoue que je n'ai pas bien compris.

Tu poses beaucoup de problème et ne proposes pas vraiment de solution.

Effectivement, parce que je n'ai pas encore toutes les réponses. Mais ça viendra, c'est un travail en cours.

Alors les messages se sont des entités ou des composants ?

Ni l'un, ni l'autre, ils vivent en dehors du système à entités pure. Ils font partie du système d'événements.

Leur durée de vie est éphémère ou ils sont recyclés ?

Nécessairement éphémère. En plus, ça simplifie la gestion de la mémoire.

Il y a broadcast ou seulement du point à point ?

Heu, c'est une sorte de publish/subscribe, les gestionnaires d'événements s'abonnent à un type d'événement et reçoivent tous les événements de ce type. Donc, c'est du multicast ;)

Sinon, je voulais savoir aussi comment on gère une information dupliquée dans un système à entité. Par exemple un nom au dessus de chaque personnage, plus un encart détaillé sur le personnage qui a le focus. Dans un système objet classique, il y a un paquet d'adapter ou de listener collé un peu partout, surtout si la donné est modifiable, il faut pouvoir propager l'information dans tous les sens (ex: modification du nom).

On essaie, comme partout ailleurs, de ne pas dupliquer l'information. Et justement, avoir des événements permet de propager l'information. Maintenant, c'est vrai qu'avec une conception objet, on a les bons design patterns pour mettre tout ça en branle facilement. Mais l'intéraction entre un système à entité pure et un système d'événements est encore mal cernée, de mon point de vue, et c'est justement là dessus que je veux me pencher.

Comment rendre cela plus simple ? Avoir une entité-composant pour la boite de propriété qui est rattaché dynamiquement au personnage qui a le focus ?

Je ne sais pas si ça sera plus simple (et j'en doute même). Mais pour le cas que tu présentes là (très rapidement), je pense que ça peut se faire. Il faudrait décrire le problème de manière plus détaillé.

De manière générale, je dirais que les systèmes à entités ne proposent pas de simplifier ou de changer tout, ils proposent un autre point de vue sur le traitement de données hétérogènes mais qui partagent des traits similaires. Ce n'est pas une solution miracle à des problèmes bien connus depuis longtemps, c'est juste une manière de faire différente, rien de plus. Il ne faut pas en attendre trop. Pour l'instant, je dirais que j'aurais pu faire tout ce que j'ai fait avec une bonne vieille architecture objet des familles, et sans doute que ça aurait été plus facile parce que j'y suis plus habitué, mais j'aime bien le challenge intellectuel que ça représente de travailler avec des systèmes à entités et c'est aussi pour ça que je partage mes réflexions sur le sujet.

Petit instant de nostalgie de ces bons moments.

Je savais bien que j'allais toucher le cœur de certains :P

concrètement, tu géres les changement de niveau à la main et dans les deux sens (et non pas juste en définissant une zone "tampon" commune à tous les calques), sauf si j'ai rien compris. Donc que ça pointe vers un calque différent ou un fichier différent, ça ne change pas grand chose.

Si, ça change beaucoup de choses en fait. La zone tampon n'est pas commune aux deux niveaux, il y en a deux et elles sont légèrement décalées parce que sinon, tu passes d'un niveau à l'autre puisque tu retombes dans une zone de changement de niveau. Et avoir des calques, c'est bien pratique pour bien positionner ces deux zones pour qu'elles soient assez éloignées.

J'ai eu un bug la première fois que j'ai défini mes zones. Elles n'étaient pas assez éloignées et j'avais le phénomène décrit. Parce qu'il faut bien comprendre comment ça se passe. La collision est détectée dès qu'il y a collision, donc dès que les deux corps sont en contact. Mais le corps de mon héros, il est assez gros, donc en passant au niveau inférieur, il peut toucher l'autre zone de changement de niveau s'il n'y a pas assez d'écart. Déjà là, je met les deux zones suffisamment éloignées mais je vois ce que je fais grâce aux calques. Sans calques, je serais obligé de largement surestimer la corpulence de mon héros pour être sûr que ça va passer.

de fait, l'ordre des calques est une information superflue pour toi, tes "zones" ne disent pas "passe au calque du dessus", mais "passe au calque ", si?

Oui, l'ordre importe peu, l'information du niveau est stockée dans une propriété des calques. L'ordre importe uniquement pour celui qui va créer les niveaux, ça lui permet de savoir où il en est et à quel niveau il est.

et donc du coup, avec des fichiers différents, tu pourrais te permettre des choses beaucoup plus rigolotes pour pas plus cher : genre dimensions intérieures et extérieures sans aucun rapport (TARDIS?).

L'un n'empêche pas l'autre je dirais. Pour le cas général de la carte de mon univers, je vais procéder avec des calques. Mais si jamais mon héros était transporté dans une dimension parallèle, j'ajouterais des zones de changement de dimension ;)

Si tu enlèves Pujadas, il ne reste que 27 millions de salaires à distribuer…

je ne crois pas que ce soit possible sans réécrire toutes les applications et redéfinir les standards Unix

C'est précisément pour cette raison que je fais confiance à Lennart pour le faire !

Moi j'ai toujours dit que le prochain truc que Lennart va péter, c'est les shells, c'est l'étape suivante logique. Mais comme sh, sainul, il va réinventer la roue carrée avec un nouveau truc qui servira pour systemd (et puis après, ça servira de shell dans Gnome Terminal pour pas que les users ils aient à apprendre bash, vous vous rendez compte de la taille de man bash ?). Allez, je vous donne le nom : shd :P

Tout le plaisir est pour moi (sans compter que ça me force un peu à avancer).

Même quand on est tout seul, gitflow est très bien, ça permet de bien organiser son travail. Je dirais que le choix vient essentiellement du type d'application (web, pas web) plutôt que de la taille de l'équipe.

Merci pour ce lien ! J'ai parcouru vite fait «The Algorithmic beauty of plants» (premier lien de la bibliographie) et il a l'air d'y avoir plein de choses intéressantes là dedans.

S'il n'y avait que ça de moche dans mes branches ! Oui, elles sont horribles, c'est pour ça que je ne les ai pas montrées seules dans l'article.

Et personnellement pour moi un arbre il y a plus de branche que de feuille.

Ça dépend des arbres et des saisons. En été, on ne voit quasiment aucune branche vu de haut. En hiver, on ne voit que ça. Il suffit d'aller faire un petit tour sur Google Maps pour s'en rendre compte.

De toute façon, comme je l'ai dit, ça fait partie des améliorations prévues. Mais pareil, il faut que je trouve comment faire ça bien (si quelqu'un a un pointeur, je prend). Dans mon premier essai, les branches rendait très mal, et elle n'avait pas de ramification.

Hey, mais c'est pas bête ! Je pourrai m'en servir pour mettre des salades dans les jardins !