December 2019

Témoignage de mon expérience en tant que designer sur la pipeline de production avec des développeur sur Unity et WebGL

Une expérience sur Unity et en WebGL ne s’aborde pas tout à fait de la même manière. Entre optimisation, interactions, rendu et accessibilité, il y a matière à les différencier, et je m’en suis rendu compte lors de différents exercices sur ces deux technologies.
Je me suis alors demandé comment choisir la plus adaptée par rapport à un projet qui m’est confié.
Je me suis intéressé à ce qui me concernait particulièrement, la Direction Artistique, et ce que je pouvais donc comparer : les interactions, la création d’assets ainsi que la diffusion.

Lorsque l’on réfléchit à une expérience interactive, on commence souvent par s’imaginer comment interagir avec l’utilisateur et comment il va interagir avec notre expérience. C’est un point primordial, à la fois pour les designers et les développeurs, car il va déterminer en grande partie la technologie à utiliser.
Unity étant avant tout un moteur de jeux-vidéo, il est beaucoup plus simple et donc plus rapide de mettre en place des principes physiques essentiels pour une potentielle gamification de l’expérience, comme les collisions, la gravité, les contrôles clavier/souris ou manette ou même la lumière et les ombres. De plus, Unity permet l’incorporation d’interactions complexes (Leap Motion, détection du visage, etc …).
Il est également très simple d’avoir un retour sur ce que l’on fait : son visualiseur en temps réel permet d’avoir un retour direct avec ce que l’on fait et l’interface graphique de travail permet à des développeurs comme à des designers d’utiliser le logiciel convenablement.
Utiliser le WebGL pour concevoir des interactions est un peu plus laborieux. Il est d’abord peut-être important de préciser que ce langage à lui seul n’est qu’une manière de communiquer avec la carte graphique (GPU) de device. Seul, il ne permet pas de produire des jeux-vidéo à la manière de Unity. Il est donc difficile de comparer ces deux technologies. Néanmoins, il dispose d’une communauté massive qui a développé, au cours des années, différentes librairies (Three.js, Cannon.js, etc …) qui permettent aujourd’hui de réaliser des expériences interactives complètes. Il est malgré tout beaucoup plus long à mettre en place des expériences de ce genre, notamment car il n’existe pas d’interface graphique (UI) évidente et ergonomique (UX) sur laquelle s’appuyer. Tout repose sur des notions de programmation complexes. Il offre pourtant une certaine flexibilité car, lorsqu’il est natif et donc écrit “from scratch” (sans utiliser de librairies pré-écrites), chaque paramètre est modifiable.

J’ai remarqué qu’une autre grande partie du travail de designer sur une expérience interactive se concentrait autour des assets. En effet, une fois tout le travail de recherche et d’écriture de l’expérience terminé (scénario, storyboard, moodboard, etc …), la production peut commencer. J’essaie au maximum de ne pas penser à la technologie et à la production pendant tout le travail de recherche pour ne pas me limiter. Il reste néanmoins important de s’imaginer, même grossièrement, la manière dont les idées vont pouvoir être réalisées. C’est pour cette raison que je trouve utile de faire, dans la mesure du possible, la majorité du travail de recherche avec les développeurs avec qui nous allons travailler.
L’avantage de travailler avec Unity est que comme l’expérience est très régulièrement destinée à être déclinée en version téléchargeable, la limite de poids des assets est moindre. Si je dois réaliser une expérience en 3D, ma limite de polygones par scène pourra être plus élevée que si j’utilise le WebGL et donc la puissance du navigateur et de la bande passante. Cependant, je dois toujours faire attention à optimiser mes assets. Bien que je puisse produire des assets relativement lourds, ils ne doivent pas dépasser un certain point. Il en va de même pour les textures appliquées aux objets 3D que j’aurais réalisées. Unity permet d’utiliser des textures en bonne définition sans pour autant surcharger l’expérience. De plus, la gestion des lumières, comme je l’évoquais dans le paragraphe précédent, est déjà incorporée au moteur du logiciel et nous permet d’avoir très facilement des rendus d’ombres, de lumières et de rayons (god rays) très satisfaisants.
Comme les expériences en WebGL sont supportées par le navigateur et la bande passante, c’est évident qu’il faut optimiser les assets au maximum. Et c’est un travail très méthodique à penser très tôt dans le processus de production. Bien que le prototypage soit important sur Unity, j’ai senti qu’il l’était davantage en WebGL, notamment par rapport au poids total de chaque scène. L’optimisation est même essentielle. Lors des différentes phases de prototypages avec les développeurs, il faut arriver à se mettre rapidement d’accord sur un poids, une dimension et même une taille physique des assets (ce dernier point n’est nécessaire qu’en 3D). J’ai appris que tout ce qui ne se voyait pas pendant l’expérience devait disparaître pour économiser le plus de performance possible. Logique, certes, mais moins lorsqu’il s’agit de supprimer, par exemple, la moitié du visage d’un modèle 3D car il n’est pas visible pendant l’expérience. Enfin, il est également nécessaire d’optimiser les textures utilisées. Il est donc souvent obligatoire de déplier les UV de ses objets 3D sur la même texture pour éviter de charger plusieurs fichiers d’image volumineux à la fois.
Travailler en WebGL est donc plus laborieux, mais c’est une excellente école pour produire des assets légers pour tout type de projets.

Le dernier point que j’ai étudié est l’accessibilité. C’est une notion souvent mise de côté au bénéfice du rendu graphique de l’expérience, mais qui pourtant est indissociable du processus de recherche technique d’un projet. En effet, lorsque l’on conçoit des expériences interactives, on pense souvent à comment interagir avec l’utilisateur, mais moins à qui interagit et qui sera amené à interagir avec.
Ce qui fait que Unity permet de produire des expériences si évoluées, tant visuellement que techniquement, est qu’il déploie des exécutables. Pour en profiter, il est nécessaire de télécharger le jeu ou l’expérience et d’avoir un appareil suffisamment puissant pour le/la faire tourner, ce qui restreint considérablement le taux d’utilisation. Quant à elles, les expériences en WebGL sont directement déployées sur le Web et sont ainsi beaucoup plus accessibles.

Il est avant tout primordial de bien penser la réalisation de son projet en amont en prenant en compte la scénarisation de l’expérience, les interactions avec l’utilisateur, le rendu souhaité et la diffusion du projet. En réunissant tout cela, on peut approximativement évaluer les pours et les contres de chaque technologie et se demander si, dans une limite de temps donnée, il est possible de produire le projet.
Ces deux technologies sont intéressantes au même niveau, mais je pense qu’elles n’ont pas les mêmes utilités, pour le moment, du moins.