Bonjours a tous,

Dans ma quête de créer un petit jeu 2D, je me retrouve a utiliser des structures pour mon ECS

J'ai deux structures :

struct mob_infos
{
	position _position;
	size _size;
	speed _speed;
	animation_infos _animation;
	std::string _sprite_path;
};

struct player_infos
{
	position _position;
	size _size;
	speed _speed;
	animation_infos _animation;
	std::string _sprite_path;
	std::string _map_path;
	//...
};

Comme vous pouvez le voir, la structure player_infos reprend tous les attributs (si c'est le bon terme) de mob_infos, et en a en plus

Voila donc ma question : est-il ici juste de faire hériter player_infos de mob_infos ?

Une question plus mineur que je me posais, il y a-t-il un problème a nommer les attributs des classes :

std::string _sprite_path;

Ou faut-il preferer :

std::string sprite_path;

J'utilise l'underscore pour pouvoir différencier type et nom sur des cas comme :

speed _speed

Sinon j'utiliserais comme pour les classe le préfixe "m_"

Merci d'avance pour votre aide / lecture

Salut,

certains conseillerons de ne pas faire d'héritage dans la conception d'un jeu

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é

Salut,

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?

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 :

using speed = float;

struct player_infos
{
   speed speed;
   //...
};

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 

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;
};

K4kugen a écrit:

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 :

using speed = float;

struct player_infos
{
   speed speed;
   //...
};

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?

C'est noter, merci a vous deux pour votre aide

Pour les types le nécessitant, je vais ajouter le suffixe "_t" comme conseiller, et je retiens la convention de nommage UpperCamelCase

Encore merci