Conception de classe RPG

Bonjour,

Sans plus attendre, voici mon bout de code (et oui, je suis un mec comme ça moi) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

#include <iostream> #include <vector>   enum { CRUSHING, SLASHING };   int dice(int sides) { return (rand() % sides + 1); }   struct Weapon { int damageType;   virtual int damage() = 0; };   struct HAMM01 : Weapon { HAMM01() { damageType = CRUSHING; }   int damage() { return dice(4) + dice(4); } };   struct SW1H01 : Weapon { SW1H01() { damageType = SLASHING; }   int damage() { return dice(6); } };             int main() { srand(time(0));   std::vector<Weapon*> weapons;   weapons.push_back(new HAMM01); weapons.push_back(new SW1H01);   std::cout<<weapons[0]->damage();   return 0; }

---

L'idée est simple : on a un marteau, qui inflige 2 dés 4 points de dégât contondant, et une épée, qui inflige 1 dé 6 points de dégât tranchant. Le but du jeu, c'est de coder la chose le plus proprement possible, et le plus lisiblement possible surtout. J'ai choisi l'héritage parce que les armes peuvent avoir des effets très différents de l'une à l'autre, et j'ai pensé que pour garder la plus grande souplesse possible dans mon code, le plus simple était encore d'écrire la fonction damage() à la main, pour chaque arme. Ça ne parait pas justifié dans mon exemple, ici, un vector stockant les jets de dé aurait amplement suffi. Mais imaginez qu'à chaque coup porté, la cible ait 5% de chance d'être aveugle pendant 3 rouds.. On ne s'en sort plus.
Ce code est à peu près cohérent, je pense, mais quelque chose m'embête : on a donc une structure par arme, et je ne trouve pas ça très "propre" : le bon sens voudrait qu'on ait une structure la plus souple possible (appelons la "Arme", qu'on crée une première instance de cette structure appelée "marteau", une deuxième, "épée", et qu'on précise, pour chaque instance, les modalités du combat (toi tu infliges 2 dés 4, toi 1 dé 6). Mais là je me mords la queue : et si une arme rend l'ennemi aveugle pendant.. Bref.
Une alternative envisageable serait de créer effectivement cette structure Arme, et que l'un de ses membres soit un pointeur sur une fonction, dans ce cas il faudrait créer plein de fonctions de dommage (dommage1(), dommage2(), etc) et, une fois que l'on a créé les instances de la classe, faire pointer ces pointeurs sur la bonne fonction. Par exemple :

Code:

---

1 2 3 4 5 6 7

Arme marteau; marteau.damageFunction = damageFunction1; marteau.damageType = CRUSHING;   Arme épée; épée.damageFunction = damageFunction2; épée.damageType = SLASHING;

---

Mais la lisibilité du code n'est pas terrible, on se retrouve avec plein de fonctions de dommage en tête de mon fichier, sans trop savoir à quoi ça correspond ni à quelle arme cette fonction de dommage est associée. Alors qu'avec mon code qui utilise le polymorphisme, c'est clair tout de suite.

Bref, je suis un peu torturé par tout ça, si un expert passe par là et qu'il a un conseil à me donner, je prends !

Cordialement,

La question a été posée ... en Java ;) Édit: Conseils conception logiciel

L'intervenant comme toi voulait faire du polymorphisme/ héritage pour un jeu mais ne voulait pas passer par des traits ou autres [j'ai vu passé le terme de mixin mais pas sûr de sa définition].

La raison aussi été la même: pleins de classes à coder/ maintenir. Il a tout à fait raison, mais on peut passer des valeurs par défaut en C++ :whistle:

La solution: une classe générique avec un parser de fichier XML/ CSV/ json/ autre [même peut-être à tester base de données] qui contient toutes les valeurs.
Un exemple en XML

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

<root> <weapon name="HAMM01" damage="CRUSHING"> <damage nb="2"> <dice>4</dice> <dice>4</dice> </damage> </weapon> <weapon name="SW1H01" damage="SLASHING"> <damage nb="1"> <dice>6</dice> </damage> </weapon> </root>

---

J'ai oublié de dire que les experts du forum avait opté pour cette solution parce qu'il n'y avait que des attributs, et en petit nombre.

Je viens de regarder la discussion dont tu as envoyé le lien, je ne suis pas très habitué (pas du tout même) à utiliser des fichiers externes pour la création de mes classes. Il me vient déjà une question : imaginons que je crée une arme dont les dégâts seraient doublés lorsqu'elle est utilisée contre une certaine classe. Genre "super épée de la mort anti paladin". Ce comportement est quelque chose de très original, un comportement qui, à mon avis (mais je peux me tromper), ne peut pas être géré par des fichiers XML, CSV, ou properties.. Si ?
Mais tant qu'à faire appel à des fichiers externes, je me suis à un moment posé la question de savoir si l'utilisation d'un langage de script ne pouvait pas être utile. Jusqu'à présent, je me suis débrouillé sans, mais peut être que c'est le moment de m'y pencher d'un peu plus près. Je pensais notamment au Lua, très facile à comprendre. J'aimerais avoir ton avis.

Cordialement,

C'est un travail pour le patron de conception ("design pattern") Visiteur/ Visitor :mrgreen:
Le lien qui va bien

En gros, tu as chargé une liste de tout ce qui peut être touché par une attaque (dont ta "super épée de la mort anti paladin")
Et tu vas coder

Code:

---

1 2 3 4 5 6 7 8 9

class Damage_Visitor { void visit(Game_Object obj); };     class Mega_Sword_Damage_Visitor: public Damage_Visitor { void visit(Paladin obj); };

---

Après on peut faire plusieurs fichiers externes (si c'est la solution retenue) dont un "damages" qui contient les dégâts spécifiques ;)

Sinon je ne connais pas LUA :whistle:

Merci pour le lien, jvais regarder tout ça ;)

Cordialement,

Salut,

Je comprend ton problème et je pense qu'on peut commencer par déplacer le problème. En effet tu peux créer une unique classe Arme qui possède un type de dégat et le montant des dégats. Comme tu l'as dit, ça pose problème vu que les armes peuvent avoir différent effets bien distincts les unes des autres. Dans ce cas, en découpant mieux, tu peux créer une classe Effect et chaque effets d'une arme héritera de cette classe, ainsi tu améliores la compositionabilité en gardant un nombre de classes réduits (plus 1 classe/arme mais 1 classe/effet). Ça donne :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

class Hero; // Représente un personnage héro. class Effect { virtual act(Hero) = 0; virtual ~Effect(); };   class BlindEffect : public Effect { private: double duration; double blindness;   public: BlindEffect(double, double); virtual act(Hero h); virtual ~BlindEffect(); };   class WeakenEffect : public Effect { private: double duration; double slowdown;   public: WeakenEffect(double, double); virtual act(Hero h); virtual ~WeakenEffect(); };   class Weapon { double damage; DamageKind kind; std::vector<std::unique_ptr<Effect>> effects;   public: Weapon(double, DamageKind); void addEffect(std::unique_ptr<Effect>&& effect); };   // Création d'une épée qui ralenti : Weapon sword(2, SLASHING); std::unique_ptr<Effect> weaken(new WeakenEffect(0.7, 50)); sword.addEffect(std::move(weaken));

---

Ce qui est bien c'est que tu peux ré-utiliser tes effets pour autres choses que les armes (l'environnement) et que tu as une combinaison infinie d'armes. Tu peux aussi ajouter des effets temporaires aux armes (bonus).

Cette histoire de trait, mixin me chiffonne parce que ce n'est pas l'idée que je me faisais du concept: un "sucre syntaxique" du langage qui permet de rajouter des méthodes à une classe en sachant que la majorité de ces dit-langages n'ont pas l'héritage multiple :koi: :koi:

Et j'ai trouvé: Présentation des classes de Traits et de Politiques en C++

Les traits en C++ utilisent massivement les templates pour adapter le comportement d'une fonction/ procédure/ méthode en fonction du type de l'objet.

@Trademark tu utilises la notion de rvalue reference qui est du c++11 et est assez difficile à appréhender pour un néophyte.
Mais peut-être que MrPchoun s'y connait :mrgreen:

En général, devant un tel type de problème, je me contente d'avoir une arme ayant des attributs tels que "noire", "coupante", "maudite", et je laisse une fonction/classe dédiée calculer les dégâts, en fonction de la cible.

Ca revient soit au visitor soit au décorator, selon la manière de faire.

Salut les jeunes, merci pour vos réponses. La solution de Trademark me plait beaucoup, j'avoue que je n'y avais pas pensé. Je vais creuser cette histoire de rvalue reference, en effet, je ne connais pas (faut dire que je suis passé au C++11 depuis deux ou trois mois à peine). Mais l'initialisation de la classe me plait, c'est propre, net, et clair (avec ça, s'il rougit pas, Trademark :oops:)

@foetus (et je réponds aussi à leternel) : du coup je suis allé chercher en quoi consistait le visitor pattern, et.. J'ai pas compris 8O En fait je ne comprends pas comment, avec ce schéma, on peut ajouter des méthodes à une classe. J'ai désespérément cherché une explication simple, mais j'ai pas trouvé. Même en UML, je pige pas le principe.. Mais cela dit, j'ai trouvé des implémentations simples en C++, mais je trouve que le code est pas évident au premier regard, alors que celui de Trademark l'est un peu plus (évidement, les design pattern c'est pas de ton niveau MrPchoun, retourne chez ta maman :aie:)

Cordialement,

Citation:

---

Envoyé par MrPchoun

@foetus (et je réponds aussi à leternel) : du coup je suis allé chercher en quoi consistait le visitor pattern, et.. J'ai pas compris 8O En fait je ne comprends pas comment, avec ce schéma, on peut ajouter des méthodes à une classe

---

Tu te fourvoies :mouarf: :mouarf:

Source Wiki:

Citation:

---

le patron de conception comportemental visiteur est une manière de séparer un algorithme d'une structure de données.

---

En gros c'est pour appliquer un traitement en parcourant un ensemble d'objets.
Le visiteur va demander à un objet accept(me).
Cet objet visité peut éventuellement envoyer cet appel à un ensemble d'objets qui le compose mais surtout, ensuite dire visit(me)

Le meilleur exemple c'est le sorcier qui crée un nuage "mortel" dans un champ de bataille.
Le nuage "mortel" est le visiteur qui va visiter tous les personnages ou autres touchés et ainsi le nuage "mortel" pourra adapter les dommages en fonction que le personnage touché est une protection plus ou moins efficace.


Et le décorateur/ décorator, c'est pour faire un traitement de façon transparente avant un autre traitement.
Par exemple un coup d’épée, cela fait mal.
Mais avec ta "super épée de la mort anti paladin", tu auras un coup d'épée normal décoré d'un effet plus "tranchant" :mrgreen:

Alors je vais poser plein de questions débiles..

1) "Tranchant", ici, c'est donc un decorator ?
2) Oui mais pourquoi tu me parles de decorator, là on parlait de visitor là nous 8O
3)

Citation:

---

Cet objet visité peut éventuellement envoyer cet appel à un ensemble d'objets qui le compose et ensuite dire visit(me)Et le décorateur/ décorator, c'est pour faire un traitement de façon transparente avant un autre traitement.

---

L'objet visité, ici, c'est l'épée ? Ou la classe Weapon ?

Sorry for noobing :mrgreen:

Cordialement,

EDIT : ah, merci pour l'exemple avec le nuage, ça commence à prendre du sens :) Du coup là, l'épée devient le visiteur, elle va visiter la cible, et si la cible est paladin, elle va doubler les dégats ? Et du coup, ce n'est que si la cible est un paladin qu'elle va dire visit me ?

Je ne suis pas convaincu par le visiteur ici. Ne serait-ce que parce que je ne suis pas convaincu de l'existence d'une classe Paladin (qui serait aussi mauvaise qu'une classe "EpéeA2MainsTueuseDeMoustiques").

Je pense que le mieux est de décomposer le calcul de dégâts en paramètres orthogonaux (par exemple dégâts de base, facteurs liés à la cible, facteurs liés à la combinaison type de dégâts/type d'armure, facteurs situationnels (une épée absorbant le sang qui marche mieux dans le désert)...) que sais-je encore) en nombre fini et identique d'une arme à l'autre.

Ensuite, on va piocher parmi ces paramètres un pour chaque type : par exemple, une épée de base 2d6, *2 contre les cibles alignées avec le bien (il va te falloir une classe liée à la cible vérifiant l'alignement de la cible), faisant des dégâts de type tranchant, et dégâts *2 quand utilisée la nuit (il va te falloir une classe liée à l'environnement testant à quelle heure on est)).

Je vois que ça part dans une discussion orienté design-pattern, alors je préfère te prévenir avant que tu fasses l'erreur. Il ne faut pas que tu essayes d'intégrer un design pattern, il faut juste que tu fasses ton design normalement et tu tomberas naturellement sur des problèmes qui seront résolu grâce à certain pattern. Évidemment ça aide de les connaitre avant :D

Pour ce qui est du visiteur, ça permet d'ajouter des traitements algorithmiques sur des structures de données (organisé en hiérarchie — avec une classe de base) sans avoir à ajouter de nouvelles méthodes dans les classes pré-existante. Par exemple si tu voulais que l'algorithme qui calcul les attaques ne soient pas une méthode de la classe Weapon, tu peux créer une classe annexe qui, pour chaque armes, calculera les dégats. Ainsi tu ne modifies pas les classes armes existantes pour ajouter une méthode. Tu peux ajouter d'autres traitement comme par exemple le calcul de la valeur d'une arme, etc. Note que ces traitements sont principalement algorithmique.

Citation:

---

Envoyé par MrPchoun

Alors je vais poser plein de questions débiles..

---

Non c'est normal :mrgreen:

Je rejoins Trademark: ce ne sont que des exemples, et cela va dépendre de comment tu vas coder/ concevoir ton jeu en fonction de tes besoins.
Les patrons de conception, vont venir naturellement.
Tu peux partir sur une solution simple comme celle de JolyLoic (qui consiste à rajouter des tests et des attributs de classes de type booléen/ enum).

Et ensuite arriver sur la solution de Trademark sur ce post
Et regardes pour ce bon de code:

Code:

---

1 2	Weapon sword(2, SLASHING); sword.addEffect(WeakenEffect(0.7, 50));

---

Au lieu de le coder "en dur", tu peux aller chercher les valeurs de manière externe (dans un fichier par exemple).
Il n'y a peu qu'une seule façon de code :mouarf: :mouarf:

Citation:

---

Envoyé par foetus

Tu peux partir sur une solution simple comme celle de JolyLoic (qui consiste à rajouter des tests et des attributs de classes de type booléen/ enum).

---

Ma solution n'était pas si simple, c'était plus une décomposition en axes orthogonaux, chaque axe étant implémenté par exemple à l'aide du pattern strategy. Par exemple, l'axe dépendance à la cible est implémenté par une stratégie qui prend en argument uniquement la cible du coup. Parmi les classes dérivée de la stratégie, on peut en imaginer une qui regarde si la cible possède un alignement (arme maudite), une autre qui regarde si la cible est liée à un élément (arme de feu), une qui regarde la taille de la cible par rapport à un seuil (arme contre les géants), un qui regarde si la cible a tué quelqu'un récemment (arme de vengeance)...

Citation:

---

Envoyé par JolyLoic

Ma solution n'était pas si simple, c'était plus une décomposition en axes orthogonaux, chaque axe étant implémenté par exemple à l'aide du pattern strategy. Par exemple, l'axe dépendance à la cible est implémenté par une stratégie qui prend en argument uniquement la cible du coup. Parmi les classes dérivée de la stratégie, on peut en imaginer une qui regarde si la cible possède un alignement (arme maudite), une autre qui regarde si la cible est liée à un élément (arme de feu), une qui regarde la taille de la cible par rapport à un seuil (arme contre les géants), un qui regarde si la cible a tué quelqu'un récemment (arme de vengeance)...

---

J'adore la solution de Trademark (vu que j'aurais surement fait la même chose), mais ton idée me semble tout aussi intéressante, même si j'ai un peu de mal à visualiser. Est-ce qu'il n'y a pas moyen de coupler la vision de Trademark qui est plus "conceptuelle (assembliste ? je ne sais pas trop comment appeler ça)" avec ta vision plus "comportementale" ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

class Strategy {};   class VaporiserEpeeAvecInsecticide : public Strategy {};   class Weapon {};   class ArmeADeuxMainTueuseDeMoustique : public Weapon { public : ArmeADeuxMainTueuseDeMoustique() { mesComportements.push_back(VaporiserEpeeAvecInsecticide()); } private : vector<Strategy> mesComportements; vector<Effect> mesEffets; //je sais pas si cela ferait office de doublon ou de complément.... }

---

Qu'est-ce que vous en dites ?

J'ai du mal à voir comment ma solution est compatible avec le pattern strategy. Ce que je n'ai pas exposé c'est comment on va appliquer un effet au personnage (implémenté dans la méthode virtuelle act(Hero)). À mon avis c'est à ce moment que le pattern visitor entrera en jeu et on obtiendra quelque chose comme :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

class AliveEntityVisitor; class AliveEntity { public: virtual accept(std::unique_ptr<AliveEntityVisitor>& visitor) = 0; };   template <class ConcreteAliveEntity> class AliveEntityCRTP : public AliveEntity { public: virtual accept(std::unique_ptr<AliveEntityVisitor> & visitor) { visitor->visit(*static_cast<ConcreteAliveEntity*>(this)); } };   class GiantMonster : public AliveEntityCRTP<GiantMonster> { };   class Hero : public AliveEntityCRTP<Hero> { };

---

Je fais ça bien au risque de perdre l'OP, mais je compte sur lui pour poser les questions qu'il voudra ;-) Pour le moment ce que j'ai écrit n'a qu'un seul but, c'est de pouvoir dispatcher les types de monstres pour leur appliquer des effets. Si on définit le visiteur il sera implémenté comme ça :

Code:

---

1 2 3 4 5 6 7

class AliveEntityVisitor { public: virtual visit(Hero &hero) = 0; virtual visit(GiantMonster &giant) = 0; };

---

Chaque effet sera donc implémenté sous la forme d'un visiteur :

Code:

---

1 2 3 4 5 6 7

class BlindEffect : public AliveEntityVisitor { public: virtual visit(Hero &hero); virtual visit(GiantMonster &giant); };

---

Et donc appliquer l'effet voulu en fonction du personnage (monstre ou héro) et de leurs propres caractéristiques. Le gros désavantage du visiteur ainsi utilisé c'est que à chaque fois que tu voudras ajouter un nouveau monstre tu devras modifier tous les effets existants. Reste à définir les caractéristiques d'un personnage, ce qui ne sera pas du gâteau non plus :-)

(Vu que ma solution précédente semblait plaire, j'ai édité pour ajouter les destructeurs virtuels et les pointeurs (via unique_ptr)).

Par contre, pour le coup je n'aime pas du tout cette approche :)

Comme tu le dis, c'est pas terrible vis-à-vis de l'OCP. Ce qui me gêne en plus dans cette approche , c'est que la notion de visiteur est tellement loin du concept des monstres, des épées, des effets, ... c'est là généralement là que je trouve que les développeurs se perdent dans la technique et oublient de rester proches du concept. La compréhension du code devient très difficile, et je suis sûr qu'il y a moyen de faire la même chose, sans perdre en lisibilité.

Tu parles d'appliquer un effet à un personnage, mais je ne comprends pas si tu parle des effets des épées, où si tu veux dire 'comment le personnage va subir ces effets ?'.

Si tu parles de comment les personnages vont subir les effets, je resterai sur le même principe que pour l'épée : le personnage peut subir (il a) des effets, le personnage est immunisé contre des effets, etc..

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Hero : public Entity { vector<Effect> mesImmunites; public : bool estImmuniseContre(Effect e); //return mesImunnites.contains(e); };   //ailleurs... if (!Hero.estImmuniseContre(Hermoroides()) //acheter de la pommade

---

Mouai, je suis aussi convaincu par ta solution que par la mienne, mais bon je pense qu'on s'emporte un peu :p La solution dépend entièrement du niveau de complexité que le jeu possède et des interactions entre les différents composants. Notre problème c'est qu'on essaye de résonner sur une solution générique et forcément c'est bien trop compliqué 8O Enfin, si ça peut inspirer MrPchoun, je serai déjà content :D

Il me semble qu'il faut utiliser une usine virtuelle/ Abstract Factory :mrgreen:

Et, à brûle-pourpoint, je dirais: Un personnage est caractérisé par une protection, une arme, un ensemble de caractéristiques [...]
Une arme par un effet et un matériau [...]
Ainsi de suite...


@JolyLoic La patron de conception Stratégie/ Strategy se rapproche plus de ce que je pensais lorsque je parlais des traits

Bonjour

Etant débutant et n'ayant jamais créé de jeu, je n'ai aucun recul.
Mais il me semble que Klaim, dans ce post, indiquait ne pas se servir de l'héritage pour définir les comportements.

Je ne m'y suis que très peu intéressé, mais le "Component-based game entity system" semble être une bonne base pour garantir une certaine flexibilité.

Effectivement, les grosses architectures, héritage sexy partout, traits etc ne sont pas légion. (pour ne pas dire quasi inexistante)
Le code du jeu doit être data-driven, afin que les GD/LD/Graph puissent modifier le rendu/comportement avec un minimum d'action du programmeur.

Dans les faits, tu auras 1 classe Arme, avec une multitude d'attributs, définis de concert avec le GD typiquement. GD qui crée des fichiers de données (Xml) : EpeeFeu, Lance, ... pour créer le contenu du jeu.

Que toutes les constantes soit définies dans un fichier qui ne nécessitent pas d'action du programmeur est tout à fait intéressante effectivement, mais je ne vois pas en quoi c'est incompatible avec une archi à "héritage sexy" :)

Une archi en béton avec héritage basé sur le comportement ou les services, et le contenu du jeu chargé ou lu à partir de fichiers plats ou de base de données (pour les MMO par exemple) est ce que personnellement je trouve le plus propre.

Hello,

Si je ne m'abuse, la solution proposée par Kaamui ressemble à peu près à ce que j'avais fait. En tous cas, chaque arme serait en fait une seule classe/structure, dont on ne ferait qu'une seule instance. Si une telle manière de coder peut être envisagée, c'est au top :mrgreen: Mais du coup, faire une classe d'effets ne serait plus très pertinent vu que chaque arme aura son comportement propre. Déjà qu'on ferait une classe d'arme par arme, pourquoi faire une classe d'effet en plus par arme ? Je pose juste des questions, ne le prends surtout pas mal Kaamui :D

Les visitor pattern, je suis dessus depuis hier soir, et j'ai sans doute compris les grandes lignes du machinchose, mais dès qu'il s'agit de l'implémenter je suis perdu, et comme le disait Kaamui, le code devient beaucoup moins visible :(

Je rebondis sur ce que vient de dire foetus : effectivement, chaque arme ou personnage est constitué d'un ensemble de caractéristiques. Et moi j'envisageais les choses de la manière suivante : on a une structure (qui ne serait jamais utilisée comme ça, elle devra être dérivée) ActiveItem, qui contient une liste de caractéristiques, par exemple :

Code:

---

1 2 3 4 5

struct ActiveItem int force int dextérité ... int vitesse

---

Un personnage, par exemple, peut dériver de cette structure, et puis il a quelques méthodes, du genre

Code:

---

1 2 3

struct Player : ActiveItem seDéplacer(Point point) attaquer(Player &ennemy)

---

Et puis finalement, si on envisage les effets d'une arme comme un ensemble de caractéristiques qu'on modifie chez l'ennemi, on peut aussi très bien écrire :

Code:

---

1 2	struct Weapon : ActiveItem ...

---

Du coup, dans le cas d'une arme qui ralenti l'adversaire, il suffit de créer une instance de Weapon :

Code:

---

1 2	Weapon batonDuTonnerre; batonDuTonerre.vitesse = -2;

---

Voilà... Moi j'envisageais les choses comme ça, je ne sais pas ce que vous en pensez ?

Cordialement,

Rien ne peut me faire plus plaisir que d'essayer d'aider et de répondre à des questions de personnes passant exactement par où je suis passé ^^

Pour les effets, effectivement pas sur que les deux ne soient pas redondants, là le choix devient surtout une question de contexte (celui de ton jeu). Si tu es sur quelque chose de très travaillé comme le sont les exemples de Loïc Joly, il vaut peut-être mieux choisir son idée. Les questions de conception, c'est aussi une question de ... conception (vision des choses). :)

Une classe par arme, une classe par effet, mais pas une classe effet par arme :)

Le but, aussi, c'est de faire le découpage le plus atomique possible, pour ne pas avoir plus de responsabilité pour une classe donnée qu'elle ne devrait. Si tu regarde dans le post cité de Klaim, il y a juste au dessus une intervention très pertinente de Koala01 qui montre l'importance de ne pas faire son radin avec les interfaces ;)

Citation:

---

Envoyé par Kaamui

J'adore la solution de Trademark (vu que j'aurais surement fait la même chose), mais ton idée me semble tout aussi intéressante, même si j'ai un peu de mal à visualiser. Est-ce qu'il n'y a pas moyen de coupler la vision de Trademark qui est plus "conceptuelle (assembliste ? je ne sais pas trop comment appeler ça)" avec ta vision plus "comportementale" ?

---

Je pense que les deux ne se situent en effet pas au même niveau. Par exemple, on pourrait imaginer que la stratégie qui prend en compte les caractéristiques de l'adversaire soit implémentée à l'aide d'un visiteur.

Là où je dit que j'ai un doute, c'est que pour que ça serve à quelque-chose, il faut déjà que les adversaires soient organisés en hiérarchie d'héritage, ce qui est peu probable (il risque de n'y avoir qu'une seule classe, avec des valeurs numériques ou des stratégies dépendant du personnage). L'autre critère pour que le visiteur soit intéressant c'est que la hiérarchie à visité soit stable (et que les opérations à effectuer soient instables). Or là, même si on partait sur une hiérarchie d'adversaire, elle aurait toute les chances d'évoluer sans cesse. C'est ce qui fait que la lourdeur du visiteur est rarement justifiée à mon sens. Un des rares cas est quand on écrit un compilateur, et je pense qu'à cause du prestige de ce cas, ce design pattern est survendu...

Je suis en train de regarder la conception "Entity Component System" (ECS) et c'est .... 8O 8O

Parce que chacun fait sa tambouille.

Dans l'état de l'art il y a 5 types: Engine, Entity, Component, System, Node.

*) Un objet de type Entity c'est juste un ID et une liste d'objets de type Component

*) Un objet de type Component c'est juste une structure avec des attributs.
Par exemple: PositionComponent c'est un X, Y, Z. HealthComponent c'est un entier health. PhysicalComponent c'est la vitesse et la vélocité et ainsi de suite.

Si je ne me trompe pas, on peut voir chaque Component comme une table de base de donnée ou un tableau associatif et on va accéder aux données grâce à l'ID de l'objet :fou:


*) Un objet de type System c'est une liste d'objets de type Node et une méthode virtuelle update qui est la logique du système.


*) Un objet de type Node c'est une liste d'objets de type Component
L'idée: Une partie d'un objet (type Component) peut-être partagée entre différents systèmes.
Par exemple le RenderSystem et le MotionSystem vont avoir besoin de la partie PositionComponent d'un objet.

*) Un objet de type Engine c'est une liste d'objets de type Entity et une liste d'objets de type System.


L'idée de l'initialisation du jeu: on va créer un objet de type Entity, lui ajouter des Component et ensuite ajouter cet objet dans le moteur. Et c'est le moteur qui se charge d'ajouter au moins les Component de l'objet dans les systèmes qui vont bien.


Pour faire la boucle de jeu, le moteur va appeler la méthode update de chaque système.
Évidemment les systèmes semblent être priorisés ou ordonnés au niveau du moteur :mrgreen:
On voit bien la séparation données et logique et même, on peut "séparer" les données/ logiques pour la programmation multithreadée.


Là ou je n'arrive pas encore à voir le truc c'est l’interaction entre les systèmes: c'est la "foire à tout" :koi: :koi:
Un exemple: le EventSystem transforme la touche tapée en message, message qui doit être transmis au MotionSystem avant le ColliderSystem.

• Il y a un système de messages qui est mis en place. Mais je trouve lourd que le EventSystem envoie un message au moteur qui le redistribue à tous les systèmes (que celui ou ceux intéressés le traite)
• À moins que le EventSystem contient la liste des systèmes qui l'intéresse
• Le Component contient la liste des Node qui l'utilisent et peut prévenir les systèmes en remontant comme un saumon. Ceci implique de la logique dans les objets Component
• Le Component contient un lien avec son objet l'appartenant et ce dernier peut prévenir les systèmes qui l'utilisent (comment??? via le moteur c'est lourd). Ceci implique de la logique dans les objets Entity
• De tout manière, il semble qu'un état soit ajouté dans certains objets Entity. Pourtant on devrait créer un type StatutComponent
• Je ne sais même pas si les objets de type Node existent.
• Pour un jeu 2D on avait un tableau (qui représente le terrain ou le plateau) pour faire des tests de collisions avec l’environnement. Donc là il faudra rajouter des murs, des pierres des lacs... Dans un sens c'est logique si on veut les afficher on n'a pas trop le choix. Le nombre d'objet devra être suivi de près.

Citation:

---

Envoyé par JolyLoic

C'est ce qui fait que la lourdeur du visiteur est rarement justifiée à mon sens. Un des rares cas est quand on écrit un compilateur, et je pense qu'à cause du prestige de ce cas, ce design pattern est survendu...

---

Ça pose même des problèmes dans les compilateurs vu qu'un langage ne cesse d'évoluer... Il suffit de regarder le C++. Mais en orienté-objet ça reste le seul moyen d'ajouter des traitements à une hiérarchie de classes sans modifier lesdites classes.

Tu veux dire que le pattern visitor est le seul moyen de respecter l'OCP dans une hiérarchie de classes ? (si oui, je ne suis pas d'accord mais pas sûr que c'est ce que tu voulais dire)

Citation:

---

Envoyé par Trademark

Ça pose même des problèmes dans les compilateurs vu qu'un langage ne cesse d'évoluer... Il suffit de regarder le C++. Mais en orienté-objet ça reste le seul moyen d'ajouter des traitements à une hiérarchie de classes sans modifier lesdites classes.

---

Oui, elle évolue, mais généralement moins vite que les traitements que l'on fait dessus.

Citation:

---

Envoyé par Kaamui

Tu veux dire que le pattern visitor est le seul moyen de respecter l'OCP dans une hiérarchie de classes ? (si oui, je ne suis pas d'accord mais pas sûr que c'est ce que tu voulais dire)

---

Dans une collection hétérogène de classe comment peux-tu respecter OCP sinon ? Évidemment sans parler des solutions impliquant le RTTI.

Avec un découpage atomique des responsabilités de chaque classe, ta collection hétérogène est ouverte à l'extension naturellement. J'allais presque dire que pour respecter OCP il faut respecter OCP :D

Plus sérieusement, pour moi c'est justement ce qu'offre SOLID, et particulièrement OCP, cette flexibilité/réutilisabilité/atomicité des classes qui fait qu'on a pas besoin de passer par des patterns comme visitor. Loïc Joly et toi y voyez un intérêt, et même si je sais très bien que si vous deux y voyez un intérêt, c'est que ça doit pas être dénué de sens, pour moi ce pattern est un modèle qui va à l'encontre de SOLID, voire de l'OO de manière générale. Il est donc pour moi même indispensable de ne pas utiliser visitor pour respecter OCP, puisque visitor t'ouvre à la modification.


EDIT : pourquoi écartes-tu la résolution des types à l’exécution au fait ?

Je reviens sur l'architecture "Entity Component System" (ECS)

Intel a fait un papier dessus avec du multhreading
ECS un peu modifié parce qu'Intel parle, par exemple, d'extensions mais ce sont les types Component, et il fait une séparation entre Object et Scene.

Ce n'est pas très précis pour certains trucs (surtout je pense que c'est au codage que tu vas trouver tous les problèmes :aie:) ... mais c'est 8O 8O