Fabien Delpiano de Pastagames

Interview du 19 février 2020, réalisée par rOmain Thouy

34ème article d’une série d’interviews réalisés sur la gestion de l’innovation dans le domaine des industries créatives (jeux vidéo, films d’animation) de la région Occitanie.

Fabien Delpiano, fondateur et directeur de Pastagames, studio de jeu vidéo indépendant, qui a travaillé sur de nombreux jeux, pour d’autres studios, comme Rayman Mini et Rayman Legends (Definitive Editions), Pang Adventures ou pour lui-même, comme Pix’n Love Rush, Burn it All ou Pix The Cat.

Formation : Ecole Centrale-Supelec.

son 1er jeu : Skull Splitter III
son 1er gros succès : Build a Bear Workshop sur Nintendo DS
son dernier gros succès : Rayman Jungle Run

"Je suis né en 1971. J’ai fait des études scientifiques. Ma plus grosse émotion, c’est quand mon papa m’a ramené une cartouche de jeu sur mon Videopac G7200. Je croyais que c’était un master mind et quand nous l’avons chargée, il y avait un écran noir avec juste une barre blanche en haut qui clignotait. Mon papa l’a ramenée au magasin, qui a confirmé que la cartouche marchait très bien et que c’était une cartouche de … programmation ! J’ai profité des vacances de Noël pour lire toute la documentation (j’étais en CM2). J’ai tout de suite été fasciné par le fait de pouvoir dire à une machine ce que je voulais qu’elle fasse et qu’elle puisse continuer à le faire même quand je n’étais pas là. Et pour cela, il suffisait de pouvoir le transcrire à la machine. C’était du Basic. Je crois que depuis ce moment-là, je n’ai plus jamais arrêté de programmer ! ”

"Arrivé en 6ème, sur mes fiches de présentation de début d’année qu’il fallait remplir pour chaque professeur, à la question “que voulez-vous faire plus tard ?”, j’ai répondu : “programmer des jeux vidéo”. Ce qui a valu à mes parents d’être convoqués par le proviseur adjoint pour leur expliquer que ce n’était pas un métier. A partir de ce moment-là, je n’ai plus jamais parlé de cela et j’ai dit que je voulais faire “ingénieur”. J’ai fait Centrale-Supelec, avec une formation très technique et un peu de programmation. Ce qui m’a le plus plu, à l’époque, c’était de créer des micro processeurs. Je trouvais ça tellement génial que je voulais aller bosser chez des fondeurs. J’étais particulièrement fasciné par les architectures RISC Power PC, avec déjà les idées de parallélisation, ce qui, en fait, préfigurait ce qui est devenu plus tard, le GPU. Je trouvai ça super excitant! ”

"En 3ème année d’école d’ingénieur, j’ai suivi un DEA sur les nouvelles architectures. J’ai trouvé un stage sur les réseaux et les calculs distribués (avant le démarrage du programme SETI) dans un département de Recherche du CNET (qui est devenu ensuite France Telecom R&D puis Orange Labs), dans le domaine des ORB (Objects Request Broker ou programmation réseau orientée objet). Le département où j’étais expérimentait des prototypes multimédia distribués temps réel, qui ressemblaient beaucoup à des jeux vidéo. Du coup, après mon stage, j’y suis resté 5 ans. ”

"En parallèle, je m’étais inscrit en thèse, pour faire une étude sur la réflexivité dans les systèmes distribués (dont un des principes est de créer des structures abstraites afin d’automatiser des traitements sans avoir tout à réécrire à chaque fois). Au bout de 2 ans, avec l’équipe de recherche, nous avions fait plusieurs prototypes très intéressants, et nous voulions construire toute une architecture à base de composants remplaçables, à froid ou à chaud. Mais cette année-là, France Telecom avait décidé de réduire la voilure de son centre de recherche d’Issy les Moulineaux en mettant en place une campagne d’accompagnement des personnels (avec un plan d’essaimage) à la création d’entreprise, pour ceux qui le souhaitaient (sur un principe de prise de participation dans le capital des futures entreprises). Je finissais tout juste ma seconde année de thèse, et avec mes autres collègues, nous nous sommes dits que c’était peut être le bon moment pour créer notre boîte. Nous avons sauté le pas en créant une start up, Kelua, dans laquelle nous proposions un système d’inversion de contrôle, à base de composants et d’un éditeur graphique. ”

"Parallèlement à cela, j’avais développé un site internet pour un bon copain qui était dessinateur. Profitant de l’arrivée du langage Java, j’avais pu rajouter dans ce site internet des fonctions interactives et j’avais fait un jeu vidéo, type Game & Watch (les petits jeux électroniques portables sortis par Nintendo entre 1980 et 1991) dans une page dynamique (en applet Java). Ce jeu là avait eu pas mal de succès (c’était avant la technologie Flash). Mes copains dessinateurs, Lewis Trondheim et Joann Sfar, avaient dessiné les différents tableaux de mes jeux. C’est comme cela que sont nés “Skull splitter 3”, un game and watch dessiné par Lewis Trondheim, ou encore “Ossour, perds pas la goutte”, un autre jeu dessiné par Joann Sfar. Nous avions alors pas mal de trafic sur ce site internet. C’est à ce moment-là que Fluide Glacial nous a contacté [le périodique de bande dessinée humoristique pour adulte]. Ses créateurs souhaitaient réaliser un site en ligne, @Fluidz, différent du magazine papier et dont le but était de proposer des expériences interactives avec des contenus originaux de dessinateurs. Nous leur avions fait 2 ou 3 jeux. En 2000, ils avaient sorti un numéro spécial de Fluide Glacial qui contenait un CD-ROM. Sur ce CD, il y avait, entre autres, le Tamagotlib, une version très particulière de Tamagotchi [animal de compagnie virtuel japonais, créé en 1996 par la société japonaise Bandaï] où tu pouvais élever … un dessinateur de bandes dessinées. ”

"Ne pouvant pas nous rémunérer au titre de droit d’auteur pour ce travail, l’éditeur de Fluide Glacial m’avait alors demandé de lui éditer une facture… Et comme je n’avais encore jamais fait cela auparavant, ils m’ont proposé un modèle, que j’avais rempli scrupuleusement. Mais j’avais buté sur le code RCS [numéro d'identification unique et officiel de l'entreprise au Registre du Commerce et des Sociétés] et pour cause, je n’en avais pas ! Je suis allé voir mes copains et je leur ai dit qu’il fallait créer une boîte pour avoir un code RCS pour pouvoir toucher notre dû. Joann m’a dit que parmi ses amis, il y avait son éditeur qui pouvait sûrement nous aider. Il s’agissait de Guy Delcourt, un entrepreneur dans l’édition. Nous sommes allés le voir en lui disant que nous devions créer une boîte. Et plutôt que de simplement nous accompagner, Guy a participé à la création de Pastagames en prenant des parts et en co-fondant avec nous le studio! C’est ainsi qu’est né Pastagames, en 2000, avec Fluide Glacial comme client, Guy Delcourt comme associé et Joann Sfar comme gérant officiel. ”

Bonjour Fabien, tout d’abord, comment définis-tu l’innovation dans ton domaine?

Bonjour rOmain. Je dirai que ça consiste à faire un truc où, au départ, quand tu commences à le faire, tu ne sais pas encore vraiment ce que c’est ! Quand tu le démarres, tu as juste une intuition, une direction générale, avec quelque chose dans tes tripes qui te crie que ça va être trop bien, mais tu ne sais pas encore à quoi te raccrocher.

Quand tu sens ça, tu sais déjà que ça va être compliqué, douloureux, long, mais, aussi, que ça va être innovant. Et quand tu commences à chercher autour de toi pour voir ce qui existe de ressemblant à ton idée et que tu ne trouves pas, alors là, c’est carrément super excitant.

Personnellement, je ressens cela très souvent, et même, j’avoue que j’adore cette sensation ! Cela fait partie des choses qui me poussent à me lever le matin, comme le fait d’apprendre des choses qui existent et que je ne connaissais pas, ou bien de pousser des idées claires dans ma tête mais qui n’ont encore jamais été réalisées.

Comment portes-tu cette innovation ?

Pour Pastagames, je dirais que j’ai une stratégie d’innovation a minima. Il se trouve que dans la boîte, nous avons tous un peu ce penchant naturel à vouloir faire des trucs bizarres que nous essayons de réfreiner autant que faire se peut. C’est pour cela que nous faisons des projets “à façon”, qui ont, en général, un brief assez clair de la part de nos clients guidés par l’envie de le vendre et parce que nous savons combien de temps cela prendra, combien cela va coûter et combien nous allons pouvoir marger. C’est ce qui paie nos salaires et nous rend contents.

Pour une société, je ne pense pas que ce soit souhaitable d’innover [rires]. Encore une fois, tu ne sais pas à quoi va ressembler le truc à la fin, tu ne sais pas comment le fabriquer, tu ne sais pas expliquer aux gens ce que tu veux, et quand ce sera fait, tu ne sauras même pas le vendre.

Par contre, pour les individus, c’est extrêmement exaltant intellectuellement !

Tiens, ça me donne envie de te raconter une petite histoire du studio.

C’était en 2003, à l’époque des premiers téléphones imode. Ils pouvaient exécuter du java (le DoJa) et ils étaient vendus avec un abonnement data illimité. Ces configurations permettaient d’avoir du code mobile téléchargeable via un système d’abonnement. les téléphones étaient équipés d’un écran 128x160 pixels, tout petit, mais qui pouvait afficher des choses. Avec Fabrice, nous avons créé un truc que nous avons adoré : une application web que nous avons appelé Pastagames (parce que c’était le nom de la boîte) qui proposait les services suivants pour les téléphones imode :

la première fois que tu te connectais, le site te proposait de créer ton avatar, un peu à la manière de Mr Patate (en choisissant de combiner des yeux, des bouches, des nez et des cheveux) et de te choisir un nom,

ensuite, sur le site, tu pouvais te faire des amis, eux aussi représentés par un avatar (fait comme le tient) où chacun se présentait par un petit texte,

tu pouvais ajouter des gens à ta liste d’amis,

tu pouvais publier tous les jours un truc sur ce que tu faisais,

tu pouvais créer une Discute, et inviter plusieurs amis à y participer : chaque fois que quelqu’un parlait, tu voyais sa tête (son avatar) avec une petite bulle de bande dessinée et ce qu’il disait, et l’autre, qui répondait avec une petit bulle, et tout ça, dans une page internet en html qui scrollait sur le petit écran du téléphone,

tu pouvais remonter les fils des conversations,

tu pouvais donc contacter des amis pour aller au restau, voir un film, etc.,

tu pouvais passer en mode privé pour des Discutes en one to one,

tu pouvais jouer avec des amis dans un jeu qu’on avait créé, où chaque joueur, ami ou ennemi, était représenté par son avatar.

Pour rappel, en 2003, il n’y avait pas encore les Mii (de Nintendo, qui sont apparus en 2006) et il n’y avait pas encore ni Facebook, ni Twitter.

Nous étions trop fiers ! Au top du top de la fréquentation, on gagnait 2000 € par mois de chiffre d’affaire. Nous avons maintenu le truc pendant 2 ans. Puis Facebook est sorti, ensuite les Mii, etc.. Rien ne nous a autant foutu dedans que ce projet là. Quand il est sorti, nous n’en avons rien fait ! Des histoires comme cela, j’en ai hélas plusieurs. Donc, depuis, on se calme.

Tout cela pour dire deux choses : il y a un bon moment pour innover, et être le first mover n’est pas forcément toujours bon. Ton innovation ne vaut rien si les gens ne la comprennent pas, ou si tu n’arrives pas, en une image, à leur faire comprendre ton idée.

Pour avoir un processus créatif plus efficace, il faudrait pouvoir identifier un besoin avant de se mettre en tête d’innover : je veux résoudre un problème bankable. C’est ce qu’a toujours fait Blizzard. Ils ont identifié le segment de marché dans lequel il y avait Ultima Online, qui marchait très bien, mais qui avait énormément de problèmes. C’est plus du problem solving, mais ça reste de l’innovation. Et c’est brillant ce qu’ils ont fait, puisque c’est devenu World of Warcraft.

Regarde aussi General Magic, en 1990, qui invente l’iPhone/iPad 15 ans avant l’heure. Ils font un truc plein de promesses, mais la technologie n’est pas tout à fait là : l’écran n’est pas très réactif, le processeur pédale. Ils se font piquer l’idée par Apple, qui sort le Newton, un peu mieux, un peu plus industriel. Derrière, le Palm sort, en reprenant seulement 10% de ce que faisait le Newton et 5% de ce que faisait General Magic, mais en le faisant bien ! 5 ou 10 ans après, l’iPhone n’a fait que rassembler toutes ces idées, en un seul produit, mais en mieux !

Là, il y a moyen d’avoir une innovation avec un business model : tu prends un machin qui a déjà une base installée, qui a déjà des utilisateurs, qui a des problèmes et des défauts, qui ne marche pas très bien. Tout criait à améliorer le truc, et à y ajouter un téléphone à l’intérieur pour être connecté !

Pourquoi est-ce si important d’innover ?

C’est notre moteur d’envies, celui qui est à l’origine de la création de la boîte. Tous les fondateurs de la boîte ont, chacun à leur façon, des envies de créer des trucs qui n’existaient pas avant.

Par exemple, Nadim, notre Game Designer. Il avait envie de faire un jeu online collaboratif entre des inconnus qui ne peuvent pas se parler.

Ou encore Fabrice, notre programmeur. Il avait une envie énorme de créer un langage de programmation dédié à l’IA (hors deep learning, ni algorithme génétique), qui serait basé sur des scripts adaptables pour le jeu vidéo.

Tous ces projets sont autant de flammes qui nourrissent notre envie de continuer à traverser les moments difficiles. Ce n’est pas facile d’être une petite structure indépendante, dans le secteur du jeu vidéo, quand tu vis seulement en autofinancement, sans prêt, sans investisseur, juste avec tes clients. Nous prenons quelques fois des paquets de mer ! Mais le fait de réinvestir notre marge dans notre R&D est très important dans notre fonctionnement. D’ailleurs, notre marge correspond à peu près au temps que nous pouvons passer sur nos projets internes, donc sur notre propre innovation.

Comment fais-tu pour innover ?

En général, nous essayons de nous convaincre, les uns les autres, de travailler sur l’idée de l’un d’entre nous. Ce n’est pas une démarche structurée ou organisée, tout se fait au fil de l’eau, en discutant à midi ou après une journée de boulot. Ces discussions permettent de faire croître l’envie chez l’autre d’en savoir plus sur l’idée de l’un ou de l’autre. La décision d’y aller se prend uniquement si nous arrivons à un consensus. Comme le processus d’innovation est itératif, nous en rediscutons à chaque boucle d’itération.

Au début, c’est assez simple : la direction est facile à voir et tout le monde est motivé. Puis, arrive le premier mur, la première grosse difficulté.

Pour illustrer mes propos, je vais prendre l’exemple du jeu que nous sommes en train de développer. C’est un jeu vidéo en ligne collaboratif qui s’appelle Karma Loop. Il se joue entre des personnes qui ne se connaissent pas et qui doivent, en groupe de 5, 10, 15 ou 20 personnes, arriver à résoudre des puzzles et avancer dans un niveau, tous ensembles. C’est un jeu coopératif : tout le monde gagne ou tout le monde perd. Les joueurs doivent donc se coordonner sans communication verbale, seulement avec du body language et des petits trucs dans le jeu. Tout cela, c’est l’idée de base que nous avons eue il y a maintenant 4 ans. Le projet, lui, a été lancé il y a 3 ans.

Pour le réaliser, nous avons choisi un jeu classique de type platformer, que tout le monde connaît : inutile d’innover dans tous les domaines et de prendre le risque de trop déstabiliser les joueurs. Nous étions tous d’accord avec cela dès le début.

Ensuite, nous avons déblayé tous les problèmes, à mesure qu’ils arrivaient : une des caractéristiques d’un projet innovant, c’est que tu ne sais pas anticiper les problèmes de mise en oeuvre (sinon, ce ne serait pas innovant !). C’est valable pour tout : là où tu pensais passer facilement, ça bloque, et là où tu croyais que tu aurais un problème, ça passe plutôt facilement.

Comme je te le disais, nous nous retrouvons souvent face à des murs et nous devons décider alors quoi faire. Il nous est arrivé une fois de supprimer purement et simplement un projet : le résultat nous convenait, au niveau réalisation, mais le jeu n’était pas aussi cool que ce que nous espérions, au final (c’était le jeu Explorobots). Il arrive également que nous fassions des pauses sur notre projet interne, ce qui explique que ces projets peuvent durer assez longtemps. Le temps de faire quelques projets à façon, par exemple, pour remplir notre compteur R&D !

Allez Fabien, tu peux m’en dire un peu plus ?

Pour recueillir les idées de l’équipe, j’utilise deux choses : mes oreilles et l’oubli. Quand quelqu’un arrive avec une idée, je l’écoute très attentivement (car j’adore écouter) et ensuite, je laisse passer du temps. Si je n’y pense plus au bout de 2 semaines, c’est que cela n’avait sans doute pas suffisamment d’intérêt. Si par contre j’y repense à plusieurs reprises, je vais aller voir la personne pour que nous en reparlions encore et encore, et si je n’arrive vraiment pas à me débarrasser de ce truc là, c’est qu’elle vaut la peine d’être creusée.

En gros, quand tu as une idée, la première chose consiste à la pitcher autour de toi, à des copains qui fabriquent des jeux vidéo, mais aussi à des éditeurs, des diffuseurs, des financiers, etc.. A toutes les personnes susceptibles de t’apporter un éclairage métier sur ce que tu fais.

Je considère qu’une idée ne vaut rien en soi, car tout est dans sa réalisation : c’est pour cela que je n’ai pas peur d’en parler. Et c’est le meilleur moyen de voir si elle tient la route. Quelqu’un te dira peut être que seulement un tout petit bout de l’idée est absolument génial et que, lui ou elle, a tilté là-dessus. C’est une information précieuse qui va façonner l’idée, la transformer jusqu’à la rendre réalisable ou pas.

Que ce soit pour les jeux Pasta, ou pour la gestion de la boîte, je considère que je n’ai aucun secret qui m’appartienne.

Dans mon processus, il m’arrive aussi de faire tester mes enfants, qui sont des joueurs différents de moi. Plus largement, les play-testeurs jouent aussi un rôle important dans la R&D, même s’il faut faire très attention à la temporalité de leur intervention : ni trop tôt, ni trop tard. C’est assez difficile de déterminer le bon moment : il faut avoir une version du projet dans un état qui permet aux play-testeurs de se rendre compte de l’intention du jeu. Mais il ne faut que ce soit trop moche graphiquement pour pas qu’ils bloquent dessus. Il faut que les contrôles ne soient pas trop approximatifs pour qu’ils n’aient pas une mauvaise sensation. Et il faut que le level design soit suffisamment avancé pour qu’ils n’aient pas non plus d’effort à faire pour se projeter dans ce qu’ils “pourraient faire”. Dans le cas de notre jeu Karma Loop qui propose une expérience pensée pour des groupes, de 5, 10, 15, 30 personnes, nous ne devons pas le faire tester tant que techniquement nous ne sommes pas capables de faire vivre ces personnes dans le même univers, sans lag et sans problème de contrôle. Si tu fais une version qui marche très bien avec 2 joueurs, ce que nous avons fait récemment, tu sais très bien que cela ne valide pas le jeu.

Comment stimulez-vous l’innovation chez Pastagames ?

Vu que l’innovation, la création, sont plus un risque qu’une opportunité, je n’ai jamais cherché à stimuler le processus créatif des gens avec qui je travaille :

soit les gens ont envie d’exprimer quelque chose et alors là, il faut être à l’écoute, en parler, et pourquoi pas travailler le truc ensemble : la seule chose que j’ai à faire dans ce cas là, c’est d’être à l’écoute.

soit ils ne l’ont pas et je ne vais pas aller les voir pour leur demander de me proposer quelque chose de foufou.

Faire de la veille constamment, c’est stimulant. Je joue beaucoup. Je regarde la GDC, je vais sur GDC Vault, Game Industry, je suis aussi des YouTubeurs, des cours en ligne, des masterclass; je rencontre des gens d’autres studios. Il y a les salons, comme celui de la Game Connection, qui permettent de rencontrer des personnes intéressantes que tu auras envie de revoir après. Le gros de ma veille, c’est vraiment les articles et les informations sur internet, comme les publications et conférences.

Je lis des articles du SIGGRAPH. Dernièrement, je devais résoudre le problème suivant : nous avions des bestioles qui se déplaçaient en meute vers une destination commune. Elles décident d’aller chacune au même endroit, et évidemment, dans le mesh de navigation, il n’y a pas la trace de leurs copines, donc il n’y a aucune raison pour qu’elles s’évitent. Et comme elles veulent toutes aller au même endroit, elles vont avoir tendance à se mettre les unes sur les autres. Le résultat ne ressemble pas du tout à une meute… J’ai donc cherché sur le net et j’ai trouvé de la bibliographie sur cette problématique, plutôt dans le monde des robots, avec des algorithmes de type Velocity object. J’ai finalement trouvé la solution à mon problème.

Une autre chose très stimulante, pour moi, c’est que j’adore donner des cours. J’ai donné des cours de programmation en Java, pendant 5 ou 6 ans, chez Orsys, au début du studio. En gros, je donnais des cours une semaine par mois, et le reste du mois, je faisais du Pasta. Aujourd’hui, j’en donnerais bien 3 ou 4 par an, d’une ou 2 journées. Tu ne comprends jamais aussi bien quelque chose qu’une fois que tu l’as expliqué à quelqu’un.

Un petit scoop, sur le futur proche ?

Pix the Cat, notre petit chat mascotte du studio, va reprendre du service, avec toute une bande de copains à lui. On a hâte, il nous a beaucoup manqué !