Interview d'un studio de jeux vidéo : Heliceum

Je suis Sébastien Broussaud, directeur technique chez Heliceum, un studio de développement parisien. Je suis ingénieur en informatique spécialisé en intelligence artificielle. Auparavant, j'ai travaillé à la DGA, puis dans la finance, notamment pour la Société Générale. Il y a environ six ans, j'ai commencé le développement de jeux vidéo chez Dontnod entertainment (Remember Me - 2012) et depuis environ deux ans et demi j'ai aidé à fonder Heliceum en tant que directeur technique.

En fait, lors de mes études, je m'étais spécialisé en intelligence artificielle, qui est déjà proche du monde du jeu vidéo. À la création de Dontnod, le directeur technique cherchant les premiers développeurs m'a contacté, car nous avions fait nos études ensemble. Chez Dontnod, j'ai aidé au développement en mettant en place une première base technique et à la préproduction du jeu.

C'est donc un studio de développement parisien constitué de 25 employés. La principale activité est le développement de jeux vidéo sur smartphones et tablettes et de quelques applications Internet.

Le responsable de la société, Adrien Dassault m'a contacté pour l'aider à fonder la société. Il souhaitait passer d'une société qui ne faisait pas du tout d'informatique à une société de développement de jeux, l'une de ses passions. Il a donc essayé de recruter des gens qui connaissaient bien le milieu, que ce soit dans le domaine du graphisme ou du développement. On a commencé à trois, il y a deux ans et demi pour être maintenant 25.

Au début, le studio ne travaillait que sur de petits projets puis, ils ont monté en gamme avec « Faker$ », « Human Defense » et aujourd'hui « Sale Gosse » ou encore avec des applications Business to Business (B2B) comme « Le grand défi Le Figaro » ainsi que d'autres petits projets.

Dans Heliceum, il y a plusieurs corps de métier décomposés en deux branches :

• la branche production, créant les applications et les jeux ;
• la branche marketing.

Je m'occupe de la branche production, dans laquelle on retrouve plusieurs corps de métier :

• les game designers, qui s'occupent du design et des spécifications des applications et jeux ;
• les graphistes, produisant les ressources graphiques ;
• le pôle développement, produisant tout le code du jeu et s'occupant de tous les aspects techniques.

Il y a aussi un chef de projet et une équipe assurance qualité et test permettant de s'assurer que les applications mises en ligne soient d'une qualité convenable.

En effet, on n'a pas développé pour Windows Market, mais cela arrivera peut-être dans quelques mois. Heliceum discute avec les équipes techniques de Microsoft et selon la place que Heliceum peut obtenir sur Windows Store, le studio réfléchit à ce portage.

Historiquement, les applications de Heliceum étaient uniquement compatibles iOS, car à la création du studio, les seules applications pouvant dégager des revenus n'étaient que sur iOS. Le marché a changé et Android a bien avancé, faisant qu'il est maintenant intéressant de faire des applications iOS et Android. Amazon étant similaire à Google Play, le portage n'est pas coûteux et la seule contrainte a été de refaire le système de monétisation pour accéder aux serveurs d'Amazon au lieu de ceux de Google. Par contre, le portage pour Windows Phone demande plus d'efforts et les technologies ne sont pas les mêmes, nécessitant plus d'énergie sans savoir si cela va rapporter l'investissement que l'on engage dans cette tâche.

Pour « Sale Gosse », nous utilisons Unity. La partie technique et la partie commune vont donc marcher sur Windows Phone. Le problème, c'est que l'on va devoir remettre tout ce qui est bibliothèques externes et les recoder pour les passer sur Windows Phone. Finalement, il y a pas mal de choses que l'on utilise qui ne vont pas marcher, mais qui ne sont pas en rapport avec le jeu : la monétisation, le tracking de données, les publicités.

Les projets précédents avaient été pensés uniquement pour iOS et avaient donc été développés avec Cocos 2D.

Le choix a été assez simple : on avait besoin d'un moteur 3D, souple et multiplateforme. Sur le marché, au niveau des moteurs matures, il en existe deux : l'Unreal Engine et Unity. Les coûts pour utiliser Unity sont bien moindres et la communauté est plus vaste. On peut facilement récupérer des expansions et des ressources graphiques que nous ne retrouvons pas chez le concurrent. Toutefois, l'équipe de développement de Heliceum possède des compétences pour les deux moteurs.

Oui. Le problème est qu'il vient de sortir et n'est pas forcément totalement fini. Le risque de production en prenant un nouveau moteur est énorme. On n'est pas certain de bien le prendre en main et on n'est pas sûr d'avoir un module de monétisation totalement fait à coûts réduits.

Chez Heliceum, on souhaite s'appuyer sur un moteur éprouvé pour ne pas faire toute la partie assurance qualité que n'a pas forcément faite la personne qui vend le moteur.

Même d'un point de vue amateur, ce qui me fait peur, c'est qu'il n'est pas assez mature. Pour Unity, si je voulais faire un projet amateur dessus, je sais que je pourrais récupérer beaucoup de choses en ligne. Il y a aussi une très forte communauté qui l'utilise et je ne conseille donc pas de commencer par du Project Anarchy, mais plutôt par Unity, ou même de l'UDK.

Ce n'est pas pour cela qu'il ne faut pas regarder. Havok est expérimenté, notamment sur l'IA et la physique, donc cela dépend vraiment du projet que l'on veut faire.

D'un point de vue professionnel, c'est compliqué d'aller vers une plateforme lorsqu'il y a très peu de personnes dessus. On arrive très vite à avoir plus de coûts à porter sur une telle plateforme que de gains. Sur une plateforme mobile, les achats sont au niveau de deux euros par personne et donc, il faut vendre en masse pour pouvoir rentabiliser les applications.

Cela dépendra des types d'applications. Par exemple, sur « Sale Gosse » qui est un jeu « Free To Play », pour qu'il marche, on est obligé de mettre plein d'autres choses que le jeu en lui-même. Comme je le disais, on a une grosse couche de monétisation qui reste dedans et qui fait appel à pas mal de prestataires externes. Si ceux-ci sont gérés dans un plugin Unity, on va pouvoir porter simplement sinon cela demandera énormément de travail. Le fait que Unity aille vers les plateformes, c'est le minimum. Il faut aussi que la communauté se dirige vers cette plateforme.

De plus, une nouvelle version de l'application demande beaucoup de coûts au niveau de l'assurance qualité afin de tester tous les matériels.

Tout à fait, maintenant, pour tester une version Apple, il y a beaucoup de versions à tester : iOS 5, 6 et 7, mais aussi pour les différentes résolutions d'écran, que ce soit téléphones (3.5'', 4'') ou tablettes, avec écran Retina ou non.

C'est assez compliqué. Il y a eu beaucoup de travail sur le « look and feel » (le ressenti). Cela a entrainé beaucoup d'allers-retours entre les tests et l'équilibrage du jeu. En développement pur, on peut finir en trois mois lorsque les spécifications sont parfaites et que l'on n'a plus qu'à les rouler. Finalement, le jeu a pris plus de temps : environ six mois. Ce n'est pas spécialement un projet complexe, mais nous apportons un grand soin à la finalisation et au ressenti du jeu.

Finalement, les tests de jouabilité ont duré trois mois et les vérifications de la qualité, environ un mois.

Comme le studio est assez petit, la communication entre les membres des équipes est directe. Nous utilisons la méthode AGILE permettant de voir où on en est et ce qui a changé, au jour le jour.

On a un responsable qualité recruté pour cela. À chaque version délivrée, le jeu passe une ou deux journées à tester les non-régressions et à le malmener. Ensuite, il va créer un rapport de test et créer des tests dans notre base de bogues JIRA (permettant aussi la gestion de projets). Ensuite les bogues sont répartis parmi les développeurs. La version corrigée revient au responsable devant la tester à nouveau et le processus continue jusqu'à avoir un nombre de bogues très limité (ou non bloquants pour la mise en production).

Dans le jeu vidéo, c'est très compliqué. Dans les autres domaines, on peut tester les programmes par des serveurs automatisés, car leurs sorties sont déterministes. On peut utiliser des tests unitaires, ou des tests de séquences. Dans le jeu vidéo, il y a une dépendance forte avec l'utilisateur et le hasard fait aussi partie de l'équation. Finalement, seuls les tests unitaires peuvent être utilisés et le reste sera testé durant la phase d'assurance qualité.

Lors du prototypage des lance-pierres, en voulant accélérer le rythme de tir, au lieu de tirer à chaque fois qu'on lâchait le doigt, à partir du moment où le doigt était lâché, à chaque image, une pierre partait. Cela faisait qu'il y avait des milliers ou millions de pierres qui volaient partout.

De façon générale, dans « Sale Gosse », ce sont les textures qui prennent le plus de place. Les modèles 3D sont limités notamment par les textures prenant environ 90 % de la place, les sons 5 % et les modèles 3D et le code, un peu moins.

Au début du projet, on a pris chacune des ressources de façon unitaire, on a regardé son poids et on a fait une projection par rapport au moment où on voulait les mettre dans le jeu permettant de savoir si on allait les voir dès le début et savoir comment limiter chacun de ses paramètres. De plus, au cours du projet on vérifiait si on respectait les différentes contraintes.

On parle au graphiste qui a mis la texture pour voir comment on peut la réduire :

• soit en réduisant la taille de la texture ;
• soit en réduisant la taille de l'atlas en enlevant certains éléments et en les mettant à l'extérieur (les atlas sont utilisés pour économiser la taille mémoire, faisant que l'on doit gérer un compromis entre taille en mémoire et taille du binaire).

Après, en réduisant les textures, la qualité, savoir si on a besoin d'autant de couleurs alors qu'elles ne sont pas forcément vues. Finalement, c'est un compromis entre la taille du binaire et ce qui est important au visuel. Si une texture est coûteuse et qu'elle est peu vue, alors il faut la compresser.

Dans le monde des jeux vidéo, les logiciels GNU sont intensément utilisés notamment pour le scripting. Étant plus jeune, je me rappelle avoir envoyé des « patch notes » pour des logiciels GNU, par exemple Flex/Bison. Ce sont des choses sur lesquelles il faut continuer à travailler, qui aident tout le monde à avancer.

Les graphistes utilisent Blender pour les modèles 3D. De façon générale, il y a toujours un GIMP installé sur les machines des développeurs permettant d'éviter de payer une licence Photoshop pour les quelques essais. On a aussi des shells et des scripts permettant d'automatiser beaucoup de tâches. Un bon développeur est un développeur fainéant.

Cela se fait selon le gameplay du jeu. On ne vise pas du tout les mêmes gens entre les deux modèles économiques. Typiquement, un jeu de plateau dans lequel on va faire les parties les unes après les autres sera payant. Un jeu sur lequel on peut avoir une première expérience qui est plaisante, sur lequel on pourra avancer assez loin et que l'intérêt du jeu va être à long terme sera « Free to Play ». On pourra rajouter des fonctionnalités dans le jeu et on demandera au joueur de payer au moment où il souhaite vraiment s'investir dans le jeu.

C'est vraiment une question de gameplay, il faut vraiment choisir le concept avant de déterminer le meilleur modèle économique lui correspondant.

Bien viser la plateforme dans laquelle on a le plus de facilité. Souvent, quand on développe on a certaines affinités avec certains langages. Personnellement, je viens d'un endroit où c'était de l'informatique pure et dure et où j'ai appris le C++, donc de gérer sa mémoire à la main et être rigoureux. Mon premier projet amateur a été un jeu sur Nintendo DS, car c'était la plateforme la plus simple d'entrée en C++, mais cela demandait de la programmation bas niveau.

Si on arrive à faire plus facilement du script ou autre, on peut passer sur de l'UDK où il n'y aura quasiment besoin d'aucune ligne de code pour faire son premier projet. Seul un éditeur visuel suffit, dans lequel vous reliez des boites permettant ainsi d'avoir une première vision du développement en ayant la logique algorithmique. Ensuite, partir sur l'Unreal Script pour apprendre à structurer un programme.

Je conseille vraiment pour des gens qui n'ont pas vraiment développé d'aller sur les moteurs qui sont déjà assez utilisés tels Unity ou Unreal. Ce choix repose sur la grande communauté et le nombre de ressources sur lesquelles s'appuyer sans avoir à tout comprendre, notamment pour les subtilités qui ne servent qu'à l'optimisation ou les choses très avancées.

Il est moins grand public et si on veut faire du développement amateur autant utiliser des plateformes assez ouvertes. Le CryEngine est utilisé dans certaines écoles, mais si on commence à partir de rien, autant aller sur des endroits où il y a d'autres gens qui peuvent nous aider. Si on fait un projet qui a un minimum d'envergure et que l'on ne va pas pouvoir travailler tout seul, sous-entendu, créer une équipe, autant aller sur une solution où pas mal de gens ont des compétences.