Derrière ce titre provocateur se cache une frustration qui a commencé en 2019 : La stabilité du moteur Unity en prend un coup à chaque nouvelle version. Pire encore, Unity nous market assez régulièrement les bienfaits d’une armée de nouvelles fonctionnalités en preview, bugués et évidemment sans support. Étant auparavant un early-adopter, j’ai raté plusieurs opportunités de lancement à cause de ces supers fonctionnalités, qu’il faut absolument utiliser et qui en réalité sont non fonctionnelles ! Unity est cependant un moteur qui innove et qui a de nombreux avantages, mais dans mon cas de figure, il s’avère que Unreal est désormais le choix pragmatique incontestable. Évidemment il faut garder une chose en tête, ce sont des outils qui conviennent à une équipe pour un projet donné, à un moment donné.
J’ai besoin d’une solution fiable, qui me permette de mettre en avant la partie graphique aussi bien sur PC que sur Mobile. Les temps d’itération doivent être le plus cours possibles car je suis seul à bosser avec très peu de temps pour ça. Enfin il faut des outils intégrés qui fonctionnent, sans devoir mettre la main au porte monnaie, encore, pour avoir une solution qui marche. Voici quelques points qui ont motivés mon switch.
1 – Les temps de build d’un projet multiplateforme avec URP sont incroyablement longs !
On commence avec problème présent depuis le tout début des Scriptable Render Pipeline : Les temps de compilation absolument déconnants ! URP (Universal Render Pipeline) se nommait alors LWRP (Lightweight Render Pipeline), c’était en 2019 et il fallait 2h pour compiler un projet VR fonctionnant sur PC et sur Mobile ! Évidemment j’ai ouvert des issues, avec des envois de projets… Mais c’est un problème qui n’est toujours pas corrigé. Il n’y a que regarder sur les forums, l’équipe le sait, des solutions existent, mais ça n’est pas corrigé totalement. DVR Simulator met actuellement plus de 5h pour une build PC. C’est à cause des shader variants, il y a en trop. Le combo gagnant se trouve lorsque l’on active le HDR, la VR et quelques RenderFeatures. Là vous allez pouvoir être improductifs un moment !
Pour info, un switch sur le renderer Legacy me fait chuter les temps de build à 10 minutes :O. URP c’est fini. Mais côté perfs ça doit être merdique non ? Et bien non, mes benchmarks sur Quest montrent que c’est à priori comme avec URP.. Sur PC ça m’a fait gagner du TAA, un deferred renderer fonctionnel et du SSR.
2 – Les lightmaps manquantes avec Unity Cloud Build
Unity Cloud Build est un service que j’affectionnais énormément jusqu’à ce qu’un bug touchant quelques projets VR soit relevé. Dans certains cas il n’y a pas de lightmaps dans les builds :'(. Alors là aussi on reporte le bug et on voit que ça a déjà été reporté plusieurs fois. La réponse officielle est :
Cloud build n’est pas optimisé pour builder des projets VR, envoyez nous votre projet car cette résolution de bug est au cas par cas
Évidemment, nous avons tous le temps d’uploader un projet de +5Go et d’attendre des semaines pour qu’on nous dise qu’il ne faut pas essayer de générer les lightmaps dans cloud build. Ce n’est PAS ce qu’on essaye de faire pourtant. Je ne comprend pas en quoi une infra peut être optimisée VR ou pas… Réponse étrange d’un support probablement dépassé.
3 – Les crashes de l’éditeur
Quand je parlais de stabilité, il n’y a pas que les packages qui sont en preview, mais bien l’éditeur lui même. La branche 202X est instable au possible avec plusieurs crashes dans la journée. Ce sont des crashes qui arrivent :
- Sur des projets perso
- Sur des projets pro
- Sur des projets que j’ai pas touché
- Combien de screenshot comme ça sur Slack au boulot ?
Alors oui il faut envoyer un rapport avec son projet de +5Go… Mais on le fait une fois, après on arrête…
4 – La lenteur de l’éditeur
Là encore je ne sais pas ce qui s’est passé… Les projets chargeaient vraiment super vite avant, désormais il faut attendre plusieurs minutes avant que l’éditeur soit utilisable. A côté de ça, on nous vente que l’éditeur est plus stable, plus rapide qu’avant et que pleins de bugs ont été corrigés. Vraiment ? Vous avez mis des try/catch partout pour que ce soit aussi long à charger ?
5 – La stack network est pétée !
UNet/HLAPI était une solution qui marchait pas si mal. J’ai eu l’occasion de livrer des jeux en production qui l’utilisait, ce n’était pas parfait, mais ça faisait le taf… Mais c’était à priori pas assez bien ! Imaginez une couche réseau qui marche pas mal, avec des services de matchmaking super rapides à mettre en place. Non il faut voir plus grand et tout déprécier… Aujourd’hui la solution retenu c’est Netcode for GameObjects aka MLAPI.
Unity nous dis que UNet n’est pas performant et n’est pas scalable. On nous propose Netcode for GameObjects, évidemment en preview. Pour le matchmaking, il n’y en a pas, mais il y a quand même un service pour du Lobby et du Relay. Pour connecter des joueurs ensemble, c’est pas la fête comme c’était avec UNet/HLAPI car la simplicité, ça ne fait pas partie de l’équation. MAIS si tout marche pourquoi pas…
Le hic c’est que Netcode for GameObject ça marche vraiment pas bien quand on cherche à faire un jeu un peu compétitif en VR. Les performances sont catastrophiques et c’est plein de bugs ! Sur discord, les développeurs du projet affirmaient en décembre que actuellement, c’était une solution taillée pour des jeux multi simples, avec assez peu de joueurs et pas compétitifs. MERCI. Photon a arrêté PUN2 (on peut toujours l’utiliser mais c’est déprécié) en faveur de Fusion qui lu aussi est complétement dans les choux.
Alors qu’est ce que j’utilise pour faire du réseau qui marche ? Il n’y a aucun standard, aucune norme. J’ai utilisé pas loin de 4 solutions network différentes en 2 ans.
Unreal Engine à la rescousse !
Par chance je connais très bien Unreal Engine ! Je l’utilise en parallèle depuis 2016, mais pas en moteur principal pour plusieurs raisons, qui aujourd’hui, ne sont plus d’actualité. Voilà ce que j’aime sur Unreal et pourquoi c’est devenu ma référence.
The goods
- L’éditeur est super rapide à ouvrir
- Beaucoup moins de plantages
- Temps de compilation super rapide
- Itération vraiment rapide sur mobile
- Pleins d’outils intégrés comme un éditeur de LOD pour les objets statiques et animés
- Taillé pour l’open world avec des outils en interne pour le gérer
- Une stack réseau intégré et identique pour tout le monde !
- Le multijoueur par défaut <3
- IK VR facile à mettre en place, par défaut !
- VR Facile à mettre en place, pas besoin de hiérarchie de bourrin
- La quantité de plugins disponibles
- Le lighting qui est quand même beaucoup plus chouette
- Pas besoin de switcher sur une target Android pour travailler sur Android
- UE5 et toutes ses features PC et console
- Epic Games Online Services
- La communauté Epic Games
- De nouvelles offres d’emploi, souvent mieux payées 😉
- L’obligation d’être plus rigoureux dans son travail
- C’est gratuit, pleins de contenus gratuit, pas d’obligation de services payants (Unity Teams, Analytics, etc…)
The Bads
- La lourdeur du workflow en équipe
- Le cauchemar git + gitlfs en équipe
- Il faut un bon PC, sur mon Mac Mini 2014 ça tournait pas bien :D. (J’ai un PC VR à côté pour bosser hein 😉 )
- L’obligation de payer Rider pour avoir un IDE qui fonctionne (Visual Studio est à la ramasse totale avec les macros et est très lent)
- L’obligation d’être plus rigoureux dans son travail
C’est marrant mais j’ai mis qu’il fallait être plus rigoureux dans son travail dans les Goods & Bads. Unity va accepter des choses que Unreal n’acceptera pas, comme des modèles un peu mal travaillés par exemple. Il faut être rigoureux dans son travail car même si cela nous fait passer un peu plus de temps à faire les choses bien, le résultat ne s’en trouve que meilleur.
Grâce à tout le travail réalisé sur Fortnite, Unreal s’adapte vraiment bien sur mobile. Sur PC on a un rendu canon avec de beaux effets. Sur mobile ces effets sont simplement désactivés et le rendu reste très propre. Il n’est pas possible de faire du post processing sur Quest alors qu’avec Unity on peut. MAIS on ne le fait quand même souvent pas à cause de l’impact sur les performances. Notez qu’il est possible de faire du tonemapping sur Quest en utilisant le fork d’Unreal Engine par Oculus.
Le multiplayer par défaut
Un des gros avantages de partir sur Unreal est que la stack réseau est présente de A à Z et fait partie du workflow. En fait quand on a l’habitude, on ne code qu’avec la logique multi, une application « Standalone » fonctionnera au final comme un host hors ligne (comme le mode hors ligne de Photon PUN2 qui était super pratique). Ça ouvre aussi la porte à la fonctionnalité intégrée de replay…
En gros la stack réseau a des fonctions communes pour les échanges de messages (les requêtes RPC), la réplication des variables, etc.. Ensuite le développeur viendra brancher un ou plusieurs système réseau, par exemple Amazon Gamelift, EOS, Facebook, etc… Du coup quand vous commencez votre application multi-joueurs, vous vous moquez de savoir sur quoi votre jeu vas fonctionner. Vous faites simplement du code multi ! C’est un gain de temps/productivité incroyable 🙂 Unity a introduit la notion de Transport (utilisé aussi sur Mirror) pour faire un peu comme ça. Mais sur Unreal le choix est nettement plus important.
Au final
Au final ce sont des outils… et il est important de savoir quand changer afin de travailler de manière la plus optimale possible. Il n’est clairement pas rare pour un développeur de changer de techno. J’ai eu ma période Flash avec Flixel, puis je me suis tourné vers XNA/MonoGame, puis vers Unity et maintenant vers Unreal. Je n’ai pour autant pas abandonné ces autres technos que j’ai beaucoup appréciées. Mon conseil est qu’il ne faut pas être trop fan de la techno qu’on utilise. Ça risque de vous enfermer dans un standard qu’il sera dur de remettre en question en cas de problème.
Je vous laisse sur le trailer du remake de DVR Simulator sur Unreal Engine 5 😉