Discussion :

[Mindiell]

Salut à tous,

J'ai lu le tutorial pong de fearyourself, et j'ai quelques questions :
Pourquoi as-tu partagé ton moteur en jeu et en menu ?
Le menu ne fait-il pas partie du jeu ?
Ne devrait-il pas être situé dans celui-ci ?

PS: je suis pas sur de poster au bon endroit, mais bon

[fearyourself]

Bien le bonjour, je vais répondre aux questions :

Pourquoi as-tu partagé ton moteur en jeu et en menu ?

Parce que les deux éléments sont différents. J'explique, à mon humble avis, les différentes solutions possibles ici :
http://fearyourself.developpez.com/t...pion/part5/#L3

Pour résumer, on a forcément deux classes, une Menu et une autre Jeu. La question est comment les faire intéragir. Passer par un 3ème classe Moteur qui est en fait la classe maître du programme me semble la meilleure solution.

Si on veut changer quelque chose du jeu à partir du menu, on passe par le moteur.

Fusionner les deux ne fait que compliquer le code et si on prend la solution de mettre le menu au-dessus du jeu alors le moteur n'a plus un lien direct avec le jeu, ce qui posera problème pour la gestion de la souris et du clavier.

Le menu ne fait-il pas partie du jeu ?

Dans un sens général oui mais lorsqu'on est dans le jeu non. Du moins, mes menus ne le sont pas. On pourrait imaginer un menu qui s'ouvre en avant-plan du jeu et le jeu est assombri mais figé.

Si le menu peut-être ouvert et le jeu peut continuer, même à ce moment là, le menu n'est pas dans le jeu puisqu'il n'a pas de lien direct avec le jeu. Si on change la résolution, on demande au moteur de tester si la résolution est possible avec le module graphique.

Si on change l'IA, on demande au moteur de voir si c'est possible avec le module réseau, etc.

Le Menu ne discute qu'avec la classe Moteur et n'a pas accès aux autres modules, cela permet de garder son code relativement générique...

Ne devrait-il pas être situé dans celui-ci ?

Pas toujours, je ne vois pas l'avantage de le mettre sous la classe Jeu ou de le mettre au-dessus de la classe Jeu.

Le menu n'a en principe aucun lien direct avec le Jeu. Il a un rapport direct avec le moteur du programme qui donnera les changements du menu au jeu sous-jacent.

Cela me semble plus propre et plus facile à gérer.

En espérant avoir été clair, c'est probablement une question de goût et d'habitude, c'est celle qui fonctionne le mieux pour moi
Jc

[shenron666]

de mon point de vue, c'est plutot le menu qui controle le jeu
donc dans l'absolu, on peux mettre le jeu dans le menu, pas l'inverse

mais comme Fear, je préfère avoir le menu "à côté", séparément du jeu
cela donne plus de liberté, enfin tout est une question de conception

[Mindiell]

Et dans un jeu comme Dungeon Master par exemple, où l'affichage du menu se fait dans le jeu, mais en pausant celui-ci, contrairement aux inventaires des persos ?
Le menu ne serait-il pas qu'un affichage différent dans le moteur lui-même ?

[fearyourself]

Et dans un jeu comme Dungeon Master par exemple, où l'affichage du menu se fait dans le jeu, mais en pausant celui-ci, contrairement aux inventaires des persos ?
Le menu ne serait-il pas qu'un affichage différent dans le moteur lui-même ?

Non, cela ne change rien...

Figure toi que j'y ai pensé. Je garderais les deux séparés car il ne font pas la même chose. La seule chose que cela change est ceci :

La gestion de la scène se fait en partant de gereScene. Dans mon pong, on dessine soit le jeu soit le menu. Donc le code ressemble à 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
17
18
19
20
21
22
23
24
25
 
void Moteur::gereScene()
{
    // Effacer le tampon des couleurs
    glClear(GL_COLOR_BUFFER_BIT);
    glLoadIdentity();
 
    if(!dans_menu)
        dessineJeu();
    else
        dessineMenu();
 
    SDL_GL_SwapBuffers();
}
 
void Moteur::dessineMenu()
{   
    menu->affiche();
}
 
void Moteur::dessineJeu()
{   
    jeu->affiche();
    jeu->gereSceneServeur();
}

Dans un jeu comme Dungeon Master, cela deviendrait comme 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
17
18
19
20
21
22
23
24
25
26
27
28
29
 
void Moteur::gereScene()
{
    // Effacer le tampon des couleurs
    glClear(GL_COLOR_BUFFER_BIT);
    glLoadIdentity();
 
    if(!dans_menu) {
       jeu->gereSceneServeur();
    } 
 
    dessineJeu();
 
    if(dans_menu) {
        dessineMenu();
    }
 
    SDL_GL_SwapBuffers();
}
 
void Moteur::dessineMenu()
{   
    menu->affiche();
}
 
void Moteur::dessineJeu()
{   
    jeu->affiche();
}

La seule différence étant qu'on dessinera toujours le jeu et le menu se retrouvera en premier plan vu qu'il est appelé ensuite (en supposant que le code de rendu soit correct bien sûr). Vu que j'ai séparé convenablement affichage et mise à jour du jeu, le fait de faire ceci :

Code :

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

1
2
3
4
 
    if(!dans_menu) {
       jeu->gereSceneServeur();
    }

mettra le jeu en pause lorsqu'on est dans le menu.


Dernière remarque, dans un jeu comme NeverWinter Nights 2, le menu ne met même pas le jeu en pause, c'est une fenêtre comme une autre. Même dans ce cas, je séparerais les deux. Par contre, le code qui gère la fenêtre et sa gestion externe serait confondue avec le code des autres fenêtres du jeu. Mais le code de la fenêtre du menu serait dans une classe Menu et se retrouverait au même endroit (cf à côté du jeu et en-dessous du Moteur).

Jc

[Mindiell]

Ok, donc la séparation des deux, tu la fais, mais ca n'a pas d'autre but que de ressembler à l'idée que tu t'en fais. Donc ça ne semblerait pas idiot de la mettre dedans...

Je commence tout juste à utiliser bouml, et je réfléchis à une conception objet un peu propre pour la suite de mon Tetris...

[shenron666]

chacun a sa logique qui influe sur sa façon de programmer
moi je dis que du moment que ça marche, que tu t'y retrouve et que tu en est satisfait, c'est bon