A l'époque où je travaillais pour Ankama, j'ai eu la chance de diriger très vite une petite équipe sur le petit projet qu'était Dofus-Arena. Je m'étais alors documenté sur les méthodes de production et de gestion de projet et j'avais essayé d'appliquer et d'adapter mes lectures à notre jeu. Peu de temps après mon arrivée chez Ivory Tower, dans le giron d'Ubisoft, je me suis rendu compte que ce qui avait le plus changé dans mon boulot de game designer était en fait directement lié à la méthode de production et non au design du jeu. C'est partant de cette constatation que j'ai voulu pousser un peu plus la réflexion et à l'époque, je me suis dis que ça pourrait être intéressant d'en faire un ticket sur le blog.
Que serait un article de méthodologie sans une image d'engrenages ?
Le passage d'une petite équipe (Ankama) à une grosse équipe (Ivory Tower) de production que j'ai connu est finalement semblable à celui que l'industrie à connu (exception faite bien sûr des productions indés), débutant dans un garage pour arriver aujourd'hui à des productions partagées entre plusieurs continents à des équipes pouvant atteindre le millier de personnes. La réflexion part donc de mon expérience et j'essaye de l'appliquer à l'évolution de l'industrie.
Commençons avec quelques mots sur la méthodologie. La méthodologie, c'est la science de la méthode, l'étude de la méthode. Quand on parle de méthodologie de production, c'est la réflexion sur la façon de produire (un jeu dans notre cas). Pour parler de choses plus concrètes, parlons de suite de deux méthodes de productions que l'on peut rencontrer dans le jeu vidéo : Le Waterfall et la méthode Scrum.
Le Waterfall est une vielle méthode de production qui divise le travail à accomplir en phase (étude des pré-requis, design, implémentation, cf le schéma ci-dessous) et dicte que l'on ne peut commencer une phase que quand la précédente est terminée (et donc on ne peut revenir en arrière sur une décision de design, une fois son implémentation débuté). Autant dire que cette méthode est difficilement applicable de manière stricte à la production d'un jeu vidéo : Il arrive fréquemment qu'on ne se rende compte que lors de test qu'un design n'est pas bon, pas fun et qu'on désire le changer.
Méthode Waterfall
La méthode Scrum, une méthode dite « Agile », est bien plus malléable et fonctionne sur le principe des itérations : On délivre régulièrement une version jouable qui sert à valider (ou non) les implémentations en cours et qui permet aussi d'analyser la vélocité de la production et donc d'estimer plus précisément une date de passage en gold du jeu, par exemple.
Ce qui est surtout intéressant dans les méthodes Agiles c'est qu'elles ne sont pas un ensemble de règles strictes gravées dans le marbre. Un des points les plus importants du manifeste Agile est qu'il faut adapter la méthode à son équipe, à son projet.
Méthode Scrum
La méthodologie de production est donc importante pour chaque projet et équipe. Si dans un premier temps, elle devrait surtout être l'apanage des producteurs, elle est en fait tout aussi importante pour un game designer, métier central à la production d'un jeu vidéo dans le sens où le game designer intervient auprès de tous les corps de métier et durant toutes les phases de conception, de la pré-production au passage gold du jeu.
Cette place centrale va faire que souvent, un game designer aura son mot à dire sur les méthodes de production (ou sera frustré de ne pas pouboir le dire ^^).
Combien de temps pour designer et implémenter un mode multi sur un jeu qui à la base ne s'y prête pas (genre l'infiltration, avant que Splinter Cell et Assassin's Creed s'y penche) ? Il va falloir bien définir ce que l'on désire vraiment pour répondre à cette question, si l'idée est (et c'est malheureusement trop souvent le cas) de garder exactement le même gameplay que la partie solo mais cloisonné dans une arène avec 7 autres joueurs, alors ce ne sera pas très long, il y aura peu de demande auprès des autres corps de métier et très peu d'aller-retour avec eux. On peut se donner X semaines et fonctionner avec une méthode de production proche du Waterfall.
Si par contre, comme Splinter Cell par exemple, l'idée est de vraiment créer quelque chose de nouveau, il va falloir adopter une approche bien plus Agile. Les game designers vont vouloir itérer sur le concept, faire de nombreux tests, voir ce que ça donne en jeu, demander aux game progs de leur coder une vue en FPS pour les mercenaires pour voir si ça marcherait, valider le concept, amener une autre idée, en retirer une qui ne marche pas, etc.
Cela demande bien plus de temps et d'implication des autres corps de métier et nécéssite donc une autre organisation de la production.
Lien entre qualité et réalité de production
Ce sont bien sûr deux exemples extrêmes, mais l'idée est que le game designer doit être capable, avec de l'expérience, d'anticiper et de choisir/proposer des méthodes de production adaptées à chaque tâche qu'il a à effectuer.
C'est d'autant plus important que des changements non-anticipés de design dans un pipeline de production peu adapté peuvent très vite soit coûter très chers, soit être impossible (et dans ce cas, on se trainera toute la production un mauvais et pesant choix de design).
J'aime beaucoup l'analogie des couches de l'oignon (qui vient de « The art of game design » si je me souviens bien) pour expliquer en quoi une mauvaise organisation dans la production peut coûter très cher :
L'idée est d'imaginer le jeu comme un oignon constitué de nombreuses couches. Au centre, on trouvera les couches de « core-gameplay », pour un jeu de plateforme on y trouvera donc les règles concernant la vélocité du personnage, la longueur de ses sauts, etc.
Chaque couche est bâtie sur les fondations de la précédente donc et enveloppe celle-ci. Et si un jour, alors que 10 niveaux de notre jeu de plateforme sont déjà level designés et en partie habillés, on se rend compte que le jeu n'est pas assez fun malgré ces super graphismes et que ce serait bien de rajouter un double saut absent jusque là ? Et bien il faut modifier une couche centrale de notre oignon et pour cela, il faut retirer toutes les couches précédente : le level design est à jeter vu que l'écart entre deux bloc doit être augmenté pour coller à la présence désormais de ce double saut, les monstres doivent changer de comportement IA également pour s'y adapter, etc.
Ceci n'est pas un oignon (mais un jeu video)
C'est ce genre de problèmes qui ont forgé une méthode de production plus solide et propre aux jeu vidéo, basée sur un important prototypage, l'utilisation de « place holders » permettant d'itérer et de tester un jeu sans avoir encore produit des ressources dont on ne connaitra pas précisément les propriété avant d'avoir suffisamment itéré le design.
Aujourd'hui encore, malgré les avancée dans la méthodologie de production pour les jeux vidéo, on emploie pas mal d'énergie sur chaque projet pour trouver au plus vite des méthodes qui marcheront bien avec ledit projet, l'équipe et le temps impartit. Et on ne veut d'ailleurs pas arriver à une unique façon de produire, chaque boite a son identité et sa façon de faire.
En me faisant toutes ces réflexions, je me suis aussi rendu compte qu'au final, la façon de designer un jeu est évidemment elle-même régie par des méthodes et que ces méthodes et leur compréhension sont vraiment à la base de la qualité d'un game designer. Etre un game designer, comme on le dit souvent, ce n'est pas être quelqu'un qui a plein d'idées pour un jeu, mais quelqu'un qui transforme des expériences en concepts de jeu, puis en mécaniques et au final en jeu. Et pour passer d'une étape à l'autre de manière efficace, il faut des méthodes (extrèmement itératives) qui seront de plus en plus efficace au fur et à mesure que l'on accumule de l'expérience.
Au final, la méthodologie tiens une place très importante dans le futur du métier de game designer. On ne trouvera pas d'aussi tôt la formule mathématique qui explique le fun, par contre on sera de plus en plus efficaces et aptes à créer des jeux dans des équipes pourtant toujours plus grosses.