Vous êtes ici : AccueilFinal Fantasy 13Post Mortem

Post Mortem

Un post-mortem (ou autopsie en français) consiste à revenir sur le développement d'un jeu afin de voir et d'analyser ce qui s'est bien passé et ce qui s'est mal passé. L'exercice permet de prendre des mesures en conséquence afin d'être mieux préparé pour les développements suivants.

Ce que nous vous proposons ici, c'est un post-mortem sorti en octobre 2010 dans le magazine Game Developer. Motomu Toriyama, scénariste et producteur du jeu, avec Akihiko Maeda, du service finance de Square Enix, reviennent ainsi sur le développement laborieux de Final Fantasy XIII, premier du nom sur les consoles de nouvelle génération (PS3/Xbox).

La série FINAL FANTASY n'est pas seulement l'un des étendards de Square Enix mais également une marque qui représente le JRPG dans son ensemble. En tant que tel, l'équipe de FINAL FANTASY XIII a eu pour mission de vendre cinq millions de copies à travers le monde. FINAL FANTASY VII (Playstation) et FINAL FANTASY X (Playstation 2) sont sortis au moment où les consoles changeaient de génération. Les deux titres sont reconnus pour avoir mis en place de nouveaux standards, pas seulement dans le JRPG, mais également en terme de graphisme, de gameplay et de narration. Avec ces attentes déjà en place, l'objectif dans le développement de FINAL FANTASY XIII, premier né de la série sur Playstation 3, était de créer quelque chose qui aurait le même impact en termes de gameplay et de savoir-faire.

Le but du projet a été de créer un jeu avec l'impact attendu d'un FINAL FANTASY numéroté. Le moins que l'on puisse dire, c'est qu'il s'agissait d'une notion un peu abstraite. Essayer d'atteindre un tel but, ouvert à tant d'interprétations, était quelque chose avec lequel l'équipe a du jongler durant tout le développement.
Avec l'apparition de la PS3 et reconnaissant les piliers d'un FINAL FANTASY, nous savions que nous devions changer la manière de faire que nous avions adopté pour la PS2. Dans le même temps, le fait que les moteurs de jeux devaient être créés en interne pour les consoles de nouvelle génération était devenu évident. Bien que cela prendrait énormément de temps au début, nous pensions que la productivité augmenterait sur le long terme. Le changement de plateforme requiert une importante restructuration des pratiques existantes de développement. Cependant, la direction du jeu et son scénario ne s'éloignait pas trop de la vision originale prévue pour PS2. Et la stratégie de développement était simplement une extension de nos pratiques habituelles, dans laquelle les membres de l'équipe avec des talents spécifiques, tels que la modélisation ou la création des décors, resteraient concentrés uniquement sur leur spécialité.

Nous avons fait face à de nombreux challenges dans la première moitié du développement, mais il y a eu un point où la situation a commencé à s'améliorer. D'habitude, on commence un postmortem avec les choses qui se sont bien passés. Cependant, dans celui-ci, nous allons regarder le projet dans l'ordre chronologique des évènements, ce qui nécessite de commencer par ce qui s'est mal passé.

:: Les aspects négatifs

1) Une absence de vision commune

FINAL FANTASY XIII a été présenté pour la première fois à travers un trailer dans la foulé de l'annonce du projet FABULA NOVA CRYSTALIS à l'E3 2006. Le trailer était plus ou moins un concept visuel, et nous n'avions encore rien créé de jouable à ce moment là.
Je sentais que ce trailer fixait la qualité que nous voulions atteindre, en termes de vitesse de combat et de graphismes, et nous pensions que ce sentiment était partagé par le reste de l'équipe. Cependant, il est devenu clair que, à ce moment là, il n'y avait en fait que très peu de membres de l'équipe qui voyaient dans ce trailer une représentation de ce que nous voulions atteindre avec FINAL FANTASY XIII. Cette absence de vision commune devint la base de nombreux conflits qui ont émergé plus tard.

2) Le moteur multi-plateforme et vision à la baisse des caractéristiques

Un autre problème fut le moteur du jeu. Parce que nous étions tellement concentrés sur la création d'un moteur unique pour les consoles nouvelle génération que nous avons fait l'erreur d'essayer de l'adapter en même temps à tous les projets en cours. Avec le recul, il aurait du être évident qu'il était impossible de satisfaire pleinement tous nos désirs. Résultat, nous avons passé un temps considérable à classer par priorité nos différentes demandes pour finalement ne pas être capable de déterminer les spécifications finales du moteur. Ceci a alors créé un gel des équipes de développement, du moteur et des jeux. En effet, si les caractéristique du moteur ne pouvaient pas être finalisées, alors les jeux non plus. Comme les débats continuaient sans trouver de solution, le calendrier en a également été affecté.

3) Commencer malgré tout

Vu la tournure prise par les évènements, le staff impliqué dans la création des données n'a pas eu d'autre choix que de commencer à travailler avant que les spécifications soit finalisées. Leur plus grande inquiétude était de ne pas tenir le calendrier s'ils continuaient à attendre les décisions finales. Après avoir calculé une estimation du volume total de données basée sur l'ébauche du script et sur l'expérience des projets précédents, l'équipe ressentit la nécessité d'augmenter le staff. Avec l'accroissement du personnel, la communication devint confuse, et même après que les spécifications soient fixées, nous avons du revenir sur nos pas. Dans certains cas, les données créées ne pouvaient même pas être utilisées. C'était non seulement une perte de temps, mais également un facteur de démotivation pour tout le monde.

4) Les limites de la structure traditionnelle de l'équipe

Comme l'envergure du projet augmentait, la méthode traditionnelle de développement consistant à diviser l'équipe en fonction de rôles spécifiques (comme la modélisation de personnages ou la création des textures) commença à poser également un problème, celui de la sur-spécialisation. Le projet était gonflé par l'augmentation du staff à travers chaque département. Et parce que les rôles étaient trop spécifiques, la communication devint mauvaise et les informations ne furent plus partagées correctement. Les mises à jour des spécifications en sont un exemple : tous les membres n'étaient pas toujours au courant des dernières informations à ce sujet et, parfois, l'équipe continuait de créer des données sans prendre en compte les derniers ajustements.
Par le passé, nous avons toujours créé le contenu graphique de manière à ce qu'il soit exploitable sous tous les angles, pour être adaptable à toutes les situations. Pendant le développement, il y avait une règle tacite pour tout produire dans les moindres détails. Cependant, la transition vers les consoles modernes a repoussé les limites des détails à un niveau jamais atteint, augmentant la charge de travail de manière considérable. Résultat, certains membres ont épuisé leur énergie pour quelque chose qui durait moins d'une seconde dans le jeu final.

5) Les tests à l'international lancés trop tard

Avant même que la génération actuelle ne soit lancée, il était évident que le marché du jeu vidéo en occident atteignait son apogée et nous ne pouvions pas l'ignorer. Le sentiment qui ressortait le plus à ce moment là était les critiques très dures envers le JRPG. La linéarité et le système de combat étaient deux choses mal perçues. C'était quelque chose dont l'équipe avait totalement conscience et nous avions des inquiétudes quant à savoir si un JRPG serait toujours accepté en occident. Parce que FINAL FANTASY XIII se devait d'être un succès mondial, nous ne pouvions ignorer ce problème qui pourrait affecter profondément le futur de la franchise. A peu près à la même époque, nous expérimentions avec l'occident des méthodes de développement. Il y avait des discutions globales au sein de l'équipe, ce qui n'avait que rarement été conduit pendant les projets précédents. Dans le même temps, Square Enix instaurait des groupes internationaux pour certains titres, dont FINAL FANTASY XIII. Malheureusement, nous étions déjà trop loin dans le développement, et nous savions que cela aurait pris trop de temps de prendre en compte la plupart des retours des sessions de test. Mais même ainsi, nous avons saisi cette opportunité pour voir comment les joueurs occidentaux allaient réagir à notre travail au moment de sa sortie.
Il y a eu quelques petits accrocs, comme nous n'avions pas eu assez de temps pour nous préparer pour ces cessions, mais nous étions capables de conduire globalement avec succès les tests des joueurs et leurs entretiens. Même s'il était trop tard pour prendre en compte la majorité des retours, la plupart des membres de l'équipe eurent le sentiment que les tests valaient la peine, leur donnant une idée de ce que les joueurs voulaient globalement. Tout ceci fut pris en considération mais en l'absence d'une communication audible, le staff n'a pas reçu d'instructions claires. Il en a résulté des conflits à l'intérieur de l'équipe sur le fait de savoir si ça valait la peine de forcer certains changements dans un calendrier déjà serré.

:: Les aspects positifs

A cause de cette combinaison d'absence de vision, de la dépendance envers le moteur graphique et de la structure traditionnelle de l'équipe, le projet traversait des temps difficiles. Cependant, nous avons été finalement capables de résoudre nos problèmes et de les dépasser à travers les méthodes suivantes.

1) Bâtir une vision partagé à travers la démo

Même à un stade avancé du développement, nous n'étions pas d'accord sur des éléments clefs du jeu à cause de ce manque de cohésion dans la vision globale, du manque de spécifications établies et de la persistance de problèmes de communication entres les départements. Ce qui nous a permis de régler ce problème, apparemment sans fin, a été le processus de développement de la démo incluse dans la version japonaise du blu-ray Final Fantasy VII : Advent Children Complete. La démo n'était pas prévue à la base, nous avons donc du faire des ajustements de calendrier pour la prendre en compte. Peu importe les effets sur le calendrier. Une fois terminée, nous avons réalisé que c'était exactement ce qu'il nous fallait. Avec une version tangible et jouable du jeu, les débats internes sont passés de discussions théoriques basées sur des concepts abstraits à des dialogues concrets. La démo n'a pas seulement unifié la vision et la compréhension du jeu pour toute l'équipe mais cela a été également la première fois que tout le monde pouvait voir exactement le résultat de leur travail dans le jeu. Pendant le postmortem interne, beaucoup de membres ont noté que la démo leur a permis de comprendre et d'assimiler la vision de FINAL FANTASY XIII. Bien qu'une « vertical slice » (expression pour désigner ici un moment où l'avancement du projet est présenté par tous les départements) soit commune pendant le développement en occident, cela n'a en fait jamais été pratiqué avec nos équipes avant qu'il n'y ait un besoin de la compagnie. Avec du recul, cette démo a été notre « vertical slice » et son efficacité a été ressenti par chacun des membres de l'équipe. C'est un point essentiel à retenir dans notre approche du développement pour le futur.

2) Clarification des éléments des processus à travers le développement de la démo

La démo a rassemblé tous les éléments développés qui étaient précédemment non-coordonnés, clarifiant de nombreuses choses et déterminant plus rapidement les spécifications restantes.
Au lieu de modéliser en détail tous les éléments pour qu'ils soient parfaits sous tous les angles, l'équipe pouvait évaluer les efforts à fournir en gardant en tête exactement comment les éléments allaient être utilisés dans le jeu. Cela a permis d'augmenter les capacités de l'équipe à fixer des priorités et, ainsi, d'augmenter également sa productivité. Avec une bien meilleure appréhension de la charge de travail, nous avons pu planifier des calendriers plus précis, si efficaces que nous n'avons jamais raté une étape.

3) Création du poste de coordinateur général

Alors que la planification ne collait pas, nous avons commencé à réaliser que nous n'étions pas capables de continuer sans modifier la manière de partager les informations. Pour résoudre le problème, nous avons créé un nouveau poste qui n'existait pas dans notre environnement de développement : le coordinateur général, qui aurait comme fonction de faire le lien entre les différents départements. Ils ont ainsi pu faire des ajustements sur à peu près tout, des cutscenes aux combats. La communication a de ce fait été grandement améliorée à tous les niveaux mais en plus, cela a été une bonne expérience pour ceux qui souhaiteraient par la suite conduire un projet. Le processus se basait majoritairement sur le talent individuel de chacun, il y a donc eu des disparités sur la qualité finale. Sans oublier le fait que ces managers n’avaient pas de réelle autorité, les empêchant de prendre des décisions. Il n'y a cependant aucun doute sur le fait que ces coordinateurs ont eu un rôle extrêmement positif sur le projet.

4) Réduire le nombre de points à corriger à travers les groupes de réflexion

À travers les groupes de réflexion que nous avons mis en place (mentionné dans la section « Ce qui s'est mal passé »), nous avons constaté que, contrairement à ce que l'on pensait, le jeu a été très bien accueilli par les joueurs occidentaux. De plus, japonais et occidentaux ont surtout aimé l'histoire et les combats, signifiant que le style que nous avons adopté pour FINAL FANTASY XIII a été apprécié après tout. Avec cela, nous étions plus confiant sur le fait que le jeu pouvait être un succès à l'étranger. Maintenant que l'équipe avait entendu les joueurs, le désir et la motivation d'améliorer le jeu s'est accru. Jusqu'à ce moment, le développement n'était basé que sur des avis personnels.
Dû au fait que les joueurs occidentaux étaient très pointilleux sur les combat, leurs retours et demandes ont été portés à l'attention du staff comme étant des points importants à régler que nous avons essayé au mieux d'incorporer dans la version finale.
Grâce aux tests, nous avons pu mieux connaître notre jeu et, à la fin, la plupart de l'équipe ressentait que même si tout n'était pas parfait, au moins cela valait la peine. Cette expérience conduisit à des discutions sur comment se servir efficacement des connaissances acquises grâce aux tests pour nos futurs projets.

:: Ce qui a changé le projet

Avec du recul, certains problèmes ressortent. Les informations n'étaient pas partagées de manière optimisée. Il y avait un manque de communication. Les spécifications n'étaient pas claires. Le concept n'était pas clair. Tels ont été les plus gros problèmes qui ont perturbé le développement. Les solutions évidentes auraient été de tenir des réunions pour discuter de l'avancement du projet, de standardiser le workflow (anglicisme, diffusion de l'avancement), clarifier les structures de l'équipe et les lignes de communication, et demander des documents pour tout. Mais ces actions auraient-elles vraiment résolues tous nos soucis ? Peut-être temporairement, mais elles n'auraient pas réglé la racine du mal. Avoir le moteur universel stable et assigner des coordinateurs ont été des plus indéniables mais ce qui a le plus aidé notre projet a avancer, ce fut la démo, qui pouvait être jouée et vue. Finalement, tout le monde pouvait discuter du contenu du CD. Résultat, tout le monde était à la page et avait une compréhension claire sur ce que le jeu cherchait à atteindre. Les développeurs occidentaux n'ont pas fait grand chose de spécial ou sortant de l'ordinaire. Ils ont simplement fait ce qui était nécessaire, ce qui faisait sens. Si nous avions été capables de faire ces tests plus tôt, beaucoup de problèmes auraient pu être réglés bien en amont.

Écrire un commentaire

Vous devez être inscrit(e) et connecté(e) pour pouvoir poster un commentaire.
Inscrivez-vous dès maintenant !