Unity est un moteur très populaire qui permet de créer des jeux pour différentes plateformes, mais il a récemment changé son modèle économique, ce qui va avoir un impact plus ou moins important sur la communauté des créateurs de contenus. Heureusement, il existe des alternatives à Unity qui peuvent répondre aux besoins de différents types de projets. Dans cet article, je vais vous présenter quelques-unes de ces alternatives, en vous donnant leurs avantages et leurs inconvénients. J’espère que cela vous aidera à faire votre choix si vous cherchez un autre moteur que Unity pour vos prochains jeux.
Vous pouvez aussi vous demander comment porter votre jeu Unity vers un autre moteur. Je vous présenterais rapidement mon workflow pour ça en fin d’article. Par exemple, j’ai été capable de porter tous les niveaux de DVR Simulator (Unity), ainsi que le code de base en seulement un weekend !
Unreal Engine
Unreal Engine, aujourd’hui en version 5.3, est une solution élégante pour presque tous les types de contenus, allant du jeu mobile à l’application de formation en réalité virtuelle. Le moteur est gratuit et il faudrait payer quelque chose à Epic à partir de 1 million de dollars de revenu. Vous payez à partir de 1M, par exemple si vous générez 1000001 millions, vous payez 5% de $1.
Evidemment c’est une solution qui a ses qualités et ses défauts. Le moteur embarque énormément de choses par défaut, pour certains c’est une faiblesse, mais en réalité c’est super car vous n’avez pas besoin d’acheter des plugins, tout est déjà là. Si vous faites de la 3D, vous verrez qu’il y a absolument tout ce qu’il faut, de l’outil de simplification de mesh/LOD, à l’éditeur de squelette, mais aussi un éditeur d’objet 3D ! Il y a aussi des profils par appareils qui permettent au moteur de faire fonctionner vos contenus aussi bien sur un PC haut de gamme, que sur un Meta Quest 2. Unreal est aussi fait pour que la conception de jeux en réseau soit la plus simple possible. Le framework réseau est unique, que vous développiez pour un serveur dédié sur Amazon ou de la LAN, le code réseau (fonctions RPC, etc…) sera identique. C’est un gain de productivité énorme. Il est aussi possible de tester plusieurs instances directement dans l’éditeur avec différentes options de simulation.
La scalabilité (la possibilité d’avoir un contenu en très haute qualité qui va fonctionner sur un large panel d’appareil) est quelque chose de vraiment remarquable ! Avec les options qui vont bien, j’ai été en mesure de faire fonctionner mon simulateur de drone sur un iMac 2015 avec une carte graphique Intel. Dans ces conditions, il est évident que sur un Meta Quest 2, cela tourne sans aucun soucis. Et pourtant le jeu sur PC utilise Lumen, etc.. Bluffant 😉
Le scripting se fait au choix en Blueprint (un langage visuel où il faut connecter des boites ensembles) et du C++. On peut réaliser des jeux entier rien qu’avec du Blueprint, l’exemple avec ce superbe remake de Tomb Raider 2 :
Quelques avantages que j’apprécie
- Création de LOD pour objets statiques et animés
- Création de squelettes / Retargeting en temps réel
- Editeur de shader puissant et scalable
- Des presets de réglage par device pour une scalabilité dingue
- Un outil artist-friendly, et ce n’est pas rien ça 🙂
- Une communauté à l’écoute, généralement assez compétente
- Un store avec des assets de bonne qualité
- C’est le premier moteur a avoir intégré OpenXR
- Le réseau par défaut, normalisé et testé depuis des années
- Les performances sur Quest 2 !
- OpenXR par défaut !
- Accès au code source sur github, pull request acceptées
- Epic utilise son moteur dans ses productions, c’est un cage de stabilité. Ils sont aussi au courant des forces et faiblesse de leur produit
- Pas de mise à jour toutes les semaines !
Quelques inconvénients
- Nécessite une machine puissante pour faire fonctionner l’éditeur, la scalabilité de l’éditeur n’est pas incroyable
- Les assets sont transformés en .uasset, un format binaire où les références avec les autres asset sont relatives au projet
- Le management des assets est lourd dans l’éditeur, le « Fix up redirectors » est obligatoire après chaque déplacement de fichier…
- Il faut impérativement git-lfs (si vous travaillez avec git), ce qui va nécessiter un coût en stockage (généralement avec Unity vous utilisez aussi git-lfs)
- La compilation des shaders à chaque fois qu’on sauve un shader…
- Le plugin MetaXR est moins mis à jour que celui d’Unity et est moins stable, heureusement il n’est pas obligatoire (OpenXR)
Godot Engine
Je suis les avancées de ce moteur depuis le début, et si il y a quelque chose de sur, c’est qu’il va dans la bonne direction. Godot est open source, sous licence MIT, vous pouvez donc l’exploiter dans vos projets commerciaux sans aucun coûts additionnels. C’est une solution encore un peu jeune qui a deux gros défauts à mon sens. Le manque d’ergonomie et le manque d’optimisations pour certains types de contenus. Sinon c’est une solution robuste qui permet de créer tout types de jeux.
Godot exploite OpenXR sur Windows, Linux, Mac et Android avec une prise en charge des casques Meta Quest et Pico (rien que ça). Le nouveau template VR vous permettra de démarrer assez rapidement. Le scripting se fait en GD Script (ça ressemble à du Python) ou en C#, mais il est possible d’utiliser presque tous les langages que l’on veut via GD Extensions. Voir ci-dessous un extrait de code qui active la prise en charge de la VR
Les avantages de Godot Engine
- Utilise des méthodes nouvelles, en particulier pour le rendu
- Plusieurs méthodes pour scaler entre PC et mobile
- Une communauté très active
- Une superbe prise en charge de OpenXR
- Gratuit et open source
- L’éditeur est très léger, et fonctionnera sur votre vieux PC
- L’éditeur a un poids très léger (50mo)
- Pas besoin d’un Launcher Electron de 200mo pour l’utiliser
Les inconvénients
- L’UX pas top, on perd du temps à chercher des choses évidentes parfois
- Pas de DirectX, donc pas de UWP
- Le scripting GDScript pas super
- La prise en charge C# n’est pas encore parfaite et nécessite un autre exécutable
StereoKit
On continue ce listing avec StereoKit, un framework C# dédié à la création de contenu XR avec OpenXR. Avec StereoKit, vous n’avez jamais été aussi proche du hardware de votre casque VR ! Travailler avec ce framework vous fera revenir aux sources, à savoir via un éditeur de code comme Visual Studio et c’est tout ! Vous devrez préparer vos assets graphiques dans Blender (ou autre) et les exploiter directement depuis le code : The old school way !
StereoKit est conçu pour être performant par défaut, avec des techniques comme l’Instancing, par défaut. Il y a aussi un simulateur mixed reality pour tester ses applications en MR sans déployer sur son casque. Le moteur graphique est une dll C++, mais le moteur en lui même est en C#. Cela permet d’avoir la « puissance » du natif et la flexibilité du C#, le meilleur des 2 mondes. Comme pour Godot Engine, ici c’est une licence MIT, donc c’est gratuit, même pour un usage commercial.
StereoKit est disponible pour Windows, Linux, (probablement prochainement Macos), Android, HoloLens et WebASM. Si vous n’avez pas de casque VR, il y a un mode « fallback ».
Les avantages
- Itération ultra rapide
- Une implémentation OpenXR complète qui fonctionne partout
- Multiplateforme : Windows, Linux, Android, HoloLens
- C# par défaut
- Performances par défaut
- Framework UI dédié VR/MR
- Moteur physique
- Fallback Flat mode
- Simulateur MR
Les inconvénients
- Pas d’éditeur, il faut faire ça à l’ancienne <3
- Pas de framework réseau
- Pas de framework son avancé
- Encore jeune
MonoGame / XNA
Comment ne pas parler de MonoGame après avoir parlé d’une solution comme StereoKit. MonoGame est le successeur du très célèbre Framework XNA de Microsoft. C’est une solution que je connais très bien et que j’ai utilisé pendant dans années. Il est clair que ça n’est pas réservé à tous les types de contenus, mais c’est une alternative intéressante, avec une bonne communauté, de nombreux tutoriels et des possibilités intéressantes. De nombreux jeux ont été publiés sur PC, mobile et console avec MonoGame
Avantages
- Une bonne communauté
- The old school way
- Stabilité
- C# first
- Multiplateforme : Windows, Linux, Mac, Android, iOS, Web et consoles
- Ca marche !
Inconvenients
- Conception vielle
- The old school way
- Difficile d’ajouter certains fonctionnalité avancée
Technique de conversion d’un projet Unity vers autre chose
Il y a plusieurs choses que vous pouvez porter facilement vers un autre moteur, il y a aussi des choses qui sont impossible à porter, faisons un listing :
Relativement facile à porter :
- Structure des niveaux
- Modèles 3D
- Textures / Sprites
- Animations
- Audio
Portable, mais peut être compliqué :
- Code : On peut porter des blocs de code (logique) C# vers C++ assez facilement
Difficilement portable :
- Timelines
- Particules
- Shaders custom
Comment exporter un niveau entier ?
Depuis Unity vous avez deux options qui fonctionnent plutôt bien
- Export FBX avec le plugin disponible sur PackageManager
- Export GLTF/GLB avec les plugins GLTFUtility ou GLTFast
Je vous recommande d’utiliser le format GLTF/GLB car vous pourrez importer votre niveau sur Unreal, Godot et StereoKit par défaut 🙂 L’export FBX est intéressant si l’export GLTF s’est mal passé. Si vous visez Godot, il existe un plugin qui permet de convertir directement vos assets depuis Unity. L’idée est d’exporter votre projet sous forme d’un Unity Package et de l’ouvrir dans Godot ! Vous aurez besoin du plugin UnityPackage_Godot pour ça.
Grâce à l’export GLTF, j’ai été capable de porter tous les niveaux de DVR Simulator (Unity) vers Unreal Engine 5 ! Le code C# se traduit assez bien en C++, et là aussi en quelques heures, j’ai été capable de porter le code qui contrôle la physique du drone. Le résultat en un weekend ? Un POC qui fonctionne avec tous les niveaux et la physique (améliorée grâce au moteur physique d’Unreal).
Conclusion
Il est impératif de ne pas avoir un business qui repose uniquement sur un outil, en cas de problème avec l’outil en question, c’est votre organisation entière qui peut être mise à mal. L’idée de cet article n’est pas de vous faire arrêter Unity, c’est un moteur super bien, mais il faut aussi savoir évoluer, ça fait partie de notre métier. Peut être qu’aujourd’hui vous ferrez un switch sur Unreal ou Godot et que dans quelques temps, vous ferrez la même chose vers une autre techno.
Porter une production est possible, il faut découper le portage en groupe logique par typologie d’assets et restructurer votre projet dans l’autre moteur. Il est évident qu’un projet bien structuré et bien architecturé sera beaucoup plus simple à porter qu’un projet pas rangé avec un code mal pensé. Le port est aussi une belle manière de devenir meilleur dans votre domaine, il faut voir cela comme une revu de code, graphique, sonore. Dans certains cas, vous allez même améliorer ce que vous avez fait.
Vous avez des questions sur les solutions proposées ou sur le port d’Unity vers un autre moteur ? N’hésitez pas à me poser vos questions !