Meilleure façon d'intégrer des données constantes dans un code-source

Bonjour :) ,

Depuis que je code des jeux en C++, je suis toujours confronté au même problème : à un moment ou à un autre, je dois implémenter une classe qui va représenter une grande variété d'objets différents. Disons par exemple que je code un RPG et que je code une classe LivingEntity. Cette classe doit représenter toute chose vivante au sein de mon jeu. Cette classe possède donc des attributs pour représenter les points de vie de l'entité, sa position dans le monde...

Sauf que dans mon jeu, comme dans tout jeu qui se respecte, il n'y a pas qu'un type d'entité. Il y en a plein : Des zombies, des monstres plus ou moins variés...

Et une des caractéristique que je veux donner à mes entités est que, toutes les entités qui partagent le même type, doivent partager certaines caractéristiques basiques (comme des valeurs de dégats, un pointeur vers la texture à utiliser pour afficher l'entité...)

Donc j'ai défini un enum EntityType qui contient quelques valeurs, comme PLAYER, ZOMBIE, DEMON..., et j'ai rajouté un attribut EntityType dans ma classe LivingEntity. Le problème, c'est que je ne sais pas où stocker les valeurs qui seront partagées par toutes les entités du même type. J'avais pensé à créer une structure qui contiendrait toutes ces valeurs, et à créer un tableau global de ces structures, de sorte à avoir une syntaxe de la forme :

Code:

---

monster[ZOMBIE] = {10, 5, "zombie.png"}

---

Mais cette solution n'est vraiment pas élégante. Auriez-vous des suggestions à me proposer ?

Merci ! :D

Bonjour,

Si des monstres sont du même types, ils peuvent hériter d'une classe commune contenant des variables statiques.

Tu peux aussi, dans un design pattern stratégie, déclarer des variables statique dans tes classes de stratégie.

Ex :
Mobs contient une constante X.
Ange hérite de Mobs et défini des constantes X et Y.
Démon hérite de Mobs et défini des constantes X et Z.

Après, il te faut juste des getters virtuels pour récupérer la valeur de la constante que tu définira à chaque fois que tu veux, dans une classe fille, changer la valeur de la constante pour la classe fille et les filles de la classe fille.

En effet, c'est pratique quand on a 3 types de mobs, pas quand on en a une centaine :mrgreen:

Généralement quand on a beaucoup de monstres différents, je pense qu'on va créer une classe mobs générique et stocker les données dans des fichiers.
Pour les "constantes", un simple fichier texte à charger et pour les stratégies, de simples scripts interprétés (ou des plugins/dll).

Il suffit alors d'avoir une factory de monstre prenant en paramètre le type de monstre à construire (un identifiant -Nombre entier (?)-) avec un proxy pour éviter d'aller lire les fichiers à chaque création de monstre.

Ainsi tu pourras ajouter/enlever/modifier des monstres sans recompiler ton programme (très pratique pour des mises à jours).

Je ne connaissais pas le proxy pattern, merci, je vais regarder :ccool: .

autre possibilité, un monstre_type, qui définit les données du jeu, et sera obtensible dans une factory/map
et un monstre, qui à une référence/un identifieur vers un monstre-type.

Tu auras une centaine d'objet monstre_type, mais une seule classe, et autant d'objets de la classe monstre que de monstres sur la carte.

Ainsi, tu n'as qu'une centaine de texture, plutot qu'un million.

j'appelle ca le schéma descriptor, mais je ne sais pas si c'est le nom officiel, ou meme si ca fait partie des habitudes.

C'est exactement ce que je voulais, merci ! :)

Citation:

---

Envoyé par Marxed

Bonjour :) ,

Depuis que je code des jeux en C++, je suis toujours confronté au même problème : à un moment ou à un autre, je dois implémenter une classe qui va représenter une grande variété d'objets différents. Disons par exemple que je code un RPG et que je code une classe LivingEntity. Cette classe doit représenter toute chose vivante au sein de mon jeu. Cette classe possède donc des attributs pour représenter les points de vie de l'entité, sa position dans le monde...

---

Ouh la!!!!

Tu n'as pas l'impression de donner (beaucoup) trop de responsabilité à ton entité vivante :question:

Car, si on prend une pierre ou un mur, c'est très clairement une entité positionnable (elle peut se positionner sur la carte, afin d'être affichée), mais on peut difficilement estimer qu'il s'agisse d'une entité vivante (elle n'a pas de point de vie) ni attaquable (elle ne subit pas de dégats) ni déplaçable (elle ne bougera jamais) ni même attaquante (elle n'attaquera jamais ton héros).

L'idéal est donc sans doute de créer un ensemble de petites interfaces de base ne donnant la possibilité de ne faire qu'une seule chose.

Tu aurais donc, de manière non exhaustive:

• PositionableEntity (permet de représenter la position de l'objet, dont hérite quasiment tout)
• LivingEntity (permet de représenter les points de vie de l'objet, son état "vivant" ou "mort", dont n'hérite que... ce qui est vivant)
• AttackableEntity (permet de représenter les objets que l'on peut attaquer, qui peuvent subir des dégats, dont n'héritent que ce qui est vivant et attaquable)
• AttackEntity (permet de représenter les objets qui peuvent attaquer, qui peuvent occasionner des dégats)
• UsableEntity (permet de représenter tout ce qui peut etre utilisé (objets d'inventaire, sort, armes, ...)
• LevelableEntity (permet de représenter tout ce qui est modifié par un niveau éventuel)

Si tu veux définir une classe concrète (par exemple un zombie), tu n'as qu'à le faire hériter de positionnable, de living, d'attackable, d'attack et de levelable, libre à toi de redéfinir les fonctions "qui vont bien" pour le zombie en question (par exemple : on pourrait dire qu'un zombie est toujours de niveau 2 ;))

Par contre, selon le gameplay, si tu veux créer une classe "potion", tu ne la feras sans doute hériter que de "usable"(afin de pouvoir l'utiliser), et éventuellement de "positionnable" (si elle ne rentre pas directement dans ton inventaire).

De cette manière, tu pourras "assez facilement" créer une collection d'objet "positionnable" (dont tu auras besoin pour l'affichage) et une série de collections d'objets divers en fonction des besoins de ton jeu.

Tu pourrais donc carrément envisager la création d'un groupe de cadavres putréfiés et de le placer quelque part si tel était ton plaisir ;)

Citation:

---

Sauf que dans mon jeu, comme dans tout jeu qui se respecte, il n'y a pas qu'un type d'entité. Il y en a plein : Des zombies, des monstres plus ou moins variés...

---

A n'en pas douter ;)

Citation:

---

Et une des caractéristique que je veux donner à mes entités est que, toutes les entités qui partagent le même type, doivent partager certaines caractéristiques basiques (comme des valeurs de dégats, un pointeur vers la texture à utiliser pour afficher l'entité...)

---

A priori, la texture d'affichage n'a strictement rien à voir avec la donnée "métier" de tes différents monstres.

Elle n'est, en effet, utile que lorsqu'il s'agit d'afficher tes objets, et ce devrait presque être (pour bien faire) un module séparé.

Rien ne t'empêche de créer un tableau mettant en relation une entité positionnable d'une part et une texture d'autre part afin de pouvoir afficher tes différents éléments, mais il n'y a strictement aucune raison de faire en sorte que tes différentes entités disposent d'une texture (essayes d'appliquer le MVC ;))

Citation:

---

Donc j'ai défini un enum EntityType qui contient quelques valeurs, comme PLAYER, ZOMBIE, DEMON..., et j'ai rajouté un attribut EntityType dans ma classe LivingEntity.

---

A priori, tu n'en as pas besoin!

Pour autant que, dans une situation donnée, tu dispose de l'interface "qui va bien" (par exemple: une fonction virtuelle void attack(*LivingEntity) ) et que tu la redéfinis en fonction de l'élément qui va devoir attaquer (donc, pour un zombie et pour un cadavre putréfié), il faut te dire que l'élément en question saura d'office s'il est un cadavre putréfié ou un zombie.

Tu ne devrais donc jamais avoir à transtyper un objet de type générique ("AttackEntity" par exemple) en un objet de type particulier (Zombie, par exemple) afin de lui permettre d'attaquer ;)

De même, si tu veux pouvoir afficher "zombie" ou "cadavre putréfié" de temps en temps, tu ne devrais pas partir sur le principe d'un pseudo RTTI (RunTime Type Information) mais plutôt sur le principe d'un visiteur ;)

Citation:

---

Le problème, c'est que je ne sais pas où stocker les valeurs qui seront partagées par toutes les entités du même type. J'avais pensé à créer une structure qui contiendrait toutes ces valeurs, et à créer un tableau global de ces structures, de sorte à avoir une syntaxe de la forme :

---

Code:

---

monster[ZOMBIE] = {10, 5, "zombie.png"}

---

Tu les stockes "là où tu en as besoin", c'est à dire dans la classe qui les manipule.

Si les valeurs sont strictement identiques "quel que soit l'instance envisagée", tu peux envisager de les déclarer comme des membres statiques, de manière à ce que la valeur soit partagée par toutes les instances de ta classe, sans dépendre d'une instance particulière ;)

Je n'ai pas tout lu mais je pense que des que tu pars sur de l'heritage de cette facon pour faire des jeux, tu es dans l'erreur absolue.

Conseil: jettes un oeil a comment on fait un systeme de composants ("Component-based game entity system" dans google ou quelque chose comme ca)
Ca vaut le coup a partir d'une certaines complexite que tu sembles atteindre.

Il n'est vraiment pas bon pour le future du code de tes jeux de faire des hierarchies pour definir les types d'objects ou comportements.

Citation:

---

Envoyé par koala01

Tu aurais donc, de manière non exhaustive:

• PositionableEntity (permet de représenter la position de l'objet, dont hérite quasiment tout)
• LivingEntity (permet de représenter les points de vie de l'objet, son état "vivant" ou "mort", dont n'hérite que... ce qui est vivant)
• AttackableEntity (permet de représenter les objets que l'on peut attaquer, qui peuvent subir des dégats, dont n'héritent que ce qui est vivant et attaquable)
• AttackEntity (permet de représenter les objets qui peuvent attaquer, qui peuvent occasionner des dégats)
• UsableEntity (permet de représenter tout ce qui peut etre utilisé (objets d'inventaire, sort, armes, ...)
• LevelableEntity (permet de représenter tout ce qui est modifié par un niveau éventuel)

Si tu veux définir une classe concrète (par exemple un zombie), tu n'as qu'à le faire hériter de positionnable, de living, d'attackable, d'attack et de levelable, libre à toi de redéfinir les fonctions "qui vont bien" pour le zombie en question (par exemple : on pourrait dire qu'un zombie est toujours de niveau 2 ;))

---

Je partirais aussi sur ce genre d'interfaces, mais j'aurais seulement une classe "Monster" derrière (ou "Item" pour l'exemple de la potion), je ne pousserais pas ça jusqu’à obtenir 1 classe par monstre.

Faire des classes pour des monstres spéciaux (genre boss) qui pourraient être vraiment différent, ok, mais pas pour tous.

@OP, Sinon stocker toutes les stats etc.. dans des fichiers, puis tu peux utiliser une factory. :)

Citation:

---

Envoyé par Iradrille

Je partirais aussi sur ce genre d'interfaces, mais j'aurais seulement une classe "Monster" derrière (ou "Item" pour l'exemple de la potion), je ne pousserais pas ça jusqu’à obtenir 1 classe par monstre.

Faire des classes pour des monstres spéciaux (genre boss) qui pourraient être vraiment différent, ok, mais pas pour tous.

@OP, Sinon stocker toutes les stats etc.. dans des fichiers, puis tu peux utiliser une factory. :)

---

A vrai dire, je m'étais contenté de reprendre son exemple, sans trop réfléchir à la classe concrète que l'on pourrait créer.

Ce sur quoi je voulais attirer l'attention, c'était surtout sur le fait que, lorsque tu te retrouves avec une classe qui fait le café, la vaisselle, la lessive et qui sort le chien, il y a de fortes chances pour qu'il soit beaucoup plus intéressant de travailler avec des interfaces séparées.

Mais, de fait, on pourrait n'avoir qu'une seul classe Monster, pour laquelle on définirait une chaine de caractères (pour l'affichage uniquement) chargée au lancement ;)

Bonjour,

Citation:

---

Envoyé par Klaim

Je n'ai pas tout lu mais je pense que des que tu pars sur de l'heritage de cette facon pour faire des jeux, tu es dans l'erreur absolue.

Conseil: jettes un oeil a comment on fait un systeme de composants ("Component-based game entity system" dans google ou quelque chose comme ca)
Ca vaut le coup a partir d'une certaines complexite que tu sembles atteindre.

Il n'est vraiment pas bon pour le future du code de tes jeux de faire des hierarchies pour definir les types d'objects ou comportements.

---

C'est en fait une "super" Factory ??

Ça donne apparemment une très grande flexibilité qui serait peut être utile pour faire un de kit de développement ou des projets avec beaucoup de monde ?!

Si une/un application/jeu est bien définit au début de sa conception, avec cette méthode ne peut on pas au contraire perdre en lisibilité ou en performance ?

D'ailleurs tellement de gens parlent de factory, je commence à croire que c'est indispensable..

Citation:

---

Envoyé par PilloBuenaGente

Si une/un application/jeu est bien définit au début de sa conception, avec cette méthode ne peut on pas au contraire perdre en lisibilité ou en performance ?

---

Lisibilité je pense pas, tant que les "Components" sont bien documentés, ça devrait pas poser de soucis.
Niveau performance, un appel de fonction d'un "component" est légèrement plus coûteux :
* récupérer le component (soit on à un pointeur / réf directement, soit on doit passer par un find dans une map/unordered_map)
* après c'est un appel de fonction standard (très probablement virtuel).

Il y a cependant moyen de stocker l'adresse de la fonction voulue si les performances posent problème.

Sauf cas particulier, je ne pense pas que le surcoût soit tel qu'on serait prêt à sacrifier la généricité de ce genre de système. :)

Au niveau de la communication entre composants, 3 choix,
* soit une variable membre dans la classe hôte (utile quand toutes les classes possèdent les mêmes composants)
* soit des composants qui contiennent une réf / pointeur vers un autre composant (utile quand 2 composants sont "forcément" liés)
* sinon par un système de messages (plus long, mais les composants ne sont plus liés du tout)

Mais ici pas de perte de performances normalement, que ce soit codé avec des composants ou autrement, les classes devront toujours communiquer entre elles.

Citation:

---

Envoyé par PilloBuenaGente

Bonjour,


C'est en fait une "super" Factory ??

Ça donne apparemment une très grande flexibilité qui serait peut être utile pour faire un de kit de développement ou des projets avec beaucoup de monde ?!

Si une/un application/jeu est bien définit au début de sa conception, avec cette méthode ne peut on pas au contraire perdre en lisibilité ou en performance ?

---

Si la question porte sur la fabrique, certes non!!!

Déjà, la fabrique intervient lorsqu'il s'agit de créer des objets.

Même en ayant beaucoup d'objets à créer "à peu près n'importe quand", tu passeras de toutes manières plus de temps à les manipuler qu'à les créer ;)

Quant à la lisibilité, c'est bien simple : une fabrique se contente... de fabriquer des objets, et c'est bel et bien tout ce qu'on lui demande ;)

Le code pour y arriver est, généralement, suffisamment simple à lire par lui même :D

Par contre, le patron de conception apporte un énorme avantage:
Le seul endroit (hors visiteurs éventuels) où il faille connaitre "toutes la hiérarchie" des classes, c'est au niveau de la fabrique.

Partout ailleurs, on ne doit connaitre qu'une (partie d') interface ;)

Citation:

---

D'ailleurs tellement de gens parlent de factory, je commence à croire que c'est indispensable..

---

Peut etre pas, mais presque.

Ce qui est sur, c'est que tu n'as besoin de connaitre que la classe de base lorsque tu fais appel à la fabrique.

Tu n'es donc pas lié par une dépendance quelconque envers les classes dérivées, et, par voie de conséquence, tu n'es pas tenté d'essayer de transtyper ton pointeur (ou ta référence): tu utilises "autant que faire se peut" l'interface de la classe de base.

Si, à un moment quelconque, tu te retrouves face au besoin de savoir spécifiquement si tu es confronté à un type dérivé plutôt qu'à un autre, tu feras sans doute appel au patron de conception "visiteur" (par exemple) ;)

Citation:

---

Envoyé par PilloBuenaGente

Bonjour,


C'est en fait une "super" Factory ??

Ça donne apparemment une très grande flexibilité qui serait peut être utile pour faire un de kit de développement ou des projets avec beaucoup de monde ?!

Si une/un application/jeu est bien définit au début de sa conception, avec cette méthode ne peut on pas au contraire perdre en lisibilité ou en performance ?

D'ailleurs tellement de gens parlent de factory, je commence à croire que c'est indispensable..

---

Je suis pas certain que tu ais bien compris le concept...

L'idee est separer les differents "composants" d'une entitee et de les rassember sois sous le meme identifiant, sois sous le meme objet (ce qui reviens au meme mais selon les manips reguliere que l'on fait ca peut avoir un impact sur les performances).

Donc en gros un "composant" c'est un ensemble donnees et comportement. Tu peux avoir un composant CorpsPhysique, un composant Graphics, etc. ensuite tu composes tes entitees selon les besoins qu'ils ont, definis par le gameplay.

Oui c'est plus utile pour un moteur generaliste, mais en fait des le moment ou il peut y avoir des tas d'objets differents et que tu as pas un gameplay fixe niveau level design, ca deviens necessaire d'avoir cette flexibilite, en particulier pour permettre de facilement composer de nouveaux types d'entitees de jeu.

Ensuite, dans le cas ou tu as une connaissance fixe des elements du jeu (ce dont je doute vu tes questions, contrairement a ce que tu dis tu pars dans un truc qui va carrement sortir de ta vision du jeu), tu peux toujours tenter d'avoir differents elements bien fixes, une classe par categorie d'entitee.
EN REVANCHE, si tu utilises l'hjeritage pour definir le comportement TU ES DANS D'ERREUR.

C'est un classique dans l'industrie du jeu d'ailleurs, les moteurs Unreal en ont fais les frais pendant des annees et c'est pas les seul. L'heritage est fortement inaproprie pour composer les comportements. Tu as mieux fais de composer tes entites avec des types qui representent les differents comportements, et d'avoir juste une interface comune pour les faire communiquer... ce qui reviens a un systeme de composants.

Je noterai que dans lejeu que je fais actuellement, tous les types d' entitees du jeu (dans mon cas on peut les compter sur les doigts d'une main) sont des classes concretes avec un comportement pre definis. Chacune de ces classes peut ou pas avoir un (smart) pointeur vers une entitee graphique ou audio qu'elle manipule (plus ou moins du MVC si tu veux). Ces entitees graphiques ou audio sont de classes specifiques et n'ont pas besoin d'heriter de quoi que ce soit, vu qu'ils ont chacun un comportement different (ou sinon tu utilises le meme type). Bref, le comportement est pas definis par l'heritage, mais bien pas un type qui manipule les autres (de la meme facon que dans un jeu de strategie, une ia va definir une action globale, et a partir de la les ias des unitees vont chacun definir leur propre action).

Tu as besion de factory pour construire les niveaux selon un fichier qui le decris, donc je comprends pas de quoi tu parles.
Moi ce que je dis c'est vraiment: n'utilises jamais l'heritage pour composer du comportement. Ca va rendre ton code impossible a lire. J'ai fait cette erreur pendant des annees avant de totalement changer de perspective, avec beaucoup de benefices.

Je te conseille vivement de recuperer "Game Engine Architecture" qui est un livre qui fait le tour des pratiques en cours sans specialement en recommander une, mais explique les points positifs et negatifs de chaque pratique. Il y a un gros chapitre sur comment organiser ses donnees niveau gameplay, en particulier pourquoi l'heritage est tout pourris pour composer des comportements, et quelles sont les autres manieres de faire plus ou moins hybrides qui sont courantes.

Bref, la discussion sur l'arbre l'heritage pour definir tes comportements d'entitees de jeux m'horripile au plus au point. 8O

EDIT> Ah oui et derniere chose: Faire un jeu c'est explorer un concept (sauf si tu clones). Ca veut dire que tu dois pas t'attendre a comprendre a ll'avance avant de l'avoir realiser tout ce que va comporter ton jeu comme elements de jeu. C'est pour ca que t'as tout interet a avoir sios un moteur deja pret, soit un systeme simple mais flexible pour pouvoir adapter le code du jeu a ta vision qui changera necessairement au fil du developpement.
C'est important de le souligner parceque trop de devs partent du principe qu'ils vont juste decrire le jeu dans un document et tout sera suivi a la lettre (meme quand l'equipe est d'1 personne). C'est une pratique autement ridicule et qui ne se fait plus trop dans le milieu du jeu (sauf peut etre en France vu qu'on est toujours en retard sur ce plan la) et maintenant on part plus d'un concept de base, definis simplement, suffisamment vague pour qu'on puisse explorer l'idee a partir des prremiers prototypes, des versions simples, mais aussi suffisamment precis sur les principes de base pour qu'on puisse construire une premiere version rapidement.