Discussion :

[alex6891]

Bonjour,

Je travaille en j2me (java) pour téléphones mobiles et je souhaite implémenter une structure pour créer des jeux-vidéo. J'ai pensé qu'un jeu pouvait se résumer en une succession logique de scènes. Une scène pouvant être un écran de titre, de crédits, de choix d'options, un niveau jouable, etc. J'ai tenté de représenter par un automate cette succession d'écrans mais je ne sais pas du tout comment l'implémenter malgré mes recherches sur le web.
Merci pour votre aide !

Alex

[Laurent Gomila]

Ca ressemble au design pattern "state pattern", qui est justement très utilisé pour gérer les différents états dans un jeu vidéo.

http://gamedevgeek.com/tutorials/man...e-states-in-c/
http://www.codeproject.com/cpp/statepattern3.asp

[alex6891]

Merci laurent je comprends beaucoup mieux maintenant !

Néanmoins j'ai une question (en rapport avec le tuto du second lien que tu m'as donné) : est-ce que toutes les classes états qui héritent du gestionnaire d'états doivent être singleton ? Si oui, pour quelles raisons ?

De plus, je ne comprends pas très bien la nécessité (toujours en rapport avec le diagramme de classe du même tuto) d'avoir autant de classes "en-dessous" du GameManager...

Enfin, j'aimerais implémenter cette solution pour les téléphones mobiles en j2me, donc je me demande quelle classe du schéma UML peut bien hériter de la classe MIDlet (GameView? MainFrame?) ?

PS: dans l'esprit, je souhaite créer une sorte de framework pour que le programmeur n'ait qu'à modifier une seule classe : la classe principale de ma structure (GameApp?) ?

Merci de m'éclairer sur ces points obscurs

[Laurent Gomila]

Néanmoins j'ai une question (en rapport avec le tuto du second lien que tu m'as donné) : est-ce que toutes les classes états qui héritent du gestionnaire d'états doivent être singleton ? Si oui, pour quelles raisons ?

Je ne pense pas que ce soit une nécessité. Si tu en vois l'utilité alors fais-le, si au contraire ça ne doit pas être le cas dans ton architecture de classes alors très bien, ne le fais pas. Ca n'empêchera pas le pattern de fonctionner

De plus, je ne comprends pas très bien la nécessité (toujours en rapport avec le diagramme de classe du même tuto) d'avoir autant de classes "en-dessous" du GameManager...

Je pense que cela a peu d'importance, ce n'est pas lié au design pattern. L'important est que tu aies quelque part une classe qui gère les game states.

Enfin, j'aimerais implémenter cette solution pour les téléphones mobiles en j2me, donc je me demande quelle classe du schéma UML peut bien hériter de la classe MIDlet (GameView? MainFrame?) ?

Je n'y connais rien en J2ME, mais si décris un peu cette classe je pourrais peut-être t'aider.

PS: dans l'esprit, je souhaite créer une sorte de framework pour que le programmeur n'ait qu'à modifier une seule classe : la classe principale de ma structure (GameApp?) ?

Il y a une question dans cette phrase ?

[alex6891]

Pour la dernière phrase, ma question est de savoir si l'exemple du second lien prends la classe GameApp comme "main" ?

Sinon la classe MIDlet pour J2ME c'est comme la classe Applet pour J2SE à savoir une classe avec les trois méthodes startApp() (lancement de l'application), pauseApp() (sa mise en pause) et destroyApp() (la libération de la mémoire allouée.)

Pour que mon application marche sur portable, je souhaite qu'une des classes de la structure hérite de cette classe MIDlet et donc implémente ces trois méthodes mais je ne sais pas laquelle...

Merci

[alex6891]

L'auteur de l'article parle aussi de la méthode doFrame()... En rapport avec ça, je n'arrive pas vraiment à m'imaginer comment la classe GameView est construite (frame rate...) ?

Encore merci (j'ai pas mal de questions décidément !)

Alex

[Laurent Gomila]

Pour la dernière phrase, ma question est de savoir si l'exemple du second lien prends la classe GameApp comme "main" ?

Il semblerait que oui.

Sinon la classe MIDlet pour J2ME c'est comme la classe Applet pour J2SE à savoir une classe avec les trois méthodes startApp() (lancement de l'application), pauseApp() (sa mise en pause) et destroyApp() (la libération de la mémoire allouée.)

Pour que mon application marche sur portable, je souhaite qu'une des classes de la structure hérite de cette classe MIDlet et donc implémente ces trois méthodes mais je ne sais pas laquelle...

Et bien pourquoi pas GameApp ?

L'auteur de l'article parle aussi de la méthode doFrame()... En rapport avec ça, je n'arrive pas vraiment à m'imaginer comment la classe GameView est construite (frame rate...) ?

doFrame affiche simplement la frame suivante. Qu'est-ce que tu ne comprends pas exactement ?

[alex6891]

Et bien pourquoi pas GameApp ?

J'y ai pensé mais j'aimerais que le programmeur qui utilise mon architecture n'ait pas besoin de faire un "extends MIDlet" avec son main...

Pour doFrame() ce que je ne comprends pas c'est où et comment elle doit être appellée... (comment gérer un frame rate en somme)

[Laurent Gomila]

J'y ai pensé mais j'aimerais que le programmeur qui utilise mon architecture n'ait pas besoin de faire un "extends MIDlet" avec son main...

Là je ne comprends pas trop ce que tu veux dire.

Pour doFrame() ce que je ne comprends pas c'est où et comment elle doit être appellée... (comment gérer un frame rate en somme)

En (très) gros, une boucle de jeu temps réel ressemble toujours à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// On tourne en boucle tant qu'on ne quitte pas
while (!quit)
{
    doFrame();
}
 
void doFrame()
{
    // Gérer les évènements
 
    // Mettre à jour la scène
 
    // Afficher la scène
 
    // ... (IA, physique, ...)
}

[alex6891]

Quand tu dis que doFrame() doit gérer les évènements, je ne suis pas d'accord, selon le tuto, c'est GameView qui capte les évènements... non ?

[Laurent Gomila]

Oui, après ça dépend des langages / bibliothèques / framework que l'on utilise. Parfois la gestion des évènements est asynchrone et on peut gérer ça ailleurs, parfois aussi on doit faire du polling et donc l'intégrer à la boucle de rendu.

Bref ça n'a pas d'importance ici

[alex6891]

asynchrone ? polling ? ...
Excuses mon ignorance

[Laurent Gomila]

Asynchrone : tu reçois des messages lorsqu'un évènement se produit, généralement dans une fonction de callback, et donc potentiellement à n'importe quel moment dans ta boucle de jeu. Mais ce n'est pas vraiment asynchrone, puisque la génération des messages va généralement être lancée par un appel du genre TraiteLesEvenements().

Polling : à chaque tour de boucle on scrute les évènements, et on récupère ce qu'il y a à récupérer. Donc là on choisit vraiment le moment où on va les gérer.

[alex6891]

OK je comprends mieux maintenant merci

[alex6891]

J'ai une autre question : comment faire pour qu'à partir du Main l'utilisateur puisse définir la logique du jeu implémentée avec le state pattern ?
Par exemple, j'ai trois états A, B et C possibles. J'aimerais faire en sorte qu'avant de lancer la boucle principale du jeu, l'utilisateur puisse définir l'ordre de succession des états pour son jeu : dire par exemple que l'état initial sera un état de type A, puis le suivant de type B avant de revenir vers un autre type A pour finir sur un type C... Pareil en ce qui concerne les transistions entre les états, je voudrais que tout puisse être défini à partir du Main.
Existe t-il une solution (en java : j2me) ?

Merci d'avance,

Alex

[Laurent Gomila]

Tu peux modéliser ça sous forme de graphe de transition d'états. Ce n'est qu'une idée, personnellement je n'ai jamais eu à utiliser ce genre de pattern.

[alex6891]

Euh, Je ne comprends pas Laurent

[Laurent Gomila]

Et bien ce que tu décris est très exactement un graphe de transition d'état. C'est-à-dire que les noeuds sont des états, et les arêtes des conditions pour passer d'un état à un autre.

Sachant cela, il doit bien y avoir quelque chose en Java pour implémenter cette solution à moindre frais. Au pire ça ne doit pas être bien compliqué à coder.