Voici donc la 2ème partie de l'interview que Zeden a réalisé auprès de Bafman, développeur français de moteur 3D. Après nous êtres intéressés au généralités du métier, de la formation suivie pour y arriver, et de l'aspect marketing dans la première partie, nous allons découvrir l'aspect plus technique du job. Des notes de la rédaction viennent éclaircir le lecteur au fur et à mesure, pour rendre l'article abordable à tout le monde.

Qu'est ce qu'un moteur 3D : quel est son rôle exact, comment s'interface-t-il avec le reste des éléments du jeu ?

C'est simplement une des briques d'un logiciel. Comme tout logiciel, un jeu est composé de plusieurs parties distinctes. On peut voir le jeu comme une sorte d'étoile. Chaque branche de l'étoile est une brique du jeu (moteur 3D, moteur d'IA, moteur de son...). Chaque branche de l'étoile rejoint les autres au centre : c'est le jeu. Finalement, ce n'est qu'un gros assemblage logiciel.
Plus précisément, le moteur 3D va nous permettre d'afficher des modèles 3D, de gérer l'éclairage, l'environnement et tout ça. Mais finalement, un moteur 3D, ça ne fait que des trucs relativement simple d'un point de vue extérieur (à l'interieur, c'est une autre histoire). Ensuite, c'est à la partie gameplay (donc le code propre à un jeu donné) d'utiliser les services du moteur 3D pour donner le resultat voulu.

Note du Rédacteur
D'un jeu à l'autre, d'un type de jeu à un autre où la 3D est requise, on voit bien qu'il y aura toujours un moteur 3D, dont le rôle suivra toujours les mêmes grandes lignes. C'est d'ailleurs pour cette raison qu'un même moteur 3D peut etre utilisé pour plusieurs jeux différents. A l'heure actuelle, notre encyclopédie FPS recense 32 moteurs différents dans les FPS, mais la liste est non exhaustive.

Quel est le processus pour fabriquer un moteur graphique ?


De la sueur et du café... Plus sérieusement, on commence par beaucoup de code bas niveau. On pose les base au-dessus d'une API 3D, et une fois cette base suffisamment solide, on regarde les spécifications du jeu, et on oriente l'architecture du moteur 3D pour obtenir les meilleurs performances possibles. Il faut vraiment voir le moteur 3D comme un gros oignon. Il y a de nombreuses couches les unes par dessus les autres, comme ça, si une des couches est trop lente, on la refait.
C'est d'ailleurs un élément principal du développement d'un moteur 3D : on refait beaucoup de code. En effet, la réalisation d'un moteur 3D au top niveau implique une grande part d'expérimentation. Malheureusement, parfois ,l'"expérience" ne donne pas les résultats voulus en terme de performances, et il faut donc recommencer en partant dans une autre direction. C'est d'ailleurs un autre avantage d'avoir un moteur proprio : on peut plus facilement casser une partie du moteur pour la refaire.
Donc pour résumer, le développement d'un moteur 3D, c'est d'abord des bases génériques pouvant servir à n'importe quel moteur 3D, puis ensuite, on les utilise pour spécialiser le tout sur notre jeu.

Quelle est la charge de travail pour développer un moteur graphique ? 6 mois, 1 an ? À 2 personnes, à 10 personnes ?

Selon la taille du moteur, ça peut fortement varier. En gros, je dirais environ 2 ans avec une équipe importante pour un gros moteur, mais on peut très bien développer un petit moteur spécifique à un jeu à 2/3 personnes en quelques mois. En fait, tout dépend du niveau d'optimisation qu'on souhaite obtenir. Un produit à petit budget peut très bien se contenter d'un moteur open source comme Ogre, qui a l'avantage d'être relativement générique, mais qui du coup n'est pas forcément le plus véloce.

Note du Rédacteur
Ogre (Object-Oriented Graphics Rendering Engine) est un moteur 3D multiplateforme Open source, écrit en C++, a priori très cohérent et bien documenté. L'album présentent quelques-uns des nombreus projets l'utilisant. Il n'est pas limité qu'aux jeux : simulation et utilisations professionnelles sont aussi dans ses cordes.

Utilisez vous des moteurs graphiques propriétaires ou déjà existants ?

Non, nous développons quasiment tout nous même. Ca permet de savoir exactement comment fonctionne le moteur en interne. Un autre avantage d'avoir un moteur proprio, c'est de pouvoir proposer un résultat unique que n'a pas la concurrence.

Note du Rédacteur
Lorsqu'on doit choisir un moteur 3D pour la réalisation d'un jeu, il y a toujours un premier choix à faire. Soit utiliser un moteur 3D disponible sur le marché, ou bien réaliser soi même son propre moteur, qu'on qualiefiera donc de propriétaire.
Les élements à prendre en compte pour ce choix sont très variés, et il faut se poser de nombreuses questions. Parmi celles-ci : financièrement, vaut il mieux payer une licence d'un moteur existant, ou plutôt engager des developpeurs pour le faire, existe-t-il un moteur 3D ayant toutes les fonctionnalités que je désire, est-ce que j'ai plusieurs jeux à réaliser qui pourraient utiliser un moteur 3D commun...
La société de Bafman a fait son choix : ils développent en interne pour garder une maitrise totale sur leur moteur. S'ils doivent faire une modification, c'est plus facile pour eux de le faire sur ce qu'ils connaissent par coeur que de se plonger dans les arcanes d'un moteur acheté.

Les shaders sont-ils devenus incontournables maintenant lors du développement d'un moteur 3D ?

Oui, bien entendu. De toute façon, ca fait déjà quelques temps qu'en interne, les carte 3D gèrent tout en shader, même ce qui était fait en "pipeline fix" dans les cartes précédentes. On n'a donc aucune raison de ne pas baser un moteur 3D sur les shaders

Les effets "Next Gen" sont-ils difficiles à mettre en œuvre ?


Tout dépend du moteur en fait. S'il a été conçu pour avoir ces effets, non, il ne seront pas durs à mettre en œuvre. Par contre, s'il n'a pas été conçu dans cette optique, ça peut effectivement rajouter un gros surcoût en terme de réarchitecture.

Est-ce qu'il faut avoir la "bosse des maths" ? Parce que j'imagine qu'il y en a énormément ?

Oui et non. Sur le moteur 3D, il faut avoir de bonnes connaissances en algèbre linéaire effectivement (matrices, vecteurs, quaternions et autres), mais pour les autres parties du jeu, on peut se débrouiller sans être une star en maths.

Note du Rédacteur
L'informatique et les mathématiques ont toujours fait bon ménage. Nos CPU et GPU sont de formidables machines à calculer. La réponse de Bafman nous oriente vers quels types de calculs sont réalisés : l'algèbre linéaire. Difficile, même avec ce lien wikipedia, de définir de manière simple ce que c'est sans avoir fait un minimum de maths à l'école. La théorie des matrices est en fait la base même du rendu 3D, puisque toutes les problématiques liées à un environnement 3D peuvent être traitées avec cet outil mathématique généralement enseigné en études supérieures à vocation scientifiques.

Pour faire le lien entre les maths et le rendu 3D, le site français Onversity propose un article intitulé "A quoi servent les mathématiques dans un moteur 3D", dont je vous recommande la lecture.

Evidemment, les programmeurs n'ont pas à réecrire du code gérant les matrices à chaque fois qu'ils concoivent un moteur 3D. Le traitement matriciel fait partie intégrante des API de jeux, notamment d'OpenGL. Cette partie de la documentation française d'OpenGL détaille la fonction "glTranslate". Ce genre de litterature est utilisée par nos chers développeurs de moteurs 3D. Dans cet exemple, il est question de "matrice de translation", de "prototypes", de "vecteur", de "paramètres", de "coordonnées" et de matrice par défaut. Mathématiques, Rendu 3D et Programmation : la boucle est bouclée.

Quels outils 3D sont utilisés pour générer les graphismes ?


À priori, du 3ds Max et du Photoshop, mais en cas de besoin, on peut utiliser d'autres outils (notamment des outils Open Source à la Blender / Gimp)

Note du Rédacteur
Les moteurs 3D ont pour principal objectif de manipuler des ressources graphiques. Sans ces ressources, un jeu n'existerait tout simplement pas. On distingue principalement deux types de ressources : d'un côté les modèles 3D et de l'autre des textures, à appliquer sur ces textures. Pour les réaliser, on utilise respectivement des outils d'images de synthèse et de retouche d'image.

Sans réelle suprise, on retrouve dans la réponse de Bafman les ténors du marché de l'imagerie de synthèse et de la retouche d'images. La lignée des produits 3D Studio Max est présente sur le marché depuis plus de 10 ans. Quant à Photoshop, il a débuté sur MacOS en 1990. La maturité de ces 2 produits n'est plus à démontrer, mais leurs coûts et la montée en puissance d'outils libres équivalents font qu'ils ne sont plus forcément les seuls outils utilisés dans des environnements dits "professionnels". L'aventure Blender débuta sur Amiga en 1989, mais ce qu'en 2003 que l'outil prit sa forme actuel de suite logicielle 3D gratuite sous Linux. Quant à Gimp, qui affiche lui aussi plus de 10 ans au compteur, il est THE outil de retouche par excellence sous l'OS au pingouin.

Niveau technique, quels sont les outils et les langages que tu manipules , et à quoi servent-t-ils?

Niveau outils, c'est très varié. En tant que développeur 3D, j'utilise principalement Visual Studio, mais on utilise aussi beaucoup d'outils développés en interne.
Niveau langage, au niveau du moteur 3D, c'est C++ only, mais pour les outils, on utilise C#, et pour la gameplay, du python. L'avantage du C++ pour le moteur 3D, c'est de pouvoir mettre en place des optimisation bas niveau (utilisation d'instructions SSE et autres) qu'on ne peut pas faire avec les autres langages. Par contre, il implique des temps de
compilation très importants. C'est pour ca que le python a été choisi pour le gameplay. En effet, toute la partie gameplay implique de nombreux réglage, et donc de relancer très souvent le programme. Si, à chaque fois, on doit compiler le tout, on en sortirait pas...

Note du rédacteur
Visual Studio est l'Environnement de Developpement Intégré (IDE) estampillé Microsoft. On appelle IDE un regroupement d'outils de programmation dans une seule application. On retrouve tout d'abord un éditeur de texte évolué, car écrire du programme, c'est écrire du texte avec une syntaxe très particulière, le langage de programmation. Une autre partie très importante de l'IDE est le compilateur. Il traduit les fichiers texte de code en un fichier dit executable, les fameux fichiers .exe. C'est le compilateur qui permet ou non les optimisations qu'Intel et AMD incluent dans leurs processeurs : MMX, SSE, etc. Le compilateur de Visual Studio permet bien évidemment tout cela. Un troisème module absolument obligatoire dans un IDE est le debugger, un ensemble d'outils dont le but est la détection des problèmes. A la charge du développeur de les corriger.

Tu parles de se "remettre à jour'". Tu veux dire par rapport au système de gestion de configuration, style CVS ou SVN ?

Exactement. On utilise SVN.

Note du Rédacteur
On aborde avec cette question le travail d'équipe lors du développement. En effet, les programmeurs se répartissent les parties à coder, mais il y a bien évidemment des morceaux de programmes communs. Si une modification est faite sur un fichier par un membre de l'équipe, il doit la donner à tous les membres de l'équipe. Soit il fait ça envoyant le fichier modifié à ses collègues par mail, ce qui peut poser problème si quelqu'un d'autres à fait une autre modification sur ce même fichier en même temps, soit on utilise ce qu'on appelle un outil de gestion de configuration, comme CSV ou SVN. Ces outils ont pour but de faciliter le développement en équipe, en permettant de gérer les modifications sur les fichiers menées par les différents intervenants.

Concrètement, ces outils fonctionnent en client / serveur. Sur l'unique serveur SVN est stocké l'arborescence des fichiers du projet. Ce serveur est la Référence : il contient toutes les versions de tous les fichiers validées par les développeurs. On peut donc revenir en arrière, comparer 2 versions entre elles, savoir qui a fait quoi et quand.
Pour ce qui est des clients : chaque programmeur dispose d'un logiciel client SVN sur sa machine. Quand il modifie un fichier, et qu'il valide (on dit aussi "Commiter") cette modification, son fichier va être placé sur le serveur comme étant la nouvelle version de référence. Pour que les autres programmeurs puissent en profiter, ils vont chacun devoir se mettre à jour (on dit aussi "updater").

La mise à jour est donc une étape importante, comme le mentionne Bafman.

Tu parles de temps compilation longs. Ca se chiffre en minutes, voire en heures ?

En minutes heureusement... sinon, on ne bosserait pas longtemps par jour

Comment se fait la phase d'optimisation des performances d'un jeu ?


Elle se fait en permanence... Si on ne surveille pas en permanence les performances, on risque de partir dans une direction qui, au final, ne sera pas suffisamment efficace, et dans ce cas là, il faut refaire une grosse partie du moteur... On a des outils qui nous permettent d'avoir des informations très précises sur les performances qu'on surveille régulièrement. Bien entendu, durant le développement, on ne va pas non plus chercher à optimiser à mort une partie du code qui risque de disparaître au final car l'architecture aura changé. Par exemple, les shaders utilisés ne sont pas optimisés au max, tout ceci sera optimisé à la fin du développement quand l'architecture sera stabilisée.

Qu'est ce que ces outils surveillent exactement ? Le temps d'exécution de chaque fonction ? La mémoire consommée ?

On essaye d'observer tout ce qui est observable, en quelque sorte. Donc effectivement, ça va du temps d'exécution à l'utilisation mémoire, en passant par le nombre d'images par seconde, voire même la dérive du nombre d'images par seconde, qui nous donne un bon aperçu de la stabilité du moteur.

Comment se déroulent les tests d'un jeu ? Sur quelles machines ? Quelle organisation ? Quels sont les problèmes les plus difficiles à voir et à corriger ?

Les tests s'effectuent tout au long du développement. Ce qu'on essaye, c'est d'avoir à tout moment une version jouable du jeu. On a donc l'ensemble des personnes qui travaillent sur le jeu qui le testent régulièrement. Les machines de tests sont nos machines de développement. Il y a aussi toute une partie test chez l'éditeur, mais je n'ai pas de détails là-dessus.
Les problèmes les plus difficiles à corriger sont les bugs silencieux qui brusquement se manifestent. Ça peut être une corruption mémoire par exemple. Le plus gros problème avec ce genre de bug, c'est qu'on ne sait pas quand ils sont apparus, et on est donc obligé de faire toute une enquête pour en connaitre l'origine. Le même bug détecté dès son apparition est généralement beaucoup plus simple à corriger.

Note du Rédacteur
Cette manière de procéder est assez classique. Il y a des tests en interne, puis des tests chez le client, afin de maximiser les chances de détection de problèmes.
Les bugs silencieux, qui apparaissent de manière aléatoire, demandent pas mal d'expérience, ne serait-ce que pour être reproduits de manière certaine. Seulement alors peut commencer l'analyse, puis, enfin, la correction.
On peut passer 2 jours à essayer de reproduire un plantage, pour aboutir à une correction sur une seule ligne de code réalisée en 30 secondes...

Connais-tu le programme Nvidia "The way it's meant to be played ?" Si oui, est ce vraiment une aide précieuse pour les dev, ou bien est-ce plutôt assez "pipeau" ?
Je le connais de nom, mais nous n'y participons pas, et donc je ne connais pas les détails de ce programme.

Note du Rédacteur
On voit de plus en plus fréquemment le logo de Nvidia dans les jeux. Ce logo represente un système d'assistance qu'Nvidia offre aux developpeurs afin de les aider à profiter pleinement des dernières carte graphique. Nous en parlions un peu plus longuement dans cette news

Les environnements de développements sont-ils optimisés pour Vista ?

Non. Absolument pas. Bon OK, j'avoue, je n'aime pas cet OS que je trouve inutilement lourd, donc je ne suis sûrement pas objectif là-dessus.

Note du Rédacteur
Vista, DX10, 64 bits, .net. Les évolutions du monde Windows ont été assez nombreuses et rapides ces dernières années, et les IDE, notamment ceux qui ne sont pas développés par Microsoft, ont parfois du mal à suivre le rythme. On imagine bien que les outils développés en interne ne sont pas, eux non plus, optimisés pour toutes ses nouveautés. Il faudra du temps, et attendant, Microsoft, à l'origine de ces évolutions logicielles, pousse en avant son Visual Studio censé tout intégrer...

En termes de contraintes techniques, quelles sont les différences entre les RTS et les FPS ?

N'ayant jamais bossé sur des FPS, je ne sais pas trop... Elles sont sûrement très nombreuses, notamment au niveau du nombre d'objets à afficher en même temps... En fait, globalement, d'un point de vue strictement graphique, on considère que le RTS atteint généralement le niveau du FPS deux à trois ans plus tard.

Penses-tu développer des jeux toute ta vie, ou penses-tu qu'on ne peut faire ça que quelques années ? Est-ce que des gens vont ensuite travailler en SSII ? Ou bien ils deviennent chef de projet ?

Vaste question à laquelle je ne sais pas répondre à l'heure actuelle. Personnellement, toutes les personnes que j'ai vu changer de boite depuis que je suis dans le milieu sont restées dans le jeu vidéo.

Conclusion

Nous ne remercierons jamais assez Bafman pour le temps qu'il a bien voulu consacrer à nos questions. Nous espérons sincèrement que cette interview, ainsi que les différentes notes explicatives, vous ont permis de mieux cerner ce qu'est un moteur 3D, comment ils sont réalisés, et ce qu'ils impliquent.