[c++]Architecture des classes pour un jeu

Tout d'abord bonjour :)

Je programme actuellement un jeu en opengl en c++.
J'avais commencé à le programmer à la bourrin histoire d'avoir un squelette qui tourne sans me preocupper des classes.

Maintenant je reorganise entierement mon code avec des classes pour avoir un truc à peu pres propre.

Pour l'instant en gros j'ai ca :
classe GameEngine ( 1 seule instance)
| classe Hero
| classe PhysicEngine
| classe GraphicEngine
| ...

( en gros hein, c'est pour simplifier :) )

les classes physicEngine et graphicEngine decrivent bien ce qu'elles font je pense ;)

La classe hero contient la position, l'angle, la vie etc...

Mon probleme est le suivant : j'ai besoin d'utiliser la classe hero ( entre autre ) dans le moteur physique ( pour les collisions ) et pour le moteur graphique ( pour l'afficher forcement ^^ )

Est-ce que ca veut dire que j'ai mal organisé mes classes? En principe une classe devrait etre fonctionnelle seule, enfin c'est du moins ce que j'ai appris :)

J'ai pensé rajouter une classe ObjetsCommuns dans le GameEngine, et passer un pointeur vers l'instance à mes 2 classes Graphic et physique, est-ce la meilleure chose à faire? je ne vois que ca pour l'instant :/

Voila, j'ai besoin de conseils pour l'organisation de mes classes, j'aimerai pas m'embarquer sur cette voie si c'est la pire des choses à faire ;)

Merci d'avance :)

[Déplacé par King Kaiser]

Citation:

---

Envoyé par Pegasus32

Tout d'abord bonjour :)

---

Luss à toi !!

Citation:

---

Envoyé par Pegasus32

J'avais commencé à le programmer à la bourrin histoire d'avoir un squelette qui tourne sans me preocupper des classes.

---

Alors soit tu "fais une connerie" soit tu t'exprime mal.
Programmer à la bourrin "pour voir comment ça marche", afin de pouvoir "definir des classes", de "cerner leurs rôles", etc... Mais tel que tu l'as dis ça me dérange un peu. Passons.

Citation:

---

Envoyé par Pegasus32

( 1 seule instance)

---

Juste une note, ça s'appelle un "singleton" (prononciation franco-française, en tout cas moi j'avais fait l'erreur !)

Citation:

---

Envoyé par Pegasus32

( en gros hein, c'est pour simplifier :) )
les classes physicEngine et graphicEngine decrivent bien ce qu'elles font je pense ;)

---

Ben OK, c'est gentil de simplifier, mais précise, je te jure, j'ai pas de boule de crystal :wink: (Dystortion? ceux qui connaissent les Spi auront compris) Bref...

Citation:

---

Envoyé par Pegasus32

La classe hero contient la position, l'angle, la vie etc...
Mon probleme est le suivant : j'ai besoin d'utiliser la classe hero ( entre autre ) dans le moteur physique ( pour les collisions ) et pour le moteur graphique ( pour l'afficher forcement ^^ )

---

Ca précise un peut... Mais...
Ta classe Hero contient les Vertex et les faces du perso, ou non ? ne serais-ce que ça, il faut le savoir...
En plus tu te situe à une frange où l'objet pur est bienvenu pour un architecture modulaire et extensible, mais la technologie (les choix d'implémentation lié au language) sont déterminants pour les performances...
Il faut pus de précisions.

Citation:

---

Est-ce que ca veut dire que j'ai mal organisé mes classes? En principe une classe devrait etre fonctionnelle seule, enfin c'est du moins ce que j'ai appris :)

---

Une classe fonctionnelle seule ? Ca dépend... Un classe métier, oui, SOUVENT. Mais tout modèle possède un "graphe de dépendance", ce qui indique dans son nom que certaines classes ne peuvent être "isolées" au sens strict du terme.

Citation:

---

J'ai pensé rajouter une classe ObjetsCommuns dans le GameEngine, et passer un pointeur vers l'instance à mes 2 classes Graphic et physique, est-ce la meilleure chose à faire? je ne vois que ca pour l'instant :/

---

J'immagine que tu parle de polymorphisme. Passage par pointeur, pkoi pas. Par référence, en C++, c'est plus propre, mais soit EXPLICITE, s'il te plait (je me répète un peu trop, je pense que tu as compris, :wink:)


Voilà, j'attend tes précisions et je (nous) pourrons t'en dire plus !

Citation:

---

Envoyé par Pegasus32

Pour l'instant en gros j'ai ca :
classe GameEngine ( 1 seule instance)
| classe Hero
| classe PhysicEngine
| classe GraphicEngine
| ...

---

On peut aussi imaginer que l'implémentation d'un moteur, soit composée de nombreuses classes regroupée au sein d'un namespace mais pas une classe en particulier.
Par exemple, l'implémentation du moteur graphique pourrait comprendre les classes : caméra, scene, source lumineuse, mesh ... regroupée au sein du namespace GraphicEngine.
L'implémentation du moteur physique pourrait comprendre différent types d'objets suivant les lois physique à modéliser : ressort, systèmes particules ... au sein du namespace PhysicEngine
La classe Héro serait dans un namespace spécifique au jeu, et par héritage elle récupérait les comportements de "mesh" (pour la partie visuelle) et "objet" pour la partie physique.

Citation:

---

Mon probleme est le suivant : j'ai besoin d'utiliser la classe hero ( entre autre ) dans le moteur physique ( pour les collisions ) et pour le moteur graphique ( pour l'afficher forcement ^^ )

---

Si tu dois partager une instance entre plusieurs objets qui l'agrégent, (ce qui t'arrivera forcément à un moment ou à un autre de ton projet), il te faut utiliser un mécanisme de smart pointeur avec comptage de référence.
Il y a beaucoup de librairies de smart ptr disponibles sur le net, mais les plus connues sont boost::shared_ptr<T> (la plus mature) et Loki (plus ambiteuse mais nécessite un compilateur très récent).

Réponse au message de SKZ81 :

Quand je disais "à la bourrin", c'etait vraiment bourrin, c a d quasiment pas de classe et tout dans le main :D
Je sais que c'est une chose à ne surtout pas faire, et j'en ai honte maintenant ^^, mais je programmais encore à la "C" à ce moment la :/ Donc j'ai fait comme ca jusqu'a avoir un programme qui me permette de construire un niveau (le monde est basé sur un tableau à 3 dimensions) et de jouer dedans.


Quand je disais une seule instance, j'instancie vraiment mon objet, mais effectivement, vu que je n'aurai de toute facon qu'une seule instance autant faire un singleton.

Dans la classe hero j'ai effectivement un tableau de vertices, d'indices de face, et les coordonnees de texture. J'ai également la position x,y,z et la velocité x,y,z, ainsi que d'autres attributs du meme genre.


physicEngine s'occupe de mettre à jour les attributs du hero en fonction de l'environnement exterieur (chute, etc...) donc je dois acceder aux attributs du hero ainsi que du monde.

graphicEngine s'occuppe de l'affichage opengl, et doit donc également accéder aux information du monde et du héro.

Au sujet de ta derniere remarque, non je ne parlais pas de polymorphisme.
Et désolé, je m'apercois que je n'ai pas du tout detaillé cette partie, normal que t'ais pas compris :oops:

En fait je pensais creer une classe objetsCommuns dans la classe gameEngine. Dans cette classe je met les objets Hero et celui contenant les informations sur le monde.

Puis je passe aux classes physicEngine et graphicEngine, un pointeur vers l'instance de objetsCommuns, afin de pouvoir acceder aux objets dont ces deux classes ont besoin.

Voila, j'espere avoir été clair cette fois ;)

je n'y connais pas grand chose mais les articles de Loulou pourront certainement t'aider
:lahola:
http://loulou.developpez.com/

Réponse au message de frecil:

Merci pour ta réponse, je vais me renseigner sur les namespace et voir si ca correspond à ce que je veut :)

Je vais voir également pour les smart pointer, vu que c'est exactement mon probleme : le partage l'instance d'un objet

Citation:

---

Envoyé par PINGOUIN_GEANT

je n'y connais pas grand chose mais les articles de Loulou pourront certainement t'aider
:lahola:
http://loulou.developpez.com/

---

En effet merci bcp, il parle justement des smart pointer dans son 1er article sur les moteurs 3D 8)

Citation:

---

J'avais commencé à le programmer à la bourrin histoire d'avoir un squelette qui tourne sans me preocupper des classes.

---

Comme beaucoup de gens qui programment des jeux pour le plaisir, on a très vite envie d'avoir un résultat sous les yeux (je suis passé par là...).

Dans n'importe quel programme, une chose très importante c'est l'ANALYSE.

On m'a toujours appris qu'un programme c'est 80% d'analyse et 20% de code. Et lorsque j'ai débuté je faisais 1% d'analyse et 99% de code.

Si je peux me permettre de te donner un conseil, laisses tomber un peu le clavier et prends un cahier et un stylo. Prends le temps de voir comment tu peux organiser tout ça.

Il n'y a pas une méthode pour tout. Le C++ est là pour te permettre de coder ton jeu selon la vision "humaine" que tu en as.

Pour ton cas précis c'est difficile de t'aider, on a pas le cahier des charges (pas assez de détails) et ton programme à l'air d'être bien avancé. Un jeux n'est pas un petit programme.

Un conseil que je donne toujours, si tu ne sais pas comment faire, regardes comment font les autres. Trouves des exemples de code sur le net et inspires-toi de leur méthode.

http://jeux-directx.com/

Il est clair que l'analyse est une étape primordiale, et que concevoir les classes d'un jeu demande énormément de cramage de neurones. Mais ce que je peux te dire également, c'est que tant qu'on a pas une certaine expérience on ne peut pas non plus pondre une conception de la mort qui tue avec son crayon et son bout de papier (ou à moins que ce soit moi qui sois vraiment très nul en conception :D). Il faut un minimum de pratique pour savoir quoi faire et ne pas faire, et il faudra tout de même y aller un peu à l'aveuglette, surtout lorsque tu débutes. C'est à force de faire, refaire, et rererefaire (et peut-être en lisant certains tutoriels aussi 8)) qu'on apprend petit à petit à organiser ses pensées, à faire des diagrammes cohérents, et à pondre des modèles bétons avant même d'avoir craché une seule ligne de code.
Bref ce que je veux dire c'est que tu vas en écrire et en réecrire du code mauvais, avant d'avoir une architecture de jeu convenable.

Ensuite pour te donner une idée concernant ton problème, personnellement je vois les choses de cette manière : tes différents moteurs de jeu (graphique, physique, son, ...) sont des genre de frameworks, qui travaillent avec beaucoup de classes abstraites et qui savent se debrouiller avec celles-ci. Ensuite les entités propres à ton jeu n'auront qu'à dériver de ces classes selon le rôle qu'elles auront dans le jeu. Exemple : ton héros dérivera de la classe Renderable (ainsi le moteur graphique saura l'afficher) et de la classe Collidable (ainsi le moteur physique saura le faire intéragir avec le reste du monde). Après il n'y a qu'à correctement redéfinir les différentes fonctions virtuelles de ces classes pour que ton héros s'integre parfaitement à ton moteur de jeu. Bien sûr en réalité c'est bien plus complexe, mais voilà le principe.

Après, selon le degré d'abstraction que tu veux donner à ton moteur, tu peux soit utiliser telles quelles ces classes abstraites, soit en dériver déjà des classes prédéfinies (Sprite, Particle, Mesh, ...) et utiliser celles-ci directement.

Citation:

---

on ne peut pas non plus pondre une conception de la mort qui tue

---

Aller Pegasus32, je suis sur qu'avec tout ces conseils tu vas nous pondre le jeu de la mort qui tue! :ccool:

Et j'espère que l'on aura le plaisir de pouvoir y jouer.

héhé merci pour les reponses, tes conseils loulou meritent reflexion 8)

je pense que je vais pour l'instant continuer sur ma lancée, cad le partage d'instance entre les deux classes, je verrai si c'est viable.

En fait mon moteur physique et graphique ne sont pas à proporement parler des moteurs, au sens où il sont fortement liés à mon jeu, ce ne sont pas des moteurs generiques reutilisable dans un autre jeu (et oui je debute encore et je pense pas encore avoir le niveau :oops: )

Pour info je bosse sur un remake de Spindizzy Worlds, pour ceux qui ont connu ce superbe jeu :wink:

Citation:

---

Mon probleme est le suivant : j'ai besoin d'utiliser la classe hero ( entre autre ) dans le moteur physique ( pour les collisions ) et pour le moteur graphique ( pour l'afficher forcement ^^ )

---

Je ne pense pas que cela soit vraiment nécessaire de créer une classe PhysicEngine.
Si elle gère les collisions du perso, alors autant les rattacher à la classe de "Hero".
On déclarera CHero::TestCollision

Citation:

---

J'ai pensé rajouter une classe ObjetsCommuns dans le GameEngine, et passer un pointeur vers l'instance à mes 2 classes Graphic et physique, est-ce la meilleure chose à faire? je ne vois que ca pour l'instant :/

---

Non cela alourdirait inutilement le code !
Tjs aller au plus simple !
Après étoffer le cas nécessaire.

Citation:

---

Envoyé par mat.M

Je ne pense pas que cela soit vraiment nécessaire de créer une classe PhysicEngine.
Si elle gère les collisions du perso, alors autant les rattacher à la classe de "Hero".
On déclarera CHero::TestCollision

---

mmmm, pas bete. On rejoint alors ce que dit Loulou, faire deriver hero d'une classe de base qui gere la physique d'un objet.
maintenant que j'y reflechis je trouve cette idee excellente lol

et pareil pour le graphisme, une methode afficher() dans une classe de base dont sont derivés hero et world, apres le moteur graphique fait juste hero.afficher() & world.afficher().

mais pour les objets communs on en reviens au meme point : hero doit connaitre l'objet world (pour les collisions avec le monde environnant) , de meme que graphic engine doit connaitre hero & world (pour les afficher), on a toujours une partage d'instance.

Oui l'héritage est un méchanisme que Loulou24 a parfaitement bien décrit.

on peut utiliser l'héritage pour un type bien particulier d'entité : par exemple si tu veux adjoindre un autre personnage à ton Hero , cela peut être un animal par exemple , comme dans un Role Playing Game.
Donc tu auras une classe de base CPerso et avec des classes héritées CHuman, CAnimal.

Citation:

---

mais pour les objets communs on en reviens au meme point : hero doit connaitre l'objet world (pour les collisions avec le monde environnant) , de meme que graphic engine doit connaitre hero & world (pour les afficher), on a toujours une partage d'instance.

---

Grâce à l'héritage on peut créer une hiérarchie d'objets.
Le moteur de Quake est basé sur cela.
Les MFC aussi
:wink:

Pour apprendre comment organiser tes classes, je te suggère de regarder quels sont les différents types de classe (types concrets, abstraits, classes de noeud, interface, structure d'application, etc...) et de voir ce qui peut le mieux convenir pour ton architecture.

Le but c'est de te simplifier la vie, de pouvoir réutiliser des classes dans d'autres programmes, modifier et ajouter des classes sans perturber la structure de l'application, que le tout soit cohérent avec aucun comportement indéfini.

Une architecture bien pensée, évite les bugs de la mort et permet une maintenance aisée.

Plus il y a de code et plus il y d'erreur. Regardes ce qui peut être regroupé, encapsulé. C'est le genre de chose qui ne peut pas toujours être pafait au début, mais avec l'expérience...

Pour voir un exemple de structure de programme, tu as la classe "cd3dapplication" du SDK de directX pour C++: c'est un très bon exemple je pense pour débuter.

J'ai fait rapidement un diagramme non-exhaustif:

http://pegasus32.free.fr/diagramme.bmp

Maintenant je dois relier les deux parties du diagramme.

J'ai pensé à deux solutions :

- un singleton qui contient les differents objets à afficher/collisionner

- un vecteur de pointeurs d'objets collidable dans le physiqueEngine et un vecteur de pointeurs d'objet renderable dans le graphicEngine.
Chaque fois qu'un objet est cree, on ajouter son pointeur dans le physiqueEngine si il est collidable et dans le graphicEngine si il est renderable.

perso je prefere la 2eme solution, les deux moteurs se contente de traiter ce qu'ils ont dans leur vecteur.

La seconde option me parait bonne à moi aussi :wink:.

Si on veut faire des choses plus compliquées, on ne rattachera pas nos objets à une simple liste, mais à un scenegraph. Mais là ça devient un poil plus compliqué (enfin quoique, on peut faire un scenegraph de base).

Citation:

---

Envoyé par Loulou24

La seconde option me parait bonne à moi aussi :wink:.

Si on veut faire des choses plus compliquées, on ne rattachera pas nos objets à une simple liste, mais à un scenegraph. Mais là ça devient un poil plus compliqué (enfin quoique, on peut faire un scenegraph de base).

---

pour commencer je vais me contenter d'une liste triee dans l'ordre d'affichage :)

Humm..., je comprends mieux ton problème là. 8O

Ta solution va fonctionner, je le pense aussi.

Sinon je ne le verrais pas du tout comme ça (je dis parce que je suis influencé par les moteurs que je connais).

Quelles sont les relations entre la classe GameEngine et les classes physiqueEngine/graphicEngine?

PhysicEngine et GraphicEngine sont instanciés dans le gameEngine
en fait gameEngine encapsule quasiment toute l'application, dans le main je me contente de creer la fenetre opengl et d'instancier le gameEngine, une petite boucle infinie et c tout.


Il m'est venu à l'esprit un autre chtit probleme ^^ :
pour les objets renderable, pas de probleme, ils peuvent s'afficher tout seuls comme des grands.

pour les collidable c plus compliqué, pour les collisions entre objets par exemple. Ca oblige chaque objet collidable à avoir connaissance de tout les autres objets collidable :/

ou alors la methode collidable::collide prend en parametre un pointeur d'instance d'un autre objet pour tester la collision entre les 2. ( reflexion en live la :D )

dans le physicEngine j'aurai ca :

Code:

---

1 2 3 4 5 6 7 8

for (i=0;i<nbObjets;i++) { for (j=0;j<nbObjets;j++) { if (j!=i) obj[i]->collide(obj[j]); //pour qu'un objet ne se teste pas sur lui meme }   }

---

mouais pas mal :)
c'est juste dommage que je doive me mettre à rediger mon probleme pour trouver une solution :twisted:

Code:

---

1 2 3 4 5 6 7 8

for (i=0;i<nbObjets;i++) { for (j=0;j<nbObjets;j++) { if (j!=i) obj[i]->collide(obj[j]); //pour qu'un objet ne se teste pas sur lui meme }   }

---

Tu n'as pas le choix, il faut bien vérifier les collisions. Après tu peux optimiser ce genre de chose selon ton programme. Par exemple voir s'il n'y pas des cas ou appeler if (j!=i) obj[i]->collide(obj[j]); n'est pas nécessaire. De plus, dans cette boucle tu vas traiter deux fois le même cas. Mais bon comme tu l'as dit

Citation:

---

reflexion en live la

---

Citation:

---

pour les collidable c plus compliqué, pour les collisions entre objets par exemple. Ca oblige chaque objet collidable à avoir connaissance de tout les autres objets collidable :/

---

Je dirais qu'il te faut un gestionnaire de collision.

Je ne pense pas que faire tester chaque collision à chaque entité soit la bonne solution. Je n'ai jamais vraiment codé de moteur physique, mais a priori ce que je ferais c'est de faire renvoyer à chacune de mes entités quelque chose permettant au moteur physique de tester lui-même les collisions, du genre son volume englobant.

Reflexion perso : tu ne crois pas que tout développer de A à Z comme ça représente énormément de travail ? Pourquoi ne pas utiliser un moteur physique (ou graphique) existant ? :)
Voire même une API qui te fait à peu près tout, style kjApi

Citation:

---

Envoyé par Loulou24

Reflexion perso : tu ne crois pas que tout développer de A à Z comme ça représente énormément de travail ? Pourquoi ne pas utiliser un moteur physique (ou graphique) existant ? :)
Voire même une API qui te fait à peu près tout, style kjApi

---

Disons que j'aime bien faire les choses moi meme :)
Et ce que je veut faire n'est pas forcement évolué, pur le graphisme la base suffit. Les collisions ne sont pas destinées à etre realistes, ca consiste en grande partie à rebondir quand on rencontre un mur et à gerer les chutes.

Apres eventuellement collision entre objets.

Et puis j'ai déja un truc qui tourne, là la difficulté c'est juste de mettre ca dans des classes.

Citation:

---

Disons que j'aime bien faire les choses moi meme Smile

---

On est 2 ;
En vue d'une adaptation pour Linux n j'ai essayé de porter mon jeu développé avec Direct X nativement :D
sous une lib graphique dont je tairais le nom :D ( licence GPL ) et ça rame énormément :oops: :oops:
Je m'y suis peut-être mal pris aussi ....