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.
[^] # Re: Systeme d'evenements
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E07 : cartes, données et systèmes à entités. Évalué à 2.
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.
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.
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 !