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 !

L'introduction est longue, alors quand vous l'aurez lue, utilisez la table des matières sur la droite pour vous déplacer plus facilement sur la page.

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 le 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 !

Le gameplay ! Sans doute la partie la plus fun de la création d'un jeu vidéo !

Avant de commencer, une petite mise en garde s'impose : si vous avez un grand projet de jeu auquel vous réfléchissez depuis un bon moment, c'est super ! Mais pour apprendre, vous allez devoir le mettre de côté pour l'instant. Pourquoi ? Deux raisons :

1. Au cours de votre apprentissage, vous allez découvrir progressivement de nouvelles possibilités, et de nouvelles façons d'organiser votre jeu. En commençant tout de suite à travailler sur votre projet, vous serez amené à le recommencer presque entièrement, et ce plusieurs fois, pour utiliser des méthodes plus optimales, plus poussées, mais que vous n'apprendrez qu'un peu plus tard. Croyez-moi, vous serez vite lassé !
2. Si vous avez ce projet de jeu depuis longtemps, il s'agit sans doute d'un projet énorme. Comme vous apprenez tout juste à faire vos premiers pas, votre projet avancera extrêmement lentement, et dans quelques mois, vous comprendrez que c'était un trop gros projet pour débuter.

Que faire alors ? Eh bien vous allez commencer par faire des petits jeux tout simples, pour apprendre la base. Puis vous ferez un jeu légèrement plus complet pour apprendre un ou deux nouveaux concepts, et vous recommencerez jusqu'à faire des jeux grandioses ! Il y a plusieurs avantages à cette approche :

1. En commençant par des petits jeux, vous obtiendrez très vite un résultat jouable.
2. Pas besoin de recommencer le même jeu des dizaines de fois, vous créez des jeux différents à chaque nouvelle étape de votre apprentissage.
3. Vous aurez rapidement une vue d'ensemble de tout ce qui est faisable dans un jeu vidéo, et de comment bien structurer un projet. C'est parfait pour vous préparer avant de vous attaquer à votre vrai projet !

Pour commencer, quel moteur de jeu choisir ? Rassurez-vous, le choix devrait être vite fait ! En effet, même s'il en existe beaucoup, la plupart des studios ne permettent pas que d'autres utilisent leur moteur de jeu, c'est le cas de Frostbite Engine de Electronic Arts, par exemple.

Parmi les moteurs de jeux que vous pouvez librement utiliser, deux s'imposent en maîtres : Unity et Unreal Engine 4. Les deux liens devraient suffire à vous en convaincre !

Honnêtement, aucun des deux n'est meilleur, mais Unity est plus facile à prendre en main si vous débutez. C'est sans doute la raison pour laquelle il est plus couramment utilisé dans les communautés de développeurs indépendants. Si vous comptez suivre la voie d'approfondissement JIN à Télécom SudParis, alors sachez que vous utiliserez Unity pour vos cours.

Maintenant, c'est le moment de vous lancer, ce n'est plus moi qui vais tout vous expliquer, car d'autres le font bien mieux que moi !

Vous trouverez ci-dessous une liste des meilleures ressources que vous pouvez trouver pour apprendre à vous servir de Unity. Notez que la plupart d'entre elles possèdent un équivalent pour Unreal Engine 4, mais n'ayant utilisé que celles pour Unity, je ne peux pas vous assurer à 100% de leur qualité !

1. Commencez par les tutoriels officiels ! Je vous conseille avant toute chose de suivre Interactive tutorials puis Roll-a-ball qui sont excellents pour saisir les bases !
2. Ensuite, plusieurs possibilités s'offrent à vous pour approfondir vos connaissances :
   1. Le cours Complete C# Unity Developer 2D de Ben Tristem sur Udemy. Il est disponible sur le compte Udemy de MiNET et est, certes long, mais très complet. Si vous vous êtes senti perdu lors des deux premiers tutoriels lorsque vous avez dû écrire des scripts, alors ce cours sera parfait pour vous ! Pour les intéressés, Ben Tristem a aussi créé le même cours pour Unreal Engine sur Udemy. Vu la qualité de celui sur Unity, je ne peux que vous conseiller d'y jeter un oeil !
   2. La chaîne de Brackeys propose d'excellents tutoriels, choisissez-en un et lancez-vous !
3. Après ça, vous aurez toutes les clés en main pour commencer à créer vos propres jeux. Les tutoriels qui vous dictent vos projets, c'est fini ! Alors maintenant, créez votre propre projet, et lorsque vous rencontrez un problème, ou que vous souhaitez améliorer votre jeu, suivez des guides spécifiques sur ce sujet :
   1. Encore une fois, la chaîne de Brackeys est très fournie, vous trouverez donc sans doute la solution à votre problème dans le tas !
   2. La seconde partie des tutoriels Unity. En bas de la page, vous avez une catégorie “Thèmes” avec de nombreuses sous-catégories. Ces guides totalement gratuits sont une véritable mine d'or ! Un peu difficiles à suivre au début de votre apprentissage, maintenant que vous avez les clés pour les comprendre et les intégrer à votre jeu, foncez !

Si vous avez des remarques concernant cette page et son contenu, écrivez-les ici !