Discussion :

[black.out]

Hello,

Je m'interresse depuis un moment à la prog de jeux vidéo mais je n'ai pas réussi a trouver les infos dont j'avais besoin.
Ce que je cherche est en particulier un organigramme, UML ou autre, sur l'organisation d'un moteur de jeux. J'ai un bon niveau en C++ et je me debrouille en OpenGL, je viens de remarquer un nouvel article sur la réalisation d'un moteur de jeux, mais en fait ce n'est qu'un tuto sur comment faire un morpion en SDL.

Alors peut-etre pourriez vous repondre a mes question ?

1- une classe pour charger les textures et les stocker dans des maps ... OK (sous forme de singleton).
2- une classe de gestion de fichier (toujours en singleton).
3- une classe d'Input souris, clavier (encore singleton).
...

vous remarquer que toutes ces classe que je considere comme des gestionnaires sont sous forme des singleton et chargées à l'initialisation du moteur.

mais c'est la qu'est mon probleme, a part ces quelques classes, je ne sait pas quoi faire pour continuer mon moteur et en particulier sur l'affichage.
Faut-il un Nieme classe singleton Affichage avec diverse fonction d'affichage (vector, map, gluint, list, gluint[], ...) ? ou implementer l'affichage dans la classe qui contient l'objet ?
par exemple la classe map contiendrais ca propre fonction affichage ?
de meme la classe sprite contiens sa propre fonction d'affichage ou bien on considere un sprite (Perso, Unite, Decor, ...) comme un GLuint que l'on passerai en parametre a une fonction de la classe Affichage ?

Cela fait longtemps que je tourne en rond sur ce genre de probleme a tel point que je n'avance plus et arrive plus a me pencher sur le probleme et ai penser arreter la ce moteur car ca m'enerve.
Je profite donc de la sortie du tuto sur les moteur 2D pour tenter une derniere fois ma chance et demander si vous aviez quelques choses a me conseiller ou a m'expliquer car je dois pas cerner le probleme dans le bon sens.

Merci

[fearyourself]

je viens de remarquer un nouvel article sur la réalisation d'un moteur de jeux, mais en fait ce n'est qu'un tuto sur comment faire un morpion en SDL.

Ben c'est qu'un morpion pour le moment, mais je vais le compliquer rapidement, faut pas dire "ce n'est qu'un morpion"... Faut déjà arriver à le faire ce petit jeu!

Alors peut-etre pourriez vous repondre a mes question ?

1- une classe pour charger les textures et les stocker dans des maps ... OK (sous forme de singleton).

D'accord pour cette classe, je le fais aussi (pas forcément stocker dans des maps, t'entends quoi par maps?)

2- une classe de gestion de fichier (toujours en singleton).

Je ne vois pas l'intêret mais pourquoi pas... Y aurait quoi dans les fichiers? Normalement, tu as un gestionnaire de ressource qui s'occupe de tout. Il peut être divisé en plusieurs module mais le principe reste le même. Aucune autre classe ne devrait toucher aux données dans les fichiers (cela permet de ne pas modifier les autres classes si on change le format des fichiers).

3- une classe d'Input souris, clavier (encore singleton).

Je ne suis pas sûr d'être d'accord mais cela dépend ce que tu voudrais en faire. Si c'est pour gérer l'entrée clavier et la souris pour le passer au moteur du jeu qui lui redistribuera l'information, alors pourquoi pas.

Si tu penses que cette classe devrait gérer "est-ce que la touche "f" a été appuyée? oui, alors il faut passer le véhicule séléctionné en mode furtif", alors non. Cette classe ne devrait pas avoir autant de pouvoir/connsaissance sur ce qui se passe en-dessous.

vous remarquer que toutes ces classe que je considere comme des gestionnaires sont sous forme des singleton et chargées à l'initialisation du moteur.

Pourquoi pas. Je ne suis pas fan du mode singleton mais je comprends pourquoi on le fait.

mais c'est la qu'est mon probleme, a part ces quelques classes, je ne sait pas quoi faire pour continuer mon moteur et en particulier sur l'affichage.

Ton moteur doit être le noyau du jeu, il est en gros le chef d'orchestre et tous les autres modules font partie de l'orchestre... Quel genre de jeu tentes-tu de faire? Il faudrait commencer par là.

Vu de très loin, il te faudra une classe pour:
- Le son
- Les données du jeu et son affichage
- Le menu...

Faut-il un Nieme classe singleton Affichage avec diverse fonction d'affichage (vector, map, gluint, list, gluint[], ...) ? ou implementer l'affichage dans la classe qui contient l'objet ?

En fait le genre de jeu joue beaucoup sur comment va se programmer et se diviser le code. Lorsque tu fais un jeu, tu vas avoir des fenêtres qui vont s'ouvrir, tu vas pouvoir les bouger et ainsi de suite. Chaque composant doit savoir se dessiner, si on clique dessus, gérer l'entrée clavier...

Si tu fais juste un morpion , c'est beaucoup plus simple (et encore, je vais compliquer le jeu côté graphique pour donner un look beaucoup plus sympa. Si j'ai le temps et si ça intéresse je donnerais un screenshot de l'état actuel du jeu...

par exemple la classe map contiendrais ca propre fonction affichage ?
de meme la classe sprite contiens sa propre fonction d'affichage ou bien on considere un sprite (Perso, Unite, Decor, ...) comme un GLuint que l'on passerai en parametre a une fonction de la classe Affichage ?

Il est généralement bon d'avoir une classe Perso qui posséde toute l'information sur comment se dessiner, mais de nouveau, cela dépend...

Cela fait longtemps que je tourne en rond sur ce genre de probleme a tel point que je n'avance plus et arrive plus a me pencher sur le probleme et ai penser arreter la ce moteur car ca m'enerve.

Une grosse erreur est de viser trop haut. Commence par un petit jeu et complique la donne. Ensuite, il faut voir les étapes de l'implémentation et ne pas se tromper dans les débuts. Une erreur de conception peut faire capoter un projet.

Je profite donc de la sortie du tuto sur les moteur 2D pour tenter une derniere fois ma chance et demander si vous aviez quelques choses a me conseiller ou a m'expliquer car je dois pas cerner le probleme dans le bon sens.

Il faudra patienter un peu pour la sortie des tutoriels, mais le 2ème devra être prêt bientôt...

Il y a aussi ces tutoriels http://loulou.developpez.com/tutoriels/moteur3d/intro/ qui pourront peut-être t'intéresser dépendant ce que tu veux faire comme projet...

Jc

PS: merci pour la pub

[Matthieu Brucher]

Je sens qu'il va falloir que j'accélère mes lectures pour répondre aux questions et proposer des livres

[black.out]

salut fearyourself, je ne voulais pas critiquer ton tuto, c'est toujours une bonne initiative :-) et en effet c'est toujours pas tres simple de faire de "petit" jeu.

par map, pour le stockage, je parlais du container de la STL.

le type de jeux visé serais RPG ou STR, mais surtout des petits trucs marrants comme des bubble bobble ou des des jeux de logiques.

J'ai peut-etre comme tu le dis, visé trop haut pour commencer, mais je voulais quelques choses de réutilisable.

Pour la classe Input, elle ne fait que récupérer les entrées et les transmettre au jeux afin de les traiter suivant le contexte.

J'ai fait toutes ces classes suivant une idée de réutilisation, avoir un ensemble de classe, avec une facade CMoteur2D qui permet d'initialiser tout ce qui faut et de dialoguer avec les gestionnaires et classes utilitaires facilements.

Merci pour le coup de main

[fearyourself]

salut fearyourself, je ne voulais pas critiquer ton tuto, c'est toujours une bonne initiative :-) et en effet c'est toujours pas tres simple de faire de "petit" jeu.

Je l'ai pas mal pris, il faut commencer quelque part et je fais pareil avec les tutoriels...

J'ai peut-etre comme tu le dis, visé trop haut pour commencer, mais je voulais quelques choses de réutilisable.

Il vaut toujours mieux viser plus haut mais être prêt à voir tout se casser la gueule.... C'est comme cela qu'on apprend...

Pour la classe Input, elle ne fait que récupérer les entrées et les transmettre au jeux afin de les traiter suivant le contexte.

J'ai fait toutes ces classes suivant une idée de réutilisation, avoir un ensemble de classe, avec une facade CMoteur2D qui permet d'initialiser tout ce qui faut et de dialoguer avec les gestionnaires et classes utilitaires facilements.

Ok, ça a l'air bien parti! Bonne chance!
Jc