DrawableGameComponent ou pas ?

Bonjour,

Je commence à me lancer dans le développement de jeux avec XNA.
J'ai une question quand à la création d'un objet player par exemple.

J'ai vu 2 méthodes et j'aimerai savoir quelle est la mieux ?
- Une méthode dont la class player étend DrawableGameComponent. Il faut implémenter les méthodes qui vont bien (Initialize, Update, Draw, LoadContent et UnloadContent).
Bon, j'ai testé cette méthode et j'ai eu un soucis car l'appli ne passe pas par la méthode LoadContent, là où je chargais mes texture.

- Seconde méthode : Ne pas étendre de DrawableGameComponent et ne mettre que les 2 méthodes suivantes : Update et Draw.

Je pense que je vais utiliser la 2 mais j'aimerai avoir quelques avis sur la question.

Merci d'avance.

Pour que le LoadContent soit appelé il ne faut pas oublier d'appeler base.Initialize(); dans ton initialize.

Pour un débutant hériter de DrawableGameComponent peut être intéressant.
Pour du développement sérieux c'est une classe à éviter tout comme spritebatch.

Merci MoDDiB pour ta réponse.

Le mieux au final ce serait donc la 2eme solution. Si on veut avoir un projet sérieux.

Pourquoi faut-il éviter spritebatch ?

Pour ma première solution, j'avais bien mis base.Initialize(); dans mon initialize :?

Merci d'avance :D

Citation:

---

Envoyé par Khrysby

Pourquoi faut-il éviter spritebatch ?

---

Pour des problèmes de performances, de manque de flexibilité et de difficulté de debugger en cas de soucis.
Tant que tu ne ressens pas un de ses problèmes là avec spritebatch ne t'embêtes pas à réinventer la roue.

Ca roule. Merci beaucoup pour ton aide !

Juste, si t'as un petit tuto que tu aimes bien et que tu conseillerais ou un petit conseil perso à donner ;), je veux bien.

Merci en tout cas.

Comme je n'ai pas de précision sur ce que tu souhaites faire je ne vais pas être bien original , je recommande les tutoriaux officiels :
http://create.msdn.com/en-US/education/catalog/

Merci :).

Pour l'instant je me lance dans la 2D. Je pense développé un jeux en 2D puis en 3D... Je ne sais pas trop encore.

Je met en résolu.

N'hésite pas si tu as d'autres idées ;).

Merci encore.

Dit moi,

Est-ce que pour toi, cette exemple : http://create.msdn.com/en-US/educati...ample/spacewar

Je peux me baser dessus (structure...) ?

Merci d'avance pour ta réponse et bon weekend !

Il y a toujours des choses intéressantes à en tirer d'un sample aussi avancé, mais au niveau de l'architecture celui-ci est très moyen.

Ah mince...
J'aimerai bien tombé sur un projet bien réalisé pour prendre exemple...

Merci encore pour ton avis !

Aucune des deux méthodes est bonne. La classe joueur reçoit trop de responsabilités, elle doit s'initialiser, se mettre à jour et se dessiner, ce sont tous des éléments qui devraient être découplés. Trop de responsabilité égal plus de couplage, le code devient difficile à maintenir et à réutiliser.

Lorsque possible, il faut utiliser la composition et non l'héritage. Au lieu de dire le joueur est dessinable, il vaut mieux dire que le joueur contient un élément dessinable. Au lieu de dire que le joueur est un comportement, il vaut mieux dire que le joueur contient un comportement. C'est la manière de voir la composition.

Le joueur ainsi que les entités devraient être composés de comportement, d'éléments dessinables, d'éléments physiques, etc.

Exemple simple, si le joueur a de la vie, et qu'il commence à 10 points de vie. Au lieu de coder cette logique dans la classe joueur elle est codé dans une class "Health" paramètrable qui gère la vie, et le joueur est composé d'une instance de cette classe qui gère la vie. Ainsi, toutes les entités du jeu peuvent se composer de ce comportement. Les classes de comportement sont hyper spécialisées et plus facile à maintenir.

On bâti les entités du jeu avec des comportements. Ça hévite le multi-héritage, et un graph d'héritage qui devient compliqué à visualiser et à gérer. Au final c'est plus facile à déboguer car les classes sont simples.

Pour faire simple avec le joueur, il pourrait être une instance d'une classe générique Entity. Cette classe pourrait contenir une instance d'une classe Drawable(2D ou 3D) qui contient la fonction Draw. Elle pourrait contenir Load et Save aussi, mais en temps normal ces fonctions devraient être dans une classe spécialisée au IO. Ensuite elle pourrait contenir une classe "PlayerLogic" qui contient la logique du joueur et une fonction Update. Ensuite l'entité du joueur pourrait aussi contenir une classe PhysicAttributes qui contient les éléments de collisions du joueur.

Pour avoir travaillé 2 ans et demi avec XNA, je dois dire que les exemples sur le site sont plus des exemples d'utilisation de XNA, que des bons exemples de design de jeux.

Citation:

---

Envoyé par Mikmacer

je dois dire que les exemples sur le site sont plus des exemples d'utilisation de XNA, que des bons exemples de design de jeux.

---

+1

Si tu cherches un exemple plus sérieux regarde de ce côté :
http://igf.codeplex.com/wikipage?tit...=Documentation
Je ne suis pas fan de tous ses choix mais ce monsieur est quelqu'un de très organisé, en rendant son code plus data-driven il y a moyen d'avoir une archi sympathique.

Citation:

---

Envoyé par Mikmacer

Aucune des deux méthodes est bonne. La classe joueur reçoit trop de responsabilités, elle doit s'initialiser, se mettre à jour et se dessiner, ce sont tous des éléments qui devraient être découplés. Trop de responsabilité égal plus de couplage, le code devient difficile à maintenir et à réutiliser.

Lorsque possible, il faut utiliser la composition et non l'héritage. Au lieu de dire le joueur est dessinable, il vaut mieux dire que le joueur contient un élément dessinable. Au lieu de dire que le joueur est un comportement, il vaut mieux dire que le joueur contient un comportement. C'est la manière de voir la composition.

Le joueur ainsi que les entités devraient être composés de comportement, d'éléments dessinables, d'éléments physiques, etc.

Exemple simple, si le joueur a de la vie, et qu'il commence à 10 points de vie. Au lieu de coder cette logique dans la classe joueur elle est codé dans une class "Health" paramètrable qui gère la vie, et le joueur est composé d'une instance de cette classe qui gère la vie. Ainsi, toutes les entités du jeu peuvent se composer de ce comportement. Les classes de comportement sont hyper spécialisées et plus facile à maintenir.

On bâti les entités du jeu avec des comportements. Ça hévite le multi-héritage, et un graph d'héritage qui devient compliqué à visualiser et à gérer. Au final c'est plus facile à déboguer car les classes sont simples.

Pour faire simple avec le joueur, il pourrait être une instance d'une classe générique Entity. Cette classe pourrait contenir une instance d'une classe Drawable(2D ou 3D) qui contient la fonction Draw. Elle pourrait contenir Load et Save aussi, mais en temps normal ces fonctions devraient être dans une classe spécialisée au IO. Ensuite elle pourrait contenir une classe "PlayerLogic" qui contient la logique du joueur et une fonction Update. Ensuite l'entité du joueur pourrait aussi contenir une classe PhysicAttributes qui contient les éléments de collisions du joueur.

Pour avoir travaillé 2 ans et demi avec XNA, je dois dire que les exemples sur le site sont plus des exemples d'utilisation de XNA, que des bons exemples de design de jeux.

---

ouep, le concept est bien, le seul truc que je ne trouve pas beau, c'est quand le comportement doit interagir avec par exemple une texture du model qui contient ce comportement... il va falloir instancier le model dans ce comportement, en gros avoir A qui contient un instance de B et B de A... et je ne trouve pas ça super propre, donc si tu as uns solution propre à cela.... je suis preneur