Sprite manager : utilisation avec des classes derivées de Sprite

Bonjour,

Dans le cadre d'un developpement d'un moteur de jeu, je viens de terminer un Sprite manager, qui permet d' ajouter, retirer, afficher, tester les collision de Sprite (Classe avec une image, une coord, un Z-Order, et des méthode virtuelle draw, ,update, cycle...).

Tout cela est bien beau, mais je voudrai maintenant utiliser des classes derivées de Sprite, plus spécialisée (Unit, Character... avec leurs propriétés spécifique ). Je les ajoutent dans le Sprite manager et ils sont affichés, mais bien entendu je ne peut pas accéder a leurs méthode spécifique (puisque au finale, ils sont stocké dans le Manager en tant que Sprite).

Que faire pour profiter du manager avec ces classes ?

Dois je ajouter ces classes derivée dans le manager pour profiter des methodes commune avec Sprite, et les garder dans une autre collection dans le jeu en lui meme (une par type derivé) puis synchroniser quand un objet doit etre retiré ? Comment vous y prenez vous ?

Merci d'avance.

C'est une très bonne question et intéressante ; ce que je vois comme solution c'est de faire un sprite manager auquel tu passes des templates génériques..
sinon à part effectivement gérer des listes en parallèle qui contiennent des classes héritées de la classe de base je ne vois pas...
si quelqu'un a une meilleure idée..
:D

Salut,

Si je comprends bien, tu as ca par exemple :

Code:

---

1 2 3 4 5 6 7 8 9

SpriteManager SM; Sprite_Unit MonUniteDeriveeDeSprite; Sprite_Char MonCharDeriveDeSprite;   SM.Add (MonUniteDeriveeDeSprite); SM.Add (MonCharDeriveDeSprite);   SM.Element[0].FonctionSpecifiqueAuxUnites(); SM.Element[1].FonctionSpecifiqueAuxChars();

---

Et ca ne fonctionne pas ? Pourquoi ne pas essayer un cast ?

Code:

---

1 2	((Sprite_Unit)SM.Element[0]).FonctionSpecifiqueAuxUnites(); ((Sprite_Char)SM.Element[1]).FonctionSpecifiqueAuxChars();

---

Merci de vos reponses,
Je ne peut pas faire un cast car le manager de sprite contiens toutes sortes de derivées de sprites, de plus je ne peut pas utiliser leurs methodes ou attributs spécifique, a moins d'utiliser un mechanisme RTTI, mais il y a peut etre mieux, je pensais effectivement a une manager template, ou peut etre un manager de "scene" plus souple... quelle est la methode utilise dans les moteurs de jeux (que je pourrai implémenter relativement facilement)

Salut,

Tiens un peu de lecture dans le forum d'Ogre3d qui peut donner quelques idées : Component Based Objects?.

MAT.

Il aurait fallu préciser que c'était pour OGRE merci parce que j'ai voulu faire une réponse générique.:?

Citation:

---

Envoyé par Mat.M

Il aurait fallu préciser que c'était pour OGRE merci parce que j'ai voulu faire une réponse générique.:?

---

Pas spécialement, d'ailleurs le contenu de la discussion au bout du lien que j'ai donné tourne très vite au générique.

MAT.

Pas de problème de ce coté la (ma question étais d'ailleurs générique exprès, bien qu'a la relire je n'aurai même pas du mentionner les méthodes virtuelle ;) )
je vais prendre le temps de lire cela et je posterai peut être une synthèse.
Et puis pourquoi ne pas poursuivre avec OGRE avant de coder un graphe de scène.

Si j'ai bien compris ton problème, pourquoi ne pas avoir une méthode abstraite update dans ta classe Sprite de base ?
Chacune de tes classes dérivées implémentent update avec leur trucs spécifiques.
A chaque tour de boucle, ton Sprite Manager appelle la méthode update de tous les objets Sprite qu'il contient.

Non ?

Sinon, un article que j'ai trouve bon a propos de l'organisation des classes d'un jeu : http://www.gamasutra.com/features/20...rouwe_01.shtml (en anglais et il faut avoir un compte Gamasutra mais c'est gratuit).

Je me permet d'ajouter mon grain de sel dans la conversation.

Le modèle que tu (TheDrev) proposes possède un point noir non négligeable: tu prétends considérer qu'une unité est un sprite, ou qu'un personnage est un sprite. Ce n'est pas vrai - le lien réel existant entre l'entité considérée et le sprite étant "l'entité possède une représentation sous la forme d'un sprite". Il ne s'agit pas d'une notion d'héritage, mais bien d'une notion de composition.

Pour s'en convaincre, il suffit de voir le problème auquel tu te heurtes. Tant que tu manipules des sprites, tout va bien. Dès lors que tu souhaite manipuler autre chose, tu te retrouves avec un problème de comportement, car une unité ou un personnage ne se comporte pas comme un sprite (en somme, il y a la une violation du principe de substitution de Liskov, qui dit grosso-modo "Une fonction qui utilise un objet d'une classe mère doit pouvoir utiliser toute instance d'une classe dérivée sans avoir à le savoir"; la formulation plus exacte est "Soit q(x) une propriété prouvable à propos des objets x de type T. Alors q(y) doit être vrai pour les objets y de type S lorsque S est un sous-type de T").

Pour passer outre cette limitation, tu dois effectuer des tests sur le type réel de l'instance considérée. La violation du principe de substitution entraine donc dans ton cas une violation supplémentaire du principe "ouvert/fermé" ("le logiciel doit être fermé à la modification, mais ouvert à l'extension", ou, pour simplifier, étendre le logiciel ne doit pas impliquer une modification du code source. Dans ton cas, ajouter une classe qui hérite de Sprite t'impose de modifier le code source là ou les sprites sont upcastés).

La solution a ton problème n'est donc pas d'ordre syntaxique, mais bien au niveau d'ordre architectural. Dans ce cas, un système de gestion des composants peut être mis en place (cf l'article sur gamasutra et le Evolve your Hierarchy de Mike West, qui cite d'autres références).

Je dis peut être une connerie mais t'es pas en train de confondre la partie graphque du jeu et la partie world model?

Un sprite ca se charge et s'affiche.
Un personnage ça a des collisions, des interactions ect. Mais c'est pas le sprite qui fait ça, c'est l'entité. Le sprite c'est juste la représentation graphique de l'entité.