(Encore un billet orienté production, désolé. La faute au petit capo producer qui sommeille en moi. Promis on reviendra à des choses plus créatives après).

Être agile en production, c’est quelque chose que j’aurais bien aimé voir abordé lors d’une GameCamp, mais visiblement personne n’en a rien à foutre alors JE M’Y COLLE LES AMIS !

Beaucoup ont fait l’apologie du SCRUM et de ses bienfaits lorsqu’on l’applique à une pré-production de jeu vidéo. Ça marche assez bien lorsque l’on cherche à itérer sur son gameplay sans trop savoir à quel moment on va atteindre cet instant où le jeu est relativement amusant à jouer. SCRUM a l’avantage de pouvoir se tromper sans trop de gravité puisque l’on peut toujours corriger le tir et essayer d’autres choses (avec une inertie de deux à trois semaines, dépendant de la longueur de vos sprints).

Quand on rentre en production, idéalement (attention j’ai dit idéalement), côté LD, nos metrics sont verrouillées (c’est à dire que l’on connait la distance de saut du perso principal, etc etc), et l’on a pu faire une map de démo interne qui démontre que la plupart de nos mécaniques de jeu fonctionnent. Côté 3D, la direction artistique est également verrouillée, on a produit suffisamment d’assets pour en réutiliser une partie. Le pipeline de production est connu et « relativement » solide. On connait la plupart des contraintes techniques et on connait l’ensemble des maps que l’on va devoir produire.

Du coup pas mal d’inconnues sont levées, et rester en SCRUM pour la production n’a pas vraiment de sens (tout du moins sur des sprints de moins de 3 semaines). Cependant, la production de levels est assujettie à la production de toutes ses dépendances: animations pour les événements scriptés ingame, gameplay exotiques, interfaces, sons, etc. Sans oublier les résultats des playtests qui mènent à des retakes plus ou moins lourds, ou des cuts de portions de maps (à cause du manque de temps ou de budget) qui entrainent un temps incompressible de restructuration. On a donc des forces, mais aussi des risques.

Il faut parvenir à trouver un moyen de produire en masse, mais en étant suffisamment réactif en cas de problèmes (et putain des problèmes on sait qu’il va y en avoir).

Le Lean / Kanban peut répondre à une partie de ces problématiques. A condition de rentrer dans ses entrailles et de charcuter un minimum.

La théorie

Qu’est ce que le Lean?

Les principes de la production en Lean vient de chez Toyota. L’idée maîtresse est de réduire les déchets de production en orientant la production vers le consommateur final. Pour résumer salement: tout ce qui nuit à l’expérience du joueur peut être mis à la benne. Exemple typique: passer 3 mois sur une cutscene qui dure 5 secondes. (Contre-exemple typique: le bossfight de God of War 3 qui dure 25 minutes et a pris 18 mois à faire à 35 personnes). Deuxième exemple, plus pratique: pouvoir envoyer la portion de niveau validée niveau gameplay au 3D artist pour transformer la whitebox en truc acceptable graphiquement le plus vite possible, sans rogner sur la qualité.

Qu’est ce que le Kanban?

Ceux qui ont déjà eu affaire au SCRUM savent déjà de quoi il s’agit. Ce sont les post-its qui vont être collés au tableau Heijunka (qui ressemble fortement au tableau de SCRUM) pour indiquer la progression journalière d’un des niveaux du jeu, et ceci, entre les différents départements impliqués dans le développement d’un niveau de jeu: Level Designers et Level Artists forcément, mais aussi Concept Artists, FX Artists, Audio Designers, Lighting Artists, Animateurs, Intégrateurs Localisation…

Il s’agit donc d’un tableau garni de post-its qui, pour un niveau de jeu découpé en zones (pour des questions de streaming), aurait cette gueule là:

Lorsqu’une zone est prête à être transférée à un autre département, l’individu va simplement déplacer le post-it d’une case. Lorsque toutes les zone sont à Done, le niveau est prêt à être gravé sur la galette.

On se rend compte ici que le workflow est linéaire: Pas question au département artistique de toucher au niveau tant que le level design n’est pas validé. Si c’est honorable en théorie, en pratique c’est de la pure connerie.

(Bon je résume grossièrement mais cet article est parti pour être un putain de pavé alors pour plus d’infos, vous pouvez lire l’autre pavé de Clinton Keith sur Gamasutra)

Ma théorie (aka Channouze’s Lean & Kaban for videogamez)

Tout cela est bien gentil, mais c’est très incomplet si on veut l’appliquer tel quel dans une prod. De toutes façons, comme pour toutes les méthodes agiles, c’est en la pliant à nos besoins spécifiques que l’on devient forgeron. En l’état, c’est cool pour avoir un aperçu de la progression du niveau. En pratique si quelque chose coince, impossible d’avoir accès aux détails. Optimisons un peu tout cela.

Première étape: calibrer le tableau pour chaque milestone et pour chaque métier

La plupart des studios de développement utilisent différents jalons pour marquer les différentes étapes de la production: on parle ici d’alpha (également connue sous le nom de feature-complete), de beta (data-complete) et de release candidate (submission-ready). Il faut donc que le tableau représente ces fameux jalons, le Done correspond alors à la milestone en cours. Il est inutile de continuer à suivre des étapes déjà accomplies: on va donc remettre à zéro le tableau de suivi chaque fois qu’une milestone est complétée.

Ensuite, établissez la liste des métiers qui ont vraiment rapport avec votre niveau. De l’un à l’autre certains intervenants peuvent changer et du coup on perd en optimisation. Pour un jeu de bagnole le script on s’en cogne par exemple. Pour la milestone Beta, inutile de se refarcir des concept arts. Soyez malins.

Seconde étape: rendre chaque métier exhaustif

Lorsque l’on rentre en production, on connait la nature de chaque tâche pour un niveau donné. Par exemple, on sait qu’un Level Designer va devoir poser des covers (pour un TPS) et scripter les missions. On sait également qu’un Level Artist va devoir créer une diffuse map pour ses modules. L’inconnue majeure par contre est de savoir la quantité exacte de ce qu’il va falloir produire/placer: Tous les meshes 3D n’ont pas besoin d’une normal map par exemple.

A ce moment là, il convient d’avoir le pipeline de chaque département sous la main, avec la liste des tâches usuelles. Chacune de ses tâches se retrouvera sur un post-it que l’on va coller PAR DESSUS le post-it générique de « Zone ». En voilà un échantillon pour vous faire une idée:

Chaque post-it a une durée fixe d’une journée. C’est pourquoi l’on n’inscrira pas les temps estimés dessus contrairement au SCRUM. Tous les matins, le LD devra puiser dans sa banque de post-its et remplacer sa nouvelle tâche par l’ancienne. Si jamais une tâche prend plus d’une journée, c’est qu’il y a un problème et c’est au producer ou au lead de le résoudre.

Ca réclame beaucoup de travail en amont, notamment pour décomposer la production d’un niveau en éléments simples. Les post-its devront être préparés à l’avance, ça va de soit. Et encore mieux, avec des gens compétents (seniors et leads). Comme nous sommes agiles, on va laisser quelques post-its vierges pour pouvoir les remplir en cas d’imprévus, le matin même lors du stand-up meeting.

Pour les tâches inférieures à 1 journée, vous pouvez les grouper sur le même post-it ou bien coller 2 post-its ou plus les uns sur les autres (attention à ne pas tuer trop d’arbres dans le processus).

Pour les tâches supérieures à 1 journée, vous les décomposerez en autant de « passes » et de post-its.

Au niveau de la granularité, inutile de descendre trop bas niveau. Comme je l’expliquai un peu plus tôt, un artiste 3D ne va pas forcément créer un post-it pour ses normal ou ses specular maps sur chacun de ses assets. Un simple post-it genre « modules atrium zone 43: UVMap(s) et Textures » fera l’affaire.

Troisième étape: Distinguer les bottlenecks des tâches parallélisables

Si votre technologie et votre pipeline le supportent, vous pouvez paralléliser certains aspects du développement du niveau. Par exemple, les lighters, les FX artists et les intégrateurs audio ont généralement leur layer dédié et ils peuvent progresser en même temps que les autres. Cela vaut également pour les Level Artists qui vont commencer à remplacer certains assets non critiques placeholders par du définitif (les arrière-plans ou les props par exemple). Au contraire, certaines tâches plus bas niveau comme la mise en place du streaming pour la découpe en zones ou la création de la hiérarchie des fichiers du niveau agissent comme entonnoir: elles doivent être accomplies avant que les autres corps de métier puissent intervenir.

Durant la pré-prod, lors de l’établissement des pipelines, vous devrez définir les tâches qui sont parallélisables de celles qui ne le sont pas. Une couleur de post-it différente pour les distinguer n’est pas du luxe.

Souvent, le ratio entre Level Designers et Level Artists n’est pas égal à 1. Si les LDs sont en surnombre, c’est pas trop mal car on peut leur donner des niveaux en extra sans support du level artist dans lesquels ils vont pouvoir faire toutes les tâches prioritaires. Là où le bât blesse c’est que le LD a absolument besoin de collaborer avec son Level Artist sinon il y a de grandes chances qu’il finisse en position fœtale dans les WCs du 5eme.

Quatrième étape: ne pas être trop à la bourre niveau planning

Il convient désormais de prioriser nos post-its. Tout ce qui n’est pas parallélisable doit être accompli en premier afin que le corps de métier suivant puisse prendre le relais le plus vite possible.

Pour gagner du temps, il y a trois façons de procéder:

• Faire une passe dans la banque de post-its et de virer ceux qui n’apportent pas suffisamment de consumer value. Radical mais parfois réducteur.
• Supprimer les passes « 2 et plus »: Moins de polish mais au moins la feature est dedans.
• Diviser le temps alloué par deux, c’est à dire s’engager à boucler 2 post-its par jour. Cela force le designer à choisir où mettre le coup de polish. Ça réclame un minimum de maturité car il faut choisir ce que l’on va sacrifier au profit du reste. La review peut agir en garde-fou dans certains cas.

Cinquième étape: Gérer les blocages

Tout le monde le sait, les Level Designers ont la chance d’être en bout de chaine (haha les cons). Ce qui veut dire que lorsque le moment est venu d’intégrer les cinématiques in-game, les anims ne sont pas prêtes. La solution la plus simple est de puiser dans la réserve de post-its pour trouver de quoi meubler le temps que l’on mette un n-ième rouleau de scotch par dessus ce foutu exporteur conçu par le stagiaire imposé par le patron (c’est la solution court terme, autrement connue sous le nom de fuite en avant).

Pour les solutions long-terme, lors de la préparation des post-its, vous pouvez ajouter un petit icône distinctif qui dit: « Cette tâche est dépendante d’une autre ». Le rôle du producer consistera à vérifier la disponibilité des assets à intégrer; s’ils ne le sont pas il peut retirer les post-its incriminés de la pile et les mettre dans le bac portant la mention « Bloqué ». Il pourra revenir dessus régulièrement. En tous cas il n’y a clairement pas de solution miracle.

Sixième étape: La gestion des cuts et du refactoring (et la fin de prod en général)

Une prod de jeu vidéo n’est pas une vraie prod sans cuts ou sans refactoring. Les cuts, ça fait parti des imprévus qu’il faut anticiper même si la prod se passe à merveille. Personne n’est à l’abri d’une décision éditoriale saugrenue, prise entre deux rails de coke. D’un seul coup, la map « n’est plus fun » ou est devenue « trop longue » alors qu’elle a eu les meilleures retours lors des playtests 3 jours auparavant.

Dans le manuel du petit producer en herbe, on prévoit 20% de temps en plus pour les impondérables. Ici on peut se permettre d’aller plus loin: chaque zone peut potentiellement être cuttée; il s’agit donc de prévoir à l’avance le temps de refactoring que cela implique, et cela pour une zone donnée. Quelques exemples de post-its pour le refactoring: « Rebrancher le streaming » , »Mettre à jour les objectifs », « Mettre à jour les dialogues »…

Bien sûr, certaines tâches liées à la gestion des cuts ne peuvent être prévues à l’avance car elles vont être étroitement liées aux spécificités du niveau et de la zone qui ne seront pas connues en pré-prod. Il convient de se réunir pour établir le contenu de ces post-its peu de temps après l’annonce du cut.

Parfois, un plaisantin vous demandera de livrer une version playtestable pour genre demain. Envoyez-le chier. Listez ce qui est nécessaire pour livrer, décomposez tout ceci en tâches, inscrivez-les sur les post-its. Vérifiez les dépendances, les bottlenecks, les métiers impliqués. Et en avant.

En fin de production, lorsqu’il s’agit d’implémenter les derniers 20% du jeu, quadruplez les estimations.

Comment appliquer le Lean & Kanban ?

Alors vous allez rire mais je n’ai jamais appliqué ce genre de méthode en prod. Donc vous allez me dire « Pourquoi je le ferai si toi t’as pas les couilles de le faire ? Tu pourrais me coûter des millions d’euros ! » J’ai néanmoins un avis là dessus:

• Ne faites pas de Lean/Kanban en préprod ! Les systèmes de jeu sont trop rudimentaires pour expérimenter cette méthodologie, les pipelines ne sont pas rodés, vous courrez droit au désastre.
• N’instaurez pas le Lean/Kanban en milieu de prod ! Ca n’est probablement pas nécessaire de le mentionner; après tout, on sait ce qui est arrivé à Darkworks lorsqu’on leur a imposé un ersatz de Scrum pour finir I Am Alive.
• Si vous êtes moins de 10 dans votre studio: C’est inutile. Désolé vous avez perdu votre temps à lire cet article.
• Si vous faites une suite basée sur la même technologie: C’est le bon moment pour expérimenter le Lean !
• Si vous faites un DLC: c’est encore mieux. Peu de changements de techno, scope réduit, petite équipe, foncez !

Le Daily Standup Meeting

Rien de sorcier ici; on réunit durant une dizaine de minutes tous les intervenants sur le niveau de jeu et on colle et décolle des post-its suivant les travaux de la veille et ceux de la journée. On énumère les tâches bloquées pour les résoudre dans la journée, etc.

Pour plus d’efficacité, le LD peut en fin de journée préparer son post-it du lendemain. Il est important que le LD décide quelle tâche il doit accomplir plutôt qu’on lui ordonne le contraire. Laissez-le s’organiser dans son travail.

Lorsque toutes les tâches non parallélisables sont terminées pour un métier donné, le post-it de zone peut passer au corps de métier suivant. Le LD, dans notre cas, est alors libre de puiser dans les tâches parallélisables.

Contrôler la qualité

Avec un rendement relativement élevé (une tâche à vérifier par journée), le responsable de la qualité finale, qu’il soit lead ou producer, peut être noyé sous la masse de travail accompli. Le meilleur moyen de s’en sortir est de faire des reviews régulières au cours desquelles on apporte les post-its complétés pour vérifier l’ensemble de la progression. Si jamais un aspect du niveau parait peu probant, le responsable replacera les post-its liés dans le bac à Todo. Le planning sera ajusté pour tenir compte du temps supplémentaire nécessaire. Ceci dit, certains post-its triviaux ne nécessitent pas de review formelle. Assurez-vous de les identifier.

Notez que tous les post-its validés ne devront plus jamais être remis sur la table une fois la réunion terminée. Je vous fais confiance pour tenir tête au Creative Director sur ce coup-là. Le but est d’éviter le syndrome du « la map n’est plus fun » qui arrive tellement souvent et qui me donne envie de pleurer à chaque fois (je suis très émotif).

Trop de micro-management ?

Peut-être qu’un suivi journalier est considéré comme trop procédurier, et peut être ressenti comme une contrainte forte parmi les membres de votre équipe. Je suis entièrement d’accord avec cela, et cette méthodo est entièrement extensible (comprendre scalable à défaut d’une meilleure traduction): Vous pouvez faire des post-its à la semaine par exemple, en opérant par groupement de tâches. On perd de l’agilité mais si c’est pour le bien-être de vos camarades de tranchées, c’est un mal pour un bien. Tout est une question de comment vous voulez équilibrer le contrôle par rapport à la liberté (j’ai l’air d’un gros nazi en disant ça c’est rigolo).

Des milliards de post-its

Ça oui vous allez en bouffer. Il y a probablement moyen d’optimiser un peu, je vous laisse maître pour aller de l’avant. Un plugin pour Hansoft quelqu’un ?

En fait ton truc c’est un mélange de scrum et de lean

Exactement.

Un récap du workflow ?

On doit certainement pouvoir trouver une meilleure représentation.

Notes

• Pour les puzzle games: Triplez les estimations de cut/refacto.
• Pour les boss fights: Traitez-le comme un niveau à part entière et adaptez les corps de métiers.
• Incorporer les résultats des playtests: Prévoyez-le à l’avance mais notez que vous ne pourrez probablement pas tout faire. Choisissez vos batailles avec soin.
• Accélérer la validation: Déléguez-la à vos seniors.
• Votre techno ne supporte pas la parallélisation: Vous pouvez probablement appliquer le Lean / Kanban tel quel. Cela dit je décline toute responsabilité si votre publisher vous jette par la fenêtre.
• C’est beaucoup de boulot de planification, d’allers-retours, de concertation etc. Ne lâchez pas et pensez à vos bonus si vous shippez à temps (haha… hum.)

Et pour finir (promis)

Je crois que c’est le plus gros tl;dr de ma vie. Quelques confessions: c’est ma première itération sur le sujet et comme l’a dit Christophe Balestra un jour « Votre première itération c’est toujours de la merde ». C’est aussi la première fois que je me mets dans la peau d’un producer, métier que j’ai haï lors de ma toute première prod (bisous Renaud!). Je compte sur vous pour me faire part de vos remarques, exploits et autres 0-day hacks que vous pourriez glaner au fil de votre lecture. Les commentaires sont encore pétés c’est regrettable mais je suis toujours joignable à l’adresse suivante:

Je reproduirai vos commentaires ici (et j’essaierai d’y répondre si mon skill me le permet).