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

Architecture d'un jeu vidéo 3D


précédentsommairesuivant

I. Introduction

Je vais présenter un modèle d'architecture pour la réalisation d'un jeu vidéo en 3D. Ce modèle devra pouvoir s'adapter simplement aussi bien à la réalisation d'un jeu à la première personne (FPS), d'un jeu de stratégie (RTS) ou même à d'autres types de jeux. L'architecture présentée pourra également gérer les jeux en mode multijoueur en réseau local ou sur Internet. De même, l'architecture pourra être simplement étendue pour la réalisation de jeux massivement multijoueurs : MMOFPS, MMORTS, MMORPG�?�

Cette architecture sera entièrement codée avec des bibliothèques multiplateformes.

L'objectif n'étant pas de fournir un jeu commercialisable, mais un modèle d'architecture sur lequel se baser pour réaliser un jeu.

I-A. Schéma général

Même sans savoir quel type de jeu on va écrire, il y aura toujours un socle commun, permettant de faire dialoguer des modules, permettant d'interfacer les différents moteurs mis en jeu.

Je vais utiliser les outils suivants :

  • Irrlicht pour le rendu 3D la gestion des entrées utilisateur ;
  • CEGUI pour la gestion des menus et des éléments graphiques non 3D ;
  • asio pour la gestion du réseau et les threads ;
  • Irrklang pour le son ;
  • boost.

Le jeu contiendra des modules plus ou moins indépendants, gérant chacun un aspect du jeu. L'objectif étant bien sûr de rendre possibles les développements des différents modules en parallèle, sans que ça n'entraîne d'effets de bord dans les autres modules.

Schéma général

Un objet contiendra tous les modules. D'un point de vue purement conceptuel, l'architecture peut contenir un nombre non défini de modules, il faut donc les stocker dans un conteneur style std::list. Chaque module aura un pointeur vers l'architecture, permettant ainsi d'accéder aux autres éléments de la liste des modules.

I-B. Les contraintes, les objectifs

  • L'architecture devra pouvoir convenir à un maximum de types de jeu, il ne faut donc faire aucune supposition sur l'utilisation qui en sera faite.
  • Nous avons une très forte contrainte de performances : l'architecture proposée devra être aussi légère que possible tant en ressources processeur, qu'en mémoire ou en espace disque nécessaire.
  • L'architecture devra aussi être légère en utilisation du réseau, de manière à favoriser des échanges rapides et supportés par les bandes passantes les plus modestes.
  • Les modules étant les pièces de base de l'architecture, ils devront pouvoir communiquer simplement et rapidement entre eux.
  • Dans le cas d'un jeu multijoueur, il faudra pouvoir tirer profit des machines puissantes pour leur assigner des tâches telles que la gestion de personnages non joueurs.

Voici un diagramme de classes simplifié pour les principales classes mises en jeu :

Image non disponible

précédentsommairesuivant

Copyright © 2007 Pierre Schwartz. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.