Chez Kylotonn #2 – À propos du développement orienté gameplay

Cet entretien avec Michaël Chinchilla a été réalisé dans le cadre d'une visite des studios de Kylotonn (retrouvez l'introduction ici). Michaël est lead programmeur, en charge d’une équipe de neuf personnes dédiées au gameplay. Leur objectif est de lier le travail des autres pôles et de créer les outils dont les autres ont besoin.

Travaillant de manière agile, les développeurs en charge du gameplay enchainent des phases de travail (sprints) dont les objectifs coïncident avec ceux des autres pôles : UI/UX (interface et expérience utilisateur), conception des véhicules et des environnements, level design, moteur… Entre Lyon et Paris, avec certaines personnes en télétravail total, la communication est  dématérialisée. N'en déplaise à certains, cela fonctionne bien. En partie aussi à cause de la récente crise sanitaire, qui a permis d'améliorer les outils à disposition pour assurer un travail efficace en distanciel.

Une autre de leurs responsabilités concerne le QA, assurant le lien entre l’équipe interne (composée de 5 personnes) et l’entreprise externe qui lui remonte de manière hebdomadaire les bugs trouvés sur le dernier build partagé. Ainsi, l’équipe de Michaël gère les soumissions effectuées auprès de Sony, Microsoft et Nintendo, afin de s’assurer que le jeu s’intègre dans l’écosystème de chacun des services. Des batteries de test sont réalisées par ces prestataires, qui ont des attentes différentes en ce qui concerne la façon dont le jeu doit gérer les possibilités de leurs consoles. Le crossplay a apporté une difficulté supplémentaire inédite, avec de nouvelles règles à satisfaire, parfois un peu tordues.

Sony est a priori le plus tatillon. Un exemple très simple : si un utilisateur est bloqué, l’ensemble du contenu qu’il a pu générer doit être masqué. Xbox n’a a priori pas les mêmes attentes de ce côté… D’ailleurs, quand je demande à Michaël s’il a une anecdote à me partager à ce propos, il me parle de ce bug récurrent qui a rendu folle son équipe pendant quatre semaines. Un crash du jeu quand un câble Ethernet était débranché, et qui s’est réglé de la plus bête des façons : grâce à la mise à jour du SDK fourni (l’environnement de développement spécifique à chaque console).

Le département peut être amené à devoir réfréner certaines envies irréalisables d’autres équipes. Même si après autant d'itérations du même jeu, les choses sont désormais bien établies, la machinerie bien rôdée, et le dialogue de plus en plus naturel. L’équipe gameplay collabore au quotidien avec celle en charge du moteur, afin de proposer et d’intégrer les changements nécessaires pour supporter le gameplay. C’est d’ailleurs un gros avantage pour eux d’ainsi posséder une maitrise de bout en bout du développement, et de pouvoir comprendre comment chaque brique fonctionne en regardant directement dans le code du moteur si le besoin s'en fait sentir. Nous avons aussi discuté avec le directeur technique en charge du moteur, plus d'informations à ce propos à venir !

En guise de conclusion sur cet entretien très instructif, Michaël me partage une maxime qui lui a été transmise par la personne qui l’a formé :

Un jeu vidéo, ça ne se termine pas, ça s’abandonne

Car même si de son point de vue ce WRC est sans nul doute le meilleur, le produit parfait n’est pas possible. Avec toujours ce côté frustrant du développeur incapable de ne pas voir tous les défauts.