Accueil ➤ Ressources ➤ Guides ➤ Guide pour développer un logiciel en 3D temps réel
🌀 Auteur : Yoann AMAR ASSOULINE
🌀 Dernière mise à jour : février 2023
La création d’un logiciel en 3D temps réel est une tâche extrêmement complexe, et celle-ci exige une expertise approfondie dans une pluralité de domaines.
La plupart des outils de développement de logiciels 3D ou de jeux vidéo sont très polyvalents, et peuvent s'adapter à des contextes
extrêmement variés. Certes, ils sont principalement destinés au développement des jeux vidéo, mais se révèlent être véritablement efficaces pour la création
de Serious Games, de Business Games, de logiciels de visualisation architecturale ou de véhicules, de films d'animations,
et bien d'autres types de logiciels !
Surtout, l'éventail des possibilités pour un moteur dépend essentiellement de son architecture, c'est-à-dire de la manière dont il est conçu ou encore des
différents outils (Frameworks, langage(s), etc.) avec lequel il est compatible.
Sur le plan historique, l'émergence de chaque nouvelle génération de console permet d'observer les fissures de limites qui semblaient pourtant
infrangibles.
Ce constat est particulièrement vrai pour la neuvième génération, avec les consoles
PlayStation 5 et
Xbox Series X|S
distribués dès novembre 2020, qui permettent d'observer des améliorations substantielles dans l'industrie vidéoludique.
Par ailleurs, on peut estimer que les outils de création de logiciels 3D vont continuer à s'implémenter et se démocratiser dans un grand nombre de domaines,
bien au-delà de ce qui semble possible à l'heure actuelle !
L'objectif majeur de ce guide est donc d'esquisser des pistes pour développer des logiciels en 3D temps réel, et surtout de répondre à toutes les interrogations
qu'on peut formuler lorsqu'on débute, du moins sur le plan technique.
D'autres guides seront rédigés et liés à celui-ci, en particulier pour mettre en surbrillance les différentes notions liées à la gestion de projet
(notamment les différents Frameworks Agile) ou encore les spécificités techniques de la programmation avec un moteur de jeu 3D (ou 2D), parfois
très différente de la programmation d'un logiciel qu'on pourrait qualifier de classique.
Un néophyte en développement pourrait être tenté de se questionner sur le choix du langage de programmation. Or, cette première variable n'entre que rarement en compte
lors du choix d'un moteur de jeu. Pour être totalement transparent, cette question n'a aucun intérêt.
En substance, c'est le choix du moteur qui va imposer le langage de programmation à utiliser, et non pas l'inverse.
D'abord parce qu'un programmeur est théoriquement en mesure d'apprendre un nouveau langage de programmation sans aucun problème,
surtout que la plupart des langages du développement de logiciels 3D utilisent le paradigme orienté objet, plus précisément celui des classes
(l'autre type de paradigme orienté objet étant celui basé sur les prototypes).
Néanmoins, si on veut réellement répondre à cette question primitive, il n'y a que l'embarras du choix avec un moteur professionnel, à l'heure actuelle :
le C++ ou le C#.
Certaines ressources peuvent lister des langages de plus haut niveau (du point de vue de la machine), notamment Java ou Python,
et les mettre sur un même pied d'égalité au niveau des possibilités de développement que le C++ ou le C#.
Or, il s'agit bien d'une erreur. En réalité, s'il est vrai que Minecraft a été conçu en Java (pour reprendre l'exemple le plus connu) depuis 2009,
celui-ci a été réalisé dans un contexte particulier, et n'est pas représentatif des outils qu'on utilise aujourd'hui dans l'industrie vidéoludique,
et encore moins pour réaliser un jeu respectant les standards triple-A, c'est-à-dire des jeux avec un budget gargantuesque.
À cette époque, les deux mastodontes des moteurs de jeu, Unity et UDK (Unreal Engine 3 en version publique),
n'étaient qu'à leurs balbutiements dans la sphère publique. Unreal existe depuis 1998 mais uniquement sous licence professionnelle,
et Unity a débuté en juin 2005 mais exclusivement sur Mac. Pourtant, ces deux moteurs étaient une véritable révolution qui changea les choses.
Quoi qu'il en soit, le développement d'un logiciel en 3D temps réel se fait d'abord un moteur de jeu (en anglais Game Engine),
c'est-à-dire un outil qui va à la fois rassembler toutes les données d'un jeu (qu'on appellera des assets), mais qui va surtout
permettre la création d'interactivité dans un logiciel, et de gérer ce qu'on appelle la 3D en temps réel (qui est calculée en direct par l'ordinateur,
contrairement à la 3D offline ou en pré-rendu, qui n'est qu'une image ou une succession d'images).
Un moteur est composé de plusieurs modules, notamment le module de gameplay (les interactions du jeu), d'intelligence artificielle,
le moteur physique, et ainsi de suite.
Étant la clef de voûte d'un projet, c'est un choix décisif (ou cornélien) qui conditionnera les chances de réussite d'un projet et
orientera des outils et technologies complémentaires au moteur (langage de programmation, format 3D utilisé, structure du jeu, plates-formes, etc.).
On peut subdiviser la catégorie des moteurs de jeu (ou moteur de création 3D) selon la nature de l'outil en question, puisque certains sont des outils
professionnels destinés à des projets respectant les standards AAA alors que d'autres outils sont simplifiés (parfois à l'extrême) pour plutôt convenir
à un public plus récalcitrant de l'aspect technique.
En effet, il ne faut pas éluder le fait qu'un moteur est un outil extrêmement complexe, et on évoque souvent des milliers d'heures d'utilisation pour en
découvrir les linéaments.
On peut aussi préciser qu'il faut différencier trois acceptions du terme moteur :
Les moteurs professionnels sont de facto les outils utilisés par des studios de développement de renom international, sur des projets particulièrement ambitieux.
Par leur qualité et leur nature, ils sont adaptés aux besoins d'une entreprise, qu'il s'agisse d'un immense studio de développement avec des milliers
de développeur ou d'un petit studio indépendant d'une ou de quelques personnes.
On évoque le sigle AAA pour les jeux imposant des standards de qualité très élevés, et triple-I pour les jeux indépendants dont les standards sont
relativement proches des jeux AAA, mais avec un contenu de facto moins important.
Généralement, seulement trois moteurs sont souvent cités comme étant de véritables incontournables :
Toutefois, la pertinence du choix d'un moteur est multifactorielle, et c'est la raison principale pour laquelle il est difficile de donner une ligne directrice
sans esquisser les contours d'un projet concret. En clair, un moteur n'est jamais réellement une solution one size fits all, et ne conviendra jamais pour
un spectre trop large de projets.
Par ailleurs, il faut préciser que Godot n'est pas encore adapté pour le développement de jeux AAA,
comme indiqué dans le blog officiel.
Cependant, il est certain qu'il deviendra un incontournable dans le milieu, au même titre que Unity ou Unreal Engine, et représente une valeur sûre pour l'avenir.
Bien sûr, il existe d'autres moteurs, à la fois développés par de gigantesques multinationales (CryEngine de Crytek, Lumberyard/ Open 3D Engine d'Amazon, etc.)
et par des indépendants (UPBGE, Armory3D, Stride, etc.).
Néanmoins, la popularité de ces moteurs dans la sphère publique est bien moins importante.
Le choix du moteur de jeu n'est pas à prendre à la légère, car il conditionne non seulement la réussite ou l'échec d'un projet entier, mais peut aussi altérer
le futur d'une entreprise ou d'un studio de développement.
En substance, on peut évoquer deux critères principaux dans le choix du moteur : sa popularité et son adaptabilité au(x) projet(s) du studio.
D'abord est préférable de privilégier les outils les plus utilisés sur le marché, pour une multitude de raisons
(abondance de tutoriaux, forums et salons Discord d'entraide, risque extrêmement faible d'abandon du moteur par les développeurs, etc.).
Pour cela, on peut citer plusieurs critères permettant de vérifier la popularité d'un moteur :
À côté des outils professionnels qui sont relativement complexes (mais adaptable à un grand nombre de projets), il existe également des moteurs de jeu simplifiés. Ces moteurs (ou outils de développement) peuvent être adaptés à des projets qui entrent déjà dans un cadre assez classique, en 2D ou en 3D. Bien sûr, la simplification de développement va de facto brider les possibilités du gameplay.
Il existe des moteurs relativement anciens, qu'il est impossible de qualifier de désuets, car certains sont encore en développement ou en maintenance,
mais ceux-ci ne répondent plus aux besoins actuels de la plupart des studios AAA ou indépendants, contrairement à Unity ou Unreal Engine, par exemple.
Néanmoins, il existe des cas de figure relativement rares où ces moteurs bas niveau peuvent avoir une certaine pertinence.
Pour recontextualiser l'apparition de ces moteurs, on peut mentionner qu'ils sont présents sur la sphère publique depuis le début des années 2000,
lors d'une époque où les moteurs professionnels étaient disponibles uniquement via une licence extrêmement onéreuse et officielle.
Généralement, il existait donc trois solutions :
Au fil du temps, les possibilités pour les développeurs indépendants évoluaient. Sans entrer dans les détails, des outils comme XNA ouvraient des possibilités,
puis Unity et Unreal ont quasiment permis une petite révolution.
Unity a été publié d'abord en 2005 sur Mac.
Puis Unity et UDK, la version publique d'Unreal Engine 3, sont publiés en 2009 sur Windows
Dans tous les cas, on peut en indiquer quelques-uns, en tout cas les plus connus (sans pour autant établir une liste complète, car il en existe des centaines) :
L'infographie concerne la création de modèles 3D (animés ou non) et d'images 2D (sprites, tilesets, interface graphique, etc.)
qui, dans le contexte du développement de logiciels 3D, sont importées dans un moteur de jeu (on utilise le terme
asset, mais celui-ci va plutôt définir toutes les données qu'un jeu utilise, donc les modèles 3D, les textures, les sons, les musiques, etc.).
Il existe de nombreux développeurs qui achètent des assets sur des sites comme TurboSquid ou Sketchfab, voire sur les marketplaces officiels (Unity, Unreal),
mais ce cas ne nous intéresse pas puisque ce guide concerne la création d'un logiciel 3D from scratch.
Ici, on s'intéresse uniquement à l'infographie 3D, et on nomme souvent ces logiciels des outils DCC, sigle de Digital Content Creation.
La création de modèles 3D est surtout un processus qu'on peut diviser en plusieurs parties : la modélisation/ sculpture, les UV Unwrapping et mapping
le texturing, le skinning/ rigging, l'animation et enfin l'exportation dans un fichier (généralement au format FBX).
Le processus de modélisation ou de sculpture digitale d'un modèle 3D peut être réalisé via de nombreux logiciels.
Mais, généralement, le choix se porte sur un nombre restreint : 3DS Max, Maya ou Blender pour la modélisation et ZBrush ou Blender pour la sculpture.
Le choix dépend surtout du moteur utilisé, et la plupart des moteurs disponibles possèdent surtout une documentation pour exporter un asset depuis les logiciels
3D qui viennent d'être cités.
Mais, avant toute chose, on précise qu'il est possible de modéliser avec une image de référence (comme un calque) ou de tête (surtout pour des modèles
fantaisistes ou pour augmenter la créativité).
On appelle ces images des Blueprints (si elles sont génériques) ou des concept art (si elles sont conçus spécialement pour ça).
Pour texturer les modèles 3D, on peut diviser cette catégorie en deux sections, même si cela reste très schématique :
les textures traditionnelles (sur un shader Blinn-Phon) et les textures PBR.
Pour les textures traditionnelles (principalement un shader appelé Blinn-Phong),
où toutes les informations sont directement inscrites sur la texture (l'éclairage, etc.).
C'était très utilisé dans les anciens jeux vidéo (PS1, PS2 et certains jeux PS3) et encore aujourd'hui dans la plupart des jeux sur smartphone.
On réalise généralement une à trois textures : une diffuse map pour la texture principale où on va inscrire la plupart des infos
(couleurs, motifs et éclairage), parfois une specular map (informations sur l'éclairage),
et souvent sur console, mais rarement sur mobile, une Normal map pour simuler le relief (attention, la Bump Map est l'ancienne version
de la Normal Map, et même si elle permet un gain infime de performance, celui-ci est rarement pertinent).
Il existe d'autres textures, mais c'est préférable de simplifier à ce stade. Les logiciels les plus utilisés pour ça sont donc les suivants :
Les textures modernes (un shader nommé PBR pour Physically Based Rendering) peuvent s'adapter à tous les environnements. Parce que ce modèle est gourmand en ressources, c'est principalement utilisé sur les jeux PC et consoles, et très rarement sur les jeux pour les smartphones. Il existe généralement deux manières d'en créer (ou deux workflows), le Metallic Roughness et le Specular/ Glossiness. Voici les logiciels pouvant être utiles, même si Substance3D reste le logiciel principal pour les PBR.