[c++]Architecture des classes pour un jeu

Version imprimable

Voir 40 message(s) de cette discussion en une page

12/02/2005, 17h22
Pegasus32

[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]
12/02/2005, 20h17
SKZ81

Re: [c++]Architecture des classes pour un jeu

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 !
12/02/2005, 21h09
frecil

Re: [c++]Architecture des classes pour un jeu

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).
12/02/2005, 21h24
Pegasus32

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 ;)
12/02/2005, 21h30
PINGOUIN_GEANT

je n'y connais pas grand chose mais les articles de Loulou pourront certainement t'aider
:lahola:
http://loulou.developpez.com/
12/02/2005, 21h31
Pegasus32

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
12/02/2005, 21h32
Pegasus32

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)
13/02/2005, 03h43
moldavi

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/
13/02/2005, 13h37
Laurent Gomila

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.
13/02/2005, 14h56
moldavi

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.
13/02/2005, 16h08
Pegasus32

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:
14/02/2005, 09h54
mat.M

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.
14/02/2005, 10h34
Pegasus32

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.
14/02/2005, 11h19
mat.M

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:
14/02/2005, 12h58
moldavi

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.
14/02/2005, 13h55
Pegasus32

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.
14/02/2005, 14h10
Laurent Gomila

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).
14/02/2005, 16h09
Pegasus32

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 :)
14/02/2005, 18h49
moldavi

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?
15/02/2005, 13h28
Pegasus32
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:

Voir 40 message(s) de cette discussion en une page