Pour moi, cette lib n'a que peu d'intérêt, parce que:
C++20 obligatoire. Pas mal de codebases n'autorisent pas C++20 (pour différentes raisons. Par exemple, daemon-engine est limité à C++14 par la dépendance a google NaCl, mais on peu aussi citer recast-navigation qui se limite
a C++11, pour leurs propres raisons).
STL utilisée, et pour de mauvaises raisons en plus. La STL, c'est gros, c'est lent à compiler, c'est chiant a debugguer, le contrôle sur la mémoire est pénible. Certains par exemple y préférerons EASTL.
la maintenance va être compliquée. Ce code utilise auto pour tout et n'importe quoi. Il y a des shared_ptr qui devraient vraiment être des unique_ptr, également.
aucun outil. C'est bien d'avoir les briques de base, mais debugguer une IA n'est pas simple. Tant qu'a avoir des dépendances sur la STL, un outil pour charger les données depuis un stockage externe n'aurais pas été de trop. Ces données pouvant ensuite être chargées dans un programme permettant une visualisation, par exemple.
Bref, je n'ai pas en tête de lib pour remplacer tout, notamment utility et les FSM, mais à choisir: GPGOAP ou behaviortree.cpp qui dispose aussi, de mémoire, d'un outil visuel pour manipuler les BT, me semblent mieux indiqués.
A noter que je n'ai pas analysé le code de behaviortree.cpp, mais celui de GPGOAP, si.
Bien que GPGOAP ait la limitation de représenter un "worldstate" sur 64 bits seulement, en réalité 64 états c'est beaucoup.
Augmenter la taille serait simple, il suffirait d'utiliser un long double, par exemple (128 bits).
Sinon, normalement le code des IAs de F.E.A.R. est disponible, par l'auteur du concept même de goap.
Pour ce qui est des outils avec GPGOAP, il est très simple de construire un pseudo fichier de conf qui soit convertible aisément en langage dot (graphviz) pour générer un graph des actions. La lib fournit également des outils pour aider le debug.
J'avais fait cette lib pour répondre à un besoin personnel, et j'ai décidé de la publier même non finie au lieu de la laisser pourrir sur mon pc.
Pas mal de codebases n'autorisent pas C++20
C'est réellement pas mon problème. C++20 et C++23 apportent beaucoup de fonctionnalités très intéressante, je vois pas pourquoi je m'en priverais.
STL utilisée, et pour de mauvaises raisons en plus.
Tu as réussi a inférer mes raisons simplement en lisant le code ?
La raison c'est que je ne voulais aucune dépendance. Le langage de base me fournit tout ce dont j'ai besoin, je ne vois pas pourquoi j'irais chercher ailleurs.
Ce code utilise auto pour tout et n'importe quoi.
Oui, parce que l'inférence de type c'est bien.
Il y a des shared_ptr qui devraient vraiment être des unique_ptr, également.
Ca c'est le premier point ou je suis d'accord. Mais j'ai eu des problèmes avec unique_ptr:
std::initializer_list ne peut pas contenir de unique_ptr car quand on itère dessus, cela fait une copie
je ne peux pas initialiser un std::vector de unique_ptr pour la même raison, car le constructeur utilise std::initializer_list
Cela m'obligerait donc a créer le std::vector, faire des push_back avec std::move, et ensuite std::move le std::vector au constructeur qui en a besoin, chiant.
Alors oui, j'ai pris l'option de facilité, utiliser shared_ptr, ça marche bien.
aucun outil.
Libre à toi de faire une PR, c'est ça aussi l'opensource.
Posté par freem .
Évalué à 2.
Dernière modification le 03 mars 2024 à 17:59.
Je pense que j'ai mal exprimé un truc. Si j'ai pris le temps de répondre, c'est déjà que je trouve la chose intéressante (j'ai pertinenté le lien de mémoire, mais je ne peux que prouver avoir voté).
Pour moi, ce site a un gros bon point: il inclue pas mal de vulgarisation sur un sujet qui semble peu connu globalement. Par exemple, pour goap, qui est je pense une avancée majeure (de 20 ans d'âge), je ne l'ai vu implémenté dans aucun jeu libre dont j'aie lu le code pour l'instant (plusieurs FPS, quelques jeux de stratégie).
Le "bof" que j'aurai clairement du lire, et relire au moins 7 fois, est… oui, je pense: mesquin.
Forcément, un titre pareil ne donne pas envie d'être poli.
Je te demande pardon.
La raison c'est que je ne voulais aucune dépendance
Mais la STL est une dépendance, régulièrement non appréciée pour diverses raisons plus ou moins valides (temps de compilation, taille du binaire notamment liée à l'obligation de supporter les exceptions ou de se passer totalement de mécanismes d'erreur, debug pénible à cause des 150 couches de template, etc)
Oui, parce que l'inférence de type c'est bien.
Discutable pour moi, mais bon.
Libre à toi de faire une PR, c'est ça aussi l'opensource.
Vu que je suis en train de bosser sur un outil pour gpgoap, justement, ça serait envisageable.
Pour les autres je vais avoir la flemme par contre, d'autant que behaviortree.cpp dispose déjà d'un tel outil.
Bienvenue dans le monde moderne. Si on doit attendre que tout le monde soit prêt alors on fait du C++20 en 2040. Je chouine pas quand un projet demande une version récente de rust, soit je m'adapte soit je laisse tomber mais je blâme pas les développeurs qui prennent les outils disponibles. La volonté de s'adapter est propre à l'utilisateur. Sinon on innove jamais. Tout le monde criait au scandale quand on a enlevé les lecteurs de disquette spuis de CDs et maintenant plus grand monde en utilise. C'est pareil dans les langages, si on prend pas de parti pris on avance pas et je suis bien content qu'en C++17 on puisse enfin parcourir des répertoires avec la bibliothèque standard sans passer par boost ou une douzaine de #ifdef.
STL utilisée, et pour de mauvaises raisons en plus. La STL, c'est gros, c'est lent à compiler, c'est chiant a debugguer, le contrôle sur la mémoire est pénible. Certains par exemple y préférerons EASTL.
Ah donc quand on fait du C++ on doit pas utiliser la bibliothèque standard qui est implémentée nativement et optimisée sur chaque plateforme ? Pareil en C ? en C# ? en python ? en rust ?
Commentaire vivement subjectif.
git is great because linus did it, mercurial is better because he didn't
# NPC = Non playable characters = PNJ = Personnage non jouable
Posté par steph1978 . Évalué à 3.
.
# Bof
Posté par freem . Évalué à -1.
Vu que le sujet m'intéresse, j'ai jeté un oeil.
Pour moi, cette lib n'a que peu d'intérêt, parce que:
Bref, je n'ai pas en tête de lib pour remplacer tout, notamment utility et les FSM, mais à choisir: GPGOAP ou behaviortree.cpp qui dispose aussi, de mémoire, d'un outil visuel pour manipuler les BT, me semblent mieux indiqués.
A noter que je n'ai pas analysé le code de behaviortree.cpp, mais celui de GPGOAP, si.
Bien que GPGOAP ait la limitation de représenter un "worldstate" sur 64 bits seulement, en réalité 64 états c'est beaucoup.
Augmenter la taille serait simple, il suffirait d'utiliser un long double, par exemple (128 bits).
Sinon, normalement le code des IAs de F.E.A.R. est disponible, par l'auteur du concept même de goap.
Pour ce qui est des outils avec GPGOAP, il est très simple de construire un pseudo fichier de conf qui soit convertible aisément en langage dot (graphviz) pour générer un graph des actions. La lib fournit également des outils pour aider le debug.
[^] # Re: Bof
Posté par David Delassus (site web personnel) . Évalué à 5. Dernière modification le 11 janvier 2024 à 22:26.
J'avais fait cette lib pour répondre à un besoin personnel, et j'ai décidé de la publier même non finie au lieu de la laisser pourrir sur mon pc.
C'est réellement pas mon problème. C++20 et C++23 apportent beaucoup de fonctionnalités très intéressante, je vois pas pourquoi je m'en priverais.
Tu as réussi a inférer mes raisons simplement en lisant le code ?
La raison c'est que je ne voulais aucune dépendance. Le langage de base me fournit tout ce dont j'ai besoin, je ne vois pas pourquoi j'irais chercher ailleurs.
Oui, parce que l'inférence de type c'est bien.
Ca c'est le premier point ou je suis d'accord. Mais j'ai eu des problèmes avec unique_ptr:
Cela m'obligerait donc a créer le std::vector, faire des
push_backavecstd::move, et ensuite std::move le std::vector au constructeur qui en a besoin, chiant.Alors oui, j'ai pris l'option de facilité, utiliser shared_ptr, ça marche bien.
Libre à toi de faire une PR, c'est ça aussi l'opensource.
Et pour finir :
C'est bien, personne ne t'oblige à l'utiliser.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Bof
Posté par freem . Évalué à 2. Dernière modification le 03 mars 2024 à 17:59.
Je pense que j'ai mal exprimé un truc. Si j'ai pris le temps de répondre, c'est déjà que je trouve la chose intéressante (j'ai pertinenté le lien de mémoire, mais je ne peux que prouver avoir voté).
Pour moi, ce site a un gros bon point: il inclue pas mal de vulgarisation sur un sujet qui semble peu connu globalement. Par exemple, pour goap, qui est je pense une avancée majeure (de 20 ans d'âge), je ne l'ai vu implémenté dans aucun jeu libre dont j'aie lu le code pour l'instant (plusieurs FPS, quelques jeux de stratégie).
Le "bof" que j'aurai clairement du lire, et relire au moins 7 fois, est… oui, je pense: mesquin.
Forcément, un titre pareil ne donne pas envie d'être poli.
Je te demande pardon.
Mais la STL est une dépendance, régulièrement non appréciée pour diverses raisons plus ou moins valides (temps de compilation, taille du binaire notamment liée à l'obligation de supporter les exceptions ou de se passer totalement de mécanismes d'erreur, debug pénible à cause des 150 couches de template, etc)
Discutable pour moi, mais bon.
Vu que je suis en train de bosser sur un outil pour gpgoap, justement, ça serait envisageable.
Pour les autres je vais avoir la flemme par contre, d'autant que behaviortree.cpp dispose déjà d'un tel outil.
[^] # Re: Bof
Posté par David Demelier (site web personnel) . Évalué à 5.
Bienvenue dans le monde moderne. Si on doit attendre que tout le monde soit prêt alors on fait du C++20 en 2040. Je chouine pas quand un projet demande une version récente de rust, soit je m'adapte soit je laisse tomber mais je blâme pas les développeurs qui prennent les outils disponibles. La volonté de s'adapter est propre à l'utilisateur. Sinon on innove jamais. Tout le monde criait au scandale quand on a enlevé les lecteurs de disquette spuis de CDs et maintenant plus grand monde en utilise. C'est pareil dans les langages, si on prend pas de parti pris on avance pas et je suis bien content qu'en C++17 on puisse enfin parcourir des répertoires avec la bibliothèque standard sans passer par boost ou une douzaine de
#ifdef.Ah donc quand on fait du C++ on doit pas utiliser la bibliothèque standard qui est implémentée nativement et optimisée sur chaque plateforme ? Pareil en C ? en C# ? en python ? en rust ?
Commentaire vivement subjectif.
git is great because linus did it, mercurial is better because he didn't
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.