Question conception d'un jeu 2d en C++

Version imprimable

07/09/2011, 05h16
marcolo21

Question conception d'un jeu 2d en C++

Bonjour tout le monde,

Je suis présentement en train de créer un petit jeu 2d de plateforme à la Mario Bros.
Bien sûr avant de programmer, j’ai décidé de me lancer dans la conception de mon jeu. Je vous expose donc mes problèmes (interrogation) ou j’aimerai avoir un peu d’aide ou du moins une piste vers où je pourrai regarder pour pouvoir me débrouiller seul.

1) Les collisions

J’ai de la difficulté à voir comment je pourrai gérer les collisions. Je sais bien comment savoir si 2 choses ont une collision entre elles, cependant, je ne sais pas comment les faire interagir ensemble.
Par exemple : le personnage touche un ennemi sur la tête. L’ennemi doit donc mourir, est- ce que je me crée une méthode ‘’Mort()’’ dans chaque classe ennemie que j’appelle lorsqu’il y a eu collision sur le dessus.
De plus supposions, qu’un ennemi particulier à des piquants sur la tête. Donc quand notre personnage va sauter sur la tête de l’ennemi, il ne doit pas mourir, mais faire mal à notre personnage.

J’aimerai avoir des pistes de solution sur comment gérer cela. J’ai donné mes exemples avec un personnage et un ennemi, mais cela s’applique pour tous les autres.
(Perso/item, Ennemi/bloc, etc)

2) Les items
Chaque item fait quelque chose de particulier à notre personnage. (Par exemple : fleur permet de lancer des boules de feux, étoile rend invincible, etc)
Comment gérer cela dans les classes ? Des boolean qui indiquent par exemple s’il est invisible, s’il peut lancer des boules de feux?

3) J’aimerai faire mon jeu sur le modèle MVC pour pouvoir séparer l’affichage du reste.
Cependant, j’ai quelque difficulté à voir comment l’implémenter. Pour l’instant dans mon modèle de personnage, j’ai un statut qui contient par exemple Walking, jumping, falling, etc. Qui signifie l’action que le personnage fait. Dans la vu que vais lire ce statut et afficher l’image en conséquence.
Est-ce correct de s’y prendre ainsi? Avez-vous de meilleures solutions à proposer ?

PS : si vous avez des liens parlant du modèle MVC et comment l’implémenter je suis preneur. J’ai trouvé quelque lien, mais il n’expliquer pas tous bien comment cela marche.

Merci beaucoup à ceux qui vont bien vouloir m’aider et qui ont eu le courage lire ce long texte :P
Pour l’instant j’aimerai principalement avoir des pistes sur les collisions puisque c’est ce qui me pose le plus de problème.

Je poste sur le forum C++, car mon jeu sera fait en C++ avec SFML, si je ne suis pas dans le forum, merci de déplacer ce sujet
07/09/2011, 09h38
Dalini71

Bonjour,

C'est une bonne chose de réfléchir à la conception avant de coder :ccool:

Je te conseil de te documenter sur les Design Pattern (State et Observer en particulier), ils répondront à pas mal de tes problèmes.
08/09/2011, 07h41
LittleWhite

Bonjour,

Pour l'instant vos réflexions semblent assez bonnes.
La réponse de Dalini71 est une solution possible pour les collisions.
Sinon, on peut faire une boucle dans la méthode update du monde, qui informe de la collision entre deux objets et qui en appelle des méthodes spécifiques des objets. Mais le observer peut aussi le faire, d'une manière surement plus belle.

Sinon, juste pour information, car votre poste n'est pas spécialement mal placé, le forum possède une section 2D / 3D / Jeux vidéo et je vous invite à présenter votre jeu là bas :).
08/09/2011, 18h21
Emmanuel Deloget

Pour le coup, et contrairement à mes saines et figées habitudes, je préconise le contraire : laisser émerger le design à partir des complexités du code initial.

Donc, pour faire plus clair, coder le système sans designer, puis généraliser, puis re-généraliser, etc, de manière à aboutir au design final.

Sinon, une solution est d'utiliser un modèle basé sur les composants (on a N composants qui s'envoient des messages: par exemple, le composant X boradcast le message CheckCollision, le composant Y lui réponds CollideWithMe, et X appelle Y.handle_collision(this) pour traiter la collision (X peut être le PJ, une balle, ... bref; un composant qui se déplace ; Y peut être n'importe quel composant, y compris un composant passif ou un autre composant actif).
08/09/2011, 19h27
JolyLoic

Tiens, pourrais tu développer les raisons qui provoquent en toi cette envie ?

A part ça, pour tout ce qui est collision, un besoin récurrent et non couvert par le langage est la notion de multi-méthode.

Salut,

J'irais sans doute même plus loin qu'Emmanuel, mais en étant passé directement à la phase de généralisation (j'ai un peu réfléchi au problème ;):D )...

De mon avis, le terme "collision" est suffisamment général pour s'appliquer à bien plus qu'entre toi et un "ennemi": il peut en survenir soit entre un élément "immobile" et un élément mobile, soit entre deux éléments mobiles, mais, quoi qu'il en soit, une collision sera... toujours une collision entre deux objets.

Cela implique qu'il y aura "interaction" entre ces deux objets, et que le résultat dépendra essentiellement de la nature de chacun d'eux ;)

Il y a en effet énormément de chances pour qu'un "ennemi" réagisse différemment à une collision avec un boulet de canon ou avec un "bonus" que toi, et que tu réagiras toi même différemment à une collision avec un mur qu'un boulet de canon rentrant en collision avec le même mur.

Et nous pourrions en dire de même pour le deuxième "objet" intervenant dans la collision, étant donné que j'ai fait remarquer qu'il s'agissait d'une inter action (chaque élément agissant d'une manière particulière sur l'autre :D)

Nous pourrions donc partir d'une situation dans laquelle il existe trois grande hiérarchies de classes distinctes représentant les différents objets susceptibles de rentrer en collision :
les joueurs (toi, les PNJ éventuels (les personnages qui ne sont pas tes ennemis, mais qui font juste "partie du décors" :D), et les ennemis)
Les objets mouvants non joueurs (les bonus qui s'écartent, les obus de canon, etc)
les objets immobiles (tout ce qui fait partie du décors et qui ne bouge pas)
Comme j'ai dit que rien ne ressemble plus à une collision qu'une autre collision, il faudrait faire en sorte que la collision soit en mesure de fournir le "contexte" dans lequel elle s'est produite. Cela revient à faire en sorte que la collision soit en mesure d'indiquer à chacun des deux éléments qui se sont rencontrés le genre d'élément qu'il a rencontré :D

Nous aurions donc une quatrième grande hiérarchie reprenant les cinq possibilités de collision à envisager:

joueur avec joueur
joueur avec objet mouvant
joueur avec objet immobile
objet mobile avec objet mobile
objet mouvant avec objet immobile
pour chaque type de collision, tu peux prévoir un ordre de priorité dans les réactions : le joueur réagira avant un objet mobile qui réagira lui-même avant un objet immobile.

Tu pourrais d'ailleurs décider d'approfondir cette notion de priorité en disant que le joueur (toi) a priorité sur les ennemis qui ont eux meme priorité sur les PNJ, voire (mais on sort du contexte "mario") de baser le calcul de priorité complexe (basé sur le niveau, la rapidité, la force ou... l'age du capitaine), lorsque deux éléments "similaires" (faisant partie de la même hiérarchie de classes) entrent en collision.

Le système qui s'occupe de détecter les collision aurait alors la lourde responsabilité de créer la collision "ad hoc" et de l'envoyer à l'élément ayant la priorité de réaction la plus élevée.

Chaque élément réagirait comme un visiteur à la collision (qui jouerait le role de "visité"), à ceci près que l'on n'a pas *vraiment* besoin de partir de l'objet visité.

Au final, cela pourrait ressembler à quelque chose comme
/* la hiérarchie "Collision" */
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 class Collision /* la classe de base */ { public: virtual ~Collision() = 0; // seule fonction réellement indispensable // virtuelle pure pour qu'il n'y ait pas moyen de // l'instancier void transmit(){doTransmit();} private : virtual void doTransmit() { } }; /* un petit coup de template pour se faciliter l'écriture :D */ template <typename FirstType, SecondType = FirstType> class TCollision { public: TCollision(FirstType * f, SecondType * s):first_(f), second_(s){} virtual ~TCollision(){} /* l'accès à l'élément ayant la priorité de réaction la plus élevée */ FirstType & first() {return first_;} /* l'accès à l'élément ayant la priorité de réaction la moins élevée */ SecondType & first() {return second_;} private: FirstType * first_; SecondType * second_; virtual void doTransmit() { first_->collide(this); second_->collide(this); } }; /* les typedef prenant les différentes possibilités en compte, pour * faciliter l'utilisation */ typedef TCollision<Player> CollisionTwoPlayers; typedef TCollision<Player, MovingObject> CollisionPlayerMovingObject; typedef TCollision<Player, ImmobileObject> CollisionPlayerImmobileObject; typedef TCollision<MovingObject> CollisionTwoMovingObject; typedef TCollision<MovingObject, ImmobileObject> CollisionMobileObjectImmobileObject; /* une collision entre deux objets immobiles n'arrivera jamais :D
La hiérarchie de classes Player prendrait donc la forme d'un visiteur de collisions utilisant le pattern NVI (un peu aménagé pour éviter de devoir implémenter chaque fois les cinq fonctions, même si un joueur ne fait rien dans certains cas ;) ) et ressemblerait à
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 class Player { public: Player(); virtual ~Player() = 0; /* la fonction a appeler par le système de détection de collisions */ void collide(Collision * col) { doCollide( *col); } /* d'autres fonctions, sans doute :D */ protected : /* pour la classe de base, on ne fait rien par défaut * il n'y a, a priori, pas à traiter le cas d'une collision * entre un objet mobile et un objet immobile, ni * entre deux objets mobiles ;) */ virtual void doCollide(CollisionTwoPlayers &){} virtual void doCollide(CollisionPlayerMovingObject &){} virtual void doCollide(CollisionPlayerImmobileObject &){} virtual void doCollide(CollisionTwoMovingObject&){} }; class Gamer : public Player { public: Gamer (/* ... */); virtual ~Player(); void collide(Collision * col) { doCollide( *col); } /* d'autres fonctions, sans doute :D */ protected : /* il ne faut réimplémenter que les fonctions qui * nécessite une réaction de notre part :D * l'idée générale étant de mettre en place * la logique qui devra etre suivie :D */ virtual void doCollide(CollisionTwoPlayers &) { /*...*/ } virtual void doCollide(CollisionPlayerMovingObject &) { /*...*/ } virtual void doCollide(CollisionPlayerImmobileObject &) { /*...*/ } virtual void doCollide(CollisionTwoMovingObject&) { /*...*/ } }; /* idem pour les ennemis et les pnj, s'il y en a */
Les hiérarchies d'objets mobiles et d'objet immobiles suivraient le même principe en veillant à ne fournir le pattern nvi que pour les collisions qui sont susceptibles d'arriver parmis les cinq cas que l'on a définis plus haut ;)

Il nous manquerait, peut etre, enfin, une "fabrique de collision" qui permettrait au détecteur de collision de ne pas s'occuper lui-même de la création de celles-ci (le fameux principe ORP (One Responsability Principle), et il (le détecteur de collision) pourrait donc ressembler à quelque chose qui serait fort proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 class CollisionDetector { public: /* j'aime les template pour éviter de devoir réécrire * vingt fois la même chose :D template <typename FirstType, SecondType> static void detect(FirstType * one, SecondType * second) { /*logique de détection de collision */ /* logique de sélection de priorité */ sendCollision(mostPriorItem, secondPriorItem); } private: template <typename FirstType, SecondType> void sendCollision(FirstType * mostPriorItem, SecondType * secondPriorItem) { Colllision * col = CollisionFactory::createCollection(mostPriorItem, secondPRior); col->transmit(); } };
Ce n'est qu'une idée qui mériterait plus grande réflexion, mais je crois que tu as là une base qui devrait pouvoir évoluer assez rapidement...

A ceci près qu'il pourrait même être intéressant de prévoir se supprimer la responsabilité de visiteur des hiérarchies de classes, car les élements qui entrent en collision ont très certainement déjà une responsabilité qui leur est propre, et cela devrait leur suffire :D

Je vais me permettre une remarque :oops:

Sur ce code
Code:

1 2 3 4 virtual void doCollide(CollisionTwoPlayers &){} virtual void doCollide(CollisionPlayerMovingObject &){} virtual void doCollide(CollisionPlayerImmobileObject &){} virtual void doCollide(CollisionTwoMovingObject&){}
Le jour ou vous allez vouloir gérer une nouvelle collision, entre 2 FlyingObject par exemple, vous allez devoir rajouter des fonctions partout dans votre code (ce qui peut être lourd, non?)
Alors oui, vous aurez le compilateur comme aide pour vous dire que vous oublier une implémentation, donc y a cette avantage. Mais je trouve pour autant qu'après quelques types de collision, cela va vraiment alourdir le code.

N'y a t-il pas une façon plus dynamique de faire. Notamment, il se peut qu'il y ai duplication de code si deux méthodes doivent implémenter le même comportement (sauf si le cast est possible entre CollisionPlayerImmobile et CollisionPlayerMoving, mais cela ne me semble pas castable).

Pour le système de message, cela peut être bien (genre, on apprend qu'il y a eu collision entre un objet et un autre. Le premier objet recevant le message, connaitra l'objet qui collide avec le pointeur sur l'autre). Par contre, c'est souvent très dangereux au niveau de la mémoire et de la validité des pointeurs (donc, pointeurs intelligent à la rescousse, j'imagine)

Voilà pour mon point de vue (moi je suis une des entités qui peut se tromper :aie: )

Citation:
Envoyé par LittleWhite
Je vais me permettre une remarque :oops:

Sur ce code
Code:

1 2 3 4 virtual void doCollide(CollisionTwoPlayers &){} virtual void doCollide(CollisionPlayerMovingObject &){} virtual void doCollide(CollisionPlayerImmobileObject &){} virtual void doCollide(CollisionTwoMovingObject&){}
Le jour ou vous allez vouloir gérer une nouvelle collision, entre 2 FlyingObject par exemple, vous allez devoir rajouter des fonctions partout dans votre code (ce qui peut être lourd, non?)
Alors oui, vous aurez le compilateur comme aide pour vous dire que vous oublier une implémentation, donc y a cette avantage. Mais je trouve pour autant qu'après quelques types de collision, cela va vraiment alourdir le code.
Le fait est que ton FlyingObject sera soit un FlyingPlayer (héritant de Player si c'est un joureur qui peut voler), soit un FlyingObject (héritant de MovingObject)...

De plus, la collision est là pour apporter le contexte du moment où elle est survenue, il n'y aura donc à priori pas énormément de cas à rajouter, car la collision n'a même pas besoin de savoir exactement quel est le type (dynamique) des objets qui entrent en collision.

Ceci est l'exemple parfait de l'importance que peut revêtir le fait de choisir correctement la granularité de tes classes de base :

J'aurais pu regrouper la classe "joueur" et la classe "objet mobile" au prétexte que tous les deux sont capables de bouger, mais ce serait alors devenu une hiérarchie bien plus importante et j'aurais sans doute été tenté de multiplier les contextes de collision là où il n'y a pas vraiment lieu de le faire :aie:

En partant du principe qu'on a le vivant, le non vivant mais mobile et l'immobile (et non vivant), on arrive à couvrir tous les cas de figure, en n'ayant que cinq contextes potentiels (une fois retiré celui qui n'arrivera jamais :D ), dont certains ne regarderont jamais une hiérarchie donnée ;)

Le fait que la collision d'un objet mobile avec un mur fasse apparaitre un bonus (mobile) ne fera pas intervenir le joueur dans la collision en elle-même, et c'est quand le joueur rentrera en collision avec le bonus qu'une autre collision (impliquant un objet mobile et un joueur) sera créée afin de gérer le cas ;)

De cette manière, si même tu trouves la possibilité de créer 150 type de personnage, autant d'éléments de décors fixe et encore autant d'éléments de décors mobiles, tu en restera toujours à... cinq contextes reprenant l'ensemble des possibilités ;)

Citation:

N'y a t-il pas une façon plus dynamique de faire. Notamment, il se peut qu'il y ai duplication de code si deux méthodes doivent implémenter le même comportement (sauf si le cast est possible entre CollisionPlayerImmobile et CollisionPlayerMoving, mais cela ne me semble pas castable).

Tu penses sans doute au fait de pousser sur un champignon ou de casser un tronçon de mur et de voir apparaitre un bonus de vie ou autres...

Je te rassure, le cas est prévu : la collision n'agit que sur deux objets particuliers. Le fait que, en réaction à la collision, l'objet "passif" (ou plutôt subissant la collision, par opposition à l'objet qui la provoque / qui en tire profit) libère un autre objet, d'une hiérarchie potentiellement différente, n'impliquera rien d'autre que le fait de créer une nouvelle collision adaptée au moment où le jour atteindra l'objet libéré :D

Citation:

Pour le système de message, cela peut être bien (genre, on apprend qu'il y a eu collision entre un objet et un autre. Le premier objet recevant le message, connaitra l'objet qui collide avec le pointeur sur l'autre). Par contre, c'est souvent très dangereux au niveau de la mémoire et de la validité des pointeurs (donc, pointeurs intelligent à la rescousse, j'imagine)

(ca me fait que j'ai oublié un delete dans la fonction doTransmit :aie:) Les pointeurs intelligents sont une solution, une relation "collection / élément" avec une classe responsable de la durée de vie des différents objets issus d'une hiérarchie donnée (voir une variable globale plus ou moins adroitement géguisée) peut en être une autre : Ce n'est, de toutes manière, ni à la collision, ni à l'objet qui est entré en collision avec un autre, ni au détecteur de collision de veiller à la libération des ressources autres que les siennes...

Par contre, on peut (et on devrait) prévoir le fait que certains comportements de nos objets sont susceptibles d'en provoquer "la mort" (le fait qu'il ne soit plus utile de les garder en mémoire, parce qu'ils sont mort ou qu'ils ont été "cassés").

Lorsque le comportement arrive dans une situation où l'objet n'est effectivement plus utile (car cassé ou mort), c'est l'objet lui-même qui signale qu'il est devenu inutile au gestionnaire de ressources dont il dépend, qui décidera de le détruire (au sens de appeler delete :D ) où de le garder "pour un usage ultérieur" (en remettant certains membre "à place" :D )

Citation:

Voilà pour mon point de vue (moi je suis une des entités qui peut se tromper :aie: )

Mais il est très instructif aussi... et je n'ai jamais dit que je ne me trompais pas non plus, mais, l'un dans l'autre, je crois sincèrement être dans la bonne logique, et avoir envisagé, si pas tous les cas de figure, au moins une grande partie :D

08/09/2011, 23h46
LittleWhite

N'est ce pas un peu lourd ?

Dans le sens, vos fonctions sont appelées même si elles ne font rien. On va avoir beaucoup d'objets actifs. Si j'ai un allié et que je suis le Gamer, la fonction de contact des deux joueurs va devoir ne rien faire, mais elle sera tout de même appelé deux fois (une fois pour l'objet prioritaire, une fois dans le cas inverse (non prioritaire) (si je ne me trompe pas)).

Un autre point important, c'est à quel moment allons nous choisir de changer l'état d'un élément suite à la collision.
Donc, joueur tue un ennemi, d'une manière ou d'une autre. La collision apparait pour le joueur, avec en contact un ennemi. Ici, je ne vais pas changer l'état de l'ennemi, car ce n'est pas à la classe Joueur de le faire. Donc il faudra bien que la collision soit déclencher dans l'autre sens (Ennemie collision un joueur). Et là, l'ennemi va changer son état pour être mort.

Cela me fait penser aussi, qu'il faut aussi transporter un état de collision. Prenons Mario (car nous sommes radicalement parti sur ce jeu, alors qu'un shoot em up, ce gère différemment). Si je saute au dessus d'un koopa, il va mourir. Par contre, si je le touche par dessous, c'est moi qui meurt.
Le problème, c'est que ce test (dessus / dessous) est à faire pour toute les collisions, et dans les deux sens. Pourquoi (d'après moi), car si on essayait de limiter la casse, et que l'on passe l'information avec la collision, le calcul serait fait pour n'importe quel élément du jeu, ce qui est fortement inutile (les éléments immobile ne s'intéresse pas à cette histoire de dessus/dessous). Par contre, si je suis le principe, cela veut donc dire que cette information, je vais la trouver dans mon doCollide des objets en collision. Donc c'est fait deux fois (répétition de code?).
09/09/2011, 06h15
koala01

Citation:

Envoyé par LittleWhite

N'est ce pas un peu lourd ?

Dans le sens, vos fonctions sont appelées même si elles ne font rien. On va avoir beaucoup d'objets actifs.

Je ne penses pas :

Pour savoir si un objet doit interagir avec un autre, tu aurais besoin de savoir de quel type réel sont les deux objets, ce qui t'obligerait à envisager toutes les combinaisons possibles, et il y en a potentiellement beaucoup (tu ne sais pas combien de classes dériveront au final de Player ou de Mobile) !

De plus, ce n'est pas la responsabilité du détecteur de collision, et tu aurais donc besoin d'une classe supplémentaire pour y arriver.

Tu perdrais donc surement beaucoup plus de temps à vérifier si l'un des objets doit réagir (et à plus forte raison si les deux doivent réagir) qu'à simplement appeler une fonction qui ne fera rien.

Citation:

Si j'ai un allié et que je suis le Gamer, la fonction de contact des deux joueurs va devoir ne rien faire

Ou cela peut modifier l'état de ton allier, en diminuant son appréciation vis à vis de toi, et qu'il finisse par t'attaquer...

Citation:

<snip>

Un autre point important, c'est à quel moment allons nous choisir de changer l'état d'un élément suite à la collision.
Donc, joueur tue un ennemi, d'une manière ou d'une autre. La collision apparait pour le joueur, avec en contact un ennemi. Ici, je ne vais pas changer l'état de l'ennemi, car ce n'est pas à la classe Joueur de le faire.

Non, mais ce peut etre ennemi qui, d'une manière ou d'une autre, réagit à la réaction de joueur, et se place lui meme dans un état de non réactivité :

Si ma réaction au contact d'un ennemi est d'attaquer et de retirer lui six points de vie, j'aurai ennemi->defend(degats);(degat étant une classe transportant le contexte propre au dégats (type d'attaque, force, modificateurs éventuels), l'ennemi va calculer le résultat effectif, basé sur ses propres résistances et faiblesses (ou du moins appeler une logique qui s'en chargera :D ), et se retrouvera avec un nombre de point de vie à soustraire de ceux qu'il lui reste.

Si la soustraction fait que l'enemi n'est plus capable de réagir (vie < 1), il ne réagira simplement pas, mais cela, ce sera à placer justement dans les points de suspention de doCollide (quitte à ce que ce soit une fonction "alive() qui renvoie vrai ou faux, car l'état "incapable de réagir" sera surement utilisé par ailleurs)

Citation:

Donc il faudra bien que la collision soit déclencher dans l'autre sens (Ennemie collision un joueur). Et là, l'ennemi va changer son état pour être mort.

comme je l'ai dit, l'état est à changer en réaction à la réaction de l'objet prioritaire, et à tester au moment où c'est à l'objet de réagir à la collision ;)

Citation:

Cela me fait penser aussi, qu'il faut aussi transporter un état de collision. Prenons Mario (car nous sommes radicalement parti sur ce jeu, alors qu'un shoot em up, ce gère différemment). Si je saute au dessus d'un koopa, il va mourir. Par contre, si je le touche par dessous, c'est moi qui meurt.

Tu auras remarqué que la première chose dont j'ai parlé, c'est de la priorité d'action, que j'ai donné des exemples simples (basés sur le type de hiérarchie) mais que j'ai aussi dit que cela pouvait être un calcul beaucoup plus complexe...

Cela pourrait parfaitement être basé sur "celui qui arrive par au dessus sur l'autre" :D

Citation:

Le problème, c'est que ce test (dessus / dessous) est à faire pour toute les collisions, et dans les deux sens. Pourquoi (d'après moi), car si on essayait de limiter la casse, et que l'on passe l'information avec la collision, le calcul serait fait pour n'importe quel élément du jeu, ce qui est fortement inutile (les éléments immobile ne s'intéresse pas à cette histoire de dessus/dessous).

Les éléments immobiles renvoie d'office une priorité basse, mais il n'est pas exclu que, si ton joueur collide, effectivement par en dessous, que ce soit justement un cas où ton joueur devra réagir différemment que s'il était arrivé par au dessus ou par le coté (en cassant l'élément immobile, par exemple).

C'est pour cela qu'il me semble important de partir du cas de base "ne rien faire" et de se baser sur des états pour que la réaction adaptée soit mise en oeuvre ;)

Citation:

Par contre, si je suis le principe, cela veut donc dire que cette information, je vais la trouver dans mon doCollide des objets en collision. Donc c'est fait deux fois (répétition de code?).

Pas forcément, cela peut n'être qu'un état "neutre / agressif / defensif", à déterminer d'une manière ou d'une autre.

D'ailleurs, fondamentalement, la collision pourrait aussi mettre le joueur et le PNJ dans un état de "communication" (question / réponse, commerce, indifférent ... )

Tout cela est à prévoir "par ailleurs", je n'ai donné que la base pour la gestion des collisions en elles même, mais il y a toute la gestion du gameplay à faire autour ;) .

je n'ai pas le temps maintenant de donner l'exemple de code, car je pars au boulot, mais je tacherai de le faire ce soir ;)
09/09/2011, 10h06
Emmanuel Deloget

Citation:

Envoyé par JolyLoic

Tiens, pourrais tu développer les raisons qui provoquent en toi cette envie ?

1/ parce que l'OP est relativement débutant en design (sinon, il ne poserais pas la question :))

2/ parce que le design est émergent lorsqu'on crée des applications complexes, que c'est une application complexe, et que donc, il va voir ses erreurs émerger, la correction possible, bref : évoluer en même temps qu'il produit son jeu.

3/ parce qu'il va voir de visu ce qu'on entends pas système ouvert à l'extension et fermé à la modification :)

4/ parce que c'est un bon exercice de design, et de correction de design, qui intervient très tôt dans le cycle de développement, et qui est donc corrigeable rapidement.

Il doit bien y avoir d'autres raisons, mais c'était hier, et entre temps, j'ai dormi et je n'ai plus la même perception des choses :mouarf:

@koala01
Il y a 2 choses qui me gène avec ta solution :

- Au final, on ne supprime pas totalement la nécessité d'utiliser des switch/if et de connaître le type réel des objets. Imaginons par exemple que pour le personnage, on a un état associé + un type d'arme et que pour l'ennemi, on a un état et une armure (on n'est plus totalement dans le cas d'un mario), on va arriver dans le doCollide à faire un switch pour tester les différentes possibilités :
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 virtual void doCollide(CollisionTwoPlayers &player) { switch (this->arme().type()) // ok, on a un problème d'encapsulation { case EPEE: { player.defend(degats); } case LASER: { switch (player->armure().type()) { case BOUCLIER_MIRROIR: { this->defend(degats); } case DEFAULT: { player.defend(degats); } } } } }
Je vois pas par exemple comment virer le switch pour éviter de devoir tester les types d'armes et le type d'armure et du coup l'interaction entre eux aussi en évitant le switch. On arrive forcement à une hiérarchie très complexe dès que l'on a plusieurs éléments à prendre en compte en même temps pour déduire le type d'interaction qu'il faut appliquer.

- Le plus gros problème est que la structure est forcement statique : si on veut ajouter un nouveau type d'interaction qui fait autre chose que faire des dégâts, on est obliger de modifier le code C++. Et il n'est pas possible d'ajouter des nouvelles interactions par scripts. Ce qui est parfois dommage pour les jeux.

Pour le moment, je teste la solution suivante : un dispatcher, c'est finalement une suite de critères qui détermine un action précise. Chaque type de critère (type d'objet, type d'arme, état, etc. peut importe) est contenu dans une collection et identifié par un type ou un id unique dans la collection (un certain nombre de types par défaut sont définit "en dur" mais il est possible d'en ajouter par script). Idem pour les actions possible. Ensuite, je garde dans une table 2D (ou un arbre) la liste des id pour les critères et l'id (ou les id) de l'action à déclencher. La table peut être créé dynamique (c'est un simple vecteur de unsigned), sauvegarder, scripté, etc.

En pseudo code, on a quelque chose comme ça :
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 // création des critères PlayerCollection players; players.append(new Gamer); players.append(new Mob); players.append(new Mob); players.append(new Mob); WeaponCollection weapons; weapons.append(new Épée); weapons.append(new Marteau); StateCollection states; states.append(new Attente); states.append(new Patrouille); states.append(new Attaque); PerceptionCollection perceptions; perceptions.append(new Entendre); perceptions.append(new Voir); perceptions.append(new Toucher); // autant de critères que l'on veut // Création des actions ActionCollection actions; actions.append(new Patrouiller); actions.append(new Attaquer); actions.append(new Frapper); actions.append(new Assommer); actions.append(new Désarmer); // création de la table // la table est un tableau contenant dans l'ordre player_type, weapon_type, state_type et perception_type // mais il n'est pas nécessaire d'avoir tous les critères Dispatcher dispatch; // Si le joueur fait du bruit et que le mob est en attente, il commence à pattrouiller dispatcher.append(GameType, MobType, AllType, AttenteType, EntendreType, PattrouillerAction); // Si le mob voit le joueur, il l'attaque dispatcher.append(GameType, MobType, AllType, AllType, VoirType, AttaquerAction); // Si le mob peut toucher le joueur, il frappe dispatcher.append(GameType, MobType, AllType, AttaqueType, ToucherType, FrapperAction); // Si en plus, le mob a un marteau, il peut assommer le joueur dispatcher.append(GameType, MobType, MarteauType, AttaqueType, ToucherType, FrapperAction); //etc.
La classe Perception permet de définir plusieurs types de perception (par exemple, une zone de toucher circulaire de 1m, une zone d'écoute circulaire de 10m, un zone de vue en cône de 20m à 45°, etc.) mais également d'activer les actions en allant chercher dans le dispatcher les actions à activer en fonction des critères.

Forcement, c'est pas très "advanced C++" mais c'est très dynamique. Il ne faut modifier le code que si on ajoute une nouvelle collection de critère. Le coût de la création du tableau et des classes n'intervient qu'a l'initialisation (soit directement dans le script d'initialisation, soit dans un fichier de sauvegarde de la table). Le coût pour trouver les actions a lancer n'est pas énorme non plus (surtout que c'est pour du game design, les calculs complexe s'il en a sont quand même en C++ et pas en script... sauf si on le veut ; en gros, il faut un map::find par critère).

Je sais pas ce que vous pensez de cette structure ?

10/09/2011, 06h45
marcolo21
Bonjour,

Tous d’abord merci beaucoup d’avoir pris le temps de réfléchir à mon problème.

@koala01 : Ta solution me semble intéressante, cependant je me posais quelque question :
Quelle est la différence entre tous les types aux niveaux du code (à part les noms des classes) ?
Car si j’ai bien compris tous les types d’objet ont besoin des fonctions DoColide et Colide.

Ensuite, où dois-je placer le test de collision dans ta structure? Dans la classe TColision ?

Pour le sens de la collision (dessus, dessous, etc) j’avais pensé à me crée un enum du type :
Code:

1 2 3 4 5 6 7 8 Enum ColisionSens { Haut, Bas, Gauche, Droite, None }
Ensuite, la fonction qui teste s’il y a une collision renvoie le sens de la collision (en se fiant sur l’objet principal pour dire le sens) ou None s’il n’y a pas de collision. Je passerai cet enum au fonction DoColide et gèrerai les différents, cas avec un switch case sur l'enum.

J’en reviens toujours à une question. Par exemple si l’ennemi a des piquants qui font mal au personnage lorsqu’il saute dessus, où est-ce que je place la fonction Personnage.Hurt() ? Je crois que cela devrait être dans l’ennemi puisque seul lui sait s’il a des piquants ou non, mais alors il faudrait que je fasse attention de ne pas tuer l’ennemi avant dans le DoColide du personnage puisque lui ne sait pas qu’il se fera mal en sautant dessus (je ne sais pas si vous comprenez bien ce que je veux dire, j’ai un peu de difficulté à l’expliquer).

De plus, une autre petite difficulté par rapport à vos classes de type. Un ennemi est de type MovingObject tous comme un bloc pourrait l’être. Alors, comment utiliser les fonctions spécifiques aux ennemis par exemple, puisque l’objet qu’on reçoit en paramètre dans le DoColide est un objet de type MovingObjet et non de type ennemi.

Citation:

1/ parce que l'OP est relativement débutant en design (sinon, il ne poserais pas la question )

Effectivement je suis relativement débutant en design et conception, cependant je ne suis pas débutant en programmation, donc pour ce qui est des questions de code je ne devrai pas avoir trop de problème

Merci encore pour votre aide.

Citation:
Envoyé par gbdivers
@koala01
Il y a 2 choses qui me gène avec ta solution :

- Au final, on ne supprime pas totalement la nécessité d'utiliser des switch/if et de connaître le type réel des objets. Imaginons par exemple que pour le personnage, on a un état associé + un type d'arme et que pour l'ennemi, on a un état et une armure (on n'est plus totalement dans le cas d'un mario), on va arriver dans le doCollide à faire un switch pour tester les différentes possibilités :
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 virtual void doCollide(CollisionTwoPlayers &player) { switch (this->arme().type()) // ok, on a un problème d'encapsulation { case EPEE: { player.defend(degats); } case LASER: { switch (player->armure().type()) { case BOUCLIER_MIRROIR: { this->defend(degats); } case DEFAULT: { player.defend(degats); } } } } }
Je vois pas par exemple comment virer le switch pour éviter de devoir tester les types d'armes et le type d'armure et du coup l'interaction entre eux aussi en évitant le switch. On arrive forcement à une hiérarchie très complexe dès que l'on a plusieurs éléments à prendre en compte en même temps pour déduire le type d'interaction qu'il faut appliquer.
Tu ne vois pas comment éviter le switch parce que tu donne trop de responsabilités à ta fonction (et donc à ta classe) !!!

Le joueur doit déjà gérer ses propres états, c'est déjà amplement suffisant, il n'y a aucune raison pour qu'il doive, en plus, gérer les états des autres ;) !!!

Ce n'est pas au joueur qui attaque de décider du nombre de dégats que l'adversaire va effectivement subir... Et ce n'est surtout pas son rôle d'essayer de savoir quel type d'armure l'adversaire porte!

Le role de l'attaquant est simplement de déterminer (grace à ses états propres) le nombre et le type de dégats qu'il est capable d'occasionner.

C'est à l'adversaire de savoir s'il porte une armure, et, si c'est le cas, il devra demander à l'armure (ou aux différents éléments d'armure qu'il porte !) de modifier les dégats subits en fonction de leurs résistances propres.

Du coté de l'attaquant, les dégats qu'il occasionne sont fonction de son arme (mais une arme est une arme, et c'est donc l'arme qui aura une fonction damage() qui créera une instance de la classe Damage en fonction de sa propre décoration :D ) et de certains "modificateurs" qui sont propre à son état de santé, à sa force ou à sa race.

tu commencerais donc par, lorsque la réaction est d'attaquer, par demander à ton arme ou à ton sort (selon l'état dans lequel tu te trouve) de te fournir les dégats "de base", que tu modifie selon les modificateurs "type" propres à ta race ou à ton état de santé.

Puis, une fois que tu as déterminé avec exactitude les dégats que tu es capable d'occasionner, tu les transmet à ton adversaire, à charge pour lui de savoir comment il va réagir aux dégats que tu essaye d'occasionner ;)

Cela donnerait 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 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 66 67 class Player { private: virtual void doCollide(CollisionTwoPlayers &player) { /* on commence par savoir si je suis le premier ou le deuxième * dans la priorité de collision car je dois attaquer l'autre * (je ne peux quand meme pas m'attaquer moi-même :D ) */ Player * other = player.first(); if(other == this ) other = player.second(); /* et je réagit en fonction de ma posture */ switch (state_->postureType()) { /* je peux être dans une phase de commerce... */ case postureTrading : other->trade(this); break; /* je peux être endormi */ case postureSleeping: break; /* je peux être dans une posture de défense */ case postureDefend : break; /* je peux être dans une posture d'attaque avec sort */ case postureAttackWithSpell: attackWithSpell(other); break; /* ou dans une posture d'attaque avec arme */ case postureAttackWithWeapon: attackWithWeapon(other); } } /* virtual */ void postureAttackWithWeapon(Player * ennemy) { /* je n'ai qu'à créer les dégats que j'inflige, à charge * de mon ennemi de voir comment il y réagit :D */ /* je pars des dégats que mon arme me permet d'infliger */ Damage acurate = weapon_->damages(); /* je les modifie en fonction de mon état général (force, santé, * maladies éventuelles, ou que sais-je); */ acurate = modifyDamage(acurate); /* puis je les envoies à l'ennem */ other->defend(acurate); } /* virtual */ void postureAttackWithSpell(Player * ennemy) { /* je n'ai qu'à créer les dégats que j'inflige, à charge * de mon ennemi de voir comment il y réagit :D */ /* je pars des dégats que mon arme me permet d'infliger */ Damage acurate = spell_->damages(); /* je les modifie en fonction de mon état général (force, santé, * maladies éventuelles, ou que sais-je); */ acurate = modifyDamage(acurate); /* puis je les envoies à l'ennemi, à charge pour lui de voir comment * il y réagit :D */ other->defend(acurate); } };
Dans le pire des cas, tu devra t'inquiéter de savoir s'il s'agit de dégats à distance ou de dégats de contact, car, s'il s'agit de dégats à distance, tu n'es, a priori, pas dans un contexte de collision, mais tu va lancer ton sort (ou ton arme de jet) vers l'adversaire, et créer un "contexte de collision espéré" entre ce que tu as lancé et l'adversaire.

En choisissant la granularité qui va bien, tu arrive à une situation dans laquele tout ne doit réagir (en cas d'attaque) qu'à un certain nombre (finalement très restreint :D ) de type de dégats pour en atténuer les effets.
on pourrait citer :

les différents dégâts dus aux différents types de sorts (de terre, d'eau, de feu, d'air, de froid, élementaires, et "mysthiques")
les différents dégâts dus aux différents types de coups (contondants, percutant, tranchants, à main nue)
Et cela peut parfaitement tenir dans un simple tableau d'entiers qui représente l'atténuation des dégats ;) (on peut même en arriver à faire en sorte qu'une armure puisse augmenter les dégats du à un type d'attaque en mettant une valeur négative :D )

Tout ce qu'il te faut, c'est une énumération reprenant les types générique de dégats envisagés (le fait que le sort de feu s'appelle "tempête de feu" ou "ouragan incandescent" n'a pas beaucoup d'importance ici :D ) proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 enum DamageType { /* les dégats non magiques */ noDamage = 0, // aucun dégats damageFreeHand , // dégats à main nue damageBlunt , // dégats contondants damageCrushing, // dégats percutants damageCutting, // dégats coupants /* les dégats magiques */ damageFire, // dégats de feu damageWater, // dégat d'eau damageFrost, // dégats de froid damageHeart, // dégats de terre damageAir, // degats d'air /* les autres types de dégats */ damageElemental, //degats élémentaires damageMisthysism, // dégats mistiques };
Tu aurais une classe damage qui ressemblerait à
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 class Damage { public: Damage(int v, DamageType t) DamageType type() const{return type_;} int value() const{return value_;} /* je passe sur la partie qui permet de gérer facilement * la liaison de plusieurs dégats successifs (une épée de * feu occasionnant des dégats coupants puis des dégats * de feu :D ) pour rester simple */ private: int value_; DamageType type_; };
Tout ce qui est susceptible de diminuer (ou d'augmenter) les dégats présentera une interface proche de
Code:

1 2 3 4 5 class LaClass { public: Damage resistTo(Damage const &); };
Pour une armure, cela pourrait etre proche de
Code:

1 2 3 4 5 6 Damage Armor::resistTo(Damage const & toResist): { /* éventuellement gérer les dégats infligés à l'armure elle-même */ return Damage(resistances_[toResist.type()],toResist.type()); }
et prendrait, pour un joueur, la forme de
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 Damage Armor::resistTo(Damage const & toResist): { /* on part de ma résistance naturelle à un type donné de dégats */ int resist = resistances_[toResist.type]; /* qui peut être modifiée par la "posture" dans laquelle je me trouve */ switch (state->posture().type() ) { case postureAsleep : // si je dors, ma résistance naturelle est vraiment // minime resist /=4; break; case postureTrading : // quand je fais du commerce, elle l'est un peu // moins, mais je reste plus vulnérable que la normale resist /= 3; break; case postureAttacking : // quand j'attaque, je suis encore moins // vulnérable mais quand meme plus que si je me // défendais resist /=2; break; case postureDefending : //et quand je me défend, j'ai un bonus de // protection resist *=2; break; } return Damage(toResist.value()-resist, toResist.type()); }
et tout ce qui est susceptible d'augmenter les dégats aurait une interface proche de Damage augmentDamage(Damage const & );Quand on invoque la fonction "defend" d'un joueur, il commence simplement par modifier les degats qu'on tente de lui occasionner sous une forme proche de
Code:

1 2 3 4 5 6 7 8 void Player::Defend(Damage const & originalDamage) { Damage real(originalDamage); if(armor_) // si j'ai une armure real = armor_->resistTo(real); // l'armure encaisse le choc et l'amoindri real = resistTo(real); // mes résistances naturelles entrent en jeu live_ -= real.value(); // et je prend le reste dans les gencives }
Evidemment, j'ai pris le cas particulier d'un adversaire susceptible d'être attaqué, mais ce doit etre considéré comme un comportement adaptable (fonction virtuelle, voire NVI)

Citation:

- Le plus gros problème est que la structure est forcement statique : si on veut ajouter un nouveau type d'interaction qui fait autre chose que faire des dégâts, on est obliger de modifier le code C++. Et il n'est pas possible d'ajouter des nouvelles interactions par scripts. Ce qui est parfois dommage pour les jeux.

Absolument pas...

A partir du moment où tu as la granularité adéquate pour tes objets (un sort est un sort, quel qu'il soit, une arme, fusse-t-elle enchantée ou à deux mains est une arme et une piece d'armure est une piece d'armure, que ce soit un bracelet, un casque ou un plastron), et où tu te donnes l'occasion d'en décorer certains (histoire de pouvoir avoir l'épée du bon dieu qui est une rapière en crystal sertie de telle et de telle pierre), il ne te manque qu'une fabrique et une collection dans laquelle ranger tous les objets en attendant de les utiliser pour être en mesure de scripter ton jeu!

Bien sur, il te faut plusieurs gestionnaires distincts (en gros, un par (sous) hiérarchie envisagé), bien sur, l'inventaire n'est pas "simplement" une collection de "objects" mais est composé d'une collection de "Weapons", d'une autre de "Potions", d'une troisième de "Spells" et d'une quatrième de "ArmorItem", mais cela te facilitera au contraire grandement la vie, ne serait-ce que pour pouvoir présenter ton inventaire sous la forme d'onglets, ou pour pouvoir déterminer si tu peux mettre tel ou tel objet à tel ou tel endroit de l'équipement :D

Arrange toi pour accéder (éventuellement de manière indirecte) à ta fabrique et à tes gestionnaires dans ton script, et le tour est joué ;)

10/09/2011, 21h25
gbdivers

En voyant ta réponse, je réalise que je n'ai pas été forcement très clair et que l'exemple choisit n'est pas idéal. En effet, pour l'exemple avec le type d'arme et le type d'armure, j'aurais fait comme toi. Cette configuration ne pose pas de problème.
Je pensais plus à quelque chose comme le grappin dans zelda, qui pouvait attraper des choses, casser une armure (dans certain cas je crois), assommer quelqu'un (dans certain aussi je crois), déplacer le personnage, activer des interrupteurs ou faire des dégâts.
Mais il est vrai que je n'ai pas réfléchi non plus à fond à la structure qui réalisait tout ça. Peut être qu'elle est effectivement aussi simple.

Pour le second point, lorsque je parlais de statique, je ne pensais pas du tout au fait de paramétrer un objet (les dégâts que font une arme, les dégâts encaissés par une armure, etc.) mais à ajouter de nouvelles "fonctionnalités" dans le script. Pour être plus précis, pour éviter que si un game designer à une idée, il faille modifier le code pour l'implémenter.
Justement, ton exemple d'associer des éléments aux dégâts me correspond à ce qui me chagrine. Pour ajouter cette fonctionnalité, tu as du modifier le code. Si un game designer te dit qu'il veut ajouter des dégâts dans le temps, a priori, le code actuel ne le permet pas. Il faut le modifier. Idem pour toutes nouvelles fonctionnalités. (je sais que j'en demande beaucoup :) )

Bref, ta solution est ce que j'aurais fait aussi. Mais je cherchais une plus grande souplesse d'où l'idée que j'ai proposé. Je testerai et je verrai à l'utilisation.

PS : il me semble que ce problème à déjà était abordé par Emmanuel sur son blog, non ?
11/09/2011, 09h27
koala01
Citation:

Envoyé par gbdivers

En voyant ta réponse, je réalise que je n'ai pas été forcement très clair et que l'exemple choisit n'est pas idéal. En effet, pour l'exemple avec le type d'arme et le type d'armure, j'aurais fait comme toi. Cette configuration ne pose pas de problème.
Je pensais plus à quelque chose comme le grappin dans zelda, qui pouvait attraper des choses, casser une armure (dans certain cas je crois), assommer quelqu'un (dans certain aussi je crois), déplacer le personnage, activer des interrupteurs ou faire des dégâts.
Mais il est vrai que je n'ai pas réfléchi non plus à fond à la structure qui réalisait tout ça. Peut être qu'elle est effectivement aussi simple.

Pour le grappin de Zelda, il y a de fortes chances pour que ce soit le type d'objet frappé par lui (ou ses décorations) qui choisisse si le grappin s'y accroche ou non, si le personnage est assommé ou blessé!

Le reste en découle : si le grappin s'accroche, lorsqu'il se "rembobine", il "tire avec lui" ce qui y est accroché, dans un sens ou dans l'autre ;)

Citation:

Pour le second point, lorsque je parlais de statique, je ne pensais pas du tout au fait de paramétrer un objet (les dégâts que font une arme, les dégâts encaissés par une armure, etc.) mais à ajouter de nouvelles "fonctionnalités" dans le script. Pour être plus précis, pour éviter que si un game designer à une idée, il faille modifier le code pour l'implémenter.
Justement, ton exemple d'associer des éléments aux dégâts me correspond à ce qui me chagrine. Pour ajouter cette fonctionnalité, tu as du modifier le code. Si un game designer te dit qu'il veut ajouter des dégâts dans le temps, a priori, le code actuel ne le permet pas. Il faut le modifier. Idem pour toutes nouvelles fonctionnalités. (je sais que j'en demande beaucoup :) )

Attends, tu changes fondamentalement les besoins, il est donc normal que l'analyse générale doive évoluer!!!

On passe d'un scénario où il n'y a qu'à réagir à la collision à un scénario où l'on doit prendre différents types d'armes, de sorts et de réactions en fonction de différentes situations! ce n'est pas le genre de changement tout à fait anodin!

Ce qui est sur, c'est que si tu partage correctement les responsabilités et que tu garde une granularité correcte dans tes hiérarchies de classes (que tu évites de partir d'un god object qui va regrouper les personnages, les armes les sorts et les éléments de décors), tu auras beaucoup plus facile à faire évoluer les choses!

Et, une fois que tu as les bonnes choses au bon endroit, si le game designer décide de donner à un ennemi une arme suprême, il n'y aura qu'à donner les caractéristiques adéquates dans ton script ;)

En outre, je n'ai fait que préciser un code que j'avais remplacé par des points de suspension à la base, même si cela a nécessité l'ajout de fonctions adaptées (qu'il n'était pas nécessaire de préciser dans mon premier code ) ;)

Après tout, lorsque tu vas démarrer l'analyse de ton jeu, il y a de fortes chances pour qu'elle contienne dans les premières pages :
Citation:
Un personnage peut disposer d'un inventaire, dont les différents éléments sont

les armes
les pieces d'armures
les objets à "usage unique" (potion, ...)
les objets de quête
...
et peut disposer de sorts parmi lesquels on peut distinguer les sorts d'attaque et les sorts de défense

Le personnage peut décider d'utiliser soit une arme, soit un sort lorsqu'il interagit avec quelque chose
car ca fait partie du gameplay global et général ;) (c'est ce qui fait la différence fondamentale entre un mario et un Ghotic :D )
11/09/2011, 16h55
gbdivers

Citation:

Envoyé par koala01

Attends, tu changes fondamentalement les besoins, il est donc normal que l'analyse générale doive évoluer!!!

J'avoue :D
12/09/2011, 00h03
marcolo21

Bonjour,

J'aimerai bien avoir quelque explication par rapport à mon post précédant, ce sont des interrogations que je me pose toujours.

merci beaucoup

Citation:

Envoyé par marcolo21

Bonjour,

J'aimerai bien avoir quelque explication par rapport à mon post précédant, ce sont des interrogations que je me pose toujours.

merci beaucoup

oui, excuses nous...

Citation:

Envoyé par marcolo21

Bonjour,

@koala01 : Ta solution me semble intéressante, cependant je me posais quelque question :
Quelle est la différence entre tous les types aux niveaux du code (à part les noms des classes) ?

La différence fondamentale est justement leur nom, et surtout la sémantique que tu donne à ce nom!!

L'héritage est la relation la plus forte qui puisse exister en POO, c'est à dire que c'est celle qui doit être employée le moins souvent possible: elle correspond à la relation EST UN, dans toute la sémantique du terme.

Tu peux très bien trouver 150 types différents ayant tous une interface identique sans arriver à trouver une classe de base qui soit commune à tous (sans arriver à dire pour chacun des 150 type "un objet de tel type EST UN objet de la classe de base spécialisé)

Citation:

Car si j’ai bien compris tous les types d’objet ont besoin des fonctions DoColide et Colide.

Seules les classes de base ont besoin de la fonction collide (les autres en hériteront !), toutes les classes ont besoin de la fonction doCollide, implémentée en fonction des besoins

Citation:

Ensuite, où dois-je placer le test de collision dans ta structure? Dans la classe TColision ?

Non, dans une structure tout à fait séparée (je l'avais appelée CollisionDetector ;) ) qui va tester la position des différents éléments et voir s'il entrent en collision
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 Pour le sens de la collision (dessus, dessous, etc) j’avais pensé à me crée un enum du type : Code: 12345678 Enum ColisionSens { Haut, Bas, Gauche, Droite, None } Ensuite, la fonction qui teste s’il y a une collision renvoie le sens de la collision (en se fiant sur l’objet principal pour dire le sens) ou None s’il n’y a pas de collision. Je passerai cet enum au fonction DoColide et gèrerai les différents, cas avec un switch case sur l'enum.
l'idée de créer une énumération est toujours bonne, l'utilisation dans un switch me semble hasardeuse... je réfléchirai plus longuement quand j'aurai cinq minutes ;)

Citation:

J’en reviens toujours à une question. Par exemple si l’ennemi a des piquants qui font mal au personnage lorsqu’il saute dessus, où est-ce que je place la fonction Personnage.Hurt() ? Je crois que cela devrait être dans l’ennemi puisque seul lui sait s’il a des piquants ou non,

Exactement, tu l'appelle dans sa propre fonction doCollide

Citation:

mais alors il faudrait que je fasse attention de ne pas tuer l’ennemi avant dans le DoColide du personnage puisque lui ne sait pas qu’il se fera mal en sautant dessus (je ne sais pas si vous comprenez bien ce que je veux dire, j’ai un peu de difficulté à l’expliquer).

je comprends très bien ce que tu veux dire ;-) tu n'auras qu'à faire en sorte que ton ennemi ne meure pas lorsque tu appelle la fonction de réaction (à l'action du joueur) (react :question:)

Citation:

De plus, une autre petite difficulté par rapport à vos classes de type. Un ennemi est de type MovingObject tous comme un bloc pourrait l’être. Alors, comment utiliser les fonctions spécifiques aux ennemis par exemple, puisque l’objet qu’on reçoit en paramètre dans le DoColide est un objet de type MovingObjet et non de type ennemi.

Tu penses là aux boulets de canon et autres saloperie du genre, sans doute :question: tu peux très bien créer une classe MovingObjectEnnemi qui hérite de MovingObject, mais pas de EnnemyPlayer (qui elle hérite de Player) qui, lorsqu'il entrera en collision avec (toi :question:) sera en mesure de te tuer ;)

Citation:

Envoyé par koala01

oui, excuses nous...

Pas de problème, pendant une seconde j'ai cru que mon message ne s'était pas envoyé :P

Citation:

Envoyé par koala01

La différence fondamentale est justement leur nom, et surtout la sémantique que tu donne à ce nom!!

Donc en gros les 4 classes sont pareil, ils ne contiennent que des fonctions virtuel (virtuel pure ?). Je peux donc faire un copier coller et changer le nom pour crées les 4 classes.

Citation:

Envoyé par koala01

Non, dans une structure tout à fait séparée (je l'avais appelée CollisionDetector ;) ) qui va tester la position des différents éléments et voir s'il entrent en collision

Ok tu doit parler de ce code:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 class CollisionDetector { public: /* j'aime les template pour éviter de devoir réécrire * vingt fois la même chose :D template <typename FirstType, SecondType> static void detect(FirstType * one, SecondType * second) { /*logique de détection de collision */ /* logique de sélection de priorité */ sendCollision(mostPriorItem, secondPriorItem); } private: template <typename FirstType, SecondType> void sendCollision(FirstType * mostPriorItem, SecondType * secondPriorItem) { Colllision * col = CollisionFactory::createCollection(mostPriorItem, secondPRior); col->transmit(); } };
Je remarque que tu utilise une Factory. Je ne sais pas exactement ce que c'est (j'avais trouver un lien sur developpez qui l'expliquait un peu), aurais-tu quelque lien qui explique comment c'est fait et à quoi cela sert ?

De plus, est-ce que c'est la fonction qui teste s'il y a une collision qui doit appeler la fonction sendCollision ?

Citation:

Envoyé par koala01

l'idée de créer une énumération est toujours bonne, l'utilisation dans un switch me semble hasardeuse... je réfléchirai plus longuement quand j'aurai cinq minutes ;)

Pour l'instant je crois que je vais y allez avec l'enumeration, faute de meilleur idée. Si tu a une meilleur idée, n'hésite pas à la poster.

Citation:

Envoyé par koala01

je comprends très bien ce que tu veux dire ;-) tu n'auras qu'à faire en sorte que ton ennemi ne meure pas lorsque tu appelle la fonction de réaction (à l'action du joueur) (react :question:)

Alors, je dois crée une fonction pour chaque réaction ? Exemple: Ennemis.ReactJumping(), Ennemis.ReactAttacking(), etc. ???
Qu'est-ce que je passerai en paramètre à cette fonction ?

Citation:

Envoyé par koala01

Tu penses là aux boulets de canon et autres saloperie du genre, sans doute :question: tu peux très bien créer une classe MovingObjectEnnemi qui hérite de MovingObject, mais pas de EnnemyPlayer (qui elle hérite de Player) qui, lorsqu'il entrera en collision avec (toi :question:) sera en mesure de te tuer ;)

En faite je parlai plus dans le sens de si je suis dans la classe personnage et que je suis dans la fonction :

Code:

virtual void doCollide(CollisionPlayerMovingObject &)

Si l'objet reçu en paramètre est un MovingObject, Comment savoir si ce MovingObject est un ennemi et pouvoir utiliser les fonctions spécifiques au ennemis par exemple ? Puisque si je comprend bien les seuls fonctions que MovingObject a son les DoColide, donc s'ils sont des Ennemis, je n'ai pas accès au fonction des ennemis.

Merci beaucoup

Citation:

Envoyé par marcolo21

P
Donc en gros les 4 classes sont pareil, ils ne contiennent que des fonctions virtuel (virtuel pure ?). Je peux donc faire un copier coller et changer le nom pour crées les 4 classes.

Pour ce qui est des trois classes de bases (Player, MovingObject et NonMovableObject), oui (en veillant à le placer dans des fichiers séparés, de manière à ne pas imposer la connaissance des deux autres lorsque tu a besoin d'une classe de base particulière :D )

Par contre, pour les classes dérivées (Gamer ( = toi), Ennemy ( == un "mechant" personnage), Bullet ( == un boulet de canon, héritant de ... MovingObject) ou Interruptor (== un interrupteur, héritant de NonMovableObject), seule les fonctions virtuelles ( doCollide( ... ) ) devront être déclarées et définies.
Citation:
Ok tu doit parler de ce code:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 class CollisionDetector { public: /* j'aime les template pour éviter de devoir réécrire * vingt fois la même chose :D template <typename FirstType, SecondType> static void detect(FirstType * one, SecondType * second) { /*logique de détection de collision */ /* logique de sélection de priorité */ sendCollision(mostPriorItem, secondPriorItem); } private: template <typename FirstType, SecondType> void sendCollision(FirstType * mostPriorItem, SecondType * secondPriorItem) { Colllision * col = CollisionFactory::createCollection(mostPriorItem, secondPRior); col->transmit(); } };
Oui, c'est bien de lui que je parle :d

Citation:

Je remarque que tu utilise une Factory. Je ne sais pas exactement ce que c'est (j'avais trouver un lien sur developpez qui l'expliquait un peu), aurais-tu quelque lien qui explique comment c'est fait et à quoi cela sert ?

L'idée d'une factory (d'une fabrique, en francais) est de déléguer et de centraliser en un point unique la création d'objets polymorphes ( comme les différents types de collisions) de manière à éviter autant que possible que d'autres objets n'aillent les créer de manière anarchique.

Il faut comprendre que le gros de la gestion de la collision sera déjà dévolu au CollisionDetector (c'est lui qui devra la détruire quand elle sera devenue inutile, c'est lui qui décidera de quant en créer une, et c'est lui enfin qui invoquera la fonction collide des deux éléments qui sont rentrés en collision).

Cela fait déjà beaucoup pour une seule classe, d'autant plus qu'il doit donc avoir une connaissance de l'ensemble des éléments (quels qu'en soient le type) qui sont affichés, afin de pouvoir, justement, calculer si collision il y a :P

Le but de la fabrique est de prendre en charge le choix du type de collision à créer et la création effective.

Il faut comprendre aussi que, comme nous sommes dans une logique d'héritage (que ce soit pour les collisions ou pour les autres hiérarchies) à but polymorphe (l'idée est de pouvoir gérer les différents éléments de chaque hiérarchie en les faisant passer comme étant du type de leur classe de base, sans avoir à s'inquiéter de leur type réel), tous les types que tu pourrais créer au départ de ces classes de base on une sémantique d'entité (cf la FAQ pour plus d'infos sur ce qu'on entend par là ;) ) et qu'il ne devraient donc pas être susceptibles d'être copiés ni affecté (seule l'utilisation de références et de pointeurs sur les objets existants devrait être admise ailleurs qu'au sein de la fabrique.

Le gros avantage de travailler de la sorte, c'est que, si un jour tu souhaites rajouter un type (on a parlé des "FlyingEnnemy" et des "FlyingObject" :D ), le seul endroit que tu devras modifier (ou peu s'en faut) sera... la fabrique (de MovableObject ou de Player, ici), parce que c'est le seul endroit où l'on aura effectivement besoin de connaitre le type réel (partout ailleurs, les objets seront traités comme des "Player" ou comme des MovableObject, sans s'inquiéter de savoir si ce sont des boulet de canon, des oiseaux ou des dragons :D )

Citation:

De plus, est-ce que c'est la fonction qui teste s'il y a une collision qui doit appeler la fonction sendCollision ?

Ouupss, j'ai oublié de fermer mes commentaires :aie: je vais corriger mon code ;)

Pour l'instant je crois que je vais y allez avec l'enumeration, faute de meilleur idée. Si tu a une meilleur idée, n'hésite pas à la poster.

Alors, je dois crée une fonction pour chaque réaction ? Exemple: Ennemis.ReactJumping(), Ennemis.ReactAttacking(), etc. ???
Qu'est-ce que je passerai en paramètre à cette fonction ?

c'est une fonction statique (car elle doit etre accessible sans qu'il n'existe forcément d'instance particulière de CollisionDetector), que j'ai rendue template pour m'éviter d'avoir à réécrire le code pour l'ensemble des possibilités (après tout, ce qui importe, c'est que deux "choses" entre en collision :D ) et que je remets ici:
Code:

1 2 3 4 5 6 7 template <typename FirstType, SecondType> static void detect(FirstType * one, SecondType * second) { /*logique de détection de collision */ /* logique de sélection de priorité */ sendCollision(mostPriorItem, secondPriorItem); }
Citation:

En faite je parlai plus dans le sens de si je suis dans la classe personnage et que je suis dans la fonction :

Code:

virtual void doCollide(CollisionPlayerMovingObject &)

Si l'objet reçu en paramètre est un MovingObject, Comment savoir!!! tout ce que tu as à faire, c'est réagir à la touch si ce MovingObject est un ennemi et pouvoir utiliser les fonctions spécifiques au ennemis par exemple ? Puisque si je comprend bien les seuls fonctions que MovingObject a son les DoColide, donc s'ils sont des Ennemis, je n'ai pas accès au fonction des ennemis.

C'est ma faute, je me suis arrêté à l'aspect "collision", mais, en gros, tu peux avoir (à peu près) cinq grosse réactions face à un objet mobile:

essayer de le retenir
essayer de grimper dessus
essayer de l'agripper
essayer de sauter au dessus
essayer de passer en dessous

Mais ces réactions seront commandées par... la touche enfoncée au moment de la collision ;),en ce qui te concerne du moins, par une logique et des algorithmes adaptés pour les autres types, voire, avoir des réactions tout à fait différentes :D (un objet immobile a peu de chance d'essayer de te sauter dessus :D )

Comme nous sommes dans un système d'interaction, un objet mobile va... réagir à chacune de ces tentative (grâce à des fonctions comme Climbed, jumpedOver, catched() ou passedUnder, par exemple)

Ces fonctions suivraient le même principe que collide et doCollide() (comprend : invoqueraient une fonction virtuelle privée à redéfinir si la réaction "par défaut" ne convient pas).

Tu n'aurais donc même pas à savoir que l'objet mobile que tu essaye d'attraper est un ennemi... sa réaction lorsque tu tenteras de le faire te le fera bien sentir :D (parce que, pas de bol, essayer d'attraper un ennemi à mains nues fera que cet ennemi te tuera, ou qu'il ne réagira pas à cette tentative, mais que sa réaction à une collision avec toi (qui arrivera juste après) le fera :D)

L'idée de base est, vraiment, de faire en sorte que chaque type d'objet ne connaisse qu'un minimum de types différents et aussi génériques que possible (les classes de base de nos quatre hiérarchies expliquées dans ma première intervention + les différents type réels de collision).

C'est le polymorphisme en réaction à une tentative donnée de ta part (ou en réaction à la collision avec toi) qui te permettra de faire qu'un objet immobile commence à descendre (parce que ton poids le pousse vers le bas), éclate (parce que tu lui a donné un coup de tête) te tue (parce que tu es face à un ennemi avec des picots) ou que justement cet ennemi meure (parce qu'il sera entré en collision avec... une carapace de tortue que tu lui auras jeté) ;)

12/09/2011, 21h46
marcolo21
Citation:

Envoyé par koala01

L'idée d'une factory (d'une fabrique, en français) est de déléguer et de centraliser en un point unique la création d'objets polymorphes ( comme les différents types de collisions) de manière à éviter autant que possible que d'autres objets n'aillent les créer de manière anarchique.

Ok merci je vais essayer de me renseigner sur la factory pour voir comment cela marche

Citation:

Envoyé par koala01

Il faut comprendre que le gros de la gestion de la collision sera déjà dévolu au CollisionDetector (c'est lui qui devra la détruire quand elle sera devenue inutile, c'est lui qui décidera de quant en créer une, et c'est lui enfin qui invoquera la fonction collide des deux éléments qui sont rentrés en collision).

Cela fait déjà beaucoup pour une seule classe, d'autant plus qu'il doit donc avoir une connaissance de l'ensemble des éléments (quels qu'en soient le type) qui sont affichés, afin de pouvoir, justement, calculer si collision il y a :P

Alors 2 question me vienne a l'esprit en lisant cela.

Comment faire pour que le collisionDetector connaisse tous l’environnement ?

Quel est la manière d'appeler la fonction detect ?

comme sa ? :

Code:

CollisionDetector::Detect<Player,MovableObject>(Gamer,Enemi);

(Va vraiment falloir que je me renseigne mieux sur les templates)

Citation:

Envoyé par koala01

Il faut comprendre aussi que, comme nous sommes dans une logique d'héritage (que ce soit pour les collisions ou pour les autres hiérarchies) à but polymorphe (l'idée est de pouvoir gérer les différents éléments de chaque hiérarchie en les faisant passer comme étant du type de leur classe de base, sans avoir à s'inquiéter de leur type réel), tous les types que tu pourrais créer au départ de ces classes de base on une sémantique d'entité (cf la FAQ pour plus d'infos sur ce qu'on entend par là ;) ) et qu'il ne devraient donc pas être susceptibles d'être copiés ni affecté (seule l'utilisation de références et de pointeurs sur les objets existants devrait être admise ailleurs qu'au sein de la fabrique.

Donc partout dans mon programme quand je me crée des ennemis par exemple je doit utilisé la fabrique ?

Je pensais me créer un classe level qui contiendrai un vector avec les ennemis, les blocks, les items, etc du niveau. Il faudra donc que j'utilise la fabrique pour crée toute c'est objet lors de mon load du level ?

Citation:

Envoyé par koala01

Le gros avantage de travailler de la sorte, c'est que, si un jour tu souhaites rajouter un type (on a parlé des "FlyingEnnemy" et des "FlyingObject" :D ), le seul endroit que tu devras modifier (ou peu s'en faut) sera... la fabrique (de MovableObject ou de Player, ici), parce que c'est le seul endroit où l'on aura effectivement besoin de connaitre le type réel (partout ailleurs, les objets seront traités comme des "Player" ou comme des MovableObject, sans s'inquiéter de savoir si ce sont des boulet de canon, des oiseaux ou des dragons :D )

Le seul problème que je vois avec cette façon de faire est que justement à partir de la classe player, je n’aie pas accès au même donnée que la classe Gamer ( comme les positions, le status, les attaques, etc). A moins que je ne comprend pas quelque chose ? Pourrais-tu me donner un exemple de ce à quoi la classe player pourrait ressembler au finale ( avec tous ce dont tu a en tête), car j'ai de la difficulté a m'imaginer. (Peut-être que je t'en demande trop :P)
Citation:
Envoyé par koala01

C'est ma faute, je me suis arrêté à l'aspect "collision", mais, en gros, tu peux avoir (à peu près) cinq grosse réactions face à un objet mobile:

essayer de le retenir
essayer de grimper dessus
essayer de l'agripper
essayer de sauter au dessus
essayer de passer en dessous

Mais ces réactions seront commandées par... la touche enfoncée au moment de la collision ;),en ce qui te concerne du moins, par une logique et des algorithmes adaptés pour les autres types, voire, avoir des réactions tout à fait différentes :D (un objet immobile a peu de chance d'essayer de te sauter dessus :D )

Comme nous sommes dans un système d'interaction, un objet mobile va... réagir à chacune de ces tentative (grâce à des fonctions comme Climbed, jumpedOver, catched() ou passedUnder, par exemple)

Ces fonctions suivraient le même principe que collide et doCollide() (comprend : invoqueraient une fonction virtuelle privée à redéfinir si la réaction "par défaut" ne convient pas).

Tu n'aurais donc même pas à savoir que l'objet mobile que tu essaye d'attraper est un ennemi... sa réaction lorsque tu tenteras de le faire te le fera bien sentir :D (parce que, pas de bol, essayer d'attraper un ennemi à mains nues fera que cet ennemi te tuera, ou qu'il ne réagira pas à cette tentative, mais que sa réaction à une collision avec toi (qui arrivera juste après) le fera :D)
Donc si je comprend bien ton raisonement la classe MovingObjet aurait des méthode du style climbed , jumpover, etc. Qui représenterai toute les actions possible d'un movingObject et donc elle ne se limiterai pas seulement au colision mais a tous ce qui rassemble un MovingObjet et donc toute les possibilités d'action qu'un MovingObject peut faire. Est-ce exact ?

Finalement, dernière petite chose, lorsqu'un personnage avance et qu'il frappe par exemple un mur, il faut une fonctions qui le face reculer collé au mur ( pour pas qu'il entrecroise le mur ). Je met cette fonction à quel endroit ? Dans le CollisionDetector ?

Merci beaucoup de prendre le temps de m'aider, ce n'est pas tous les personnes qui aurait le courage de bien m'expliquer le tous comme tu le fait.

ps: Je sèche toujours pour ce qui est du sens de la collision (dessous, dessus, droite, gauche) :P

ps2: Je vais essayer de modifier mon schéma de classe en suivant tes interventions et je le posterai ici pour avoir un avis sur ma conception

Je vais, si tu le permet, t'expliquer (je ne te donnerai pas tous les codes, mais les explications devraient te mettre sur la voie de ce qu'il faut faire :D ) comment je gérerais ce projet si c'était à moi de le faire...

Dans le code que je mettrai, j'écrirai énormément de commentaires. Ils sont presque plus importants que le code lui-même car ils ont pour but de te faire comprendre la raison pour laquelle je fais les choses de cette manière ;)

Cela devrait répondre à quelques unes de tes questions (et sans doute à d'autres auxquelles tu n'as pas encore pensé :D ), puis je répondrai à celles qui restent :D

Je créerais une classe Game qui serait le point "d'entrée du programme", qui présenterait comme interface une unique fonction publique "run".

Elle serait sans doute utilisée par la fonction main sous la forme de
Code:

1 2 3 4 5 int main() { Game g; return g.run(); }
(on voit rarement une fonction main aussi petite :D )

Cette classe déléguerait à un certain nombre de classes les différents aspects qui sortent du cadre du niveau, tels que:

la gestion du menu principal (déléguée à une classe "HeadMenu" :-D )
la gestion des meilleurs scores (déléguée à une classe "HightScores" )
la gestion du niveau de jeu (déléguée à une classe Level)
la gestion des options de jeu (déléguée à une classe OptionManager)
la gestion du chargement et de la sauvegarde d'une partie en cours (déléguée à une classe "GamePersistance", si pas à une classe GameSaver et un autre GameLoader :D )
Le chargement d'un niveau (délégué à une classe LevelLoader)
j'en oublie peut etre, mais les principaux sont là ;)
Le fait de déléguer toutes ces taches à des classes particulières va, tu vas le remarquer, te permettre d'avoir une classe Game qui, au final, ne fait plus grand chose :

Elle ressemblerait sans doute à 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 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 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 /* une énumération pour que les choses soient plus parlantes :D */ enum MenuChoice { choiceNoChoice, choiceNewGame, choiceLoadGame, choiceSaveGame, choiceOptions, choiceTopScores, choiceExit, choiceCount }; class Game { public: void run() { MenuChoice choice= choiceNoChoice; do { Menu menu; choice=menu.sow(); switch (choice) { case noChoice: // ca ne devrait pas arriver, mais sait on jamais // :D break, case NewGame: lives_ = 5; level_ = 1; gold_ = 0; play(); break; case choiceLoadGame: loadGame(); play(); break; case saveGame: GameSaver saver; saver.save(level_, lives_, gold_); case choiceOptions: OptionManager man; man.setUp(); break; case choiceTopScores: topScores(0); case choiceExit: break; default : assert(!"You never should come here !!!"); } } while(choice != choiceExit); } /* les autres fonctions peuvent être privées, car elles ne doivent etre * appelées que par run :D */ private: /* mais n'oublions pas les membres de Game... les valeurs qui doivent * passer d'un niveau à un autre :D */ int lives_; int level_; int gold_; /* la fonction play va s'occuper de déléguer au LevelLoader le fait * de charger le niveau ad-hoc puis de demander au niveau de s'exécuter */ void play() { LevelLoader loader; /* la fonction "play" du niveau peut nous renvoyer trois valeurs * différentes (qui prendrait bien place dans une énumération * "LevelResult" :D) * levelFinished (on est arrivé au bout :D ) * levelDie (on est mort en cours de route ) * levelAbord (on a décidé d'abandonner ) * * il y a, à vrai dire, au moins une autre valeur intéressante à placer * dans l'énumération : levelNoResult (pour pouvoir initialiser * les variables avec une valeur neutre ) * */ /* on ne peut continuer, de toutes manières, que si le joueur a * encore un nombre de vies suffisant (au moins une) * et s'il n'a pas décidé d'abandonner :D, mais, tant que l'on n'est * pas dans un de ces cas, on continue à jouer :D */ LevelResult result = levelNoResult; do { loader.load(level_, lives_,gold_); Level & level = loader.level(); result = level.play(); // c'est la fonction qui prend en charge // l'ensemble de l'exécution du niveau ;) switch (result) { case levelFinished : ++level_; lives_= level.lives(); gold_ = level.gold(); break case levelDie: gold_=level.gold(); break; case levelAbord: break; default: assert(!"You should never come here"); } }while(live >0 && result!= levelAbord); topScores(gold_); // permet de gérer le score par rapport // aux meileurs scores actuels :D } void loadGame() { GameLoader loader(); loader.load(); lives_ = loader.lives(); level_ = loader.level(); gold_ = loader.gold(); } void topScores(int score) { TopManager manager; manager.show(score); } };
Tu auras remarqué que, du simple fait que j'ai correctement partagé les responsabilités, j'obtiens des fonctions particulièrement simples à implémenter :D

La classe Menu ne sera pas beaucoup plus compliquée: elle sera composée essentiellement d'une fonction show() renvoyant une valeur énumérée de type MenuChoice qu'elle aura obtenu d'une autre classe ( que l'on pourrait appeler "GraphicalMenu" :D )ayant pour responsabilité d'afficher le menu et de gérer l'aspect "visuel" de celui-ci (y compris le clique sur les différents éléments :D )

Il en va de même des classes GameLoader et GameSaver, qui n'auront elle aussi qu'une fonction publique(respectivement load et save), qui s'occuperont respectivement de charger et de sauvegarder l'état actuel de la partie et qui délégueront l'affichage du choix du fichier à une classe particulière (que nous pourrions appeler respectivement GraphicalGameLoader et GraphicalGameSaver) ;)

La classe LevelLoader, par contre, sera sans doute un peu plus compliquée...

Elle a en effet la lourde responsabilité de s'assurer que l'ensemble du niveau sera correctement chargé!

Cela ne veut pas seulement dire remplir ne niveau avec les éléments de décors et les ennemis, mais cela signifie aussi veiller à ce que les fonds sonores (musique et effets spéciaux) ou les images, par exemples, soient correctement chargées!

Elle pourra s'appuyer dans cette tâche sur plusieurs classes particulières, parmi lesquelles nous pourrions citer: Les fabrique de personnages, d'objets mobiles et d'objets immobile, ou encore les gestionnaires de sons et d'images.

Son role sera "simplement" de lire un (ou plusieurs) fichiers et de déterminer en fonction de ce qu'elle lit à quel gestionnaire ou à quelle fabrique elle doit s'adresser pour prendre en charge les informations qu'elle vient de recevoir.

Elle disposerait en outre d'un membre de type Level auquel on accéderait (sous la forme d'une référence) grâce à la fonction membre... level().

J'imagine déjà les points d'interrogations qui tournent autour de ta tête en lisant cela, parce que tu te demande très certainement comment tout cela va fonctionner ;)

Le fait est que tu ne dois, à un moment donné, n'avoir qu'une seule instance de ta classe Level et que le meilleur moyen de s'assurer que ce sera le cas, c'est encore de veiller à n'en créer qu'une seule instance :D

De plus, il faut s'assurer que l'ensemble du niveau sera correctement détruit, et, comme le niveau est un membre (pas un pointeur, un membre tout à fait ordinaire :D ) de LevelLoader, il le sera détruit en même temps que... l'instance de LevelLoader qui le contient, c'est à dire, lorsque nous quitterons la portée dans laquelle nous avons créé notre instance de LevelLoader, à savoir... quand nous sortirons de la fonction play() ;)

Tu n'auras même plus à envisager le recours à un singleton ou à un pattern monostate pour certains éléments, avec le risque toujours latent) qu'il faut veiller à les vider à certains moments sous peine de voir certaines ressources du niveau précédent s'inviter dans le niveau en cours et le poluer car les dites ressources seront correctement détruite "en meme temps que tout le reste" :D

Nous en arrivons maintenant à notre fameuse classe "Level", qui sera le "coeur du système" (ou peu s'en faut) ;)

Ce sera aussi une classe un peu plus complexe, mais nous allons essayer de la garder aussi simple que possible, et, pour cela, elle pourra faire appel à un certain nombre d'autres classes telles que:

des gestionnaires de ressources (sonores et graphiques) !!!ce seront des membres de la classe, surtout pas des singletons :D ou des monostate!!!
des "utilisateurs" de ressource (les classes qui jouent les musiques et les effets spéciaux, les classes responsable de l'affichage, ... )
les gestionnaires d'éléments de jeu (de NonMovableObject, de MovableObject et de Player, pour reprendre les termes utilisés dans mes interventions précédentes) Ce seront également des membres de la classe, en aucun cas des singleton ou des monostates
Le fameux CollectionDetector, qui devra détecter les collisions
Quelques classes "secondaires" qui permettront, par exemple, de trier les éléments en fonction de leur proximité (il ne sert à rien de vérifier si un objet risque d'entrer en collision avec la dernière marche tout au bout du niveau si on n'est pas "à vue" de celle-ci :D )
une ou plusieurs classes qui géreront les mouvements des objets "susceptibles de bouger" (ceux qui sont "à vue" et qui... ont la capacité de bouger: les MovingObject et les Player, essentiellement :D )
j'en oublie peut etre, mais les principaux sont là ;)
Il devrait ressembler à quelque chose de fort proche de
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 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 class Level { public: /* on n'y coupe pas, c'est ce qui le caractérise en premier :D */ Level(int lev, int liv, int go):alive_(true), finished_(false), aborded(false); level_(lev),lives_(liv),gold_(go){} /* les fonctions qui seront appelées par Game */ LevelResult play() { /* nous sommes dans la boucle principale du niveau... * nous resteront dedans tant que l'objet représentant * le joueur ne nous a pas signalé sa mort ou son arrivée * à la fin du niveau et tant que le gestionnaire d'événements * ne nous a pas signalé l'abandon du joueur :D */ while (alive_ && ! finished_ && ! aborded_) { // cette partie, je te la laisse :D } if(aborded_) return levelAbord; if( ! alive) return levelDie; return levelFinished; } int gold() const{return gold_;} int lives() const{return lives_;} /* les fonctions qui permettent "d'enregistrer" différentes ressources * certaines seront appelées par les fabriques, d'autres * seront appelées directement par LevelLoader */ void registerSound(std::string const & str) { sounds_.registerItem(str); } void registerImage(std::string const & str) { images_.registerItem(str); } void registerItem(NonMovableObject * obj) { nonMovables_.registerItem(obj); } void registerItem(MovableObject * obj) { movables_.registerItem(obj); } void registerItem(Player * obj) { players_.registerItem(obj); } /* Le joueur est susceptible de lui parler directement */ void gotGold(int count) { gold_ += count; } void catchLive() { ++ lives_; } void died() { --lives_; alive_ = false; } void finished() { finished_ = true; } /* cette fonction sera plutôt invoquée par le gestionnaire * dévénements (vu qu'elle implique que le joueur a cliqué * quelque part ou qu'il a enfoncé une touche particulière :D */ void abord() { aborded_ = true, } /* a priori, s'il manque des fonctions, elles seront surement * privées, car je crois qu'on a tout ce qu'on peut demander * à notre niveau... mais j'ai peut etre oublié quelque chose :D */ private: bool alive_; bool finished_; bool aborded_; /* il est quand meme sympa pour un niveau de savoir lequel c'est :D */ int level_; int lives_; int gold_; /* les différents gestionnaires qu'il va utiliser */ SoundManager sounds_; ImageManager images_; NonMovableManager nonMovables_; MovableManager movables_; PlayerManager players_; }
Voilà, grâce à toi, je vais encore me faire taquiner à cause de la longueur de mon poste:cry::cry::D

Il n'y a très certainement pas toutes les classes, ni toutes les fonctions, mais tu devrait maintenant avoir une idée globale de la manière dont tout prend sa place :D

1 pièce(s) jointe(s)

Bonjours tout le monde,

J’ai fait ma conception en générale et je viens maintenant vous la montré pour avoir des avis et des idées d’amélioration.

Je vais surtout me concentrer sur les classes de type d’objet (Player, MovableObject, ImmobileObject).

Pour voir mon diagramme de classe pour c'est classe (il me manque encore la classe ImmobileObject) voir la pièce jointe

Quelque point :

J’ai ajouté les fonctions de collision tel que discuté dans le sujet.
J’ai aussi ajouté les variables pour gérer les positions.
J’ai aussi ajouter des fonctions de spécifique à un type ( par exemple Catched). Est-ce que c’est correct d’ajouter des fonctions spécifiques à un type ou les 3 classe doivent être strictement identique ?

Je n’ai pas ajouter toute les fonctions spécifique a chaque type puisque je manquai d’inspiration (d’ailleurs si vous avez des choses à me proposer d’ajouter je suis preneur :P)

Encore une fois tout commentaire ou amélioration sera très apprécié.

J’aurais encore un problème que je n’arrive pas à comprend.
Comment, vais-je faire, par exemple, pour que si un ennemis est touchée par une balle de feux, il meurt ou bien il pourrait avoir une résistance à cette boule de feu et alors ne rien faire de spécial. Comment gérer des cas spécifique comme celui-ci ?

De plus, vous m’avez conseillée d’utiliser une fonction react qui sera utilisé lorsque par exemple un personnage saute sur un ennemi mais que celui-ci à des piquants. Cependant, ce que je ne comprends pas c’est que cette fonction react par exemple prendra un peu le rôle de la collision puisque c’est elle qui fera mal au personnage ? A moins que cette fonction ne serve seulement à ne pas faire mal au personnage ? Je ne suis pas sûr de bien expliquer la problématique.

Et alors je me pose cette question, ou est-ce que je place l’action de blesser un autre objet (ennemis, block, etc) ?

Ce sont là les interrogations que j’ai et qui me bloque dans l’avancement de mon projet.

Autre point,
Pour ce code :
Code:

1 2 3 4 5 6 static void detect(FirstType * one, SecondType * second) { /*logique de détection de collision */ /* logique de sélection de priorité */ sendCollision(mostPriorItem, secondPriorItem); }
Comment est-ce que cela s’appelle dans le code ?
CollisionDetector<Player, MovableObjet>(object1, object2)

Aussi , comme sendCollision est une fonction template, je ne devrai pas faire dans le code de detect un autre appele du type :
sendCollision<Player, MovableObject>(mostPriorItem, secondPriorItem);
ou il prend les memes type que ceux donner à CollisionDetector

Mes autres diagrammes de classe sont dans le fichier Join.

Pour c’est classe :

StateManager :

Je me suis fait un stateManager pour gérer les différents écrans du jeu. Cependant je pense les changer pour des singleTon puisque parfois j’ai besoin d’avoir accès à la vrai classe pour pouvoir passez un objet à cette classe (comme un choix de level par exemple)

RessourceManager :

Je me suis aussi fait des ressource manager eu aussi singleton, mais en ayant vu votre post je crois les changer pour qu’il soit déclaré dans une classe.

Voilà pour ma conception et mes problèmes, si vous avez des commentaires ou suggestions ils sont les bienvenue.

Citation:

Voilà, grâce à toi, je vais encore me faire taquiner à cause de la longueur de mon poste

Il n'y a très certainement pas toutes les classes, ni toutes les fonctions, mais tu devrait maintenant avoir une idée globale de la manière dont tout prend sa place

Merci beaucoup de prendre tout ce temps pour m'aider, c'est vraiment très appréciée. Pour la longueur de votre poste, quand il sont aussi bien fait cela mérite plus des bravos que des taquinerie :P

15/09/2011, 08h07
LittleWhite

Moi, je ne vais faire qu'un survol de ce que vous avez fait.
Pour vos manager, on voit des singletons, si je ne me trompe pas (GetInstance()). Certains diront que le singleton est un anti pattern et qu'il ne doit pas être utilisé. Donc je vous conseille d'être extrêmement prudent.
Et puis, un singleton hérité ... c'est violent, non ?

Pour les Manager, il faut aller voir le dernier article d'Emmanuel Deloget :aie:

Je ne vois pas pourquoi le Player n'est pas un MovableObject (ou du moins, un truc movable). Finalement, vous avez fait hérité les Ennemy, du Player, cela est très étrange à dire.
Je pense qu'il manque toute une partie du coté du diagramme pour les objets. Les objets fixes ? entre autre.
16/09/2011, 05h55
marcolo21

Citation:

Envoyé par LittleWhite

Moi, je ne vais faire qu'un survol de ce que vous avez fait.
Pour vos manager, on voit des singletons, si je ne me trompe pas (GetInstance()). Certains diront que le singleton est un anti pattern et qu'il ne doit pas être utilisé. Donc je vous conseille d'être extrêmement prudent.
Et puis, un singleton hérité ... c'est violent, non ?

Pour les Manager, il faut aller voir le dernier article d'Emmanuel Deloget :aie:

En effet, comme préciser dans mon message mes manager son des singletons, mais je croit que je vais les changer pour des objet normal et les mettre en argument de mes classe. C'est juste que si 2 level utilise les même tile je ne veux pas avoir à les recharger 2 fois parce ma première instance de manager a été supprimer en même temps que mon premier level. C'est principalement pour cela que j'utilisai un singleton.

Citation:

Envoyé par LittleWhite

Je ne vois pas pourquoi le Player n'est pas un MovableObject (ou du moins, un truc movable). Finalement, vous avez fait hérité les Ennemy, du Player, cela est très étrange à dire.
Je pense qu'il manque toute une partie du coté du diagramme pour les objets. Les objets fixes ? entre autre.

Je l'ai mit dans player, car koala01 l'avait fait ainsi mais je crois effectivement qu'il devrai être placer dans MovableObjet.

Et oui je n'ai pas encore eu le temps de faire les objets fixes :P

Toute remarque, suggestion, amélioration, etc sur la conception présenter dans mon précédant message seront les bienvenues.

Si vous avez des réponses à mes question aussi, cela m'aidera grandement, car c'est plus sur cela que je bloque pour l'instant
16/09/2011, 06h31
koala01

Citation:

Envoyé par marcolo21

En effet, comme préciser dans mon message mes manager son des singletons, mais je croit que je vais les changer pour des objet normal et les mettre en argument de mes classe. C'est juste que si 2 level utilise les même tile je ne veux pas avoir à les recharger 2 fois parce ma première instance de manager a été supprimer en même temps que mon premier level. C'est principalement pour cela que j'utilisai un singleton.

De toutes manières, il faut te dire que tu ne chargera qu'un niveau à la fois, et qu'il est beaucoup plus risqué (parce que tu auras "oublié" de vider ton singleton) de se retrouver avec des éléments du niveau précédant dans le niveau actuel que de devoir charger deux fois une ressource quelconque...

Lorsque tu rend simplement tes gestionnaires membres de Level, et que tu les transmets (sous la forme de référence) aux fonctions / objets qui en ont besoin, tu t'assure que tu n'auras qu'une seule instance de gestionnaire à chaque fois (parce que tu n'aura qu'un seul Level à la fois), ce qui est le principal objectif du singleton ;)

Citation:

Je l'ai mit dans player, car koala01 l'avait fait ainsi mais je crois effectivement qu'il devrai être placer dans MovableObjet.

J'ai, effectivement, très mal nommé cette classe (cela aurait du être proche de "PersonObject"), mais l'idée est vraiment de faire la distinction entre les objets mobiles qui ont une "volonté propre", bref, les "personnages" des objets qui n'en ont pas (de volonté propre),c'est à dire qui se "contentent" de suivre les "lois de la physique" pour leur déplacements.

Un exemple de Personnage serait la tortue ou le "boss" en fin de niveau, alors qu'un exemple de MovableObject serait un obus ou une carapace de tortue dans laquelle tu aurais shooté.

Le fait de ne pas considérer les personnages comme des objets mobiles (et donc de créer un type de collision supplémentaire) va t'éviter bien du soucis lorsqu'il sera question de créer tes différents visiteurs et / ou médiateurs :

Si tu place les personnages dans les objets mobiles, ce n'est pas parce que tu sauras avoir affaire à un objet mobile que tu saura si c'est un personnage ou non!!!

Si tu décide d'en rajouter un à ta hiérarchie, tu devra donc modifier tous tes visiteurs et médiateurs agissant sur les objets mobiles en leur rajoutant une fonction virtuelle prenant ton nouveau personnage en compte (dont certains qui, à la limite n'en ont rien à foutre du type réel de personnage sur lequel ils agissent!!! )

Si, par contre, tu place les personnages en dehors de la hiérarchie des "objets mobiles", tu devra, certes, créer des visiteurs / médiateurs qui les prennent spécifiquement en compte, mais tu auras la facilité de pouvoir avoir d'un coté les visiteurs qui n'ont rien à foutre de savoir sur quel type de personnage ils travaillent et d'un autre ceux pour qui le fait de travailler spécifiquement sur Mario ou sur Luiggi a une importance, et tu pourras te "contenter" de ne modifier que cette deuxième catégorie si tu décide de rajouter une classe de personnage!

(le raisonnement est identique si tu décide de rajouter un type d'objet mobile qui n'est pas personnage :D )

Bref, tu gagne en flexibilité, et, bien que tu ne sois pas encore tout à fait dans le respect de OCP, tu t'en approche malgré tout d'avantage que si les personnages font partie de la hiérarchie des objet mobiles.

De plus, on pourrait alors se demander pourquoi on ne place pas les objet non mobiles dans la même hiérarchie que les objets mobiles, et on en arriverait à créer un "god object" de type Object, regroupant aussi bien les objets immobiles que les objets mobiles (qui contiennent eux même les personnages et le reste des objets mobiles).

C'est donc un choix délibéré que j'ai clairement expliqué dans mes premières interventions, et c'est, à mon sens, le meilleur (ou du moins le moins mauvais) que l'on puisse envisager ;)

Par contre, à moins que tu ne veuilles prévoir des comportements spécifiques pour Mario et pour Luiggi (et je ne parle pas "simplement" des sons ou des images à utiliser, car cela peut se gérer simplement en donnant ceux qui conviennent :D ) je ne suis pas sur qu'il soit vraiment utile de prévoir la distinction...

Sinon, cela implique que si tu veux par la suite rajouter la petite amie de Mario, tu devra rajouter une classe, alors que si tu en reste à Gamer, sans précision, il te suffira de donner les sons et les images adéquates pour avoir la petite amie de Mario :D

Citation:

Et oui je n'ai pas encore eu le temps de faire les objets fixes :P

Si vous avez des réponses à mes question aussi, cela m'aidera grandement, car c'est plus sur cela que je bloque pour l'instant

J'avais prévu d'essayer d'y répondre hier, mais j'ai été à une conférence sans passer par chez moi, et je n'ai pas eu le courage de le faire après.

Là, je pars au boulot, mais j'essayerai de le faire en rentrant ;)
16/09/2011, 17h56
Mat.M

Citation:

Envoyé par LittleWhite

N'est ce pas un peu lourd ?

Dans le sens, vos fonctions sont appelées même si elles ne font rien. On va avoir beaucoup d'objets actifs

Citation:

Envoyé par Emmanuel Deloget

Pour le coup, et contrairement à mes saines et figées habitudes, je préconise le contraire : laisser émerger le design à partir des complexités du code initial.

je suis d'accord

Citation:

Envoyé par marcolo21

1) Les collisions

J’ai de la difficulté à voir comment je pourrai gérer les collisions. Je sais bien comment savoir si 2 choses ont une collision entre elles, cependant, je ne sais pas comment les faire interagir ensemble.
Par exemple : le personnage touche un ennemi sur la tête. L’ennemi doit donc mourir, est- ce que je me crée une méthode ‘’Mort()’’ dans chaque classe ennemie que j’appelle lorsqu’il y a eu collision sur le dessus.
De plus supposions, qu’un ennemi particulier à des piquants sur la tête. Donc quand notre personnage va sauter sur la tête de l’ennemi, il ne doit pas mourir, mais faire mal à notre personnage.

pour les collisions sans parler de Design Patterns ni de classes d'un point de vue technique il faut tester basiquement si les rectangles dans lesquels les personnages sont contenus sont en intersection.
Sinon le classique c'est la méthode de Pixel Detection tu compares les pixels qui se confondent mais ça risque d'être long en termes de performances.
Si tu veux tester au niveau de la tête il faut diviser le rectangle qui contient ton personnage en sous-zones
C'est une idée parmi d'autres....

Citation:

Envoyé par marcolo21

2) Les items
Chaque item fait quelque chose de particulier à notre personnage. (Par exemple : fleur permet de lancer des boules de feux, étoile rend invincible, etc)
Comment gérer cela dans les classes ? Des boolean qui indiquent par exemple s’il est invisible, s’il peut lancer des boules de feux?

je pense que le mieux c'est d'avoir une classe de base CItem par exemple et de faire hériter des autres types de cette classe de base en reprenant les fonctionnalités de CItem..

Citation:

Envoyé par marcolo21

Cependant, j’ai quelque difficulté à voir comment l’implémenter. Pour l’instant dans mon modèle de personnage, j’ai un statut qui contient par exemple Walking, jumping, falling, etc. Qui signifie l’action que le personnage fait. Dans la vu que vais lire ce statut et afficher l’image en conséquence.
Est-ce correct de s’y prendre ainsi? Avez-vous de meilleures solutions à proposer ?

Je ne sais pas si ce MVC est bien adapté;
il faut que tu gères les états dans une "machine à états" c'est un grand classique de la programmation des JV.
Par exemple le livre de Buckland "Programmig Game AI by example" aborde ce sujet.
Chercher dans google Finite State Machine..;
http://en.wikipedia.org/wiki/Finite-state_machine
18/09/2011, 06h47
marcolo21

Citation:

Envoyé par koala01

C'est donc un choix délibéré que j'ai clairement expliqué dans mes premières interventions, et c'est, à mon sens, le meilleur (ou du moins le moins mauvais) que l'on puisse envisager ;)

Je crois effectivement que vous semblez avoir bien réfléchit au probleme et votre approche me semble bonne et pas trop compliquer à utiliser, a par pour certain point.

Citation:

Envoyé par koala01

Par contre, à moins que tu ne veuilles prévoir des comportements spécifiques pour Mario et pour Luiggi (et je ne parle pas "simplement" des sons ou des images à utiliser, car cela peut se gérer simplement en donnant ceux qui conviennent :D ) je ne suis pas sur qu'il soit vraiment utile de prévoir la distinction...

En faite j'aimerai ajouter aussi Wario et donc quand il attaque et tous le reste est assez différent de mario. C'est pour cela que j'ai fait différente classe

Citation:

Envoyé par koala01

Là, je pars au boulot, mais j'essayerai de le faire en rentrant ;)

Merci beaucoup, j'attend votre intervention avec impatience :P

Citation:

Je ne sais pas si ce MVC est bien adapté;
il faut que tu gères les états dans une "machine à états" c'est un grand classique de la programmation des JV.
Par exemple le livre de Buckland "Programmig Game AI by example" aborde ce sujet.
Chercher dans google Finite State Machine..;
http://en.wikipedia.org/wiki/Finite-state_machine

J'ai regarder un peut sur google et cela semble beaucoup ressembler a ma classe StateManager(présenter dans ma conception dans le fichier joint de mon précédant message) pour gérer les différents écran d'un jeu.

Cependant je ne sait pas comment je pourrais utilisé une classe semblable pour savoir qu'est-ce que j'affiche dans ma view. Pour l'instant j'ai un statue dans mon model qui est par exemple: Running, jumping, falling, walking, etc. qui représente les différentes action de mon personnage et dans ma view je fait un switch/case et j'affiche l'animation correspondante.

Est-ce une bonne méthode selon vous ? Si non, que me proposeriez-vous ?
21/09/2011, 17h56
r0d

Citation:

Envoyé par Mat.M

Je ne sais pas si ce MVC est bien adapté;

Effectivement. Après un cuisant échec, je suis aujourd'hui persuadé que le MVC n'est du tout adapté au dev d'un jeu vidéo.

Aujourd'hui, je suis parvenu à la quasi-certitude que le meilleur modèle reste le client/serveur (même si on reste toujours en local, si la communication entre le client et serveur ne se fait pas par le biais d'un protocole réseau).
Un bon exemple: l'architecture de quake II.

Ensuite, attends-toi a avoir devoir gérer des états, beaucoup d'états, différents, voire antagonistes. Tu peux regarder mon article sur le D.P. State, mais sincèrement je le trouve de plus en plus médiocre. A la limite, il vaudrait mieux prendre une lib qui implémente une machine à état (au hasard, celle de boost), et de jouer avec pour bien appréhender les possibilité qu'elle offre avant de l'utiliser dans ton code. Attention, l'implémentation et l'utilisation d'une machine à été, fut-elle finie, n'est pas aussi simple qu'il n'y parait.
21/09/2011, 18h52
koala01

Citation:

Envoyé par r0d

Attention, l'implémentation et l'utilisation d'une machine à été, fut-elle finie, n'est pas aussi simple qu'il n'y parait.

Encore moins le premier jour de l'automne:aie:

Bon, :dehors:
22/09/2011, 04h27
marcolo21

1 pièce(s) jointe(s)

Bonjour,

@koala01

J'ai toujours quelque problème à m'imaginer certaine chose, même après y avoir réfléchit.

Je me permet de remettre les questions d'un de mes ancien poste qui ne sont pas réglée dans mon cas.

En faite ce sont plus des situation, que j'aimerai que vous m'expliquer comment vous règleriez cela.

Comment, vais-je faire, par exemple, pour que si un ennemis est touchée par une balle de feux, il meurt ou bien il pourrait avoir une résistance à cette boule de feu et alors ne rien faire de spécial. Comment gérer des cas spécifique comme celui-ci ?

De plus, vous m’avez conseillée d’utiliser une fonction react(mais que passé à react ? un des 3 type d'objet?) qui sera utilisé lorsque par exemple un personnage saute sur un ennemi mais que celui-ci à des piquants. Cependant, ce que je ne comprends pas c’est que cette fonction react par exemple prendra un peu le rôle de la collision puisque c’est elle qui fera mal au personnage ? A moins que cette fonction ne serve seulement à ne pas faire mal au personnage ? Je ne suis pas sûr de bien expliquer la problématique.

Et alors je me pose cette question, ou est-ce que je place l’action de blesser un autre objet (ennemis, block, etc) ?

Voici une situation pour mieux comprendre:

Prenons l'exemple de mon personnage(Mario). Il saute sur un ennemis tu la tête. Cependant, cet ennemis possède des piquants sur le dessus et donc c'est a moi de me faire mal. Comment gérer un cas spécifique comme celui-ci ?

Finalement, auriez-vous une meilleur idée qu'un énumération pour savoir si la collision c'est passé sur le dessus, dessous, gauche, droite ??? (Ma problématique dans ce cas la va être de déterminée le sens de la collision)

Ce sont là les interrogations que j’ai et qui me bloque dans l’avancement de mon projet. Après cela, je pourrait avancer rapidement dans mon développement.

Merci beaucoup

Ps: En pièce jointe les classes d'objet ( fortement inspiré ce de sujet). Bien sur rien n'est parfait encore. Le reste évoluera lorsque je programmerai.

Bonjour tout le monde,

Tout d'abord désolez de remonter ce topic, mais je suis rendu à la partie ou je dois coder les collisions et j’ai un problème.
J’essaie de coder la class collision un très inspiré de celle présentée par Koala01.

Voici le code :
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 66 67 68 69 70 #ifndef COLLISION_H_INCLUDED #define COLLISION_H_INCLUDED #include "ECollisionType.h" /*#include "IntelligentObject.h" #include "MovableObject.h" #include "ImmobileObject.h"*/ template <typename FirstType, typename SecondType = FirstType> class Collision { public: Collision(FirstType* f, SecondType* s):m_First(f), m_Second(s) { } FirstType* First() { return m_First; } SecondType* Second() { return m_Second; } CollisionType::ECollisionType CollisionTypeFirst() { return m_CollisionTypeFirst; } CollisionType::ECollisionType CollisionTypeSecond() { return m_CollisionTypeSecond; } void Transmit() { DoTransmit(); } protected: //Virtual Function virtual void DoTransmit() { m_First->Collide(this); m_Second->Collisde(this); } //Member FirstType* m_First; SecondType* m_Second; CollisionType::ECollisionType m_CollisionTypeFirst; CollisionType::ECollisionType m_CollisionTypeSecond; }; /*typedef Collision<IntelligentObject> CollisionTwoIntelligentObject; typedef Collision<IntelligentObject, MovingObject> CollisionIntelligentMovableObject; typedef Collision<IntelligentObject, ImmobileObject> CollisionIntelligentImmobileObject; typedef Collision<MovingObject> CollisionTwoMovableObject; typedef Collision<MovingObject, ImmobileObject> CollisionMovableImmobileObject;*/ #endif
La class en tant que tel ne pose pas de problème. Le problème est lorsque je veux créer ma fonction Colide comme koala avait fait dans un de ses premiers postes de la façon suivante :
Code:

1 2 3 4 5 void collide(Collision * col) { doCollide( *col); }
Le problème c’est que je ne peux pas me crée un pointeur de cette façon, le compilateur me demande de lui donner le type c'est-à-dire l’écrire sous cette forme :
Code:

1 2 3 4 5 void collide(Collision<IntelligentObject>* col) { doCollide( *col); }
En faisant cela, je perds toute le cotée dynamique avec les doColide.
J’ai remarqué que Koala01 avait utilisé 2 classes pour ça (Colision et TColision). Mon problème est que dans le code qu’il a montré dans le premier message, est-ce que TColision hérite de collision. Aussi, si je passe un pointeur Colision je n’aurai pas accès aux méthodes first et second puisqu’ils sont déclarés dans TColision et non dans Colision.

Aussi un autre problème, j’ai mes typedef dans un fichier comme montré dans le premier message:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #ifndef TYPEDEFCOLLISION_H_INCLUDED #define TYPEDEFCOLLISION_H_INCLUDED #include "Collision.h" #include "IntelligentObject.h" #include "MovableObject.h" #include "ImmobileObject.h" typedef Collision<IntelligentObject> CollisionTwoIntelligentObject; typedef Collision<IntelligentObject, MovingObject> CollisionIntelligentMovableObject; typedef Collision<IntelligentObject, ImmobileObject> CollisionIntelligentImmobileObject; typedef Collision<MovingObject> CollisionTwoMovableObject; typedef Collision<MovingObject, ImmobileObject> CollisionMovableImmobileObject; #endif
Cependant je ne sais pas où les placers puisque je dois inclure tous les types d’objet pour pouvoir déclarer mes typedef, mais après quand je l’inclue par exemple dans ma classe IntelligentObject, j’ai des problèmes de compilation comme si j’aurai des inclusions multiples (malgré les ifndef dans mes fichiers).

Auriez-vous une solution pour pouvoir régler mes 2 problèmes ? Peut-être que Koala01 s’il passe par ici pourra expliquer comment marchent ses codes.

Merci beaucoup

Tu as oublié de faire hériter ta collision template d'un type non template "collision"...

Il faut comprendre que tel que tu as codé collision Collision<Truc, Machin> n'a strictement rien à voir avec TCollision<Machin, Bidule> en terme de hiérarchie de classe (ce sont deux types totalement différents qui ont "simplement" une interface commune, et qui réagissent potentiellement de la même manière).

Lorsque tu réfléchis aux différentes combinaisons possibles de collision, tu te rend compte qu'il y en a un certain nombre:

joueur avec joueur
joueur avec objet mobile
joueur avec objet fixe
objet mobile avec objet mobile
objet mobile avec objet fixe
(un objet fixe n'a aucune chance d'entrer en collision avec un autre objet fixe :D )
L'approche Orientée Objets classique t'aurais amené à créer une classe Collision de base puis à faire hériter cinq classes (une par type de collision potentielle) et à dupliquer autant de fois le même code d'implémentation des fonctions virtuelles car la collision en elle meme réagit de manière strictement identique quelle que puisse etre le type des objets qui entre en collision: elle appelle une méthode clairement définie sur le premier objet de la collision puis appelle exactement la même méthode sur le deuxième objet de la collision.

Or, un bon programmeur est un programmeur fainéant, qui va tout faire pour que le compilateur en fasse un maximum pour lui et pour écrire le moins de code possible, et on entre donc tout à fait dans la définition du paradigme générique :

Citation:

on ne sait pas encore quel sera le type des objets que l'on va manipuler, mais on sait par contre parfaitement la manière dont on va les manipuler.

Or, on veut profiter du polymorphisme (au sens Orienté Objets du terme) pour n'importe quel type de collision !

Il faut donc faire en sorte d'avoir un type de base unique pour n'importe quel type de collision susceptible d'être généré de manière automatique par le compilateur.

Pour obtenir ce résultat, c'est tout simple : on crée une classe (non template) de base, qui implémente le NVI sous une forme proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 class Collision { public: void collide(){doCollide();} virtual ~Collision(){} /* en C++11, on peut interdire la copie et l'affectation sous cette forme */ Collision(Collision const &) = delete; Collision & operator = (Collision const &) = delete; private: virtual void doCollide(){/* ne fait rien à la base;} /* mais pour interdire la copie et l'affectation en C++ d'avant, il faut * déclarer le opérateur d'affectation et le constructeur par copie * privé et ne surtout pas les définir */ Collision(Collision const &); Collision & operator = (Collision const &); };
puis on fait hériter une classe (template) TCollision de cette classe de base, de manière à ce que quels que soient les paramètres template utilisés, la classe résultante dispose de la même classe de base, sous une forme proche de
template <typename T1 , typename T2 /* = T1 */ >
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 class TCollision { public : /* simplement pour pouvoir récupérer le type des deux objets en * présence */ typedef T1 * first_type_ptr; typedef T2 * second_type_ptr; TCollision(T1 * f, T2 s):first_(f), second_(s){} private: T1* first_; T2* second_; /* la spécialisation de NVI */ virtual void doCollide() { first_->react(*this); second_->react(*this); } };
Du coup, pour générer les cinq types de collision potentiel, "YAPUKA" définir les alias de types correspondants:
Code:

1 2 3 4 5 6 typedef TCollision<IntelligentObject> CollisionTwoIntelligentObject; typedef TCollision<IntelligentObject, MovingObject> CollisionIntelligentMovableObject; typedef TCollision<IntelligentObject, ImmobileObject> CollisionIntelligentImmobileObject; typedef TCollision<MovingObject> CollisionTwoMovableObject; typedef TCollision<MovingObject, ImmobileObject> CollisionMovableImmobileObject;
Et tout ira pour le mieux :d

Bonjour Koala01,

J'ai toujours un petit problème avec mes collisions.

Je vous montre le code et ensuite je vais expliquer mon problème.

Classe Collision:

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
#ifndef COLLISION_H_INCLUDED
#define COLLISION_H_INCLUDED
 
#include "ECollisionType.h"
 
class Collision
{
    public:
 
        void Transmit()
        {
            DoTransmit();
        }
 
    protected:
 
        //Virtual Function
        virtual void DoTransmit()
        {
        }
};
 
 
#endif

Classe TCollision:

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
#ifndef TCOLLISION_H_INCLUDED
#define TCOLLISION_H_INCLUDED
 
#include "Collision.h"
#include "ECollisionType.h"
 
template <typename FirstType, typename SecondType = FirstType>
class TCollision : public Collision
{
    public:
 
        TCollision(FirstType* f, SecondType* s):m_First(f), m_Second(s)
        {
        }
 
        FirstType* First()
        {
            return m_First;
        }
 
        SecondType* Second()
        {
            return m_Second;
        }
 
        CollisionType::ECollisionType CollisionTypeFirst()
        {
            return m_CollisionTypeFirst;
        }
 
        CollisionType::ECollisionType CollisionTypeSecond()
        {
            return m_CollisionTypeSecond;
        }
 
    protected:
 
        //Virtual Function
        virtual void DoTransmit()
        {
            m_First->Collide(this);
            m_Second->Collisde(this);
        }
 
        //Member
 
        FirstType* m_First;
        SecondType* m_Second;
 
        CollisionType::ECollisionType m_CollisionTypeFirst;
        CollisionType::ECollisionType m_CollisionTypeSecond;
};
 
#endif

Les typedef :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#ifndef TYPEDEFCOLLISION_H_INCLUDED
#define TYPEDEFCOLLISION_H_INCLUDED
 
#include "TCollision.h"
/*#include "IntelligentObject.h"
#include "MovableObject.h"
#include "ImmobileObject.h"*/
 
class IntelligentObject;
class ImmobileObject;
class MovingObject;
 
typedef TCollision<IntelligentObject> CollisionTwoIntelligentObject;
typedef TCollision<IntelligentObject, MovingObject> CollisionIntelligentMovableObject;
typedef TCollision<IntelligentObject, ImmobileObject> CollisionIntelligentImmobileObject;
 
typedef TCollision<MovingObject> CollisionTwoMovableObject;
typedef TCollision<MovingObject, ImmobileObject> CollisionMovableImmobileObject;
 
#endif

La classe IntelligentObject:

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
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
#ifndef INTELLIGENTOBJECT_H_INCLUDED
#define INTELLIGENTOBJECT_H_INCLUDED
 
/*#include "ReactObject.h"
#include "Collision.h"*/
 
 
/*class CollisionTwoIntelligentObject;
class CollisionIntelligentMovableObject;
class CollisionIntelligentImmobileObject;*/
 
//class CollisionTwoMovableObject;
//class CollisionMovableImmobileObject;
 
#include "TypeDefCollision.h"
 
namespace IntelligentObjectType
{
    enum EIntelligentObjectType
    {
        None,
        Character,
        Enemy,
        Count
    };
}
 
///////////////////////////////////////////////////////////////////////////////////
//Base Interface Class for every intelligent Object (Character, ennemy, etc)
///////////////////////////////////////////////////////////////////////////////////
 
class IntelligentObject
{
    public:
 
        IntelligentObject() : m_X(0), m_Y(0), m_Width(0), m_Height(0), m_Speed(0.f), m_AccelerationX(0.f), m_AccelerationY(0.f), m_Score(100), m_IsVisible(true), m_Type(IntelligentObjectType::None)
        {
        }
 
        IntelligentObject(IntelligentObjectType::EIntelligentObjectType type) : m_X(0), m_Y(0), m_Width(0), m_Height(0), m_Speed(0.f), m_AccelerationX(0.f), m_AccelerationY(0.f), m_Score(100), m_IsVisible(true), m_Type(type)
        {
        }
 
        //Pure virtual function to prevent to instanciate it
        virtual ~IntelligentObject()
        {
        }
 
        //The function that will be call by the collision system
        void Collide(Collision* col)
        {
            DoCollide(*col);
            //DoCollide(*col);
        }
        /*
        void React(ReactObject* obj)
        {
            DoReact(*obj);
        }*/
 
        void Update(float elapsedTime)
        {
            DoUpdate(elapsedTime);
        }
 
        virtual void Hurt(){}
 
 
        int GetX() const
        {
            return m_X;
        }
 
        int GetY() const
        {
            return m_Y;
        }
 
        int GetWidth() const
        {
            return m_Width;
        }
 
        int GetHeight() const
        {
            return m_Height;
        }
 
        float GetSpeed() const
        {
            return m_Speed;
        }
 
        float GetAccelerationX() const
        {
            return m_AccelerationX;
        }
 
        float GetAccelerationY() const
        {
            return m_AccelerationY;
        }
 
        int GetScore() const
        {
            return m_Score;
        }
 
        bool IsVisible() const
        {
            return m_IsVisible;
        }
 
        void SetVisible(bool visible)
        {
            m_IsVisible = visible;
        }
 
        void SetX(int x)
        {
            m_X = x;
        }
 
        void SetY(int y)
        {
            m_Y = y;
        }
 
        void SetPosition(int x, int y)
        {
            m_X = x;
            m_Y = y;
        }
 
        void SetWidth(int width)
        {
            m_Width = width;
        }
 
        void SetHeight(int height)
        {
            m_Height = height;
        }
 
        void SetSpeed(float speed)
        {
            m_Speed = speed;
        }
 
        void SetAccelerationX(float accelerationX)
        {
            m_AccelerationX = accelerationX;
        }
 
        void SetAccelerationY(float accelerationY)
        {
            m_AccelerationY = accelerationY;
        }
 
        void SetScore(int score)
        {
            m_Score = score;
        }
 
        IntelligentObjectType::EIntelligentObjectType GetType() const
        {
            return m_Type;
        }
 
    protected:
 
        //Protected function
        virtual void DoCollide(CollisionTwoIntelligentObject& col){}
        virtual void DoCollide(CollisionIntelligentMovableObject& col){}
        virtual void DoCollide(CollisionIntelligentImmobileObject& col){}
        //virtual void DoCollide(CollisionTwoMovableObject& col){}
        //virtual void DoCollide(CollisionMovableImmobileObject& col){}
        /*
        virtual void DoReact(ReactIntelligentObject& reaction){}
        virtual void DoReact(ReactMovableObject& reaction){}
        virtual void DoReact(ReactImmobileObject){}*/
 
 
        virtual void DoUpdate(float elapsedTime){}
 
 
        //Member
        int m_X;
        int m_Y;
        int m_Width;
        int m_Height;
        float m_Speed;
        float m_AccelerationX;
        float m_AccelerationY;
        int m_Score;
        bool m_IsVisible;
        IntelligentObjectType::EIntelligentObjectType m_Type;
 
};
 
#endif

Petite précision :
Dans le Fichier Typedef. J'ai mit

Code:

1
2
3
class IntelligentObject;
class ImmobileObject;
class MovingObject;

Car si je mettais les includes des classes direct j'avais des problèmes quand j'incluai ce fichier dans intelligentObject par exemple. Je ne sais pas si c'est correcte de faire ça ainsi.

Mon probème ce trouve dans la fonction Colide de la classe intelligentObject.

L'erreur que j'obtient est :

Citation:

In member function 'void IntelligentObject::Collide(Collision*)':|
error: no matching function for call to 'IntelligentObject::DoCollide(Collision&)'|
note: candidates are: virtual void IntelligentObject::DoCollide(CollisionTwoIntelligentObject&)|
note: virtual void IntelligentObject::DoCollide(CollisionIntelligentMovableObject&)|
note: virtual void IntelligentObject::DoCollide(CollisionIntelligentImmobileObject&)|
||=== Build finished: 1 errors, 0 warnings ===|

Comment puis-je fait pour corriger cette erreur ?

Merci beaucoup

Bonjour,

Est-ce que je devrais utiliser les dynamic_cast pour corriger ce problème ?

Comme ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
        void Collide(Collision* col)
        {
            CollisionTwoIntelligentObject* twoIntelligent = 0;
            CollisionIntelligentMovableObject* intelligentMovable = 0;
            CollisionIntelligentImmobileObject* intelligentImmobile = 0;
 
            if((twoIntelligent = dynamic_cast<CollisionTwoIntelligentObject*>(col)))
            {
                DoCollide(*twoIntelligent);
            }
            else if((intelligentMovable = dynamic_cast<CollisionIntelligentMovableObject*>(col)))
            {
                DoCollide(*intelligentMovable);
            }
            else if((intelligentImmobile = dynamic_cast<CollisionIntelligentImmobileObject*>(col)))
            {
                DoCollide(*intelligentImmobile);
            }
 
        }

Cependant, dynamic_cast semble toujours me retourné NULL même si l'objet est effectivement un CollisionIntelligentImmobileObject par exemple.

merci

12/10/2011, 00h16
LittleWhite
En théorie, nous devons éviter les cast. Si je me rappelle bien, les dynamic_cast provoque le parcours de la table virtuelle (table d'héritage) afin de savoir si le cast est bien possible. Cela peut facilement prendre du temps et est donc à éviter dans le code critique (tel que la vérification de collision).

Avec la fonction suivante:
Code:

1 2 3 4 5 6 // The function that will be call by the collision system void Collide(Collision* col) { DoCollide(*col); //DoCollide(*col); }
Vous devriez être capable de l'appeler directement avec votre col, donc il ne devrait pas y avoir de cast explicite.
Mais peut être que je me trompe...
12/10/2011, 06h32
koala01
Rajoute un destructeur virtuel public dans la classe Collision.

Tu en auras de toutes manières besoin, vu qu'il faudra bien détruire la collision une fois qu'elle aura rempli son office et que tu ne saura pas quel est son type réel, et j'ai pu remarquer que cela aidait bien souvent le compilateur à prendre en compte l'héritage (bien que la seule présence d'une fonction virtuelle devrait normalement suffir :P)

autre chose : Que font ces deux lignes :question:
Code:

1 2 3 CollisionType::ECollisionType m_CollisionTypeFirst; CollisionType::ECollisionType m_CollisionTypeSecond;
Ce qu'il te faut, c'est un typedef public sur chaque type template, histoire de savoir quel est le type des objets qui entrent en collision :
template <typename FirstType, typename SecondType = FirstType>
Code:

1 2 3 4 5 6 7 class TCollision : public Collision { public: typedef FirstType first_type; typedef SecondType second_type; /* la suite };
Ce qui, avec une collision de type connu te permet de faire un coll:first_type * ptr=col.getFirst(); ;)

Bonjour,

Toujours le même problème. Il ne semble pas être capable de ramener le type Collision (classe mère) en type TCollision (classe fille). Je suis un peut bloqué là.

Je vous remet mon code:

Classe Collision:

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
#ifndef COLLISION_H_INCLUDED
#define COLLISION_H_INCLUDED
 
#include "ECollisionType.h"
 
class Collision
{
    public:
 
        void Transmit()
        {
            DoTransmit();
        }
 
        virtual ~Collision()
        {
        }
 
    protected:
 
        //Virtual Function
        virtual void DoTransmit()
        {
        }
 
        Collision(Collision const&);
        Collision& operator = (Collision const&);
};
 
 
#endif

Classe TCollision:

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
#ifndef TCOLLISION_H_INCLUDED
#define TCOLLISION_H_INCLUDED
 
#include "Collision.h"
#include "ECollisionType.h"
 
template <typename FirstType, typename SecondType = FirstType>
class TCollision : public Collision
{
    public:
 
        typedef FirstType First_Type;
        typedef SecondType Second_Type;
 
        TCollision(FirstType* f, SecondType* s):m_First(f), m_Second(s)
        {
        }
 
        virtual ~TCollision()
        {
        }
 
        FirstType* First()
        {
            return m_First;
        }
 
        SecondType* Second()
        {
            return m_Second;
        }
 
        CollisionType::ECollisionType CollisionTypeFirst()
        {
            return m_CollisionTypeFirst;
        }
 
        CollisionType::ECollisionType CollisionTypeSecond()
        {
            return m_CollisionTypeSecond;
        }
 
    protected:
 
        //Virtual Function
        virtual void DoTransmit()
        {
            m_First->Collide(this);
            m_Second->Collisde(this);
        }
 
        //Member
 
        FirstType* m_First;
        SecondType* m_Second;
 
        CollisionType::ECollisionType m_CollisionTypeFirst;
        CollisionType::ECollisionType m_CollisionTypeSecond;
};
 
#endif

TypeDef Collision:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#ifndef TYPEDEFCOLLISION_H_INCLUDED
#define TYPEDEFCOLLISION_H_INCLUDED
 
#include "TCollision.h"
 
class IntelligentObject;
class ImmobileObject;
class MovingObject;
 
typedef TCollision<IntelligentObject> CollisionTwoIntelligentObject;
typedef TCollision<IntelligentObject, MovingObject> CollisionIntelligentMovableObject;
typedef TCollision<IntelligentObject, ImmobileObject> CollisionIntelligentImmobileObject;
 
typedef TCollision<MovingObject> CollisionTwoMovableObject;
typedef TCollision<MovingObject, ImmobileObject> CollisionMovableImmobileObject;
 
#endif

Classe intelligent Object:

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
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
#ifndef INTELLIGENTOBJECT_H_INCLUDED
#define INTELLIGENTOBJECT_H_INCLUDED
 
#include "EObjectType.h"
 
#include "TypeDefCollision.h"
 
namespace IntelligentObjectType
{
    enum EIntelligentObjectType
    {
        None,
        Character,
        Enemy,
        Count
    };
}
 
///////////////////////////////////////////////////////////////////////////////////
//Base Interface Class for every intelligent Object (Character, ennemy, etc)
///////////////////////////////////////////////////////////////////////////////////
 
class IntelligentObject
{
    public:
 
        IntelligentObject() : m_X(0), m_Y(0), m_Width(0), m_Height(0), m_Speed(0.f), m_MaxSpeed(0.f), m_AccelerationX(0.f), m_AccelerationY(0.f), m_Score(100), m_IsVisible(true), m_Type(IntelligentObjectType::None)
        {
        }
 
        IntelligentObject(IntelligentObjectType::EIntelligentObjectType type) : m_X(0), m_Y(0), m_Width(0), m_Height(0), m_Speed(0.f), m_MaxSpeed(0.f), m_AccelerationX(0.f), m_AccelerationY(0.f), m_Score(100), m_IsVisible(true), m_Type(type)
        {
        }
 
        //Pure virtual function to prevent to instanciate it
        virtual ~IntelligentObject()
        {
        }
 
        //The function that will be call by the collision system
        void Collide(Collision* col)
        {
            DoCollide(*col);
        }
        /*
        void React(ReactObject* obj)
        {
            DoReact(*obj);
        }*/
 
        void Update(float elapsedTime)
        {
            DoUpdate(elapsedTime);
        }
 
        virtual void Hurt(){}
 
 
        float GetX() const
        {
            return m_X;
        }
 
        float GetY() const
        {
            return m_Y;
        }
 
        int GetWidth() const
        {
            return m_Width;
        }
 
        int GetHeight() const
        {
            return m_Height;
        }
 
        float GetSpeed() const
        {
            return m_Speed;
        }
 
        float GetAccelerationX() const
        {
            return m_AccelerationX;
        }
 
        float GetAccelerationY() const
        {
            return m_AccelerationY;
        }
 
        int GetScore() const
        {
            return m_Score;
        }
 
        bool IsVisible() const
        {
            return m_IsVisible;
        }
 
        void SetVisible(bool visible)
        {
            m_IsVisible = visible;
        }
 
        void SetX(float x)
        {
            m_X = x;
        }
 
        void SetY(float y)
        {
            m_Y = y;
        }
 
        void SetPosition(int x, int y)
        {
            m_X = x;
            m_Y = y;
        }
 
        void SetWidth(int width)
        {
            m_Width = width;
        }
 
        void SetHeight(int height)
        {
            m_Height = height;
        }
 
        void SetSpeed(float speed)
        {
            m_Speed = speed;
        }
 
        void SetAccelerationX(float accelerationX)
        {
            m_AccelerationX = accelerationX;
        }
 
        void SetAccelerationY(float accelerationY)
        {
            m_AccelerationY = accelerationY;
        }
 
        void SetScore(int score)
        {
            m_Score = score;
        }
 
        IntelligentObjectType::EIntelligentObjectType GetType() const
        {
            return m_Type;
        }
 
        float GetMaxSpeed() const
        {
            return m_MaxSpeed;
        }
 
        void SetMaxSpeed(float speed)
        {
            m_MaxSpeed = speed;
        }
 
        BaseObjectType::EBaseObjectType GetBaseType() const
        {
            return BaseObjectType::IntelligentObjectType;
        }
 
    protected:
 
        //Protected function
        virtual void DoCollide(CollisionTwoIntelligentObject& col){}
        virtual void DoCollide(CollisionIntelligentMovableObject& col){}
        virtual void DoCollide(CollisionIntelligentImmobileObject& col){}
        //virtual void DoCollide(CollisionTwoMovableObject& col){}
        //virtual void DoCollide(CollisionMovableImmobileObject& col){}
        /*
        virtual void DoReact(ReactIntelligentObject& reaction){}
        virtual void DoReact(ReactMovableObject& reaction){}
        virtual void DoReact(ReactImmobileObject){}*/
 
 
        virtual void DoUpdate(float elapsedTime){}
 
 
        //Member
        float m_X;
        float m_Y;
        int m_Width;
        int m_Height;
        float m_Speed;
        float m_MaxSpeed;
        float m_AccelerationX;
        float m_AccelerationY;
        int m_Score;
        bool m_IsVisible;
        IntelligentObjectType::EIntelligentObjectType m_Type;
 
};
 
#endif

Et l'erreur qu'il me donne toujours :

Citation:

||=== Projet_Jeu, Debug ===|
|In member function 'void IntelligentObject::Collide(Collision*)':|
|60|error: no matching function for call to 'IntelligentObject::DoCollide(Collision&)'|
|195|note: candidates are: virtual void IntelligentObject::DoCollide(CollisionTwoIntelligentObject&)|
|196|note: virtual void IntelligentObject::DoCollide(CollisionIntelligentMovableObject&)|
|197|note: virtual void IntelligentObject::DoCollide(CollisionIntelligentImmobileObject&)|
||=== Build finished: 1 errors, 0 warnings ===|

Auriez-vous une idée ?

Citation:

autre chose : Que font ces deux lignes

CollisionType::ECollisionType m_CollisionTypeFirst;
CollisionType::ECollisionType m_CollisionTypeSecond;

Ces deux lignes me servent pour savoir quel partie de l'objet à été collisionné. C'est en faite un enum ( haut, bas, gauche, droite). Comme je n'ai pas trouvé de meilleur solution, j'ai décider d'y aller ainsi.
J'en ais de besoin puisque dans un Mario, on ne réagit pas pareil selon la place ou on a été frappé.

Fuseau horaire GMT +2. Il est actuellement 22h08.