Cette page est dédiée à la création de jeux vidéo, elle est principalement axée sur le développement, mais le but est aussi d'y parler des aspects plus créatifs et artistiques : le game design, la modélisation 3D, etc. Elle est destinée à tous, quel que soit votre niveau en développement ou vos compétences artistiques.

L'introduction est là pour vous expliquer la structure des jeux vidéo : qu'est-ce qu'un moteur de jeu, qu'est-ce que ça veut dire “créer un jeu vidéo” ? Lisez-là, puis selon vos goûts, votre intérêt ou votre niveau de départ, explorez les sections suivantes dans l'ordre de votre choix !

Si vous ne pensez pas avoir besoin de l'introduction, utilisez la table des matières sur la droite pour directement passer aux sections qui vous intéressent !

Lorsque vous jouez à un jeu, vous ne voyez que le résultat : le gameplay, les graphismes, la musique, etc. Le but de cette introduction est de partir de ce que vous voyez pour vous présenter les différents blocs qui permettent le fonctionnement du jeu vidéo, et de vous expliquer les principes de base de la programmation orientée objet (POO).

Prenons l'exemple du premier Super Mario Bros, sorti en 1985 sur NES. Vous pouvez regarder cette vidéo pour vous (re?)familiariser avec ce jeu !

À l'écran, vous pouvez distinguer plusieurs choses :

1. votre personnage Mario
2. les différents ennemis (les Goombas, les Koopas, les plantes carnivores)
3. les pièces à ramasser
4. les champignons à ramasser
5. les blocs sur lesquels vous marchez
6. les blocs sur lesquels vous pouvez sautez pour obtenir des pièces ou un champignon
7. des informations à l'écrans comme le temps restant ou le score
8. plein d'autres choses.

Vous observez aussi ce qu'on appelle les règles du jeu :

1. Mario élimine un ennemi en lui sautant sur la tête
2. Mario rétrécit lorsqu'il touche un ennemi, et grandit lorsqu'il ramasse un champignon
3. votre score augmente lorsque vous ramassez une pièce
4. si le temps restant tombe à 0 ou que vous tombez dans le vide, vous perdez la partie
5. si vous atteignez le drapeau à la fin du niveau, vous passez au niveau suivant
6. plein d'autres règles.

Enfin, vous observez des mécanismes qui peuvent vous paraître tout à fait naturels, mais sans lesquels les règles du jeu ci-dessus ne pourraient pas exister :

1. il y a un système de gravité : Mario retombe après avoir sauté, Mario tombe s'il n'y a aucun bloc sous lui. Par contre la gravité n'agit pas sur les blocs, qui semblent fixés, ni sur l'affichage du score qui reste bien toujours en haut de l'écran.
2. il y a un système de collisions : Mario ne passe pas à travers les blocs, il marche ou se cogne dessus. De même pour les ennemis
3. lorsque vous appuyez sur une touche de votre NES, Mario exécute l'action correspondante : la touche A pour sauter, par exemple
4. le temps s'écoule comme dans la vraie vie, vous pouvez le voir sur le compteur en haut à gauche
5. plein d'autres mécanismes plus difficiles à expliquer.

Les “choses” que l'on a listé au début sont les composants du jeu vidéo, en programmation orientée objet (POO) nous les appelons des objets : ce sont des entités avec des propriétés bien précises, leur apparence en est une par exemple.

Nous verrons que les objets sont toujours regroupés dans des familles d'objets : les Goombas et les Koopas sont des ennemis, les pièces et les champignons sont des objets ramassables, les blocs forment le terrain, etc. Cela permet de factoriser les propriétés des objets : prenons l'exemple des objets ramassables. Que ce soit les pièces ou les champignons, lorsque Mario passe dessus, l'objet disparaît et une action est exécutée. L'action qui est exécutée est une propriété spécifique à chaque objet de la famille, mais le fait que l'objet soit ramassable par Mario est une propriété commune à tous les objets de la famille.

Ce concept de familles correspond à deux concepts en POO : l'héritage et l'utilisation d'interfaces, qui s'utilisent légèrement différemment selon le langage de programmation utilisé.

Les règles du jeu sont des relations entre objets et entre familles d'objets. Par exemple, un objet de la famille des Personnages comme Mario peut éliminer n'importe quel objet de la famille des Ennemis en lui sautant dessus. Plus tôt, on a noté cette règle : “Si le temps restant tombe à 0, la partie est perdue”. Eh bien il se trouve que le compteur de temps restant est un objet, et que la partie en cours est aussi un objet. La règle précédente n'est qu'une relation entre ces deux objets.

Enfin, ce que j'ai appelé “mécanismes naturels” sont aussi des règles, mais qui semblent s'appliquer indépendamment à chaque objet. En réalité, chacun de ces mécanismes est un objet.

Par exemple, le système de gravité peut être contenu dans l'objet GravitySystem, et le système de collisions dans l'objet CollisionSystem. Ainsi, la gravité n'est qu'une relation entre l'objet GravitySystem et tous les objets sur lesquels la gravité doit s'appliquer : les personnages, les ennemis, mais pas le terrain, les objets ramassables ou encore les éléments de l'interface utilisateur comme le score ou le temps restant.

On peut ainsi définir GravityApplicableObjects, une famille de familles d'objets : celle des objets sur lesquels la gravité s'applique. Une alternative serait de dire que GravityApplicableObjects n'englobe pas les familles Personnages et Ennemis, mais plutôt de dire à chacun des membres de ces deux familles qu'il appartient aussi à GravityApplicableObjects. Peu de différence entre les deux solutions à première vue, mais la seconde permettrait de créer des nouveaux ennemis ou personnages sans les ajouter à GravityApplicableObjects, et donc de créer des personnages qui ne sont pas affectés par la gravité. Est-ce qu'on a envie de pouvoir créer de tels personnages ? Eh bien c'est au développeur du jeu de décider, c'est à lui de faire ces choix d'architecture logicielle !

Les remarques précédentes avaient surtout pour but de vous introduire des notions toutes simples de POO. Mais dans tout ça, c'est quoi le moteur de jeu, le gameplay ?

Commencons par comprendre le rôle d'un moteur de jeu. Pour cela, imaginons que le développeur de Super Mario Bros 1985 décide de développer un nouveau jeu sur NES, j'ai nommé Metroid ! Regardez une ou deux minutes de gameplay ici avant de lire la suite.

Dans tout ce qu'on a listé plus haut, certains objets, certaines relations sont spécifiques à Super Mario Bros : on ne va jamais faire apparaître de Koopas dans l'univers de science-fiction de Metroid par exemple. Par contre, on va pouvoir reprendre certains éléments et certaines relations : on peut garder des familles de personnages et d'ennemis, auxquels s'appliquent la même gravité que dans le jeu Mario, et simplement changer les personnages et ennemis qui appartiennent à ces familles. Ainsi, la plupart des “mécanismes naturels” seront réutilisables dans Metroid, de la même manière que la structure globale des familles.

C'est ici que se trouve la séparation entre un jeu et son moteur. Si vous retirez à un jeu son identité : ses personnages, ses ennemis et ses règles de jeu, vous obtenez des fondations que vous pouvez utiliser pour créer de nombreux jeux différents. Ces fondations sont le moteur de jeu, et les jeux qui l'utilisent ne se différencieront que par leur gameplay : leurs personnages et leurs ennemis, qui constituent l'univers du jeu, mais aussi leurs règles de jeu qui sont spécifique à chaque jeu : Mario grandit quand il ramasse un champignon, mais Samus ne va pas forcément grandir si elle croise un champignon sur son chemin !

Je n'en ai pas parlé en détails au cours de cette introduction, mais la partie “Graphismes” est présente à la fois dans le moteur de jeu et dans le gameplay.

Je vous explique : dans le moteur de jeu de Super Mario Bros, l'apparence des personnages et ennemis ne sont qu'une simple image, et leur animation n'est qu'une succession de trois ou quatres images légèrement différentes pour donner une impression de mouvement. Cela est spécifié dans le moteur de jeu, ce sont les bases de l'apparence d'un objet 2D dans un jeu vidéo, et elles peuvent être réutilisées telles quelles dans Metroid ou un autre jeu du même style. Par contre, les images en question sont spécifiques à chaque jeu.

C'est exactement la même chose pour les musiques d'ambiance ou les bruitages qui sont joués à chaque action d'un joueur par exemple. Dans les jeux 3D, c'est la même chose, mais en remplacant les images et animations par des modèles 3D, (presque) tout simplement !

J'ai juste une dernière remarque, pour vous plonger dans le contexte actuel du développement de jeux vidéo.

Aujourd'hui, la plupart des gros studios de développement développent leur moteur de jeu, puis développent leurs jeux avec. Cependant, les personnes qui développent le moteur de jeu ne sont pas celles qui créent le gameplay du jeu, qui ne sont pas non plus celles qui créent les graphismes ou les musiques. Et toutes ces personnes n'ont pas les mêmes compétences ! Ceux qui créent le moteur de jeu ne peuvent pas se permettre de créer “juste” une interface de programmation que le game designer pourra utiliser dans son code. Le game designer doit pouvoir créer le gameplay de son jeu en n'ayant que le minimum de code à écrire. C'est pourquoi les moteurs de jeu actuels possèdent des interfaces graphiques, faciles à prendre en main, et qui permettent de créer le gameplay d'un jeu sans grandes connaissances en programmation : il est nécessaire de savoir faire du scripting, c'est-à-dire des petits programmes comme vous avez pu le faire en python en prépa, mais pas plus !

À cet effet, de plus en plus de studios rendent leur moteur de jeu public : c'est le cas d'Epic Games qui a développé les moteurs Unreal Engine : ils continuent de vendre et de créer de nouveaux jeux, mais n'importe quelle autre entreprise, ou particulier passionné, peut utiliser leur moteur de jeu pour créer des jeux vidéo, même à but lucratif.

Certaines autre organisations, comme Unity Technologies, se sont spécialisées dans le développement d'un moteur de jeu. Elles ne créent pas de jeu, et ne travaillent pas sur la partie gameplay, mais permettent à beaucoup d'autres petits studio de ne pouvoir se focaliser que sur la partie gameplay, en utilisant un moteur de jeu performant et reconnu.

Aujourd'hui, la plupart de ces moteurs de jeu sont très polyvalents, chaque moteur de jeu permet de créer des jeux très différents : jeu de voiture en 3D, plateformer en 2D, FPS, etc.

Voilà, vous savez tout ce qu'il faut savoir pour débuter votre apprentissage ! Dans mon explication, qu'est-ce qui vous a le plus intéressé ? Le moteur de jeu ? Le gameplay, car vous avez toujours rêvé de créer votre propre jeu de stratégie ? Ou bien vous préférez créer un univers à part entière, et donc vous orienter vers la partie artistique de la création de jeux vidéo ? Faites votre choix, et suivez les sections suivantes dans l'ordre de vos préférences !