philosophie evenement

philosophie evenement - Java - Programmation

Marsh Posté le 01-02-2003 à 12:57:56    

bonjour
 
je compte essayer de développer un min jeu 2D sur plateau,
et voici la décomposition que j'ai retenue :
 
je voudrais décomposer les différentes modules de ce programme
en couches le plus indépendantes possible pour pouvoir les réutiliser
dans d'autres jeux2D à 2 balles.
 
Couche réseaux
 
Couche monde (Map + Entités)
 
Couche Jeu (le moteur du jeu)
 
Couche InterfaceGraphique
 
Couche Configuration
 
en fait en créant une nouvelle instance de Configuration je veux
modifier presque tout le comportement, soit pour jouer avec des
règles différentes et des modifs des maps soit pour carrément
faire un nouveau jeu.
 
le concept des evènement me parait bien pour ca, pour que les
parties soient indépendantes à 100% , mais jusqu'ici je n'ai vu
des events que pour les interfaces graphiques (y a bien l'eventObject
de java.util mais je n'ai pas trouvé d'examples)
 
est ce une bonne philosophie ?
y a t-il une meilleure approche ?

Reply

Marsh Posté le 01-02-2003 à 12:57:56   

Reply

Marsh Posté le 01-02-2003 à 13:04:42    

[:drapo]


---------------
Le site de ma maman
Reply

Marsh Posté le 01-02-2003 à 16:40:29    

Plusieurs façons de voir les choses:
 
Les classes pour le jeu, l'interface, ... sont créees au début de la partie en fonction de la configuration. Ca ressemble au design pattern 'factory'.
 
Ex: un monopoly avec un grand ou un petit plateau, joué avec des dés à 6 ou 10 faces.
 

Code :
  1. Interface PlateauFactory
  2. {
  3.   Plateau createPlateau();
  4. }
  5. Class PetitPlateauFactory implements PlateauFactory
  6. Class GrandPlateauFactory implements PlateauFactory
  8. Interface DesFactory
  9. {
  10.   Des createDes();
  11. }
  12. Class Des6Factory implements DesFactory
  13. Class Des10Factory implements DesFactory


 
Puis tu auras un classe Options qui contient une instance de chaque interface.
 

Code :
  1. class Options
  2. {
  3.   private DesFactory desFactory;
  4.   private PlateauFactory plateauFactory;
  5.   public Game createGame
  6.   {
  7.     Game = new Game(desFactory.createDes(), plateauFactory.createPlateau();
  8.   }
  9. }


 
La définition d'une configuration de jeu se fait donc en choisissant une factory pour chaque élément. C'est pas trop dur de recenser les différentes factories et de proposer à l'utilisateur d'en choisir une dans des listes par exemple

Reply

Marsh Posté le 01-02-2003 à 16:58:19    

Bon, l'autre façon, c'est avec les evenements. Mais un évènement permettrait de changer les règles en cours de jeu, ce qui n'est pas forcément ce que tu veux faire, et qui risque de poser des problèmes variés (ex: le plateau devient subitement plus grand, où est-ce qu'on replace les objets?).
 
Les évènements sont basés sur le design patter observer.
(premier résultat google sur 'design patter observer' : http://sern.ucalgary.ca/courses/SE [...] erLib.html )
 
La configuration serait un 'subject' et tes différents éléments les 'observers'.  
Quand les éléments sont crées (avec une factory par exemple), on leur attache la configuration comme observeur  
 

Code :
  1. configuration.attach(plateau)
  2. configuration.attach(des)


 
Quand la configuration est changée, on appelle config.notify(), et comme chaque élémet du jeu est observeur de la config, chaque élément recevra un appel à update().
Rien ne t'empêche de faire passer des informations comme paramètre de notify() à update(), comme c'est le cas avec les composant des gui (il y a toujours un objet event en paramètre je crois)
 
Par contre, utilisés sous cette forme, les évènements c'est pas très pratique, car c'est toujours la même fonction qui est appelée pour les éléments du jeu quand quelque chose change.
Une possibilité est de définir plusieurs stratégies (y'a aussi un design patter strategie, mais il n'est pas vraiment utilisé comme ça) de réponse aux messages pour les observers (éléments du jeu).
Une implémentation possible est de donner une hashmap de handlers à chaque observer. Un handler est une classe qui a la fonction handle(). Le handler est choisi en fonction du paramètre de notify/update.
Donc en gros :  
 

Code :
  1. config.notify(new ChangementDeDes() )
  3. --> provoque l'appel de
  5. plateau.update(descriptionChangement)  // c'est l'objet event
  7. qui fait
  9. handler = (HandlerStrategy) handlerStrategie.get(changementDes)
  10. if (handler!=null) handler.handle()


 
Bon, c'est ptet pas très clair car c'est présenté un peu rapidement, mais les idées sont dans les desciptions des design patterns
 
Bonne chance :)

Reply

Marsh Posté le 01-02-2003 à 21:05:26    

je lis les "designs patterns" thanks !
 
 
 
mais je m'appercois que j'ai mal formulé le message
je pensais à inclure une instance de configuration au départ (une fois choisie) dans les classes qui en auront besoin, et les évènement pour la communications entre tous les autres modules...
 
et je ne suis pas encore sûr de quoi j'ai besoin, je dois encore réfléchir plus à quels type de changements de règles je veux :)

Reply

Marsh Posté le 02-02-2003 à 04:47:13    

Juste pour relever un truc qui m'a 'choqué', histoire de faire une petite polémique:D ... :
 

_gtm_ a écrit :


Quand les éléments sont crées (avec une factory par exemple), on leur attache la configuration comme observeur  
 

Code :
  1. configuration.attach(plateau)
  2. configuration.attach(des)




 
D'après ta phrase, le code devrait etre

Code :
  1. plateau.attach(configuration)
  2. des.attach(configuration)


 
 :sol:  
 
 
 :hello:


---------------
#19b | Mardi 18 Février 2003 - nous fêtons les Bernadette | contre le fleur icq!
Reply

Marsh Posté le 02-02-2003 à 18:42:10    

ben non...
 
Dans le pattern, on fait  
 

Code :
  1. subject.attach(observer)


 
On veut que les éléments de jeu soient informés quand la config change, donc ce sont les éléments les observers et la config le subject
 
donc bien  
 

Code :
  1. config.attach(plateau)

Reply

Marsh Posté le 02-02-2003 à 19:50:12    

_gtm_ a écrit :

ben non...
 
Dans le pattern, on fait  
 

Code :
  1. subject.attach(observer)


 
On veut que les éléments de jeu soient informés quand la config change, donc ce sont les éléments les observers et la config le subject
 
donc bien  
 

Code :
  1. config.attach(plateau)



je me fous de ce qu'on fait dans le pattern, je te dise juste que ta phrase en français correspond pas au code que tu lui associais :o


---------------
#19b | Mardi 18 Février 2003 - nous fêtons les Bernadette | contre le fleur icq!
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed