Moteurs de jeux : synthèse et plan du rapport final

Synthèse

Dans le cadre de ce projet de veille technologique, nous avons tenté de dresser un état de l’art des moteurs de jeux-vidéos. Nos considérations ont principalement été d’ordre technique afin de bien comprendre et expliciter l’intérêt des fonctionnalités proposées par les moteurs de jeux modernes. Les fonctionnalités auxquelles nous nous sommes intéressés sont :

  • Le pipeline 3D (affichage)
  • Les moteurs physiques
  • Les langages de script
  • La recherche de chemins
  • Les systèmes de particules

Cette sélection n’est pas exhaustive (on aurait pu parler d’intelligence artificielle, de spatialisation du son, d’animations de personnages ou encore de réseau) mais elle est assez variée pour proposer un aperçu du fonctionnement global d’un moteur de jeu (ou tout simplement d’un jeu). Ce fut aussi l’occasion de revenir parfois quelques décennies en arrière pour comprendre comment certaines fonctionnalités, comme la recherche de chemins ou les langages de script, avaient atteint leur état actuel.

Au final, il semble cependant que le domaine où les moteurs évoluent le plus et qui se prête le mieux à une veille technologique ce n’est pas (plus) leur fonctionnement mais leur diffusion (et leurs modèles économiques). C’est en tout cas ce que nous avons découvert avec nos articles sur l’aspect multiplateforme de moteurs et celui sur les moteurs à faible coût.

Plan du rapport final

  1. Introduction
    • Contexte
    • Problématique
  2. Fonctionnalités d’un moteur de jeu
    • Affichage
    • Physique
    • Scripting
  3. Le marché des moteurs de jeux
    • Multiplateforme
    • AAA vs Indie

Licence Creative Commons

Particules

Après nous êtres intéréssés dans notre précédent article aux fonctionnalités de pathfinding proposées par les moteurs de jeux, nous allons aujourd’hui discuter d’une autre fonctionnalité importante : les systèmes de particules.

Pour quoi faire ?

Si vous avez lu notre article « Un moteur de jeux, ça fait quoi ? », vous savez déjà que dans les jeux les personnages et les décors sont représentés par des maillages de triangles appelés mesh sur lesquels on plaque des textures. Voici par exemple le mesh d’un petit lapin.

Un mesh de lapin

Un mesh de lapin (source : http://www.ceremade.dauphine.fr/~peyre/geodesic_computations/)

Le procédé est très versatile mais il admet tout de même ses limites : on ne peut pas décemment demander à un artiste de modéliser une flamme ou de la fumée avec uniquement des petits triangles. Dans la capture d’écran de Dark Souls ci-dessous, on imagine à peu près le maillage du personnage ou du décor mais pas celui de la flamme. Bravo, vous venez de repérer un effet de particules !

Dark Souls

Un effet de particules dans Dark Souls (source : http://www.giantbomb.com/dark-souls/61-32697/user-reviews/?review_id=21106)

D’une manière générale, les effets de particules servent à faire tout ce qu’il est difficile de modéliser avec un mesh traditionel : le feu, la fumée, l’eau (pas toujours), les effets spéciaux (magie, etc.) ou encore les explosions.

Comment ça marche ?

Un système de particules n’est pas une simulation physique du phénomène qu’il représente, le principe est le même pour tous les types d’effets (alors qu’une cascade et une flamme n’ont pas grand chose à voir physiquement). Notre explication du fonctionnement d’un système de particule va s’appuyer sur l’exemple concret de la réalisation d’un effet de particules qui ressemble à une flamme. L’outil utilisé pour cet exemple est un système de particules fait maison (en langage HaXe).

Voici la “particule” de base qui sera l’unique texture utilisée (ici sur fond noir). C’est un simple dégradé radial blanc.

Une particule

Une particule

Le principe de base consiste à definir une zone qui va émettre des particules, plusieurs centaines par seconde, et leur attribuer des paramètres de base (taille, couleur, transparence, etc.). Ces particules ont une durée de vie limitée (de l’ordre de quelques secondes) et sont soumises à toute sortes d’effets : changements de taille, de couleur ou encore déplacements. Ici on va émettre des particules de couleur orange. Pour plus de diversité on laisse une part de hasard dans l’attribution de la couleur, toutes nos particules n’auront pas exactement le même orange.

Une particule colorée

Une particule colorée

Notre zone d’emission étant un petit disque, nos particules vont démarrer leur vie proche les unes des autres et se superposer un peu pour générer une forme aléatoire. C’est l’occasion d’expliciter un principe important pour le résultat final : les modes de fusion. Habituellement, la superposition d’un pixel de couleur [R1,G1,B1,A1] (pour red, green, blue, alpha — alpha étant l’opacité) par dessus un pixel de couleur [R2,G2,B2,A2] est représentée par un pixel de couleur [R1*A1 + R2*A2*(1-A1), G1*A1 + G2*A2*(1-A1), B1*A1 + B2*A2*(1-A1), A2 + A1*(1-A1)]. Cela produit un résultat illustré par l’image ci-dessous :

Utilisation d'un canal alpha

Mode de fusion « normal » (source : http://fr.wikipedia.org/wiki/Alpha_blending)

Ici nous allons utiliser un mode de fusion additif et l’on va additionner les composantes (rouge, vert, bleu et alpha) des pixels qui se superposent. Voici ce que l’on obtient :

Modes de fusion

Modes de fusion

Ensuite, on paramètre l’émetteur pour que les particules diminuent de taille au cours de leur vie et on applique un champ de force à notre ensemble de particules pour les faire se déplacer vers le haut. Le résultat est une flamme à peu près convaincante que vous pouvez voir en mouvement ici :

Résultat final

Résultat final

Et dans un moteur ?

Dans le cas d’un moteur de jeu en 3D comme le Source Engine ou l’Unreal Engine on suit exactement le même procédé en dessinant le résultat sur un rectangle (deux triangles) qui est toujours face à la caméra. Une telle surface de dessin s’appelle un billboard et elle est surtout connue des joueurs car elle servait à faire la végétation dans les vieux jeux, comme ici Colin McRae Rally 2 sur Playstation.

De la végétation sur des billboards

De la végétation sur des billboards dans Colin McRae Rally 2 (source : http://www.romulation.net/PSX/Colin_McRae_Rally_2.0_%5BU%5D%5BNTSC-U%5D_%5BSLUS-01222%5D.rar.html/)

Les particules sont omniprésentes dans les jeux réalisés avec les moteurs modernes. Elles sont peu coûteuses à afficher et très agréables à l’oeil (bien que la plupart des joueurs ne soit même pas conscient de leur présence). Elles ont toutefois leurs limites. Puisqu’elles ne sont affichées que sur une surface en deux dimensions, elle n’ont pas de volume propre et on peut difficilement faire passer un personnage à travers de la fumée (faite en particules) de manière réaliste. Une solution à ce type de problèmes existe et s’appelle très justement le brouillard volumétrique. Si le sujet vous intéresse je vous engage à lire (ou au moins regarder les images très explicites) cet excellent article sur le sujet.

Enfin, voici une vidéo pour vous rincer l’oeil avec quelques effets de particule impressionants (et précalculés).

Licence Creative Commons

Pathfinding

« Votre épée à la main, vous franchissez fièrement le seuil de l’antre du dragon paré à affronter la bête pour piller son trésor et délivrer la princesse. Le silence se fait autour de vous et la sueur vous perle sur le front. Soudain le monstre apparaît ! Gigantesque, effrayant et véloce comme le décrivent les légendes, le dragon ne vous accorde aucune attention…et se précipite aussitôt vers le mur le plus proche qu’il tente déséspérement de traverser. »

Voici une expérience que bien des joueurs ont déjà du faire, celle d’affronter une IA qui semble avoir des difficultés à naviguer dans l’espace (comme l’illustre à merveille cette vidéo). Le pathfinding (ou « recherche de chemins » en bon français) est un problème mathématique bien plus vieux que le jeu vidéo qu’il est nécessaire de résoudre pour programmer une intelligence artificielle digne de ce nom. De nos jours, les moteurs de jeux proposent (presque) tous une solution intégrée pour faciliter la vie des développeurs et leur éviter de réinventer la roue.

Un peu d’histoire

Prenons le problème à la source :

Lievro VS cailloux

Le grand problème du pathfinding

Voici une (fausse) capture d’écran de Secret of Mana qui va servir d’illustration à notre problème. Il est du devoir des développeurs de doter le lievro (la créature jaune en bas à droite) d’une intelligence suffisante pour aller mordre sauvagement le personnage du joueur (en haut à gauche). Seulement voilà, pour que le jeu soit ne serait-ce que vaguement cohérent, il ne faut pas que le lievro marche sur les obstacles (ici des cailloux) sur lesquels le joueur ne peut pas se déplacer. C’est de cet état de fait que nait le problème du pathfinding.

A l’époque de Secret of Mana, les consoles avaient une capacité de calcul très réduite et largement insuffisante pour traiter naïvement la quantité astronomique de chemins qui vont du lievro au personnage (en considérant des déplacements de 1 pixel de long). Une simplification évidente du problème consiste à re-échantilloner l’espace comme le montre l’image ci-dessous. C’est d’autant plus facile que cette discrétisation en tiles (des carrés de taille régulière) est déjà présente et nécessaire au stockage des décors.

Discrétisation

Discrétisation

Le problème peut alors être traité avec un algorithme classique comme celui de Dijkstra. Le principe de cet algorithme est de considérer les tiles voisins du point de départ puis les voisins de ces voisins etc. Au fur et à mesure, on veille à ne pas considérer deux fois le même tile et à retenir pour chaque tile le chemin le plus court qui a permis d’y arriver. L’algorithme termine lorsque l’on en vient à considérer le tile où l’on souhaitait atterir (succès) ou lorsque l’on a plus de tiles à considérer (echec, la destination est inatteignable). Une illustration animée et une description un peu plus complètes de cet algorithme sont visibles sur Wikipedia. Dans le cas de notre lievro sauvage, on aboutit au résultat suivant :

Résultat

En blanc, le chemin obtenu

L’algorithme le plus populaire dans les jeux vidéo (en 2D comme celui-ci) est une variante de l’algorithme de Dijkstra appelée A* (à prononcer A star pour briller en société). La nuance réside dans l’étiquette attribuée aux tiles qui n’est plus seulement fonction de la distance parcourue pour les atteindre mais également de la distance (estimée) restant à parcourir. L’estimation de la distance restante (appelée heuristiques) la plus courante est la distance Manhattan entre le point courant et l’arrivée. C’est tout simplement la distance en X additionnée à la distance Y entre les deux points (comme quand vous vous déplacez dans Manhattan, il n’y a pas de diagonales).
Cette variante a l’avantage d’avoir la même complexité algorithmique (calculer des distances Manhattan, c’est à peu près gratuit en terme de complexité) et de réduire le nombre de tiles considérés dans les cas un peu labyrinthiques qui sont légion dans les jeux vidéo.

Revenons en 2012

C’est bien gentil tout ça mais en 2012, un décor de jeu vidéo ça ressemble plutôt à ceci :

Hawken

Hawken

Libéré de leurs contraintes techniques, les décors ont beaucoup changé. Ils sont devenus beaucoup plus grands, les obstacles n’ont plus tous la même taille et ils sont en 3D. Discrétiser un tel décor avec une grille en 3D n’a aucune chance de fonctionner car il faudrait un pas de discrétisation beaucoup trop petit et un nombre astronomique de tiles. Mauvaise idée.

Les algorithmes issus de la théorie des graphes (parce que, au cas où vous ne l’auriez pas remarqué, c’est de ça qu’on parle) comme Djikstra et le A* étant encore ce qu’on a de mieux sous la main, la solution est de changer la façon dont on transforme notre problème en un graphe mathématique. Il existe deux principales approches qui sont utilisées dans les jeux en 3D (et dans certains jeux modernes en 2D) : les systèmes à base de waypoints et ceux à base de navigation mesh.

Un système à base de waypoints représente le graphe de navigation par un semble de noeuds reliés par des arêtes rectilignes sur lesquels les personnages peuvent se déplacer. Il est assez relativement facile de positionner automatiquement ces points de navigation avec des algorithmes comme la triangulation de Delaunay ou de confier cette tâche à un level designer. Voici un exemple en image :

Un graphe de waypoints (source : Michael Grenier)

Un graphe de waypoints (source : Michael Grenier)

Les modèles à base de navigation mesh sont un peu plus compliqués à manipuler et à définir automatiquement mais ils ont plusieurs avantages en terme de résultat à l’écran. L’idée est de définir un graphe de navigation dont les noeuds sont des polygones convexes (des zones sans obstacles) et les arêtes sont des côtés communs à plusieurs de ces polygones. Voici une image tirée du même article qui illustre le principe :

Un navigation mesh (source : Michael Grenier)

Un navigation mesh (source : Michael Grenier)

Le principal avantage des navigation mesh est que l’on peut faire naviguer les personnages dans des polygones entiers et pas seulement le long de segments prédefinis. Une fois muni d’un tel graphe, on peut de nouveau appliquer des algorithmes de Dijkstra ou A* pour trouver des plus courts chemins. Ouf!

Notre histoire ne s’arrête cependant pas ici et les jeux modernes bénéficient de quelques fioritures qui rendent le tout plus agréable à l’oeil. Dans les jeux qui mettent en scène beaucoup de personnages, les programmeurs ajoutent des comportement de flocking qui permettent de gérer intelligement des groupes d’unités. L’approche la plus courante consiste à calculer un chemin pour le groupe en tant qu’entité unique et à déplacer chaque unité en fonction du chemin suivi par le groupe et d’une force de répulsion qui l’éloigne des autres unités du groupe (pour les empêcher de se chevaucher). Le résultat est très visible dans Starcraft II, au bout d’une minute dans cette vidéo. Un autre ajout courant aux technologies de pathfinding est le lissage des chemins calculés au moyen de courbes de Bézier.

Les moteurs de jeux les plus populaires du marché (Unreal Engine 3, Source Engine, etc.) intègrent tous leur propre technologie de pathfinding. Certaines entreprises sont entièrement dédiées au développement de middleware sur le sujet, comme par exemple PathEngine (dont la licence coûte tout de même entre 4500€ et 25000€). C’est à se demander pourquoi les dragons se plantent toujours dans les décors mais j’ai bien ma petite idée sur la question !

Sources et saines lectures :
Develop Online
AI blog
Gamasutra
Michael Grenier
Amit’s Game Programming Information

Licence Creative Commons

Les moteurs de jeux pour les pauvres

A l’origine, cet article devait parler d’argent et répondre aux deux questions suivantes : combien coûte le développement d’un moteur de jeu ? Combien coûte la licence d’utilisation d’un moteur de jeu ?

Seulement voilà, les coûts de développement ne peuvent être obtenus que par des estimations hasardeuses auxquelles nous ne nous risquerons pas, et le prix des licences des moteurs les plus réputés (Unreal Engine 3, Source Engine, etc.) est en général variable et soumis à un “Non-Disclosure Agreement” sans pitié. Voici par exemple ce qu’on peut lire sur le site du Source Engine :

> Pricing
Valve technology offers the most advanced features, tools, and support at extremely competitive prices.
Discussed under NDA.

Voilà c’est tout. Circulez y’a rien à voir.

Heureusement, il existe aussi des moteurs de jeux pour les pauv…euh pour les développeurs indépendants. Nous allons donc laisser un peu de côté nos habituels moteurs AAA bien connus des joueurs modernes et comparer quelques solutions en vogue gratuites ou peu coûteuses.

Unity

Unity est un moteur de jeux 3D très complet (moteur de rendu, moteur physique, réseau, scripting en Javascript/C#/Boo, etc.) accompagné d’un éditeur de scènes lui aussi très riche en fonctionnalités.
La version gratuite du moteur est privée de quelques fonctionnalités (parfois importantes, comme la possibilité d’effectuer des post-traitements sur le rendu à l’écran) et produit des jeux jouables sur PC/Mac ou dans un navigateur. La version pro (qui coûte 1500$) enlève ces limitations et permet pour quelques centaines de dollars de plus de faire des jeux jouables sur iOS et Android. Pour un prix à négocier, le déploiement vers la PS3, la Wii et la Xbox 360 est également possible.

La version gratuite satisfait de nombreux développeurs indépendants en phase tandis que la version pro est utilisée par bon nombre de petits studios de par le monde. A titre d’exemple, l’excellent Rochard (évalué à 79% sur Metacritics) sorti fin 2011 et développé en Finlande par Recoil Games est développé avec Unity. Son rendu graphique et son esthétique ne sont pas sans rappeler Team Fortress 2, développé par Valve avec le Source Engine dont les tarifs sont vraisemblablement d’un autre ordre de grandeur.

Image de rochard

Image de Rochard, un jeu où l'on joue avec la gravité

Multimedia Fusion 2

Malgré son nom très 1997, MMF2 (Multimedia Fusion 2) est un logiciel français sorti en 2006 qui permet de créer des jeux en 2D en utilisant un éditeur qui fonctionne avec un langage de programmation graphique très accessible. Les jeux réalisés avec peuvent être déployés sous la forme d’exécutables Windows, d’applications Flash, Java et Java Mobile. Un déploiement vers iOS est également possible moyennant 100€, en plus de la licence de base qui coûte de 100€ à 300€ selon la version choisie (la moins chère étant un peu bridée).

Un exemple de jeu relativement connu réalisé avec MMF2 est Noitu Love 2, développé par Joakim Sandberg.

Polycode

Polycode est un moteur de jeu open-source qui sert aussi bien à faire des jeux en 2D qu’en 3D, en C++ ou en Lua (ou les deux à la fois). Le projet est relativement jeune mais déjà très complet grâce à la communauté très active de développeurs qu’il a su attirer en quelques mois. Les fonctionnalités sont nombreuses (réseau, physique, son, Kinect (!), etc.) mais la documentation est peu abondante en dehors du site officiel qui est heureusement bien fourni. Les plateformes supportées sont PC/Mac/Linux et (prochainement) iOS.

Il n’existe à notre connaissance encore aucun jeu commercial sorti utilisant Polycode mais vu le succès rencontré par le moteur, cela ne saurait tarder dans les semaines ou les mois à venir.

Flixel

Flixel est un moteur de jeux en 2D open-source écrit en Actionscript 3 sorti en 2008. Les jeux produits ne fonctionnent que dans le Flash Player mais cela n’empêche pas le moteur d’être extrêmement populaire auprès des développeurs indépendants. Les points forts de ce moteur sont son très grand nombre de fonctionnalités qui rendent le développement très rapide, sa documentation abondante et de qualité et enfin sa rapidité (ce qui est difficile à obtenir dans le Flash Player) pour un programmeur inexpérimenté.

Quelques jeux populaires réalisés avec Flixel sont Canabalt (http://www.adamatomic.com/canabalt/) et Diamond Hollow 2 (http://www.kongregate.com/games/Arkeus/diamond-hollow-ii).

Image de Canabalt

Canabalt développé avec Flixel propose de s'échapper avec un unique bouton de saut (source : destructoid.com)

Il existe une pléthore d’autres moteurs gratuits ou vendus à des prix abordables pour les développeurs indépendants. Ces quatre-ci ont été choisis parce qu’ils étaient très différents les uns des autres et parce qu’ils étaient des références chacun dans leur domaine (moteur 3D pour développeur indépendant, moteur facile d’utilisation, moteur open-source, moteur de jeu pour le web). On aurait également pu s’intéresser à Construct 2 qui va probablement supplanter Multimedia Fusion 2, à Torque qui est un dinosaure auquel Polycode fait de l’ombre ou encore à Marmalade dont la licence annuelle est un parti pris économique pour le moins original — nous vous laissons le soin de les découvrir si vous souhaitez approfondir le sujet.

Sources :
Unity : http://unity3d.com/
Multimedia Fusion 2 : http://www.clickteam.com/
Polycode : http://polycode.org/
Flixel : http://flixel.org/

Licence Creative Commons

Les moteurs de jeu et leur composante multiplateforme

Dans notre précédent article, nous vous présentions un peu plus en détails les moteurs de jeu avec leurs fonctionnalités les plus courantes : moteurs de rendu, moteurs physiques et langages de script. Aujourd’hui, nous allons nous intéresser à leur éventuelle composante multiplateforme.

Le multiplateforme, c’est quoi ?

Il s’agit tout simplement de permettre l’utilisation d’un même code sur des plateformes différentes. Par plateforme on entend aussi bien les plateformes hardware (matériel) que software (logiciel) : Windows, Linux, MacOS, iOS, Android, PS3, Xbox 360, Wii, DS, PSP, etc. En gros, c’est le principe qui permet à Treyarch ou Infinity Ward (les deux studios en charge des Call of Duty) de sortir alternativement un Call of Duty au rythme industriel de un par an sur toutes les plateformes les plus rentables en même temps (PS3, Xbox 360 et PC).

L’intérêt, vous l’aurez sûrement deviné avec un exemple aussi parlant : gagner encore du temps de développement. Et le temps, c’est de l’argent (le monde du jeu vidéo n’échappe pas à cette cruelle règle, il est même particulièrement touché) ! Ainsi aujourd’hui on voit de moins en moins d’exclusivités (des jeux qui ne sortent que sur une plateforme) puisque la contrainte technique multiplateforme d’antan n’est plus aussi compliquée à gérer.

Le multiplateforme c’est compliqué

Cette contrainte technique n’est plus aussi forte mais néanmoins elle pose encore beaucoup de problèmes et impose dans certains cas un travail assez monumental : adapter les routines généralisées du moteur de jeu aux différentes architectures avec lesquelles elles vont être utilisées. Car là où l’architecture traditionnelle d’un PC se dompte de manière identique d’une machine à une autre, c’est une toute autre affaire quand on parle d’une Xbox360 et d’une PS3 (console qui a valu bien des maux de tête à de nombreux développeurs). La popularité d’une plateforme auprès des développeurs ne se mesure pas seulement à ses capacités mais aussi à la simplicité d’utilisation de ces dites capacités. Un exemple marquant est celui de Bayonetta, un jeu sorti sur Xbox 360 et PS3. Celui-ci était moins fluide sur PS3 à qualité équivalente, alors que sur le papier la PS3 jouit de performances plus élevées. Un autre exemple est celui de la Playstation 2, dont l’API n’était à ses débuts que très peu documentée en langue anglaise.

Bayonetta

Bayonetta, un jeu qui pédale un peu sur PS3 (source : IGN)

Les grands constructeurs tels que Sony, Microsoft ou Nintendo développent dans leurs labos des architectures gardées secrètes jusqu’au bout, qui sont donc très différentes d’une console à l’autre, bien qu’ils aillent se fournir à la même crémerie (les processeurs sont très souvent fournis par IBM) !

Solutions techniques

Les machines virtuelles sont une première catégorie de solutions, très simples à employer. Une machine virtuelle comme son nom l’indique est une machine simulée sur une autre (ressources mémoire, processeur, disque dur, etc.). L’avantage de celles ci c’est qu’elles ont le bon goût d’être elles-mêmes multiplateformes. L’exemple que tout le monde connait est la Java Virtual Machine, capable de fonctionner sous Windows, Linux, MacOS, iOS et Android. On peut donc écrire son moteur de jeu en Java sans vraiment se soucier de la machine de destination, si ce n’est ses capacités. Ainsi en Java on trouvera des moteurs tels que Ardor3D ou Lightweight Java Game Library, et en Flash on trouvera Flixel ou encore Flashpunk.

Une image de Minecraft

Minecraft est codé en Java, ce qui lui permet d'êter porté sur de nombreuses plateformes supportant la JVM. (source : Wikipédia)

La seconde catégorie de solutions est constituée par les langages multiplateformes tels que le C++ ou encore Python. L’avantage ici est de gagner en performance puisqu’il n’y a pas de couche intermédiaire constituée par la machine virtuelle. L’inconvénient est en revanche de taille puisqu’il faut écrire des morceaux de code qui sont spécifiques à l’architecture de la machine utilisée. On peut aussi utiliser des bindings de langage, qui permettent d’utiliser un moteur via un langage éventuellement moins compliqué que celui dans lequel il est codé (exemple : Lua). Parmi les exemples de moteurs, on citera Pygame pour le Python, ou encore l’impressionnant Unreal Engine 3 capable de fonctionner sur Android, iOS, Linux, Mac OS, PS3, PSVita, Wii U, Windows, Xbox 360 et Flash (certaines plateformes citées ici ne sont même pas encore sorties dans le commerce).

Licence Creative Commons

Un moteur de jeux vidéo ça fait quoi ?

Dans notre précédent article, nous avons présenté les moteurs de jeux vidéos comme des « boîtes à outils » qui facilitent le développement de jeux. Aujourd’hui, nous allons étudier un peu plus en détail les fonctionnalités les plus courantes de ces moteurs.

Scènes et rendus

Une fonctionnalité que l’on est en droit d’attendre d’un moteur de jeu est la possibilité d’afficher des choses à l’écran (un grand pas en avant pour le développement d’un jeu). Cela semble trivial mais il ya beaucoup beaucoup d’étapes entre « le graphiste m’a fourni le modèle 3D de Donkey Kong sur une clé USB » et « Donkey Kong apparait dans le jeu ». Voici une version édulcorée du processus :

  • Il faut lire le fichier qui contient Donkey Kong découpé en un maillage de petits triangles
  • Il faut insérer Donkey Kong dans un graphe de scène (une structure de données qui représente la scène graphique dont il fait partie — les chutes d’eau, les poissons, les autres singes, etc)
  • Il faut lire un fichier de texture que l’on souhaite plaquer sur Donkey Kong et les informations de correspondance entre le maillage et la texture (pour que des éléments de la texture comme la cravate ou les yeux soient plaqués au bon endroit du maillage)
  • Il faut envoyer le maillage et les textures de Donkey Kong (ainsi que du reste de la scène) à la carte graphique. Cette opération est différente selon la plateforme pour laquelle on développe ; une Nintendo DS n’attend pas exactement les mêmes données qu’une Xbox 360
  • Il faut donner des informations d’éclairage à la carte graphique
  • Il faut donner des directives d’affichage (les shaders) à la carte graphique pour qu’elle fasse un joli rendu (et pour qu’elle fasse pousser des poils sur Donkey Kong)
  • La carte graphique fait son travail et renvoie une image
  • Et paf! Donkey Kong est à l’écran. Enfin !

Le travail d’un moteur de jeu dans tout ça est de fournir un graphe de scène prêt à l’emploi, de savoir lire les fichiers qui contiennent les modèles 3D et les textures, de fournir une collection de shaders et de savoir parler aux cartes graphiques de différentes plateformes. A titre d’exemple, l’Unreal Engine 3 (Gears of War, Unreal Tournament 3) est capable de faire tout ça sur une dizaine de plateformes, de iOS à la Playstation 3 en passant par le Flash player.

Un paysage de Skyrim

Un paysage de Skyrim qui utilise le Creation Engine (Source : images éditeur de Bethesda)

Moteur physique

Le moteur physique permet, comme son nom l’indique, d’ajouter au jeu des lois physiques qui vont s’appliquer aux éléments du graphe de scène. C’est lui qui gère la gravité (Lara Croft tombe dans un précipice), qui détecte les collisions entre les différents objets (Lara Croft se fait écraser par une boule en pierre géante) et les déformations qu’ils subissent (Lara Croft s’écrase par terre et prend une posture improbable de mannequin désarticulé).

La plupart de ces calculs sont basés sur des modèles physiques très simplifiés et rigides car il est plus important pour un jeu en temps réel d’être fluide et réactif plutôt qu’extrêmement réaliste (Lara Croft est bloquée par un caillou de 4 centimètres). Un moteur de jeu permet d’associer aux objets du graphe de scène des modèles simplifiés (parfois des modèles d’élements finis comme dans Star Wars: The Force Unleashed) qui seront utilisés pour les calculs physiques. En effet contrairement à la boule qui l’écrase, Lara Croft n’a pas un physique parfaitement sphérique. Elle est vraisemblablement représentée par un cylindre qui est plus pratique pour faire des calculs que son maillage de plusieurs milliers de triangles.

Les contraintes de précision et de performance sur le moteur physique sont très variées d’un jeu à l’autre et le temps de calcul qui leur est alloué est très variable d’un jeu à l’autre. Dans les jeux de course le moteur physique calcule jusqu’à 2000 étapes par seconde (alors que le moteur de rendu affiche moins de 60 images par secondes), tandis que dans les jeux où il n’est pas essentiel (les RPG, les jeux de stratégie, etc.) il ne calcule qu’un état par image ; c’est pour ça que dans certains jeux un objet ou un personnage très rapide peut traverser un mur.

Une explosion dans Uncharted 2, qui utilise le moteur physique Havok

Une explosion dans Uncharted 2, qui utilise le moteur physique Havok (source : mcvuk.com)

Langage de script

Les moteurs de jeux les plus populaires sont écrits en C++, un langage qu’il faut compiler avant d’exécuter. Non seulement cela peut prendre un temps considérable mais en plus, le C++ n’est pas un langage très adapté pour permettre aux level designers de décrire séquentiellement des évènements (cinématiques, apparition de monstres) qui se déroulent dans un jeu. Pour pallier à ces problèmes, la plupart des moteurs peuvent s’interfacer avec un langage de script (le plus souvent Lua ou Python) qui est lui interprété pendant l’exécution du jeu sans être compilé à l’avance.

Le Python et le Lua (et d’autres langages de script) étant de vrais langages de programmation, ils permettent de définir des structures de données complexes et de définir des routines internes réutilisables et qui simplifient d’autant plus le travail des créateurs de contenu.

Le rôle du moteur de jeu se limite à interfacer le C++ (ou autre) avec le langage de script. Bien souvent, les développeurs doivent écrire de nombreuses fonctions annexes pour que le langage de script ait accès à des fonctions spécifiques du jeu écrites en C++, comme par exemple « ouvrir une boîte de dialogue ». Ce genre d’outils est absolument essentiel pour un jeu lourdement scripté comme Baldur’s Gate 2 qui fonctionne grâce à un très vieux moteur appelé l’Infinity Engine et dont le langage de script (pas joli joli) est basé sur Lua.

Ces trois fonctionnalités des moteurs sont loin d’être les seules existantes mais ce sont les plus universelles et les plus essentielles au bon fonctionnement d’un moteur.

Une image de Gears of War 3

Une scène pleine d'effets de lumière de Gears of War 3, qui utilise l'Unreal Engine 3 (source : magnumerique.com)

Sources :
http://www.lfsforum.net/showthread.php?t=48927 (fréquences de calculs de moteurs physiques de jeux de course)
http://www.ugcs.caltech.edu/~jedwin/baldur.html (informations sur l’Infinity Engine)

Licence Creative Commons

Moteurs de jeux vidéos

Pour beaucoup de joueurs d’aujourd’hui, les jeux vidéos sont avant tout synonymes de Angry Birds (ou Zenonia pour ceux qui ont du goût) dans la salle d’attente du dentiste, de la Megadrive chez les grand-parents ou des soirées Lapins Crétins avec ses amis bourrés. Pourtant, derrière la légèreté apparente de toutes ces situations se cache une industrie dont le chiffre d’affaires avoisine les 50 milliards de dollars en 2010, soit environ le PIB du Luxembourg (ou 5,8 fois le PIB du Burkina Faso).

Pour atteindre une telle productivité, les studios de développement ne peuvent pas tous se permettre (pour des raisons de temps ou de budget) de développer leurs jeux à partir de zéro. C’est pourquoi ils utilisent des moteurs de jeu, sortes de boîtes à outils, librairies et frameworks pré-développés et qui comportent des routines généralisées aux noms ésotériques (nous y reviendrons dans de futurs articles) comme des moteurs de rendu, des moteurs physiques, des langages de scripting, etc.

Il en existe un vaste choix, des gratuits, des payants, des open-source, des simples, des compliqués. Notre étude portera sur un tour d’horizon des fonctionnalités principales qu’offre un moteur de jeu et prendra appui sur des exemples de moteurs populaires comme le Source Engine de Valve et l’Unreal Engine de Epic Games. Nous allons tenter de traiter des problématiques auxquelles doivent faire face les moteurs d’aujourd’hui par rapport à ceux d’hier : multiplicité des plateformes, diversité des budgets (des développeurs indépendants aux studios AAA), jeu mobile ou encore hétérogénéité des produits développés avec un même moteur.

Un screenshot de Portal 2 (source : site officiel)
Portal 2, un jeu basé sur le Source Engine de Valve
Sources :

Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Paternité – Pas d’Utilisation Commerciale – Pas de Modification 3.0 non transcrit.