Moteur de jeu

Un moteur de jeu est un ensemble de composants logiciels qui effectuent des calculs de géométrie et de physique utilisés dans les jeux vidéo. L'ensemble forme un simulateur en temps réel souple qui reproduit les caractéristiques des mondes imaginaires dans lesquels se déroulent les jeux. Le but visé par un moteur de jeu est de permettre à une équipe de développement de se concentrer sur le contenu et le déroulement du jeu plutôt que la résolution de problèmes informatiques.

Diagramme montrant les nombreux composants systèmes avec lesquels un moteur de jeu est amené à interfacer sur Linux.

Le moteur 3D crée des images par des calculs de projection, tandis que le moteur 2D construit l'image du jeu par empilement d'images matricielles. Le moteur effectue le mixage des bruits et de la musique tout au long du jeu. Les possibilités de scriptage des moteurs de jeu permettent de simuler le comportement des personnages non-jouables avec peu ou pas de programmation et le moteur physique sert à appliquer des règles de physique telles que l'inertie ou la pesanteur dans le but d'obtenir des mouvements plus réalistes.

Origines

La notion de game engine (en français moteur de jeu) est apparue dans les années 1990, en référence aux logiciels utilisés dans les jeux de tir à la première personne tels que Doom. L'architecture de Doom faisait une distinction claire entre les composants moteur du jeu et les ressources numériques propres à Doom telles que les graphismes, les sons, la musique, les scènes et les règles de déroulement qui reproduisent l'ambiance du jeu. Les composants du moteur ont ainsi pu être réutilisés, moyennant des modifications mineures, dans des jeux comportant d'autres armes, d'autres ennemis et d'autres règles de jeu, ce qui a permis de mettre sur le marché de nouveaux jeux plus rapidement qu'auparavant.

Vue générale

Dans les jeux vidéo modernes, il existe des ensembles principaux parfois gérés par des moteurs distincts, chacun concernant une fonction spécifique du développement : le système (entrée/sortie, interface utilisateur, mémoire, etc.), le graphisme, le son, le réseau (pour les jeux multijoueurs), la physique et l'intelligence artificielle. Un moteur de jeu est un ensemble des moteurs spécialisés nécessaires à la réalisation d'un jeu. Par exemple la société Valve Software commercialise le Source engine qui est le nom commercial de son moteur de jeu. Le Source engine est une solution de développement « clé en main » regroupant les différents moteurs (graphisme, son...) nécessaires au développement d'un jeu. La gestion de la physique de ce moteur de jeu est assurée par le moteur Havok, spécialisé et développé par une société tierce et qui est lui-même utilisé dans d'autres moteurs de jeu.

Le choix d'un studio de création de jeu se limite donc généralement à acheter ou développer tout ou partie des moteurs nécessaires au développement de son jeu. Il est en revanche important de signaler que depuis plusieurs années le rôle des moteurs de jeu ne cesse de grandir. L'investissement que représente en effet le développement des moteurs de jeu ne cesse de croitre et rend délicat voire impossible l’amortissement de ceux-ci sur une unique production.

Liste de moteurs de jeux

Parmi les moteurs de jeu les plus utilisés ou remarqués ces dernières années, on citera (liste non exhaustive) : le Renderware, les différents Unreal engine, Unity, Quake engine, le Source engine, le CryEngine, le Torque Game Engine, RealityEngine, Novodex, Antiryad Gx, etc.

Parmi les moteurs de jeu en logiciel libre, on peut citer :

Nom	Langage principal	Bibliothèque graphique	Bibliothèque audio	Notes
Blender Game Engine	Python	OpenGL	OpenAL	construit autour de Blender
Cube Engine	?	OpenGL	?	Moteur pseudo 3D
Godot	GDScript, variante de Python	OpenGL et OpenGL ES)	?	orienté 2D et 3D
LÖVE	Lua	OpenGL	?	Orienté 2D avec extensions 3D.
Luxe ou LuxeEngine	Haxe	WebGL	?
Armory ou Armory Engine	Haxe	OpenGL,WebGL et Vulkan	?	construit autour de Blender

Framework

Certaines entreprises sont maintenant spécialisées dans le développement de logiciels dits framework, c'est-à-dire fournissant des fonctions qui restent personnalisables. L'utilisation de tels produits vise à éviter de « réinventer la roue carrée » et réutiliser une suite logicielle déjà éprouvée qui inclut plusieurs éléments nécessaires à la création d'un jeu. De nombreux logiciels de ce type dans le domaine du jeu vidéo fournissent des facilités de développement pour les graphismes, les sons, la physique, et l'implémentation d'intelligences artificielles. Gamebryo et RenderWare sont deux représentants largement répandus.

Certains frameworks fournissent exclusivement une seule facilité, par exemple la synthèse d'arbres et de plantes, c'est le cas de SpeedTree, cette spécialisation lui permet de générer des images plus convaincantes que des moteurs plus généralistes.

Certains frameworks sont fournis avec tout le code source, d'autres avec la documentation de leur interface de programmation pour permettre leur réutilisation dans d'autres logiciels.

Fonctionnalités

Chaque moteur de jeu est unique. Toutefois, certaines fonctionnalités se retrouvent.

Entrées/sorties

Cette partie s'occupe de la lecture des périphériques externes :

• Joystick (lecture de l'état des boutons et du ou des sticks) ;
• Souris (lecture de l'état des boutons, du mouvement relatif, de la position) ;
• Clavier.

Elle est aussi chargée de la lecture des données du jeu, et de l'écriture des sauvegardes.

• Lecture/écriture depuis un disque dur.
• Lecture depuis un DVD, un CD ou un mini disk.
• Lecture/écriture depuis une carte mémoire.

C'est elle qui se chargera de compresser/décompresser les données du jeu (notamment pour accélérer les chargements). Elle sera aussi chargée de leur éventuel chiffrement/déchiffrement.

Mathématiques

On y trouvera toutes sortes de fonctions mathématiques nécessaires à l'élaboration d'un jeu. Pour un jeu 3D, on y trouvera plus particulièrement :

• les matrices. En général des matrices 3x4 ou 4x4 pour le stockage de l'orientation des objets (sur les trois axes), de leur échelle (sur les trois axes) et parfois aussi de leur position. La signification réelle des lignes et colonnes est directement liée au moteur et n'a pas toujours de base mathématique réelle. Certains stockeront une échelle uniforme sur la dernière colonne ou ligne, d'autres la translation, d'autres encore utiliseront des matrices de transformations plus complexes pour éviter les problèmes d'échelle dans le cas des matrices hiérarchisées.
• les quaternions. Ils servent au stockage des orientations. Ils sont beaucoup plus compacts que les matrices et supportent beaucoup mieux les interpolations. On les retrouve typiquement dans les animations, pour stocker l'orientation de chaque clef d'interpolation.
• les vecteurs. À deux, trois ou quatre dimensions. On parle de composantes x, y, z et w. La composante w n'est en général pas utilisée, et n'existe qu'à des fins d'optimisation sur les processeurs 128 bits.

On peut citer comme exemple de calcul très souvent effectué dans un moteur de jeu : la multiplication de matrices, l'inversion de matrices, le produit scalaire ou vectoriel.

Physique

Le module de physique calculera le mouvement des objets, la manière dont ils interagissent les uns avec les autres, la manière dont ils glissent sur le sol ou sur les murs, la manière dont ils rebondissent, etc. C'est lui aussi qui calculera la déformation des objets mous, des cheveux, poils, vêtements et autres rideaux. On peut distinguer trois grandes catégories de simulation :

• la physique du point. C'est la plus simple. Un objet est formalisé par un seul point en mouvement avec une vitesse, une accélération, une friction, de la gravité, etc. En général, ce genre de physique se contente de déplacer les objets sans agir sur leur orientation ;
• la physique du solide. Chaque entité est formalisée par une ou plusieurs primitives géométriques (boîte, sphère, gélule, cylindre) ou même par une enveloppe (maillage quelconque) éventuellement convexe. La physique du solide est beaucoup plus réaliste (et donc complexe) que la physique du point puisqu'elle gère aussi l'évolution de l'orientation. Certains éditeurs se sont spécialisés dans la fabrication de modules de physique du solide pouvant être directement intégrés dans les moteurs existants. On citera par exemple Havok, Novodex, et dans le domaine du libre ODE ou Bullet ;
• la physique de particules. Elle s'apparente à la physique du point. Un volume est constitué d'un ensemble de particules (on parle aussi d'atomes) liées entre eux par des contraintes (le plus souvent des ressorts). Ce type de physique autorise la déformation et la rupture de volume. Elle est donc particulièrement bien adaptée à la simulation des tissus.

Détection des collisions

La gestion des collisions est une couche logicielle qui permet de détecter lorsque deux objets se rencontrent et ainsi de pouvoir définir une action résultante. Un objet est alors une représentation géométrique d'éléments du jeu (personnages, obstacle, projectiles…). Un module de collision est typiquement constitué d'un ensemble de fonctions mathématiques pour le calcul des intersections par paires de primitives géométriques : sphère contre sphère, sphère contre boîte, boîte contre triangle… Chacune de ces fonctions calculera selon les capacités du module le point d'intersection, la normale au point de contact, ainsi que la distance de pénétration des deux objets.

On distingue deux grandes catégories de collisions :

• La détection sur modèle d'objets statiques, la plus simple, considère que deux objets sont en collision si au moment du traitement de la détection les deux objets se touchent. Comme le traitement est échantillonné régulièrement dans le temps, des objets en mouvement rapide ont très bien pu entrer en contact avec d'autres objets entre deux temps d'échantillonnage.
• La détection sur modèle d'objets dynamiques s'attache aussi au mouvement des objets. On traite la transition d'un instant échantillonné au suivant. Les calculs sont plus coûteux, mais ont l'avantage d'empêcher un volume en mouvement d'en traverser un autre sans que cela soit détecté. L'instant de la collision de deux objets peut être calculé plus précisément qu'avec la technique dite statique.

Selon le type de jeu l'une ou l'autre des approches est utilisée. Les moteurs de jeu en 3D actuels utilisent typiquement un mélange de ces deux méthodes. Pour optimiser les calculs de collision sur les formes complexes, les moteurs de jeu peuvent utiliser la notion de volume englobant et plus généralement de hiérarchie des volumes englobants. Le calcul rapide mais approximatif permet alors d'éliminer des états de non collision, dans le cas contraire un calcul exact est réalisé sur l'objet. La hiérarchie de volumes englobants rajoute seulement des étapes supplémentaires en subdivisant un objet en sous ensembles englobés dans une forme simple. Pour réduire le nombre de calcul de paire d'objets les moteurs recourent généralement à structurer l'espace en sous ensembles d'objets proches.

Graphisme en 3D

Dans les jeux en 3 dimensions, les scènes et les objets du jeu (monstres, véhicules, projectiles) sont enregistrés sous la forme des coordonnées en 3 dimensions de polygones — souvent des triangles. Chaque suite de polygones forme les contours des différents objets du monde du jeu. Le moteur 3D effectue des calculs de synthèse d'image en vue d'obtenir une projection en 2 dimensions du monde du jeu, projection qui sera envoyée à l'écran.

Dans le procédé dit du rendu polygonal (ou rasterisation), le moteur 3D effectue le calcul de la projection à partir d'un point de vue donné, en commençant par les polygones les plus éloignés de ce point de vue. La texture (couleur, motifs…) des surfaces est une image matricielle déformée en fonction de la distance et l'orientation du polygone par rapport au point de vue avant d'être appliquée sur la projection.

Dans le procédé dit voxel (contraction de volume et pixel), les objets du jeu sont enregistrés sous forme d'une suite de cubes (les voxels) et le calcul de la projection utilise le procédé du rendu polygonal.

Dans le procédé dit du lancer de rayon (ou ray tracing), le moteur 3D effectue le calcul de la couleur de chaque pixel de la projection (qui est une image matricielle) en calculant en sens inverse le chemin parcouru par la lumière pour chaque pixel de l'image, conformément aux règles de l'optique géométrique telles que la transparence, la réflexion ou la réfraction. Ce procédé donne des images très réalistes, mais il demande une grande puissance de calcul et, en 2011, il est encore peu utilisé pour les jeux vidéo.

Les calculs de projection peuvent être effectués par le processeur graphique (abr. GPU) pendant que le processeur central est utilisé pour d'autres calculs tels que ceux du moteur son ou du scriptage.

Son

Le moteur son combine un logiciel de lecteur audio avec un logiciel de mixage et un générateur d'effets sonores (écho, compression, spatialisation). Les trois composants sont interconnectés.

Le moteur son effectue en continu des calculs de synthèse sonore et de traitement numérique du signal, sur la base d'échantillons (sample) numérisés, de partitions musicales (souvent au format MIDI) et de tables d'ondes. Certains moteurs son simulent la réverbération, le déphasage, et le changement de timbre d'un son émis par une source éloignée, et produisent ainsi des illusions auditives.

Scriptage

Les langages de script sont souvent utilisés dans les jeux vidéo pour programmer le comportement des ennemis ou des machines et ainsi simuler leur intelligence. Le recours à un langage de script permet à un designer ou un scénariste, qui a peu ou pas de connaissance en programmation, de « configurer » le comportement des ennemis et ainsi modifier le gameplay sans faire appel à un programmeur. Historiquement, le besoin d'un système de script s'est fait sentir pour les jeux d'aventure nécessitant beaucoup d'interactions. Il en a découlé Script Creation Utility for Maniac Mansion (SCUMM). Créé initialement, et comme son nom l'indique pour le jeu Maniac Mansion (1987), et réutilisé pour chaque nouveau jeu avec un minimum de modifications, il a resservi dix ans plus tard pour le jeu The Curse of Monkey Island (1997). Les autres genres de jeu sont aussi devenus à leur tour complexes, leurs moteurs de jeu ont alors souvent incorporé un système de script.

Pour le développement de Jedi Knight: Dark Forces II (1997), le moteur de jeu a été adapté pour supporter un langage de script. Robert Huebner, qui a participé à cette évolution, explique qu'il existait avant cela un langage binaire INF qu'il était dur d'assimiler — un livret complet était destiné à cet usage. Le langage de script implémenté, COG, est compilé à la volée lors du lancement d'une partie puis exécuté sur une machine virtuelle (un automate à pile) pour assurer la robustesse du jeu. Il n'y a eu aucune conséquence négative rapportée que ce soit sur le développement ou sur le jeu lui-même, mais plutôt un accroissement de la créativité des concepteurs. Certaines entreprises ont développé leurs propres langages de script, comme il est écrit plus haut. C'est aussi le cas d'id Software avec le langage QuakeC ou d'Epic Games avec le langage UnrealScript. Mais l'intégration d'un langage de script est devenue très accessible, certaines bibliothèques logicielles étant développées indépendamment spécialement dans ce but. C'est le cas de la bibliothèque et du langage Lua qui a été utilisé dans un grand nombre de jeux de genres très divers.

Annexes

Articles connexes

• Liste de moteurs de jeu - Une liste de moteurs de jeu existants.
• Recréation de moteur de jeu - Une liste de moteurs de jeu ayant été ré-écrits pour diverses raisons.

Liens externes

• Developpez.com, ressources pour le développement de moteurs de jeu vidéo.
• REWiki - Un dépôt d'information sur les formats de données des jeux vidéo.