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

Architecture d'un jeu vidéo 3D


précédentsommaire

VII. Pour aller plus loin

Cette architecture a pour but d'être facilement réutilisable pour la réalisation de tout type de jeu. Pour tout développement d'un type de jeu, il conviendra de spécifier un format de fichier (XML ?) pour représenter une partie, une carte, une intelligence artificielle�?� Une partie contiendra toutes les données nécessaires à la reprise d'un jeu sauvegardé : position des personnages, état de tous les objets�?� Une carte contiendra les noms de tous les modèles 3D nécessaires, les objectifs, mais aussi des données nécessaires aux intelligences artificielles par exemple des points de passage, des zones de regroupements�?�

Le code que je propose se veut le plus générique possible, il va falloir poursuivre dans les directions suivantes :

  • dégager une charte graphique ;
  • développer un thème graphique CEGUI relatif à la charte graphique (détaillé dans les tutoriels CEGUI) ;
  • interfacer un langage de scripts pour les intelligences artificielles et pour le suivi des parties (Boost.Python ? lua ?) ;
  • modéliser les objets 3D, les terrains, les cartes ;
  • développer un module de chargement/sauvegarde (sérialisation des objets map ?) ;
  • réaliser les textures, les sons et les musiques ;
  • réaliser des shaders pour l'aspect graphique (GLSL ?) ;
  • vérifier l'intégrité des données (cohérence par checksum et grammaire des fichiers xml ?) ;
  • intégrer ou non une gestion de la physique (wrapper Newton pour Irrlicht ?).

VII-A. First Person Shooting

Pour réaliser un FPS, il va falloir une carte, des modèles 3D et faire déplacer ces modèles dans la carte. La caméra devra être spécialisée pour représenter un mouvement à la première personne. Il va falloir enrichir la gestion des évènements dans le event_handler pour prendre en compte les coups de feu, il va falloir enrichir la classe player pour rajouter un niveau de vie, éventuellement des équipements. Vous pourrez même vous servir du moteur graphique pour déterminer les objets (et les polygones) situés derrière le viseur. La réalisation d'un FPS se révèle ainsi très conventionnelle.

VII-B. Real Time Strategy

Ce type de jeu est légèrement plus complexe. Comme pour un FPS, il faudra gérer les déplacements des unités et développer un modèle de pathfinding. La caméra devra être spécialisée. Il existe des modèles de caméras pour RTS développés par certains utilisateurs d'Irrlicht, mais vous pouvez tout à fait redévelopper la vôtre. Le gameplay et l'ergonomie sont directement dépendants du type de caméra Irrlicht.

VII-C. Jeu de simulation / course

La réalisation d'un jeu de simulation / course est aussi très conventionnelle, il conviendra d'utiliser un modèle physique performant pour gérer correctement tous les déplacements des objets.

VII-D. Jeu massivement multijoueur : MMO�?�

L'aspect 3D lié à un jeu massivement multijoueur est la même que pour un jeu non massivement multijoueur. Ce qui va faire la différence sera l'utilisation d'une base de données pour stocker les positions de tous les joueurs. Ainsi, en mode serveur, il faudra rajouter un observateur au graphe de scène : un module d'accès aux données, pour accéder par exemple à une base de données spatiale relationnelle, qui serait tout à fait pertinente pour ce genre d'utilisation.

Un autre aspect concernera les personnages non joueurs : il sera plus délicat de les faire gérer par les machines réseau, la cohérence du jeu sera beaucoup plus difficile à conserver. La solution la plus simple serait de les gérer au niveau du serveur.

La mise en place d'un jeu massivement multijoueur peut aussi avoir un autre impact sur la gestion réseau : il n'y aura pas forcément un seul serveur. Il faudra donc mettre en place un système de redirection des messages d'un serveur à l'autre selon que les joueurs sont connectés sur un serveur ou sur un autre. Un simple identifiant pour une machine réseau ne sera plus suffisant pour communiquer avec un joueur, il faudra que l'identifiant soit utilisé à la manière d'une adresse IP, passant de routeur en routeur. Chaque serveur devra savoir au premier coup d'oeil où transférer un message.

VII-E. Les points à ne pas négliger

Il sera très important de réaliser proprement les interactions avec l'utilisateur : la gestion des évènements dans le event_handler et la gestion de l'affichage dans le moteur graphique. Le game play sera le résultat presque exclusif de la bonne conception du event_handler. S'il n'est pas pratique, c'est tout le jeu qui ne sera pas pratique. Ensuite toute l'interface graphique gérée par CEGUI est basée sur des images, et des fichiers XML. On peut donc facilement rendre l'interface plus esthétique, plus colorée, plus pratique. Et surtout, une interface esthétique ne sera pas plus lente qu'une interface bâclée.

Les modèles 3D doivent posséder le moins de polygones possible. Les possibilités du moteur et de votre machine ne sont pas infinies. Encore une fois, un modèle réussi ne sera pas plus lent à afficher qu'un modèle bâclé et c'est pareil pour la texture.

VII-F. Cohérence entre les joueurs

Il faut que le jeu réagisse de la même manière sur les différentes machines qui le lancent. Par exemple il faut que les modèles 3D soient partout les mêmes. De même, il faut que les caractéristiques des intelligences artificielles soient les mêmes. Pour garantir la cohérence du jeu, à chaque connexion d'un joueur, il va falloir vérifier qu'il possède les mêmes fichiers que le serveur. Pour cela, on peut mettre en place un système de comparaison de hash d'une archive contenant tous les fichiers nécessaires à une partie.

Il va aussi falloir éviter qu'on puisse modifier manuellement les fichiers de sauvegarde ou de caractéristiques de personnages. Et pour cela, même principe, on peut chercher à comparer les hashs pour vérifier que tout le monde joue bien avec les mêmes données.

VII-G. Téléchargement

Voici l'archive contenant le code source et un projet Visual C++ 2005 : ./fichiers/archi.zip 6 Mo

J'ai dû recompiler CEGUI et notamment le module IrrlichtRenderer pour le faire fonctionner avec la version d'Irrlicht que j'ai utilisée : la version 1.2.

Image non disponible

VII-H. Remerciements

Je tiens à remercier toute l'équipe de la rubrique 2D/3D/Jeux pour leurs remarques et leurs impressions ainsi que gorgonite , trinityDev et ClaudeLELOUP pour leur relecture attentive.


précédentsommaire

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.