Mon expérience du jeu vidéo commence à la fin des années 80, j'étais alors un jeune adolescent du collège lorsque j'ai commencé à m'intéresser à la modélisation 3D, je connaissais le langage Basic et l'assembleur (Z80).

L'un de mes premiers programmes sur ce sujet a été un modèle en 3D fil de fer du système solaire (et oui j'étais passionné aussi par l'astronomie).

La méthode employée consistait à d'abord créer un cercle, puis un 2éme cercle aplatie (donc une ellipse) circonscrit dans le premier cercle.

Ceci donnait alors l'illusion d'une sphère sur l'écran de l'ordinateur. En reproduisant le procédé avec différentes tailles et en plaçant les sphères obtenues sur le bord d'un cercle beaucoup plus grand (représentant la trajectoire autour du Soleil) j'ai obtenu un modèle 3D du système solaire.

Il ne manquait plus qu'à animer le tout pour obtenir les effets liés à une rotation, une translation ou encore au zoom (homothétie). Il suffisait d'implémenter des systèmes d'équations à 3 variables (3 dimensions d'espace). Ci-dessous un petit rappel des formules :

Pour les rotations en x, y ou z

Pour les autres types de déplacement

Quelques années plus tard, j'étais cette fois-ci au lycée, j'ai commencé à programmer des petits jeux de plateforme (2D), pour lesquels je souhaitai intégrer des introductions en 3D.

J'ai donc appris à reproduire des formes géométriques telles que des cubes, des tétraèdres, etc... puis j'ai appliqué à nouveau les systèmes d'équations que je connaissais pour les faire bouger.

Mais lorsque j'ai voulu programmer les rotations de ces objets, je me suis heurté à un étrange phénomène. En effet les objets se déformaient pendant les phases de rotation. Il y avait peu de documentation à l'époque et je n'arrivai pas à corriger le problème que j'attribuai à un ordinateur trop stupide pour suivre le résultat des équations, bref un gros bug...

Ce n'est que plus tard en étudiant l'ensemble des nombres complexes que j'ai compris (ou plutôt que l'on m'a expliqué...) d'où venait le problème. En réalité virtuelle il porte le nom de blocage de Cardan ou 'Grimbal Lock'. Il est du à une perte dans les degrés de liberté des angles d'Euler (un problème bien connu dans le monde de la 3D). Pour le résoudre il faut alors utiliser 4 dimensions d'espace au lieu de 3, c'est l'ensemble des Quaternions, c'est à dire des nombres hypercomplexes englobant nombres réels et nombres imaginaires.

Il est étonnant de devoir utiliser 4 dimensions pour faire de la 3D sur l'écran 2D de son ordinateur. Mais ça fonctionne très bien et l'on commence alors à percevoir un lien indicible entre les dimensions.

Dans les années 90, la modélisation 3D a pris un nouveau virage avec l'arrivée de jeux vidéo, tels que 'Alone in the dark' et surtout Wolfenstein 3D. à cette époque je travaillais sur 3D Construction Kit un super outil pour faire de la 3D. Cependant peu efficace en terme de rapidité de rendu.

Ma première satisfaction va venir avec la sortie de Duke Nuken. Son éditeur 3D était fabuleux pour l'époque et j'ai pu développer des niveaux assez intéressants :

Suite à cela je me suis penché sur des développements dans le style de Doom I avec le moteur Ack3D et la librairie Wing (l'ancêtre de DirectX).

Finalement il faudra attendre la fin des années 90, pour qu'enfin je décide de me lancer dans une première réalisation. Il s'agissait d'un jeu complet en 3D ayant pour titre 'Genesis 4, secteur G2' (voir plus bas pour le scénario). Au niveau des technologies j'avais choisi visual C++ et le SDK d'Half Life pour le développement. Pour la modélisation des éléments 3D spécifiques dont j'avais besoin, notamment pour les cinématiques, le choix s'était porté sur 3DS MAX et enfin pour l'assemblage et la création des niveaux j'avais utilisé l'éditeur WorldCraft. En seulement quelques semaines le jeu avait pris forme.

Sous WorldCraft on trouvait de très nombreuses fonctionnalités permettant de faire à peu prêt tout ce que l'on imaginait pour le jeu. Bien sûre pour des spécificités non présentent dans le moteur d'Half Life, cela nécessitait au préalable des modifications au niveau du SDK en langage C++.

Mais c'était tout de même très agréable de créer le game design du jeu avec cet outil.

Il ne restait plus qu'à intégrer les animations en images de synthèse faites sous 3DSMax :

Le scénario du jeu était l'un des éléments essentiels pour vous guider tout au long du processus de développement, voici celui que j'avais imaginé pour Genesis4 :

"En mission d'exploration dans l’amas globulaire Genesis, à bord de votre vaisseau spatial "L'Archangel", vous vous apprêtez à rejoindre la Terre grâce à un saut dans l'hyper-espace. Malheureusement des fluctuations quantiques perturbent la stabilité du passage inter-dimensionnel au moment de votre départ. Votre vaisseau se retrouve alors projeté dans un champ d'astéroïdes. Vous vous en sortez de justesse, mais vous subissez des dommages importants. Impossible pour vous de regagner la Terre. L'ordinateur de bord réalise une cartographie de la zone et en déduisant l'écart de trajectoire subit, vous indique que vous vous trouvez dans la région "Genesis4 secteur G2". Une région peu explorée car les taux de rayonnements cosmiques y sont particulièrement élevés. La présence d'une planète vous est signalée par les détecteurs longue portée. L'analyse biochimique indique que l'atmosphère est respirable et qu'il existe des formes de vie. Un rapport plus détaillé affirme même que la planète a été terraformée très récemment. De toute façon vous n'avez pas le choix et vous devez vous poser afin de réparer les avaries causées par le champs d'astéroïdes. En survolant la planète un étrange complexe se dessine au loin, entouré d'une légère brume. Cette planète est donc habitée... Quels mystères se cachent dans ces lieux ? Quelles menacent allez vous découvrir ? L'aventure commence et vous ne pouvez pas imaginer à ce moment là les enjeux en cours et le rôle important que vous allez jouer pour venir en aide aux autochtones et même prévenir un très grand danger pour la Terre..."

Si les maps de ce jeu vous intéressent, n'hésitez pas à me contacter je pourrai vous les fournir.

En 2007, j'ai pris part à un projet de production d'un jeu vidéo original qui s'appelait MitalWar. Vous pouvez d'ailleurs voir sur notre page d'accueil, l'un des croquis du projet.

Il s'agissait d'un jeu rétro-futuriste pour Xbox et PC. Le mode de développement choisi était collaboratif. Nous avons travaillé à distance (partage web) dans le cadre d'une association à but non lucratif 'Futurn'. Ainsi j'ai pu participer à un projet d'envergure en équipe et ainsi me familiariser avec les méthodologies de conceptions modernes des jeux vidéo.

MitalWar était un jeu de stratégie de guerre en 3D temps réel, dont l'action se déroulait dans un monde à l'aspect ancien (genre XIX siècle) mais où l'on pouvait néanmoins trouver des technologies avancées. D'où l'appellation 'Rétro-futuriste'.

Mon travail consistait à travailler sur le moteur du jeu en veillant à ce qu'il n'y ait pas de décalage entre le code source et les modèles UML. Le langage utilisé était le C# (CSharp) et après des recherches le choix du moteur 3D s'était porté sur OGRE3D. Le moteur du jeu est le niveau central qui gère tous les autres moteurs constituants le jeu (moteur physique, son, IA, etc...). Ci-dessous vous trouverez un exemple de diagramme UML que je devais maintenir et mettre à jour durant les phases de développement du moteur du jeu, ainsi que quelques documents que je devais produire régulièrement, tout comme les autres membres de l'équipe.

- Conception BDD pour les protocoles du jeu

- Génération automatique de diagramme de séquence

Si vous souhaitez vous lancer dans ce type de développement, mais que vous ne savez pas par où commencer afin de mettre en place l'organisation nécessaire, n'hésitez pas à me demander quelques conseils ou documentation sur le sujet. Par exemple pour ceux qui sont intéressé par le thème de cet article 'Réalité virtuelle', il vous faudra dans un premier temps maîtriser un langage de programmation, le C# est très robuste pour cela et exploitable pour les consoles Xbox ainsi que pour PC. Cela fera donc un bon début.

Par la suite vous aurez besoin de connaître les mathématiques 3D indispensable à la réalisation d'un modeleur (si vous désirez être propriétaire de votre propre outil afin de ne pas trop dépendre des licences des autres éditeurs de logiciels).

Olivier EDWIGE.