Parlez-nous de votre parcours en tant que développeur de jeux vidéo et de la manière dont vous en êtes venu à travailler avec Rogue Factor en tant que directeur technique sur Hell is Us.
Comme beaucoup de personnes dans cette industrie, je me suis intéressé aux ordinateurs et aux jeux vidéo dès mon jeune âge. Ma première expérience en programmation a été un jeu à recopier publié dans le magazine Compute!. Mon intérêt pour les jeux vidéo et l’informatique a toujours été présent ; je passais beaucoup de temps à bidouiller de vieux PC pour améliorer la mémoire, les cartes son, etc.
J’ai commencé à créer des jeux vidéo sur Nintendo DS dans une petite entreprise (aujourd’hui disparue) appelée Wicked Studios. J’ai passé quelques années à travailler sur des jeux web, puis j’ai rejoint Cyanide Montréal en tant que programmeur gameplay.
J’ai toujours fait partie de l’équipe centrale de Rogue Factor. J’ai occupé des postes de direction sur tous nos projets, passant à la direction technique à mesure que le studio prenait de l’ampleur. Fait intéressant, je travaille encore avec la majorité de l’équipe avec laquelle j’étais chez Wicked Studios. Nous nous sommes retrouvés à nouveau chez Cyanide Montréal avant de fonder Rogue Factor. Je travaille avec les mêmes personnes depuis plus de 20 ans !
Je programme moins qu’avant, mais j’aime encore garder certains systèmes pour moi. Quand je ne programme pas pendant quelques semaines, cela me manque profondément, et je me remets à travailler sur des projets personnels pour apaiser cette envie.
Hell is Us est sorti simultanément sur Steam, Epic Games Store, PS5 et Xbox Series. Quels ont été les principaux défis techniques liés au développement d’un jeu multiplateforme ?
L’une des bonnes décisions que nous avons prises a été de définir très tôt nos objectifs de performance sur chaque plateforme. Ces objectifs ont évolué quelque peu au fil du projet, mais le fait d’avoir constamment cette cible en tête nous a permis de ne jamais perdre le cap.
La Xbox Series S est très différente d’un PC haut de gamme. Nous nous sommes assurés que les technologies utilisées dans notre jeu soient évolutives, et avons ajusté l’expérience pour cette console en particulier. Chaque console nécessite des optimisations spécifiques et des ajustements pour donner le meilleur d’elle-même. Cela a représenté de nombreuses heures de jeu afin de repérer les goulots d’étranglement et d’analyser comment optimiser ces zones du jeu.
Travailler avec les services de plateforme nécessite également du code personnalisé, mais ils sont en général assez similaires. Nous avons par exemple pu fusionner notre code lié aux succès (achievements) et le faire communiquer avec Steam, le PSN ou l’Epic Games Store.
Tout ce travail est planifié des années avant la sortie finale. Nous avons itéré et testé continuellement sur toutes les plateformes tout au long de la production. Cela nous permet d’avoir un jeu semi‑optimisé durant sa création, et ça réduit la surcharge de QA à la fin du projet, au moment où tout le monde est trop occupé pour se concentrer sur du travail spécifique à chaque plateforme.
L’une des philosophies centrales de Hell is Us est le « player‑plattering » (aucune indication, pas de marqueurs de quête, etc.). Y a‑t‑il eu des défis techniques inhérents à cette approche de game design ?
Créer une expérience immersive est toujours difficile. Une des zones où nous avons beaucoup itéré concernait la visibilité des interactions (portes, objets à ramasser, etc.) lorsque le joueur se déplace dans le monde. Au départ, nous avions un système qui n’affichait les zones interactives que lorsque le joueur cessait de bouger. Finalement, nous avons opté pour un discret effet de brillance toujours présent, car nous ne voulions pas que quelqu’un manque des éléments importants.
Nous avons toujours dit que nous ne voulions pas que le joueur dispose d’un radar lui montrant tout ce qu’il peut faire, mais avoir une boussole pour l’orienter restait important. Nous avons localisé le jeu dans plusieurs langues et dû créer des textures de boussole spécifiques pour chacune d’entre elles.
Dans un concept comme le player‑plattering, la localisation est essentielle, car tous les éléments clés doivent être cohérents et avoir du sens dans toutes les langues. La localisation peut être difficile, car les traducteurs n’ont pas toujours le même contexte que les développeurs. Nous avons donc passé beaucoup de temps à leur fournir le maximum d’informations, et avons mené une solide phase de QA de localisation afin de nous assurer que le jeu soit clair pour les locuteurs natifs.
Hell is Us a été développé avec l’Unreal Engine 5. On lit beaucoup en ligne que les jeux développés en UE5 sortent « mal optimisés ». Pourtant, Hell is Us a été salué par les critiques et les joueurs pour sa stabilité au lancement. Comment avez‑vous abordé le développement pour garantir cela ?
On me mentionne cela souvent, et tout ce que je réponds généralement, c’est : « Nous avons utilisé les outils qui nous étaient fournis. » Nous sommes une équipe gameplay ; nous n’avons ni programmeurs moteur ni programmeurs rendering. Nous essayons de faire le meilleur jeu possible avec les outils à notre disposition.
Unreal Engine propose énormément de fonctionnalités, qui possèdent souvent de multiples paramètres. Ajuster ces paramètres — parfois non documentés — pour notre jeu était essentiel afin d’obtenir un rendu à la fois esthétique et optimisé.
Nous utilisons bon nombre des technologies les plus récentes d’Unreal : Nanite, Lumen, MetaHuman, et d’autres. Malgré cela, nous avons dû épurer et ne garder que les sous‑fonctionnalités nécessaires. Par exemple, MetaHuman génère des personnages de qualité cinéma, ce qui aurait été trop coûteux en performances. Nous avons passé du temps à retirer certaines fonctionnalités des personnages, comme les niveaux de détails les plus élevés, afin qu’ils ne contiennent que ce dont nous avions réellement besoin pour notre jeu.
La compilation des shaders est l’une des principales causes de saccades lors de la première partie. Nous avons opté pour une solution en deux volets pour atténuer ces saccades. Nous effectuons une partie de la compilation des shaders au démarrage du jeu. Beaucoup de joueurs ne la remarquent pas, car elle se fait en arrière‑plan dès que le jeu est lancé. Nous compilons également certains shaders lors du premier chargement d’un niveau. Nous répartissons donc la charge afin que le joueur ne soit pas trop incommodé, tout en nous assurant que toute la compilation des shaders soit terminée avant qu’il commence à se déplacer dans la carte.
Dans nos tests, des saccades survenaient aussi lors du chargement de nouvelles zones de la carte. Cela était causé par les données de collision. Nous avons donc passé beaucoup de temps à créer des assets de collision optimisés et à retirer des collisions inutiles sur certains objets afin de réduire cette charge lors du chargement des nouvelles zones.
Très tôt dans le développement, nous avons mis en place des captures de performance automatisées, ce qui nous a aidés à évaluer le niveau d’optimisation du jeu sur les différentes plateformes. Cela nous a énormément aidés à comprendre plusieurs de nos goulets d’étranglement.
Les précédents jeux de Rogue Factor étaient des jeux tactiques au tour par tour — très éloignés d’un jeu d’action‑aventure à la troisième personne avec un système de combat à créer entièrement. Comment avez‑vous abordé cette transition d’un point de vue technique ?
Mordheim et Necromunda, même s’il s’agissait de jeux tactiques au tour par tour, comportaient une caméra dynamique à la troisième personne. Cela nous a donné une longueur d’avance pour comprendre les défis inhérents à ce style de caméra dans Hell is Us.
Le système de combat est quelque chose sur lequel nous avons travaillé continuellement tout au long de la création de Hell is Us, pour le rendre intéressant, amusant et percutant. Nous sommes passés par de nombreuses variations. Introduire des mécaniques différentes pour la santé et l’endurance nous a obligés à jouer, itérer et valider nos idées. Le système de combat de Hell is Us est également conçu pour des affrontements en 2 contre 2 : Rémi et le Drone contre un Hollow Walker et la Haze. Nous ne nous sommes vraiment pas facilité la tâche !
Le principal défi technique d’un système de combat, c’est l’enchaînement des effets. Ça semble simple, mais c’est très difficile. Une attaque déclenche un repoussement qui annule votre attaque en cours, mais vous ne pouvez pas être projeté derrière un mur, etc. Il y a énormément d’actions qui s’enchaînent et peuvent créer des problèmes difficiles à retracer (pour comprendre où, dans cette longue chaîne d’événements, quelque chose s’est mal passé).
Une priorité pour nous dans Hell is Us était d’avoir en tout temps une version (build) stable. On entend des histoires d’horreur de builds injouables pendant des mois, mais nous avons toujours corrigé les crashes et les problèmes majeurs de comportement très rapidement. Cela nous a permis de continuer à itérer directement dans le monde réel du jeu plutôt que dans des cartes de test.
Donc au fond, techniquement, mon rôle a été de m’assurer que chacun disposait du temps nécessaire et ne se retrouvait pas bloqué lorsqu’il travaillait sur les mécaniques de combat. Parce que l’itération prend du temps, et que le temps est toujours ce qui manque le plus.
Parfois, les plus grandes réussites techniques sont invisibles pour les joueurs. De quoi es-tu le plus fier dans Hell is Us, que les joueurs ne remarquent pas forcément ?
Dans Hell is Us, nous avons accordé beaucoup d’importance au fait que chaque zone du jeu soit unique. Chaque carte a été conçue sur mesure, ce qui a représenté des défis pour toutes les équipes afin de la faire briller.
L’ambiance à Talju nécessitait beaucoup d’effets visuels : fumée, brouillard, braises, ainsi qu’un système spécial permettant de transformer les planches de bois en bois brûlé. Dans une carte où la visibilité est réduite, nous voulions également nous assurer que les signaux de détresse fumigènes restent visibles.
Arcas Spire, avec sa multitude d’ennemis, a été particulièrement difficile à gérer. Notre base dans le jeu était un maximum de 6 ennemis simultanément. Dans Arcas Spire, il y en a cinq fois plus par zone ! Nous avons donc créé des versions « allégées » des ennemis pour rendre cela possible. Nous avons retiré certains éléments, comme les barres de vie, afin de réduire leur coût de traitement, et modifié leur IA pour donner une bonne impression de vagues successives. Il a aussi fallu mettre en place un système qui désactive complètement les ennemis par zone afin que, si vous décidez de foncer tout droit, les ennemis des deux zones ne soient pas calculés en même temps. C’était un défi amusant !
Hell is Us est le plus gros titre de Rogue Factor à ce jour et le sortir dans la nature est toujours effrayant. Surtout sur PC : on ne sait jamais si le jeu aura des problèmes ou non malgré tous les tests possibles, car il existe tout simplement trop de configurations différentes. Au final, tout s’est bien passé, et voir les gens apprécier le jeu et dire qu’il est beau et bien optimisé, c’est tout ce que je pouvais espérer. Tout le mérite revient aux différentes équipes qui ont travaillé dur pour rendre cela possible, et je ne pourrais pas être plus fier d’elles.
