C++

Problème de design objet

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Problème de design objet

_momone_

J'aimerais faire une sorte de "game engine". Pour cela, j'ai pensé le décomposer en plusieurs parties, théoriquement indépendantes les unes des autres.
Par exemple, il pourrait y avoir un module consacré pour le son, un autre pour les graphismes, un autre pour le rezo...

Le problème c'est que chacun de ces modules devrait etre accessible de n'importe où dans le programme. Par exemple, dans la fonction qui s'ocuppe de faire tirer le personnage, j'aimerais produire un son de coup de feu. Il faudrait donc que je puisse accéder au module 'SoundManager'. Mais le truc, c'est que je n'ai pas envie de créer une instance de SoundManager a chaque fois que je veux jouer un son.
Donc, j'ai pensé a plusieurs solutions que je trouve pas tellement élégantes.

- On commence par la pire:
Je mets toutes les fonctions membres de SoundManager en static ce qui a mon humble avis, est vraiment ce qui peut ce faire de plus crade... enfin peut etre que je me trompe.
Pour jouer un son, ca donnerait:

Code :

SoundMng::PlaySound(...);

- Un peu moins crade mais dans le meme registre d'idées:
Regrouper tous les modules dans une classe GameEngine, encore une fois en static. Mais ca eviter que tous les membres de tous les modules soient en static. Donc en gros, ca me donnerait ca:

Code :

class GameEngine
{
public:
static SoundManager SoundMng;
static VideoManager VideoMng;
...
};
//Et donc, pour jouer un son, il faudrait que je fasse:
GameEngine::SoundMng.PlaySound(...);

- J'ai pensé aussi à créer une instance de chaque module en tant que variable globale. Je pourrais alors accéder a mon SoundManager sans problème depuis partout, mais je sais pas, je trouve ca un peu crade aussi.

Code :

g_SoundMng.PlaySound(...);

- Enfin, jpeux faire de chacun des modules un singleton:

Code :

SoundManager::GetInstancePointer()->PlaySound(...);

J'aimerais avoir votre avis sur toutes ces propositions ou alors meme, que vous en proposiez de nouvelles plus adaptées.

Publicité

chrisbk

ben tu peux faire une class "Son" qui connait le soundManager d'ou elle est issu, et donner cette class "Son" a ton gugus.

genre :

Code :

class Soldat
{
Son *bruitDeFusil;
}

Code :

void Soldat::tir()
{
bruitDeFusil->joue();
}

_momone_

Pas mal, j'y avait pas pensé
Mais du coté de la classe son, tu implémenterais ça comment?

Un truc genre:

Code :

class Son
{
private:
static SoundManager *SoundMng;
};

ou quelquechose de complètement différent?

En tout cas, merci pour ta réponse!

Message édité par _momone_ le 15-03-2004 à 22:05:59

chrisbk

pas de static, non
snul le static
chaipas, je sais pas comment est foutu ton bazard. Ptet un constructeur privée, une relation d'amitié avec SoundManager et soundManager qui crée des instance de Son

genre

Son *prout = SoundManager->load("prout.wav" );

enfin je te dis ca au debotté hein ?

Message édité par chrisbk le 15-03-2004 à 22:07:49

_momone_

Citation :

Son *prout = SoundManager->load("prout.wav" );

Ouaip, mais ca change pas tellement le problème, il faut toujours que je trouve un moyen pour accéder à SoundManager.

Sinon, jsuis d'accord avec toi, le static, c'est pas super beau... :|

xterminhate

Si vis pacem, para bellum.

Il y a une autre solution (celle que j'utilise actuellement) mais qui est nettement plus complexe et qui demande un effort de programmation au départ assez conséquent.

Voci comment se décompe cette solution (je vais essayé de vulgariser) :

* Chaque module de traitement hérite d'une classe de type "boite aux lettres".

* Toutes les classes "boite aux lettres" communiquent entre elles via un unique "module de messagerie (singleton)".

* Les modules de traitement s'échangent des message standardisés (basés sur une classe message de base non typée) que le "module de messagerie" aiguille.

Les avantages de cette solution sont multiples :

* une architecture evolutive et extensible.
* des possibilités de trace/debug interessantes.
* ...

L'inconvénient majeur est la lourdeur pour des applications simples avec peu de modules de traitement. La commutation (nombre de messages aiguillés par seconde) demande bcp de ressources cpu/mémoire par rapport à une architecture optimisée.

D'autre part, si tu ajoutes au "module de messagerie" une fonction de communication réseau, tu peux réaliser une application complexe dont les modules s'executent sur des machines différentes et distantes via Internet ou un réseau local.

Cordialement,
Xter.

Message édité par xterminhate le 15-03-2004 à 22:46:48

xterminhate

Si vis pacem, para bellum.

Cela dit, pour reprendre l'idée de chrisbk, un singleton repond partiellement à ton problème, à condition que chaque type de module soit unique : 1 x son, 1 x video, 1...

Cordialement,
Xter.

blackgoddess

vive le troll !

bin il peut avoir 1 seule instance de son soundmanager, qui contient une liste (un cache en qq sortes) de sons chargés, (un std::map par exemple) puis ses objets (soldat par exemple) doivent avoir acces au son dans la liste

---------------
-( BlackGoddess )-

xterminhate

Si vis pacem, para bellum.

Oui tout a fait.

frenchkiss

c est pas au soldat de faire le bruit du fulsil !

le tir du soldat ne devrait faire qu'un truc su style
if (arme)
arme->tir()

bon vla ma contribution.

les arme derivant toutes d'une classe arme de base
qui prendrait en constructeur un soundmanager*

(cree par ton engine au demarrage)

et chaque arme appelle le bon play sur le sound manager dans sa methode tir ( qui est virtuelle pure dans la classe arme de base)

c'est donc l arme qui produit le bruit (logique)
bazooka::tir()
{
sndmanager->playbazooka(); // tu peux faire ton propre snd manager qui herite de l existant pour avoir des noms de methode explicite aussi..
pis dautre truc du style
emettrefummee()...
}

ect...

Message édité par frenchkiss le 16-03-2004 à 13:44:57

Publicité

_momone_

Ok merci pour toutes vos réponses!

Jtrouve l'idée de xterminhate, pour faire communiquer les différents modules entre eux à l'aide d'une classe unique de "messagerie", plutot astucieuse et ca m'a donné des idées pour implémenter d'autres choses

Sinon, le probleme avec la solution de frenchkiss, qui a l'air d'être à peu près la même que celle de chrisbk, c'est qu'il faut toujours passer un pointeur vers le SoundManager au constructeur de bazooka. Et justement mon problème c'est de savoir comment connaitre l'adresse du SoundManager à partir de n'importe où dans le prog (si j'ai par exemple envie de creer un bazooka en plein milieu du jeu).

Donc je pense m'orienter vers la solution:

Citation :

Regrouper tous les modules dans une classe GameEngine, encore une fois en static. Mais ca eviter que tous les membres de tous les modules soient en static. Donc en gros, ca me donnerait ca:

Code :

class GameEngine
{
public:
static SoundManager SoundMng;
static VideoManager VideoMng;
...
};
//Et donc, pour jouer un son, il faudrait que je fasse:
GameEngine::SoundMng.PlaySound(...);

J'aimerais avoir votre avis sur cette solution.
Et vous ne pensez pas que ca serait pas plus propre de faire de SoundManager une variable globale, ou un singleton?

Merci

xterminhate

Si vis pacem, para bellum.

Connais tu le design pattern singleton ? Il est tres facile de récupérer le pointeur sur l'instance unique d'un singleton n'importe ou dans ton programme.

Code :

class soundmanager // programmé selon le design singleton...
{
public:
static soundmanager * GetInstance() { if( smInstance == NULL ) smInstance = new soundmanager; return smInstance; }
playsound( std::string & );
private:
soundmanager();
~soundmanager();
soundmanager( soundmanager & );
soundmanager & operator= ( soundmanager & );
static soundmanager * smInstance;
}
soundmanager * soundmanager::smInstance = NULL;
class player
{
public:
player();
tir();
private:
soundmanager * sm; // pas tres judicieux comme nom :)
};
player::player()
{
sm = soundmanager::GetInstance();
}
player::tir()
{
sm->playsound("panTmort" );
}

Cordialement,
Xter.

Message édité par xterminhate le 16-03-2004 à 19:48:56

_momone_

Le singletons m'ont l'air de correspondre en effet à ce que je cherche à faire

frenchkiss

non ca n a rien a voir avec ce que propose chrisb

de toute facon si t as envie de creer un bazooka encore une fois
il te faut un object du style " fabrique d'arme "
aui pourrait eventuellement etre un singleton mais je pense pas que ca soit tres uilise
puisqu'a priori tu pourra construire une arme que dans ceraint cas particulier ( chai pas moi genre fabrique d arme)
et a toi de t arranger pour avoir toute l info necessaire au moment ou tu construit ton jouet... etc..

c'est un travail de conception avant tout , eventuellement tu peux lire un bouquin sur les design pattern . C'est plein de bon sens avec un mot technique dessus mais apparement ca t'aiderai pour pouvoir penser un peu plus " object"

salut
FK

FORUM HardWare.fr

Programmation

C++

Problème de design objet

Sujets relatifs
[JAVASCRIPT] problème de compatibilité du code entre IE<--> Mozilla	[STRUTS] Problème de connexion à la database
problème avec Eclipse	probleme envoi mail ifrance
envoyer fomulaire par mail avec un objet	Problème avec affichage d'une Jtable
Problème avec une variable dans une requête	Probleme Graphics
overload <<, probleme :/	CVI probleme d'utilisation des API windows
Plus de sujets relatifs à : Problème de design objet

Page générée en 0.069 secondes