IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement 2D, 3D et Jeux Discussion :

Structure d'un moteur de jeu


Sujet :

Développement 2D, 3D et Jeux

  1. #1
    Membre du Club
    Profil pro
    Inscrit en
    février 2006
    Messages
    57
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 57
    Points : 41
    Points
    41
    Par défaut Structure d'un moteur de jeu
    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 ?

  2. #2
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : juillet 2005
    Messages : 9 810
    Points : 20 967
    Points
    20 967
    Par défaut
    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 ?

  3. #3
    Membre du Club
    Profil pro
    Inscrit en
    février 2006
    Messages
    57
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 57
    Points : 41
    Points
    41
    Par défaut
    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 :-/

  4. #4
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : juillet 2005
    Messages : 9 810
    Points : 20 967
    Points
    20 967
    Par défaut
    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.

  5. #5
    Membre éprouvé
    Homme Profil pro
    Inscrit en
    février 2006
    Messages
    943
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : février 2006
    Messages : 943
    Points : 1 147
    Points
    1 147
    Par défaut
    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.

  6. #6
    mat.M
    Invité(e)
    Par défaut
    Citation Envoyé par black.out
    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


    Citation Envoyé par black.out
    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...

  7. #7
    Membre confirmé
    Homme Profil pro
    Consultant MOA
    Inscrit en
    juillet 2004
    Messages
    289
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant MOA
    Secteur : Conseil

    Informations forums :
    Inscription : juillet 2004
    Messages : 289
    Points : 634
    Points
    634
    Par défaut
    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

  8. #8
    Membre éprouvé
    Homme Profil pro
    Inscrit en
    février 2006
    Messages
    943
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : février 2006
    Messages : 943
    Points : 1 147
    Points
    1 147
    Par défaut
    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 :-))

  9. #9
    mat.M
    Invité(e)
    Par défaut
    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

  10. #10
    Membre éprouvé
    Homme Profil pro
    Inscrit en
    février 2006
    Messages
    943
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : février 2006
    Messages : 943
    Points : 1 147
    Points
    1 147
    Par défaut
    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.

Discussions similaires

  1. Réponses: 4
    Dernier message: 07/07/2006, 16h09
  2. [recherche documentation] Moteur de jeu ou de démo interactive temps réel
    Par shenron666 dans le forum Développement 2D, 3D et Jeux
    Réponses: 10
    Dernier message: 20/06/2006, 17h56
  3. Conception d'un moteur de jeu
    Par black.out dans le forum Développement 2D, 3D et Jeux
    Réponses: 4
    Dernier message: 27/03/2006, 16h41
  4. [AS2] Moteur de jeu et réutilisation
    Par ooyeah dans le forum ActionScript 1 & ActionScript 2
    Réponses: 6
    Dernier message: 06/07/2005, 12h25
  5. Moteur de jeu 2D
    Par washall dans le forum Autres éditeurs
    Réponses: 3
    Dernier message: 15/05/2005, 23h19

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo