Discussion :

[black.out]

Salut a tous,

Je vous avais déjà demandé des conseils et je reviens après avoir un peu cogité sur le sujet.
Je désire réaliser un moteur de jeu, mais pas pour un jeu en spécifique, d’où mon problème d’une architecture assez souple.

Après conseil de Ash.Ice.Loky j’en suis arrivé à la conclusion suivante :

Une classe Moteur (FAIT – en cour) :
C’est en faite un pattern Façade permettant d’accéder a toutes les fonctions du moteur (son, affichage, I/O, …).

Ressources (FAIT)
Une succession de classes suivant le pattern Factory pour la gestion des ressources automatiques (textures et sons).

ENTRE_SORTIE (FAIT – en cour)
Singleton redirigeant les entrées vers (touche, souris, …) vers des fonctions spécialisé pour simplifier le développement.

MAP - SPRITE – AFFICHAGE
La j’ai un problème.
Je ne sais pas du tout comment faire pour gérer tout ce petit monde.
J’avais pensé à l’architecture suivante :

Infos : <- signifie que cette classe est contenu par la première.

DECOR (gestion du décor, le fond) <- Couche[] ; Camera
COUCHE (une couche ou layer, permet la superposition) <- Tile[][]
TILE (une portion de l’écran, associé à un tile d’un tile set) <- Affichage
CAMERA (gère le focus sur une partie du décor)
AFFICHAGE (fonction pour afficher une portion de textures)

SPRITE (texture simple, fixe ou animé, de taille différentes) <- AFFICHAGE
AFFICHAGE (fonction pour afficher une texture simple).

Ash (que je remercie ;-)) m’a conseillé de faire de en sorte qu’une classe soit minimale, mais réutilisable (par exemple Affichage) afin de permettre de faire autant des RPG que des Pong.
D’éviter l’héritage au profit de la composition. Donc de ne pas faire une fonction dans Affichage qui soit de cette facon :
Afficher (MAP) ou Afficher (Couche), mais Afficher (posX, posY, GLuint), appelé dans une fonction membre de Tile qui ressemblerais a ca Afficher () {Afficher (posX,posY,Texture)}
Puis une fonction Afficher dans Couche qui appelle Afficher pour chaque Tile, puis une fonction Afficher dans Map qui appel Afficher pour chaque Couche.

Je voudrais donc avoir plusieurs avis sur ce type de conception, je ne m’y connais pas donc j’aimerai progresser et plusieurs avis sont toujours bons à prendre.

Un dernier point qui me chagrine c’est le nombre d’appel à « glBindTexture » avec cette technique, mais je n’ai pas trouvé comment résoudre ce problème.
Peut être en mettant l’afficheur dans MAP ou COUCHE et non dans TILE ?

[Matthieu Brucher]

Fait une façade peut-être pour ton code d'affichage pour pouvoir changer le moteur facilement, au besoin.
Peut-être aussi que la factory des ressources devrait être associée à un singleton qui gère ces ressources ?

[black.out]

Oui Miles, je ne l'ai pas spécifié mais la factory est aussi un singleton.

Que veut tu dire une facade pour le moteur d'affichage ?

EN fait je bloque sur l'organisation de ce dernier, les classes SPRITE, AFFICHAGE, TILE, MAP, COUCHE, CAMERA, ne me semblent pas très bien organisés :-/

[Matthieu Brucher]

Une façade, c'est une interface simplifiée pour accéder à des éléments plus complexes qui seraient tes moteurs audio, vidéos, ... Ca te permettrait de développer ton coeur de jeu indépendemment du monde extérieur.

[ash.ice.loky]

Ton moteur d'affichage pourrait-être améliorer en le structurant par étapes :

étape 1 - initialisation d'un frame
* InitFrame () - mise a jour des couleurs, chargement des divers paramètre propre a la frame.

Étape 2 - dessin de la frame
* LoadTexture (gluint) - charge une texture pour les dessins suivant
* AffTile (coordX, coordY, numTile) - affiche le tile sélectionner l'endroit voulu.
* ...

étape 3 - fin de la frame
* EndFrame () - ferme le pointeur sur la texture et termine la frame.


Je pense qu'une telle structure te donnera plus de souplesse.

[mat.M]

Salut a tous,

Une classe Moteur (FAIT – en cour) :
C’est en faite un pattern Façade permettant d’accéder a toutes les fonctions du moteur (son, affichage, I/O, …).

Je n'en vois vraiment pas l'utilite; un moteur de jeu par essence c'est une structure qui regroupe toutes les fonctionnalites d'un jeu: affichage , son , IA etc...
Faire le plus simple possible parce que sinon on s'embrouille tres vite et garder en vue l'essentiel

EN fait je bloque sur l'organisation de ce dernier, les classes SPRITE, AFFICHAGE, TILE, MAP, COUCHE, CAMERA, ne me semblent pas très bien organisés :-/

cela ne sert a rien de perdre son temps au debut a l'organisation parce que ton moteur de jeu va evoluer constamment.
Faut se fixer un but precis s'y atteler et lorsque cela donnera une forme satisfaisante alors tu organiseras et structureras ton moteur.
Sinon tu risques de te tourner en rond et perdre du temps.
Et quand on tourne en rond dans un projet cela finit bien souvent a la poubelle.
Se fixer un but tres precis : je veux developper un moteur de jeu comme Quake par exemple.
Une fois le moteur developpe je me construis un editeur qui permet de changer de maps ,eclairages,sons modeles 3d etc...

[Captain_JS]

A l'inverse de mat.M je ne dirais pas que l'organisation des classes doit etre gardée pour la fin (je le dis parce que j'ai déjà testé ).

C'est sur que ton moteur va évoluer, et que si tu te focalise sur tes classes ça n'avancera pas.

Par contre il est bien d'avoir quelques UMLs sous la main histoire de savoir comment ça s'organise, et quand tu fais évoluer ta structure et/ou tes UMLs, tu reportes les changements suivant ce qui te semble le mieux adapté.

Si maintenant tu parles de ce qu'il y a dans tes classes ... ça je pense que c'est à toi de voir par rapport à ce que tu fais de ces classes

[ash.ice.loky]

Je pense aussi qu'il est important de bien penser ton projet avant d'aller trop loin.

Le but n'est pas de couvrir tous les problèmes ou de tout penser, mais de faire en sorte que TES buts soient atteints avec le maximum de souplesse afin de permettre une certaine liberté d'évolution par la suite.

Pour le pattern Façade, ce n'est pas une obligation mais je l'aime bien, il permet de réutiliser des fonctions oublié sans se replonger trop dans la procédure en automatisant un peu tout ca, il permet aussi de facilité les interfaces en les regroupant.

Ta façon de voir les choses mat.M me pose un problème, tu as une structure de Carte, un moteur d'affichage non générique adapté a ta structure, avec les fonctions associés, et la tu fais un éditeur.
TU te rends compte que tu veux faire un mario-Like avec ton moteur et qu'il te faut 5 couches de Tiles avec des tilesSet de 512*512 mais ton moteur est trop statique pour le permettre.
Hop tu changes tout et la c'est le bazar, ton éditeur est out, ton moteur d'affichage intégré a ta structure de Carte est a refaire, tes ancienne créations ne sont plus compatible, obligation de tout refaire sur tes anciens projets ou alors 2 versions de moteurs pour tes différents projets (intérêt de la façade ;-) )



Mais bon chacun à ses habitudes et les miennes ne sont pas meilleurs, loin de là, mais j'ai vu le code de black.out avant et après et y a pas photo.
Continu et bonne chance.



bref penser et agir, telle est ma devise :-))

[mat.M]

Ta façon de voir les choses mat.M me pose un problème, tu as une structure de Carte, un moteur d'affichage non générique adapté a ta structure, avec les fonctions associés, et la tu fais un éditeur.
TU te rends compte que tu veux faire un mario-Like avec ton moteur et qu'il te faut 5 couches de Tiles avec des tilesSet de 512*512 mais ton moteur est trop statique pour le permettre.

Oui je me suis totalement trompé car j'ai lu un peu trop vite , mea culpa;
ce que veux faire black.out en l'ocurence un moteur générique c'est un travail de longue haleine.
Il peut s'inspirer de Blender par exemple qui se veut un peu générique

[ash.ice.loky]

Oui la je suis d'accord avec toi, faire un moteur de jeu générique est très dur et très long :-) et je suis encore plus d'accord sur le faite que de passer trop de temps sur les détails tue la progression et la motivation.