Donc ce n'est pas du tout la même chose, je ne me situe pas au niveau de "l'architecture interne" des agents (genre ton automate permet de décrire comment ça marche dedans), mais je me situe à l'extérieur, au niveau de l'interaction, et mon objectif est de permettre d'avoir des moyens d'interaction, mais aussi des mécanismes d'exécution (scheduling, connections au reste du monde, connexion à l'environnement) qui soient tous le plus proche du problème.
Au final, on est plus dans la fabrication de framework/plateforme SMA, que dans la fabrication de SMA directement (mais comme l'idée sur laquelle je m'appuie est qu'il n'est pas possible d'échapper à la fabrication de ce framework quand on fabrique des SMA, alors ça aide au dev des SMA).
En français j'ai bien un article de journal, je peux te l'envoyer par mail (pas le droit de le diffuser publiquement…), envoie moi un message, ça me ferait plaisir d'être lu, même partiellement :]
Mon argument, c'est que si tu utilises un truc comme le tiens, tu es obligé de traduire ta solution à ton problème dans le "langage" de tes concepts, un peu comme quand on fait de l'objet, on traduit toute interaction en éléments du système sous forme de méthode.
Comme c'est un peu limitant en terme d'abstraction, la communauté du dev (industrielle et académique) a fait des design pattern, des frameworks, qui permettent de palier ces limitations, et ça marche bien.
Mais dans les SMAs, enfin en tout cas dans ceux que j'étudie, on a une conception tellement proche du problème et tellement éloignée de l'implémentation, que ces "contraintes", ces limitations sont trop importantes, on a besoin pour implémenter son SMA d'abstraction ultra adaptées au problème (genre on veut pouvoir raconter dans son implem que notre agent envoie des messages, mais perçoit ses voisins, ce voisinage étant maintenu par l'environnement car il est dynamique et représente l'extérieur du système qu'on ne contrôle pas, qu'il y a des échanges en local mais aussi à distance, qu'ils ne doivent pas être gérés de la même façon par l'agent, etc, et d'autres trucs comme ça).
Et donc, mon truc permet de fabriquer ces abstractions adaptées au problème, ou plus précisément d'en réutiliser pour les composer et faire sa plateforme SMA maison.
C'est là qu'on fait le lien avec les ES, au final, ça semble permettre de définir et de réutiliser des systèmes entre différents jeux, pour les composer dans les entités et définir leur structure et leur dynamique de façon très adaptée et très proche du problème que l'on veut modéliser.
Et on peut mettre dans ces systèmes l'implémentation de ces différentes préoccupations de façon bien séparée.
Forcement, tout les gens qui bossent sur le jeux retrouvent leur billes sans aucun "gap" entre ce qu'ils ont dans la tête (des tanks qui se déplacent, qui ont une tourelle) et la façon dont c'est organisé dans l'implémentation (l'entité tank et tout les composants qui la concernent, et les systèmes qui l'intègrent au reste du monde).
En objet, chacun de ces concepts se seraient retrouvés un peu partout dans différentes parties du code il me semble.
[^] # Re: Un autre « framework » : ma vie mon œuvre
Posté par Victor . En réponse au journal entity.JS - un "Entity System" en JavaScript. Évalué à 2.
Donc ce n'est pas du tout la même chose, je ne me situe pas au niveau de "l'architecture interne" des agents (genre ton automate permet de décrire comment ça marche dedans), mais je me situe à l'extérieur, au niveau de l'interaction, et mon objectif est de permettre d'avoir des moyens d'interaction, mais aussi des mécanismes d'exécution (scheduling, connections au reste du monde, connexion à l'environnement) qui soient tous le plus proche du problème.
Au final, on est plus dans la fabrication de framework/plateforme SMA, que dans la fabrication de SMA directement (mais comme l'idée sur laquelle je m'appuie est qu'il n'est pas possible d'échapper à la fabrication de ce framework quand on fabrique des SMA, alors ça aide au dev des SMA).
En français j'ai bien un article de journal, je peux te l'envoyer par mail (pas le droit de le diffuser publiquement…), envoie moi un message, ça me ferait plaisir d'être lu, même partiellement :]
Mon argument, c'est que si tu utilises un truc comme le tiens, tu es obligé de traduire ta solution à ton problème dans le "langage" de tes concepts, un peu comme quand on fait de l'objet, on traduit toute interaction en éléments du système sous forme de méthode.
Comme c'est un peu limitant en terme d'abstraction, la communauté du dev (industrielle et académique) a fait des design pattern, des frameworks, qui permettent de palier ces limitations, et ça marche bien.
Mais dans les SMAs, enfin en tout cas dans ceux que j'étudie, on a une conception tellement proche du problème et tellement éloignée de l'implémentation, que ces "contraintes", ces limitations sont trop importantes, on a besoin pour implémenter son SMA d'abstraction ultra adaptées au problème (genre on veut pouvoir raconter dans son implem que notre agent envoie des messages, mais perçoit ses voisins, ce voisinage étant maintenu par l'environnement car il est dynamique et représente l'extérieur du système qu'on ne contrôle pas, qu'il y a des échanges en local mais aussi à distance, qu'ils ne doivent pas être gérés de la même façon par l'agent, etc, et d'autres trucs comme ça).
Et donc, mon truc permet de fabriquer ces abstractions adaptées au problème, ou plus précisément d'en réutiliser pour les composer et faire sa plateforme SMA maison.
C'est là qu'on fait le lien avec les ES, au final, ça semble permettre de définir et de réutiliser des systèmes entre différents jeux, pour les composer dans les entités et définir leur structure et leur dynamique de façon très adaptée et très proche du problème que l'on veut modéliser.
Et on peut mettre dans ces systèmes l'implémentation de ces différentes préoccupations de façon bien séparée.
Forcement, tout les gens qui bossent sur le jeux retrouvent leur billes sans aucun "gap" entre ce qu'ils ont dans la tête (des tanks qui se déplacent, qui ont une tourelle) et la façon dont c'est organisé dans l'implémentation (l'entité tank et tout les composants qui la concernent, et les systèmes qui l'intègrent au reste du monde).
En objet, chacun de ces concepts se seraient retrouvés un peu partout dans différentes parties du code il me semble.