Sinon, il serait préférable de ne pas faire hériter une structure d'entité à une autre entité (mob et player dans ce cas). Cela n'aurait en effet pas beaucoup de sens, on utilise l'encapsulation pour regrouper des données afin de créer un nouvel objet. L'objet player_info n'a aucune raison d'hériter de mob_info. Si tu veux tout de même faire un héritage, quelque chose comme ceci serait plus approprié :
struct common {
position _position;
size _size;
speed _speed;
animation_info _animation;
...
};
struct mob_info : common {
...
};
struct player_info : common {
...
};
De sorte à ne pas mélanger ce qui n'a pas de raison d'être mélanger.
Pour le nom de tes champs, c'est à toi de voir, tant que tu respectes les critères que tu t'es imposé
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Point d'héritage dans un ECS : il n'y a qu'agrégation
Par contre, il n'y a pas forcément besoin de dupliquer des informations non plus, vu que chaque composant sera en théorie associé à une entité particulière.
Du coup, tu peux tout à fait envisager d'avoir un composant de type mob_infos pour ceux qui peuvent s'en contenter et un composant (tu trouveras le nom toi même) "supplémentaire" qui contienne les informations "manquante", destiné aux entités qui ont besoin de cette information particulière.
Par la suite, il "pourrait" suffire d'un test sur les différentes entités destiné à savoir de quel composant elle dispose pour savoir... comment traiter les données représentées par les différents composants
NOTA: L'underscore en prefixe est une très mauvaise idée, car c'est "réservé" par la norme...
De plus, comme tu as de toutes manières affaire à des structures (qui exposent donc les données qu'elles contiennent dans l'accessibilité publique), tu n'a pas vraiment besoin de rajouter des fioritures (préfixe ou suffixe) aux noms des données en question.
Pourquoi ne pas te contenter de noms correspondant simplement à la donnée que les éléments représentent?
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Il y a méprise, je vous ai mener sur la piste que ces deux structures sont des composant, ce qui n'est pas le cas. En voulant donner le contexte, j'ai embrouiller le sujet principal. Ces deux structures ne sont pas des composants, elles ont pour but de servir a la création des entités, et sont detruites une fois utiliser, elles ne servent qu'a initialiser le niveau.
Ce qui me rassure, c'est que si ça avait été des composants, j'aurais opter pour ta solution Koala, ce qui signifie que mon ECS ne doit pas être complètement incohérent
Pour ce qui est du nommage des données, je vais donc courir virer ces underscores. Par contre j'ai du mal a comprendre cette phrase :
"Pourquoi ne pas te contenter de noms correspondant simplement à la donnée que les éléments représentent?"
Je souhaitais rajouter des prefixes/suffixes parce que je ne trouve pas cela tres clair dans un code comme celui-ci :
Je n'ai pas trouver un autre moyen de nommer la donnée "speed", et j'ai toujours du mal a nommer une donnée/un objet/une variable du même nom que son type, cela pose-t-il un réel problème pour maintenir de plus gros projet ? (sinon le problème est vite regler, pas de fioriture, c'est plus simple pour tous le monde)
Tu n'as qu'à nommer tes types autrement dans ce cas.
Moi je nomme toujours mes types avec une majuscule, de sorte à en faire ressortir l'importance, ou alors je dis explicitement que c'est un type avec un underscore + t (_t) :
using Speed = float;
using speed_t = float;
Pour speed, ça pourrait donner ça :
using Speed = float;
struct player_infos {
Speed speed;
};
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Il y a méprise, je vous ai mener sur la piste que ces deux structures sont des composant, ce qui n'est pas le cas. En voulant donner le contexte, j'ai embrouiller le sujet principal. Ces deux structures ne sont pas des composants, elles ont pour but de servir a la création des entités, et sont detruites une fois utiliser, elles ne servent qu'a initialiser le niveau.
Cela ne change rien : même s'ils ne sont que temporaires, ou -- d'une manière ou d'une autre -- destinés à servir de "modèle", ce sont toujours bel et bien des ... composants...
C'est là toute la beauté de la chose: dés que tu parles de donnée, tu parles de composant, dans un ECS. Même si tu utilises, par la suite, ces composant sous une forme "flyweight", parce que le composant en question fournit les données graphiques destinées à alimenter un sprite, et que ce sprite est utilisé par différentes entités
K4kugen a écrit:
Pour ce qui est du nommage des données, je vais donc courir virer ces underscores. Par contre j'ai du mal a comprendre cette phrase :
"Pourquoi ne pas te contenter de noms correspondant simplement à la donnée que les éléments représentent?"
Elle était surtout destinée à aller avec les phrases précédentes qui concernaient les underscore, à leur donne plus de "vigueur"
K4kugen a écrit:
Je souhaitais rajouter des prefixes/suffixes parce que je ne trouve pas cela tres clair dans un code comme celui-ci :
Je n'ai pas trouver un autre moyen de nommer la donnée "speed", et j'ai toujours du mal a nommer une donnée/un objet/une variable du même nom que son type, cela pose-t-il un réel problème pour maintenir de plus gros projet ? (sinon le problème est vite regler, pas de fioriture, c'est plus simple pour tous le monde)
Merci pour votre aide
On ne peut qu'approuver l'idée de créer un alias de type, et, pour résoudre ce problème, peut-être "suffit-il" de désigner clairement le type speed comme étant... un identifiant de type.
C'est, d'une certaine manière, tout l'avantage qu'il y a à choisir la convention de nommage dite UpperCamelCase, car on peut alors faire la différence entre le type nommé Speed et la donnée nommée speed. Tu as choisi la convention underscored, et ce n'est pas un mauvais choix, mais cela rend les chose un peu plus compliquée.
Une solution pour faire la différence pourrait être de nommer le type sous la forme de speed_type (ou -- plus simplement -- sous la forme de speed_t )
Cependant, poses toi peut-être la question qui fâche : comme un tel alias de type ne t'empêchera absolument pas de transmettre "n'importe quelle donnée de type float" (pas même une donnée dont le type serait un autre alias de type que speed_t pointant équivalent au type float) lorsque tu t'attends à recevoir une donnée de type speed_t, quel intérêt as-tu réellement à créer cet alias de type?
Autrement dit, le choix judicieux du nom de ta variable (ou de ton paramètre) n'est-il pas "plus que suffisant" que pour t'éviter de vouloir utiliser une donnée "aberrante" là où tu t'attends à recevoir une vitesse?
Albert Einstein a dit
Rendez les choses aussi simples que possible, mais pas plus simples
Dans le cas présent, le fait d'utiliser un float n'est il pas la mise en pratique de cette phrase?
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
GitHub
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
GitHub
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
GitHub