Quand nous avons entrepris de créer Star Wars™: Squadrons, nous voulions vous offrir l’expérience de pilotage complète dont vous rêviez à bord d'un chasseur grâce à la VR et aux périphériques de simulation de vol. Malgré notre expérience poussée dans la création de jeux en 2D, nous n'étions pas encore des experts en VR (dans cet article, le terme 2D fait référence à l’affichage d’un jeu sur un écran de téléviseur, et non à la 2D basée sur des sprites à proprement parler). Ainsi, au cours des années de développement suivantes, nous avons surmonté un bon nombre de défis techniques enrichissants. Dans cet article, nous partageons notre expérience de développement et présentons quelques-uns des défis les plus intéressants que nous avons surmontés afin de vous donner une idée de ce que nous avons dû faire pour créer la VR. Des astuces d’optimisation du rendu à la gestion des performances en passant par les défis de logistique liés à la COVID-19; nous vous racontons tout.
Du point de vue technique, notre plus grand défi lié à la VR consistait à atteindre une combinaison robuste de fréquence d’images et de résolution, surtout sur les consoles où nous poussions le matériel à ses limites. Dans tous les jeux vidéo à haute-fidélité visuelle, la perception que les joueurs ont de la qualité dépend d’une simulation exécutée à un minimum de 30 FPS (idéalement 60 ou plus) et avec une résolution de 1080p.
Les jeux 2D ont une tolérance acceptable en matière de fréquence d’images et de résolution, mais nous n’avons pas cette chance avec la VR. Les chutes de fréquence peuvent causer un mal de la réalité virtuelle, de la fatigue oculaire, une désorientation et des nausées, même pour ceux qui ont le « pied marin » pour la VR (expression utilisée pour les personnes qui ont une forte résistance aux maux de la réalité virtuelle lorsqu’elles utilisent un casque de réalité virtuelle).
Afin d’obtenir 60 FPS, le strict minimum pour une simulation de VR acceptable, chaque image devait être rendue au maximum en 16,6 millisecondes. De plus, une simulation en VR demande qu’une image distincte soit rendue pour chaque œil. L’approche la plus simple consisterait à rendre deux images au lieu d’une, mais cela réduirait de moitié notre budget de millisecondes afin de conserver les 60 FPS requises. Comme vous le lirez plus tard, il y a quelques astuces pour mieux utiliser le matériel et éviter de dessiner deux fois plus d’images pour la même période.
Afin de produire une image stéréoscopique (en d’autres mots, une « image en VR »), nous avons besoin de projeter l’image telle qu’elle est vue par chaque œil et de laisser le cerveau faire sa magie pour la suite. Comme nous le savons, chaque œil voit le monde d’une manière un peu différente car nos yeux se trouvent à deux endroits différents. Dans une simulation sur ordinateur, cependant, certaines opérations de rendu ne dépendent pas de la position et de l'orientation des yeux. Cette situation crée une occasion d’optimisation où nous mettons en « mémoire » les résultats de ces calculs; nous les effectuons d’abord pour le premier œil, puis nous réutilisons ces résultats pour le second. Les calculs des ombres sont un bon exemple de mise en application de ce type d’optimisation, puisque les ombres ne dépendent pas de la position ou de l’orientation du joueur. Elles dépendent principalement des objets et de la position des sources de lumière.
Les ombres sont rendues en fonction du point de vue des sources de lumière. Les partager permet de réduire le temps de rendu des images dans son ensemble.
Une autre manière d’éviter le double coût d’utilisation du processeur graphique et de l’unité centrale de traitement consiste à ajuster certains calculs pour qu’ils soient valables pour les deux yeux au même moment. Prenons par exemple la technique du « frustum culling », elle consiste en la suppression d’éléments indésirables du champ de vision. Ces calculs consomment beaucoup de ressources, car ils demandent de traverser de larges structures spatiales d’objets en 3D. Même si chaque œil possède en principe son propre champ de vision, les deux champs sont presque similaires. Au lieu de faire le calcul deux fois, nous avons effectué le calcul une seule fois en utilisant un nouveau volume de champ de vision qui comprend toutes les données relatives aux deux yeux simultanément. Avec cette approche, quelques objets du monde sont rendus inutilement dans l’image de gauche ou de droite, mais les économies de ressources réalisées en effectuant la suppression une seule fois dépassent largement les coûts liés à ces rendus; du moins, dans notre cas!
Les champs de vision de l’œil gauche (bleu) et de l’œil droit (orange) sont combinés afin de créer une vision plus large qui comprend les deux champs
Contrairement aux images en 2D classiques affichées sur un écran plat, la lentille des casques de réalité virtuelle a une forme qui tient compte du fait que les yeux se trouvent très près de l’écran. La forme de ces lentilles permet une optimisation qui est tout simplement impossible à réaliser en 2D. En coulisses, les objets sont tout de même dessinés sur une image plane en 2D pour réaliser le rendu en VR. Lorsque l’image est projetée sur les lentilles, nous pouvons remarquer que la distorsion rend la vision de certaines parties de l’image 2D impossible. Nous utilisons cette propriété afin d’appliquer un masque de réduction tout simple aux pixels se trouvant sur la limite extérieure, ce qui nous permet de réduire grandement la consommation des ressources du processeur graphique.
En VR, les pixels à rendre sont beaucoup plus nombreux qu’en 2D. Non seulement parce que le rendu doit être effectué pour deux yeux, mais aussi parce que chaque image est très proche des yeux et nécessite donc une résolution plus haute afin de ne pas être pixelisée ou floue. En tenant compte de ceci, et en considérant le fait qu’écrire dans le la mémoire vidéo de rendu est coûteux en matière de ressources (plus d’informations sur le rendu différé et les tampons de rendu ici ou ici). Le rendu différé est trop coûteux pour la VR, nous avons donc décidé de nous rabattre sur la méthode de rendu direct classique. Ce changement a eu un impact minime sur la fidélité visuelle, car il y a moins de sources de lumière dans un jeu de combat spatial par rapport à d'autres jeux d’action et d’aventure classique.
Nous avions initialement utilisé cette technique uniquement pour le PS VR, mais elle a si bien fonctionné que nous l’avons ajoutée comme correctif à la version pour PC. Les joueurs qui ne possèdent pas un processeur graphique haut de gamme peuvent ainsi quand même jouer à Star Wars Squadrons avec une meilleure fréquence d’images.
La résolution dynamique est une technique d’optimisation très répandue de nos jours. Elle consiste en une réduction automatique et temporaire de la résolution effectuée par le moteur afin de compenser la présence de quelques images lourdes. Tant que la résolution n’est pas réduite de manière trop importante et trop longtemps, le changement de qualité ne se remarque pratiquement pas.
Pour des raisons techniques qui dépassent le sujet de cet article, seule la version pour console a pu profiter de la résolution dynamique. En fin de compte, les gains obtenus grâce à cette technique ont été minimaux comparativement à la 2D. Afin de tirer le maximum de cette technique, nous devons configurer la résolution « par défaut » à une valeur plus élevée que le strict minimum. Par exemple, en 2D sur la PS4 nous utilisons le format 1080p par défaut et 900p comme minimum (le moteur n’ira pas en deçà de cette limite). Cependant, en raison de la résolution du PS VR sur une PS4 classique, nous ne disposions pas de la marge de manœuvre nécessaire pour tirer le maximum de cette technique. Les chutes de résolution sont beaucoup plus apparentes sur un écran qui se trouve à quelques centimètres des yeux. Cela étant dit, avec la résolution dynamique, nous avons du moins été en mesure d’obtenir une bonne augmentation de résolution sur la PS4 Pro et la PS5 grâce à la puissance de traitement supérieure de ces deux consoles.
Certaines optimisations sont prometteuses sur papier, mais en tant que développeur de logiciels, vous devez toujours prendre en considération la quantité de code à réécrire, les autres systèmes qui pourraient être touchés et le niveau de risque qui en découle. À l’instar d’un projet de rénovation, les changements sont rarement simples et il faut toujours se préparer à quelques surprises.et vous préparer à quelques surprises.
Nous voulions utiliser d’autres techniques, comme le rendu fovéal, mais nous étions trop avancés dans le projet pour faire un changement si important. Nous devions concentrer nos efforts vers d’autres besoins, comme le débogage et la stabilisation. Certaines optimisations sont prometteuses sur papier, mais en tant que développeur de logiciels, vous devez toujours prendre en considération la quantité de code à réécrire, les autres systèmes qui pourraient être touchés et le niveau de risque qui en découle. À l’instar d’un projet de rénovation, les changements sont rarement simples et il faut toujours se préparer à quelques surprises.et vous préparer à quelques surprises.
Une idée consistant à mélanger rendu 2D et rendu stéréoscopique semblait prometteuse, mais a été abandonnée en raison du travail que sa mise en œuvre aurait entraîné. L’idée est la suivante : quand un objet se trouve suffisamment loin des yeux, la différence entre ce que chaque œil « voit » est minime (essayez-le à la maison en fermant votre œil gauche et droit l’un à la suite de l’autre). Ce concept est connu depuis toujours dans le milieu des jeux vidéo. Vous pouvez l’observer grâce aux effets de parallaxe des jeux de SNES et de Genesis. Il se matérialise par un défilement plus lent des objets en arrière-plan et plus rapide en avant-plan pour créer une illusion de profondeur. Ce même concept aurait pu s’appliquer à un jeu en VR où les objets n’ont qu’à être dessinés une fois pour les deux yeux lorsqu’ils apparaissent à une certaine distance. Aussi simple que cette idée puisse sembler, sa mise en œuvre présentait un trop grand défi dans un pipeline graphique qui n’était pas conçu avec cet algorithme en tête. Sans parler du fait que, comme c’est le cas pour la plupart des optimisations, il est impossible de prédire les gains avec une exactitude de 100 %. Ce changement aurait donc pu en valoir le coup ou non.
L'optimisation de Star Wars : Squadrons a fait l’objet d’efforts constants au cours des 12 derniers mois du projet. Nous avons fait appel à de nombreux programmeurs, des artistes techniques et des spécialistes de l’assurance qualité. Durant cette période, nous avons mis en œuvre d’autres optimisations, dont plusieurs visaient à améliorer les parties principales du moteur afin qu’il gère mieux le travail supplémentaire requis pour la VR. Sans aller trop dans les détails, ces optimisations comprenaient :
Malgré nos nombreuses optimisations, beaucoup d'objets et effets doivent toujours être rendus à deux reprises en VR. L’unité centrale doit également faire du travail supplémentaire : préparation d’une seconde image, traitement « invisible » propre à la VR, mesure de la position de la tête dans l’espace, double projection d’images, mises à jour des caméras, de l’interface utilisateur et de l’audio 3D. Si Squadrons avait été un titre uniquement offert en VR, nous aurions disposé de plus de liberté pour respecter des budgets de ressources plus restreints. Nous avons cependant dû veiller à la parité entre les expériences en 2D et en VR. Non seulement parce que notre jeu possède un volet multijoueur et que la parité est une nécessité, mais, plus important encore, parce que notre vision a toujours été que la VR ne soit pas un sous-produit du jeu, mais bien une expérience complète identique à celle en 2D.
Star Wars: Squadrons est plutôt unique, dans le sens où il prend en charge la VR et la 2D pour l’ensemble du jeu. Il ne s’agit pas du seul titre à le faire, mais la plupart des jeux ont un volet en VR assez limité, ou ils ne sont offerts qu’en VR. Respecter notre engagement de livrer une expérience exceptionnelle tant en 2D qu’en VR a été un défi technique important. Nous partagerons ensuite avec vous les aspects clés de cette fidélité visuelle et comment nous l'avons réalisée. Nous avons un article entier couvrant tous les aspects de conception de la construction d’un jeu 2D +VR ici, nous en recommandons la lecture!
En matière de jeux en VR, ceux qui ont joué à Squadrons savent qu’il s’agit d’une expérience assez intense. Sachant cela dès le départ, il est possible d’activer et de désactiver la VR à tout moment dans le jeu. Si jamais vous éprouvez un malaise physique (comme des nausées, par exemple) et que vous êtes au beau milieu d’un combat de flottes important, redémarrer le jeu n’est tout simplement pas une option! À cause de cette contrainte de conception, les deux modes devaient être pris en charge dans le même exécutable, et notre code ne devait jamais supposer lequel des deux modes était actif. Dans l’univers de l’optimisation de jeux, les suppositions sont habituellement extrêmement utiles. Par exemple, vous pouvez outrepasser certaines allocations de mémoire, ne pas charger en mémoire certaines resources, etc. Dans notre cas, cependant, tout a été bâti pour que le mode de rendu (VR ou 2D) puisse être changé n’importe quand. Plus précisément, les deux modes devaient s’exécuter à partir des mêmes données et tous les ajustements de fidélité visuelle devaient être dynamiques en exécution.
Notre système d’éclairage est un bon exemple, car il est totalement différent en VR. Cela signifie que nous pouvions régler ou retirer des fonctionnalités sans aucun impact sur l’apparence de la version non-VR. Lorsque vous jouez avec la qualité la plus basse du jeu, avez-vous remarqué qu’il n’y a presque aucune contribution spéculaire?
Afin de compenser la résolution plus basse, nous avons mis en œuvre un traitement pour améliorer la netteté à la toute fin du pipeline graphique. Cela a grandement aidé à éliminer une partie de l’effet de flou. Puisque notre interface utilisateur se trouve principalement dans le monde du jeu lui-même (comparativement à une interface 2D classique), cet effet de flou avait un impact important sur la qualité du texte. Nos équipes de l’interface utilisateur et de l’expérience utilisateur ont dû expérimenter avec différentes polices, différentes tailles de police, différentes couleurs et différents contrastes pour veiller à ce que le texte soit toujours lisible. Le tout s’est avéré être un défi; mais intégrer l’IU à l’univers du jeu lui-même a, selon nous, permis de donner l’impression aux joueurs d’être vraiment présents dans le jeu.
En plus des aspects liés à la mise en œuvre, l’optimisation d’un jeu comprend beaucoup de collectes et d’analyses de données préliminaires. Vous devez non seulement savoir quand et où les performances de votre jeu sont basses, mais vous avez aussi besoin de mesures avant-après afin d’évaluer correctement les résultats de l’optimisation dans un environnement réel.
La première application de la collecte de données de performance cohérentes est la prise en compte de la variabilité naturelle d’un jeu multijoueur en 5 contre 5, c'est-à-dire : la sélection des vaisseaux, la personnalisation, la carte, les habillages de vaisseaux, les styles de jeu, etc. Ensuite, nous nous penchons sur les combinaisons de plateformes sur lesquelles mener nos essais. Cet article porte principalement sur la VR, mais il faut garder à l’esprit la Xbox One, la Xbox One X, la PS4, la PS4 Pro, le PS VR sur PS4, le PS VR sur PS4 Pro, et, bien sûr, les PC et leur matériel diversifié.
Un autre élément à prendre en compte pour la collecte de données est la logistique lourde qui peut être requise afin de gérer 10 testeurs disponibles quotidiennement.
Lors du développement, il peut être difficile de maintenir des versions stables. Pour le suivi des performances, cela signifie que nous pouvions ne pas recevoir de nouvelles données quotidiennement. En tant qu’équipe, nous avons dû faire preuve de rigueur en matière de stabilité de jeu afin de ne pas être touchés par ce problème trop fréquemment.
Ensuite, il y a la question de l’utilisation des données. Ces données sont des mesures de performance en temps réel, collectées 60 fois par seconde pour 10 joueurs sur une période d’une demi-heure. Ces données contiennent parfois du bruit, de nouveaux bogues, des erreurs d’utilisateurs, etc. Pour aider à décomposer, analyser et visualiser les informations , nous avons créé un petit portail Internet pour faire le suivi de valeurs élevées précises au fil du temps, comme la durée d’image globale de l’unité centrale et du processeur graphique. Cet outil improvisé, simple et rudimentaire s’est avéré utile, et d’autres outils étaient accessibles lorsque des données plus détaillées étaient requises... et elles l’étaient souvent!
En mars 2020, notre équipe n’était pas plus préparée que le reste du monde à ce que l’avenir nous réservait. La pandémie a pris de l’ampleur très rapidement, et nous avons tous été informés que nous devions rester à la maison, et ce, avec un très court préavis. Tout le monde est passé au télétravail grâce à un programme qui nous permettait d’utiliser un ordinateur à distance. Cette manière de travailler convenait à un certain type de travail, mais en ce qui a trait à la VR, c’était un obstacle important.
Nous nous sommes restructurés rapidement; et nous avons décidé de commencer à expédier des PC de travail et le matériel requis, comme des trousses de développement logiciel pour consoles et, bien sûr, des casques de réalité virtuelle, aux télétravailleurs. À l’époque, nous avions l’impression qu’il s’agissait d’une mesure un peu excessive, mais nous ne voulions prendre aucun risque dans l’éventualité où le confinement durerait plus longtemps que les deux à quatre semaines initialement prévues.
Pendant que des membres du studio attendaient leur équipement à la maison, nous avons ajouté une commande de débogage spéciale au jeu pour faire basculer le rendu de « qualité VR » en 2D. La solution n’était pas parfaite, mais elle a permis aux artistes de vérifier les réglages de niveaux de détail, la qualité d’éclairage et d’autres effets sans avoir de casques de réalité virtuelle sous la main.
À mesure que les jours et les semaines passaient, il devenait progressivement évident que cette situation de télétravail serait un défi de longue durée. Nous avons continué à envoyer du matériel aux membres de l'équipe (et nos équipes de l’organisation matérielle sont devenues très efficaces), mais nous nous sommes rapidement heurtés à un nouveau problème : nous avons commencé à ne plus avoir d’espace où mettre leur matériel, et à avoir des problèmes d’alimentation électrique et de températures de pièces. D'autres éléments sont à prendre en compte dans ce grand casse-tête. Les casques de réalité virtuelle ont certainement aggravé le problème, puisque la plupart d’entre eux sont accompagnés de caméras, de capteurs et de fils. L’installation de certains casques demande même une pièce entière. À un certain moment, nous disions même en blaguant qu’il faudrait acheter des perceuses pour installer notre matériel. Ce n’est pas exactement le genre d’outil qu’on associe à un studio de jeux vidéo!
Mais le télétravail présentait bien sûr quelques avantages. Nous pouvions, par exemple, nous reposer sur nos lits et nos canapés afin de nous remettre de notre mal de la réalité virtuelle, une situation assez fréquente lorsqu' on crée un jeu en VR.
Au fil du temps, notre ambition a grandi. La VR s’annonçait prometteuse, et, considérant que ce jeu était un hommage aux amateurs de Star Wars, l’équipe voulait faire en sorte que le jeu soit accessible au plus grand nombre de propriétaires de plateformes de VR possible. Lorsque notre campagne de marketing a commencé, elle a généré beaucoup d’intérêt auprès du public, et plus particulièrement auprès des propriétaires de plateformes de VR. C’est à ce moment que nous avons commencé à réaliser que nos joueurs qui optaient pour la VR utilisaient une vaste gamme de casques, et nous ne pouvions pas nous procurer certains de ces casques à ce moment. Nous avons donc contacté plusieurs fabricants et leurs réponses ont été, de manière générale, fantastiques. La plupart d’entre eux nous ont envoyé du matériel pour mener des essais. Nous avons même eu accès à des modèles qui n’étaient pas encore sortis, et certains fabricants nous ont apporté un soutien pratique pour la programmation. Ce fut tout simplement extraordinaire de voir une réponse si positive. (D’ailleurs, notre expérience avec les périphériques de simulation de vol a été relativement similaire, mais nous en parlerons dans un autre article.)
Le changement ayant eu le plus grand impact est survenu quand nous avons décidé d’ajouter la prise en charge de Steam et d’OpenVR à notre titre. À ce moment, nous avons ouvert une boîte de Pandore contenant les spécificités et les particularités de chaque casque dans sa manière d’adhérer à la norme OpenVR.
À ce sujet plus précisément, nous remercions les membres de notre communauté de VR pour leurs rétroactions et leur patience avant et après le lancement, ce qui nous a aidés à améliorer le jeu.
Ce fut un véritable défi, mais nous sommes fiers d’avoir pu offrir une compatibilité avec autant de casques. Le nombre de joueurs qui ont profité de l’expérience du jeu en VR a largement dépassé même nos attentes les plus optimistes.
Star Wars: Squadrons était conçu pour pouvoir se jouer en VR, et nous sommes ravis d’avoir eu l’occasion d’offrir cette version du jeu au monde. Cette conception a été accompagnée de son lot de défis, qu’ils soient techniques ou organisationnels, mais une fois encore notre équipe a su les surmonter avec brio. La réaction très largement positive de la communauté nous a montré que c’était certainement la bonne décision et que tout ce travail valait les efforts que nous lui avons consacrés. Piloter un chasseur était pour beaucoup d’entre nous un rêve d’enfant et pouvoir le faire en créant la technologie nécessaire (notre autre passion!) a rendu la réalisation de ce rêve encore plus gratifiante.
Lucasfilm, le logo Lucasfilm, STAR WARS et les propriétés connexes sont des marques de commerce et/ou sont protégés par des droits d’auteur de Lucasfilm Ltd. et/ou de ses sociétés affiliées, aux États-Unis et dans d’autres pays. © et ™ 2021 Lucasfilm Ltd. Tous droits réservés.