Discussion :

[bisthebis]

Bonjour � tous,

Au fil de mes p�r�grinations programmatiques, j'ai plusieurs fois fait l'exp�rience d'un dilemme. Lorsque je veux cr�er classe en contenant une autre ainsi que d'autres donn�es, je ne sais jamais quand ajouter ladite classe en attribut ou au contraire, quand h�riter de ladite classe.
Exemple : Admettons que je programme en 2D et que j'ai une classe Sprite qui contient l'imagine affich�e ainsi que la position dudit Sprite dans le monde. Je veux cr�er une classe Personnage : un personnage est repr�sent� par un sprite, mais contient d'autres informations : nom, vie, etc... ainsi qu'une flop�e de m�thodes qui vont avec.
Convient-il d'avoir le Sprite en attribut, ou plutot d'h�riter du Sprite ?
Instincitvement j'utilise la solution de l'attribut, mais lorsque ledit attribut poss�de beaucoup de m�thodes, le code s'alourdit beaucoup (Si par exemple, pour mon personnage, je dois cr�er une m�thode afficher qui appelle la m�thode afficher du Sprite). D'un autre c�t�, h�riter de Sprite me laisse perplexe, notamment parceque le Personnage "contient" un Sprite plus qu'il n'en est un. Niveau LSP et tout �a, �a me semble bof.

Du coup, en r�gle g�n�rale, comment choisir la technique utilis�e ?

[prgasp77]

Une premi�re question que tu dois te pauser est : doit-on pouvoir utiliser un personnage comme on utilise un sprite ? Mais attention, si la r�ponse est "oui", il faut continuer l'investigation : ce besoin est-il r�el et justifi� ou est-ce un gimmick, une mauvaise conception ? C'est une id�e d'entr�e en mati�re.

[Bousk]

De mani�re g�n�rale, si la classe de base n'a aucune fonction virtuelle, y'a peu de chance que tu doives en h�riter.

[bisthebis]

Merci pour les r�ponses. Dans mon cas tout incite � encapsuler, mais je vais devoir copier quelques m�thodes du Sprite pour qu'elles s'appliquent au Personnage. (En fait, mon "souci d�clencheur" tenait dans le fait que je d�place mon personnage et non son sprite, qui est toujours au point 0,0 des coordonn�es... du personnage. Parfait pour d�placer l'image, moins pour calculer les collisions avec les m�thodes du Sprite.)
D'un autre c�t�, je ne vois dans mon cas aucun inconv�nient � h�riter de Sprite, notamment car Personne comme Sprite h�ritent des meme classes abstraites d'interfaces Drawable et Transformable. Du coup, dans ce cas particulier, le Personnage est "parall�le" au Sprite qu'il contient... Ca porte � confusion

[Iradrille]

Parfait pour d�placer l'image, moins pour calculer les collisions avec les m�thodes du Sprite.)
D'un autre c�t�, je ne vois dans mon cas aucun inconv�nient � h�riter de Sprite, notamment car Personne comme Sprite h�ritent des meme classes abstraites d'interfaces Drawable et Transformable. Du coup, dans ce cas particulier, le Personnage est "parall�le" au Sprite qu'il contient... Ca porte � confusion

A priori, Sprite et Collision c'est deux choses diff�rentes, donc 2 classes, �a devrait pas �tre regroup�.

Un Personnage n'� imo pas � �tre Drawable.

Tu peux tout � fait exposer le Sprite pour l'affichage.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
class Personnage : public Transformable {
public:
   Sprite const& sprite() const() { return m_sprite; }
 
private:
   Sprite m_sprite;
};
 
// ...
Personnage p;
draw(p.sprite());

Si le fait d'exposer le Sprite d�range, tu peux l'exposer via une classe utilitaire.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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
template <class T>
struct DrawT : public Drawable {
   void draw(RenderTarget& rt) const {
      rt.draw(m_sprite);
   }
 
   DrawT(T const& obj): m_sprite(obj.sprite()) { };
 
private:
   Sprite m_sprite;
};
 
class Personnage : public Transformable {
public:
   DrawT<Personnage> drawer() const { return DrawT<Personnage>(*this); }
 
private:
   friend class DrawT<Personnage>;
   Sprite const& sprite() const { return m_sprite; }
 
   Sprite m_sprite;
};
 
Personnage p;
auto d = p.drawer();
 
draw(d));

[ternel]

Normalement, ton personnage est positionn� par des coordonn�es propres aux donn�es (en metres, par exemple), et le sprite en pixels.
Tu as probablement du �crire une fonction, quelque part dans le code graphique, qui converti ces coordonn�es de jeu en coordonn�es �cran.

C'est cette fonction qui te donnera les coordonn�es du sprite

Ca ne devient �vident qu'en 3D, o� les coordonn�es du monde sont relatives � un rep�re stable et 3D, tandis que les coordonn�es en pixels sont li�es � la projection cam�ra.

[bisthebis]

Un Personnage n'� imo pas � �tre Drawable.

Tu peux tout � fait exposer le Sprite pour l'affichage.

En fait, Drawable ne poss�de qu'une m�tode virtuelle pure, draw. Mon impl�mentation de draw dans personnages appelle simplement la fonction draw du Sprite contenu. J'imagine que c'est fort �quivalent � un accesseur du Sprite si ledit accesseur n'a pas d'autre utilit�.

Normalement, ton personnage est positionn� par des coordonn�es propres aux donn�es (en metres, par exemple), et le sprite en pixels.
Tu as probablement du �crire une fonction, quelque part dans le code graphique, qui converti ces coordonn�es de jeu en coordonn�es �cran.

C'est cette fonction qui te donnera les coordonn�es du sprite

Pour l'instant j'utilise comme unit� de mesure le "pixel en zoom nul", mais r�flexion faite je pense pertinent de changer �a. Je pense que je vais placher l�-dessus

[JolyLoic]

Du coup, en r�gle g�n�rale, comment choisir la technique utilis�e ?

La r�gle en g�n�ral est le principe de substitution de Liskov (LSP, Liskov Substitution principle, nomm� d'apr�s Barbara Liskov). Pour que B d�rive de A, il faut que partout o� on peut utiliser un A, on puisse substituer un B et que le code soit justifi�, logique et coh�rent.

On a souvent tendance � sur-utiliser l'h�ritage qui est la relation la plus forte qui soit entre deux classes. Du coup, si tu h�sites, c'est probablement qu'il vaut mieux t'abstenir

[foetus]

Si tu as 2-3 heures � perdre, il y a un livre gratuit sur le d�veloppement de jeu � l�ancienne: O'Reilly Media - iPhone Game Development.

Bon c'est de l'Objective-C, mais c'est facile � comprendre [les premiers chapitres t'expliquent la programmation iOS 3-4-5]: le pdf et les codes sources

�dit: Le chapitre 5 c'est pour un jeu 3D [tr�s] [tr�s] l�ger et le chapitre 3 ce sont les fondations. Donc c'est le chapitre 4 qu'il faut regarder

[koala01]

Salut,

De mani�re g�n�rale, tu dois te dire que l'h�ritage est la relation la plus forte qui puisse exister entre deux classes. C'est donc la relation que l'on essayera d'utiliser le moins possible.

Si tu te pose la question de savoir s'il est pr�f�rable d'utiliser l'h�ritage ou la composition(/l'agr�gation), on peut donc assez facilement partir du principe que la composition (ou l'agr�gation) sera sans doute le meilleur choix par d�faut.

En effet, pour que tu puisse faire h�riter une classe B d'une classe A, il faut que le principe de substitution de Liskov soit imp�rativement respect�, ainsi que l'a d�j� fait savoir Loic et, pour qu'il soit respect�, il faut que tu puisse envisager d'utiliser ta classe B partout o� un objet de type A aurait �t� attendu.

Mais ce n'est pas tout : Si tu y r�fl�chis bien, absolument tout ce qui fera partie de ton jeu sera -- tot ou tard -- destin� � devoir �tre affich�. De l� � estimer que tout ce qui fait partie de ton jeu devrait h�riter d'une classe quelconque (de Sprite, par exemple), il n'y aurait qu'un pas, que tu aurais tr�s largement tord de franchir.

Car, si tu franchis ce pas, tu ne vas pas tarder � te retrouver avec une hi�rarchie de classes monstrueuse et totalement ing�rable, dans laquelle tout d�rive de Sprite.

Or, m�me si ton personnage, tes armes, tes potions, tes sors ou que sais-je d'autre finiront bel et bien par devoir �tre affich�s, ce que tu attends de la part de ces diff�rents types d'objets est et restera d'�tre en mesure de rendre certains services sp�cifiques, propres � la nature m�me du type en question.

De plus, il existe un concept appel� MCV (pour Model Controler View) qui nous incite � essayer de s�parer le plus possible la notion d'affichage (que l'on retrouve pour n'importe quel Sprite) du reste du code.

De ce fait, on se fout pas mal de savoir que ton Personnage est repr�sent� par un Sprite particulier, car, ce que l'on attend en priorit� de sa part, c'est qu'il soit capable de fournir des services tels que:

• r�pondre � la question "quelle est ta position"
• r�pondre � la question "es-tu en vie"
• ob�ir � l'ordre "d�place toi vers telle position" ou "d�place-toi de telle distance en X et telle distance en Y"
• ob�ir � l'ordre "attaque tel ou tel �l�ment"
• ob�ir � l'ordre "�quipes-toi de telle ou telle arme"
• ob�ir � l'ordre "bois telle ou telle potion"
• j'en passe, et sans doute de meilleures...

Et l'id�e est donc d'avoir "quelque chose" qui pourra indiquer que, pour repr�senter ton personnage, il faut utiliser tel sprite particulier, et le faire afficher � telle position particuli�re. Tu devras, pour faire simple, trouver le moyen de cr�er une relation "la plus l�g�re possible" entre ton personnage et le sprite qui permet de le repr�senter, de mani�re � pouvoir demander l'affichage de ce sprite, sans avoir � s'inqui�ter des autres caract�ristiques de ton personnage

[bisthebis]

Merci foetus pour le lien, je regarderai �a en d�tail quand j'aurai du temps


A la r�flexion, faire tout h�riter de Sprite semble en effet hasardeux, en revanche je suis instinctivement tent� de tout faire d�river de Drawable pour que chaque objet soit affichable, mais quand on pense en architecture genre MVC (j'ai lu pas mal de trucs l�-dessus, mais je n'ai jamais appliqu� et ma compr�hension n'est que th�orique) j'imagine que pouvoir faire monPersonnage.afficher() est mal. Reste que j'ai du mal � comprendre le pourquoi exact
Est-ce une histoire de "ne remplir qu'une fonction par classe" ?

Du coup, quelles sont les possibilit�s propres pour s�parer �a ? Avoir le sprite en attribut ? En pointeur ? Autre chose ?
Je vais devoir relire tout ce que je sais sur le MVC car c'est fort confus pour moi. Faut-il pour chaque objet avoir un objet vue correspondant ? Ou est-ce que la vue correspond � mon moteur graphique ? C'est assez abstrait pour moi

[Bousk]

A moins d'avoir une classe de manager d'affichage sur lequel enregistrer chacun de tes sprites � leur cr�ation, tu ne pourras de toutes fa�ons pas �chapper � avoir un �quivalent de myPerso.Draw()

[prgasp77]

A moins d'avoir une classe de manager d'affichage sur lequel enregistrer chacun de tes sprites � leur cr�ation, tu ne pourras de toutes fa�ons pas �chapper � avoir un �quivalent de myPerso.Draw()

Pas n�cessairement, ou pas directement. Si on part du principe qu'une classe n'a qu'une responsabilit� (dans le sens de fonctionnalit�), on est pouss� � s�parer la gestion du personnage de son affichage. Une classe Person qui g�re les attributs dudit personnage (position, statut, inventaire, �l�ments du jeu...) et une autre qui n'a pour seule charge que de le dessiner.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
class PersonDrawer
{
    Person const& _person;
public:
    PersonDrawer() = delete;
    PersonDrawer(Person const& p) : _person(p) {}
    /** @todo : destructor, copy cstr, move cstr, operator= w/ & w/o move semantics */
 
    void Draw(Context c);
};

On est ici dans un patter Mod�le-Vue. Il est tout � fait possible d'ins�rer un contr�leur et pouf ! �a fait un MVC.

Qu'en penses-tu ?

[foetus]

Le contr�leur existe d�j� : c'est [en gros, et d�pendant de l'impl�mentation] la classe "World" qui contient le plateau - "Tiles" et la liste des "Entities *" [en plus de la cam�ra]

Donc, si on coupe la classe "Entity" en 2, 1 avec [seulement] le gameplay comme les points de vie et 1 autre avec [seulement] l'affichage, effectivement on a un MVC


*: On parle d'entity parce qu'un mur doit �tre repr�sent�, mais n'est pas forc�ment anim� [pas de sprite, juste un tile suffit]

[bisthebis]

Du coup, si je fonctionne en MVC comme vous le d�crivez, comment fonctionne PersonDrawer ? Un pointeur sur le mod�le pour connaitre la position etc, et une texture en attribut ?
Enfin, en parlant de contr�leur, est-ce que ca veut dire que je dois utiliser le Drawer pour g�rer les �v�nements ?

[koala01]

Avant toute chose, il faut bien se rendre compte que l'approche purement OO montre des faiblesses lorsqu'il s'agit de d�velopper un jeu, � cause du nombre de combinaisons possibles et de classes que cela finira par sous entendre.

Prenons les armes, par exemple : Si je veux cr�er une hache, une �p�e et un gourdin, je pourrais cr�er une classe m�re Weapon dont je ferais h�riter une classe Sword, une classe Axe et une classe Cudgel. Pas mal...

Mais, par la suite, je vais sans doute vouloir avoir une claymore, une hache de guerre ou un marteau de guerre. Ce sont aussi des armes, mais ce sont des armes qui n�cessitent les deux mains pour �tre utilis�s. Je devrai donc faire la distinction entre les "petites" �p�es, celles qui peuvent �tre utilis�es � une main et les grandes, celles qui n�cessitent les deux mains pour les utiliser, et je devrai faire pareil pour les hache et mes gourdins.

Puis, j'aurai besoin d'une classe pour les arcs, puis d'une autre pour les couteaux de lanc� et, qui sait, une autre pour le boomerang.

Mais ce n'est pas tout : avec l'�volution du jeu, je voudrai avoir des armes magiques, qui ajoutent des d�gats magiques � ceux de la lame, puis des armes qui modifient l'une ou l'autre caract�ristique du personnage, puis des armes que je peux sertir afin de les rendre magiques avec des r�sultat divers (certaines pierres ajoutant des degats de magie, d'autres modifiant l'une ou l'autre caract�ristique du personnage qui l'utilise).

Le tout sans oublier qu'une arme, c'est d'abord et avant tout une piece d'inventaire qui peut �tre �quip�e. On devrait donc retrouver une classe de base commune entre les armes et les pieces d'armure, afin de pouvoir m�langer les deux dans l'inventaire.

Mais on devrait aussi trouver une classe de base commune entre les armes, les armure et les �l�ments que l'on peut manger ou avaler (ex : les potions), parce que ces derniers prennent aussi place dans l'inventaire. Et au final, on va se retrouver avec un "god-object" et une hi�rarchie de classe totalement ing�rable.

L'id�e pour un jeu est donc de partir d'une approche de type ECS (Entity Components System), qui permettra de mettre "n'importe quel composant" en relation avec "n'importe quelle entit�" et de mettre en place un ensemble de "syst�mes" qui s'assureront de la pr�sence d'un composant donn� pour une entit� donn�e et de la mise � jour en fonction des situations.

Maintenant, pourquoi voudrait tu faire h�riter tous tes objets de Drawable Peut �tre as-tu l'impression que les seules vues que tu auras seront des vues graphiques

Mais, dis moi alors, est ce qu'un affichage "console" proche de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
nom    |  race    |   type   |niveau | vie | arme            
====================================================
Henry  | goblin   | eclaireur| 3     | 15  | gourdin
Jaques | orc      | chaman   | 15    | 150 | bâton sacré
Victor |nain      | guerrier | 6     | 75  | marteau de guerre

ne te semble pas �tre une repr�sentation "tout aussi correcte" de tes donn�es que ce que tu pourrais obtenir en faisant tout h�riter de Drawable

Ce sur quoi je veux attirer ton attention, c'est sur le fait que tu as forc�ment des donn�es qui seront manipul�e par ton jeu, mais qu'il doit toujours y avoir une distinction tr�s claire entre les donn�es que tu utilises et la mani�re dont tu les repr�sente dans ta vue.

Ainsi, peut �tre que tu pourras associer une image � "marteau de guerre", � "chaman orc" ou � "eclaireur goblin". Mais cette image n'a rien � faire au niveau de la classe personnage! Elle n'a du sens que dans le contexte d'affichage particulier dans lequel tu utilise des �l�ments "drawables" (et des sprites, selon toute vraisemblance).

Du coup, tu peux t'arranger pour maintenir "quelque part" (sans doute au niveau du contexte d'afffichage) une liste des images qui te permettent de repr�senter les diff�rents �l�ments (je simplifie, ce sont peut �tre des objets 3D avec squelettes, textures et tout le saint frusquin ) et, tout ce qu'il faut pouvoir faire est d'indiquer "ce qui doit �tre affich�" et "� quel endroit". Autrement dit, pour que l'affichage fonctionne, tout ce qu'il te faut sera un code qui pourrait ressembler � quelque chose comme

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
view.draw(leContext, perso.id(), perso.posX(),perso.posY());
view.draw(leContext, spell.id(), spell.poX(), spell.posY());
vie.draw(leContext, weapon.id(), weapon.posX(), weapon.posY());

Le respect du principe de la responsabilit� unique est donc bel et bien une base saine pour arriver � s�parer correctement les diff�rents �l�ments, car, si tu le respecte, tu te rend compte qu'une classe Personnage, Weapon ou Spell n'a aucune raison d'avoir la responsabilit� de se tracer (car on peut donner un aper�u pr�cis de la situation d'une mani�re diff�rente) et que, de leur cot�, les �l�ment "tra�ables" n'ont absolument aucun besoin de savoir "� quoi cela correspond" effectivement (car tout �l�ment tracable n'est "rien d'autre qu'un image" qu'il faut afficher � une position donn�e, m�me si c'est simplifi� � l'extr�me )

[Bousk]

Pas n�cessairement, ou pas directement. Si on part du principe qu'une classe n'a qu'une responsabilit� (dans le sens de fonctionnalit�), on est pouss� � s�parer la gestion du personnage de son affichage. Une classe Person qui g�re les attributs dudit personnage (position, statut, inventaire, �l�ments du jeu...) et une autre qui n'a pour seule charge que de le dessiner.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
class PersonDrawer
{
    Person const& _person;
public:
    PersonDrawer() = delete;
    PersonDrawer(Person const& p) : _person(p) {}
    /** @todo : destructor, copy cstr, move cstr, operator= w/ & w/o move semantics */
 
    void Draw(Context c);
};

On est ici dans un patter Mod�le-Vue. Il est tout � fait possible d'ins�rer un contr�leur et pouf ! �a fait un MVC.

Qu'en penses-tu ?

Tout cela est bien beau, mais � quel moment tu appelles ton Draw ?
- par le personnage qui contient un Drawer ?
- par un manager o� tu as enregistr� ton Drawer et qui les appelle tous ?
Bref, tu tournes en rond.

D'ailleurs, te fatigue pas � overengeenerer du code que de toutes fa�ons tu jetteras dans quelques semaines/mois parce que tu auras gagn� en exp�rience et comprendras comment faire mieux. Ou tout simplement parce que tu seras all� dans un mur avec et il te faudra (re)commencer (en partie).

[bisthebis]

Ce sur quoi je veux attirer ton attention, c'est sur le fait que tu as forc�ment des donn�es qui seront manipul�e par ton jeu, mais qu'il doit toujours y avoir une distinction tr�s claire entre les donn�es que tu utilises et la mani�re dont tu les repr�sente dans ta vue.

Ainsi, peut �tre que tu pourras associer une image � "marteau de guerre", � "chaman orc" ou � "eclaireur goblin". Mais cette image n'a rien � faire au niveau de la classe personnage! Elle n'a du sens que dans le contexte d'affichage particulier dans lequel tu utilise des �l�ments "drawables" (et des sprites, selon toute vraisemblance).

Du coup, tu peux t'arranger pour maintenir "quelque part" (sans doute au niveau du contexte d'afffichage) une liste des images qui te permettent de repr�senter les diff�rents �l�ments (je simplifie, ce sont peut �tre des objets 3D avec squelettes, textures et tout le saint frusquin ) et, tout ce qu'il faut pouvoir faire est d'indiquer "ce qui doit �tre affich�" et "� quel endroit". Autrement dit, pour que l'affichage fonctionne, tout ce qu'il te faut sera un code qui pourrait ressembler � quelque chose comme

Je vais para�tre con, mais qu'est-ce que tu appelles le contexte ? (J'imagine que dans mon jargon mental j'utilise betment un synonyme, mais... je bloque )

Reste ma question principale : faut-il stocker la liaison entre la donn�e et sa repr�sentation par un pointeur... Ou par autre chose ?

[koala01]

Ben, le contexte d'affichage n'est rien de plus que ce que le mot veut dire : c'est toute la m�canique qui te permet de cr�er une fen�tre et d'y afficher de jolies image � des positions que tu as clairement d�termin�es, et qui permet aussi g�n�ralement de r�cup�rer les �v�nements issus du clavier, de la souris ou, pourquoi pas, du joystick

C'est donc un concept tout � fait g�n�ral qui m�rite d'�tre cit� pour savoir "comment les diff�rents �l�ments seront affich�s dans ta fen�tre"