Wildstar – Le processus de création de WildStar

Sur Gamasutra, Stephan Frost a écrit un article (pas d'interview, ce sont ses mots). Il nous parle alors du processus de création de WildStar et du maintien des dates limites.

Le premier point abordé, qui sert de prélude, est qu'un MMORPG n'est pas un seul jeu mais l'assemblage de plus petits jeux développés séparément mais qui ont des points communs. Il s'agirait du JcE, du JcJ, de l'artisanat, de la personnalisation, etc... Tous les joueurs sont intéressés par au moins un des aspects. Dans l'article du blog, Stephan Frost se propose de décrire le processus pour le contenu en JcE.

Les premiers pas

Nous avons une multitude de designers/créateurs de contenu ici à Carbine. L'un des premiers défis que nous avions à remplir était de nous assurer que tout le monde comprenne la propriété intellectuelle et le type de jeu que le producteur exécutif, le directeur créatif et le directeur artistique voulaient concevoir. Pour établir cette vision, nous avions besoin de solidifier la communication dans l'équipe.

Pour cela, des documents propres à chaque race ont été développés pour que tout le monde s'approprie les traits généraux des personnages et commence à créer du contenu là-dessus. Il y a également eu une Feuille de route du Contenu qui a été éditée pour ne pas s'égarer.

Établir les systèmes en jeu

Nous voulions être sûrs que la phase de progression ne se résumait pas simplement à des quêtes "Tuez 10 rats" qui affluent dans les autres MMO, donc nous avons développé des types variés de systèmes de jeu qui permettent d'interagir avec le jeu lorsqu'on y joue. Initialement, nous avons créé des prototypes, puis nous les avons affiné et au final, nous les avons inclus dans le jeu. Cette phase signifie que la création des modèles/éditeurs dans le jeu permet d'implémenter plus vite le contenu.

On y retrouve donc les quêtes, les vocations et les défis.

L'importance de l'entraînement

Quand vous travaillez sur un projet massif comme un MMO, c'est impératif que les nouveaux employés apprennent les systèmes et les processus. Cela parait évident, mais j'ai travaillé dans quatre sociétés de développement de jeux vidéo et Carbine est le premier studio de développement à disposer d'un régiment d'entraînements pour les nouvelles recrues. Sous la direction du Design Director et de l'un de nos Senior Designers, nous avons pu mettre en place un programme de formation. La navigation sous JIRA, les pratiques de conceptions vidéoludiques et les traditions (Lore) sont enseignées aux nouveaux designers pour les mettre à niveau rapidement. Ce temps de formation est également combiné avec le planning afin que nous puissions leur permettre d'apprendre et de définir les attentes de production quand ils terminent leurs formations. La formation doit également être mise à jour lorsque les systèmes changent, nous avons une personne en charge de l'entretien de ce programme de formation.

Contenu par couches et développement

Toutes les sections mentionnées au-dessus ont contribué à fournir à nos designers les blocs de construction dont nous avions besoin pour débuter le process de développement. Dès lors, les designers ont utilisé la Feuille de Route du Contenu pour établir des points précis de l'histoire. Ils ont ensuite créé du contenu basé sur les personnages et le Lore (contenu toujours créé par l'équipe narrative). Ils ont enfin utilisé les systèmes de jeu pour implémenter le contenu. Par exemple, disons qu'un designer doit créer du contenu basé sur nos Maraudeurs qui volent une petite ville minière, et les joueurs aident un personnage important à se débarrasser des pirates. Le designer lit donc le lore des Maraudeurs, fait un brainstorming d'idées concernant la quête en question. Il utilise enfin les systèmes de jeu pour créer le contenu directement dans le jeu.

Cela a pour but de récompenser le joueur qui varie les manières de jouer et de compléter certaines zones.

Revue du contenu

Le Content Design Lead ou le Design Director vont vouloir revoir le contenu qui a été créé. Notre processus de revue consiste à jouer le contenu comme un simple joueur. Oui, vous ne rêvez pas... nous sommes bien sérieux à ce sujet. Nous essayons d'éviter la tricherie chaque fois que c'est possible afin que nous puissions vivre au mieux le jeu comme le joueur le fera et découvrira le monde. Nous avons aussi plusieurs personnes qui jouent en même temps pour voir si le contenu peut accueillir plusieurs joueurs effectuant les quêtes au même moment.

La fin de cette phase est de montrer au designer comment son contenu est testé et de voir s'il existe des anomalies. Cela permet d'éviter des erreurs futures. Les tests et les actions qui en découlent suivent un modèle très présent dans l'industrie, le PDCA (Planifier, Développer, Contrôler, Ancrer/Ajuster - développé par Toyota).

Ce Rohsdower est-il bien au bon endroit ?

Le suivi de la production

De même que pour notre système de développement par couches, le suivi de production a une méthode similaire. Au niveau global, nous avons un planning qui définit ce que nous allons créer dans les mois à venir. Si on rentre en profondeur dans les processus, chaque étape est identifiée et assignée à un designer avec une date limite pour livrer le contenu. Nous ajoutons alors les étapes dans le logiciel de management des tâches/bugs JIRA. Chaque jour, on regarde l'avancement des étapes une par une avec les équipes.

L'amusement... et ce que ça inclut dans le calendrier

L'une des philosophies de base de notre jeu est que le plaisir est indispensable. Cela peut parfois aller à l'encontre de livrer le contenu à temps. Nous avons eu des fonctionnalités que les personnes ont concoctées et qui étaient exceptionnellement amusantes, mais ces fonctions ont fondamentalement changé le jeu. Dans ce genre de cas, on se pose les questions suivantes :

• Peut-on avoir plus de temps ?
• Si nous ne pouvons pas obtenir plus de temps, que pouvons-nous couper pour donner plus de temps ?
• La fonction vaut-elle le coup de travailler des heures supplémentaires ?
• Pouvons-nous faire travailler plus de personnes dessus pour éviter de couper d'autres fonctions ?
• Est-ce que cette fonction est plus important qu'une autre ? En a-t-on vraiment besoin ?
• Pouvons-nous faire du chantage à quiconque pour obtenir plus de temps ? (Nous avons des artistes extrêeeeemement bons sur Photoshop et nous pouvons créer des photos compromettantes au besoin)

Stephan Frost rajoute que l'éditeur (NCSoft) est flexible et permet à Carbine de faire passer l'amusement du jeu d'abord, de telle manière que les livraisons de contenu soient faisables.

Comprendre les dates butoirs

Le principe est de planifier et de prévoir le temps que prendra le développement afin de poser des dates butoirs. Cela force en quelque sorte les designers à faire preuve de créativité et de talent dans le temps imparti. Ce qu'on attend, c'est que le jeu doit être amusant et fonctionnel. Étant donné qu'un point est fait chaque semaine, les responsables peuvent voir si telle ou telle idée est trop ambitieuse, ou au contraire, pas assez.

Communication

La communication inter-équipes est primordiale pour coordonner tous les efforts. Ça peut paraître simple, mais cumuler plusieurs retards est catastrophiques.

Comme producteur, il est de mon devoir de débloquer cette question (ndlr : de la communication). Parfois, il est aussi simple de converser pendant 5 minutes dans un couloir avec quelqu'un. Parfois, cela me prend deux heures avec 5 personnes de trouver la solution. Parfois, je dois apporter les donuts. Peu importe la manière, la communication est souvent la solution... ou des viennoiseries.
 

L'heure du polissage, des réactions de la Bêta et des corrections de bugs

L'importance du polissage et de la correction des bugs est un aspect que toutes les entreprises doivent s'efforcer de comprendre. Nous nous efforçons toujours de prévoir le développement d'une étape jusqu'au polissage de son contenu. Le projet est planifié afin de corriger le contenu le plus possible jusqu'à la fin. Les chefs de département et les responsables jouent tout le contenu implémenté et fournissent des lignes directrices de polissage. Ce temps est également utilisé pour la correction des erreurs et anomalies pour conserver un niveau de qualité stable. Il y a également eu une phase où la bêta fermée était déconnectée, donc nous avons pu compiler les retours des joueurs et les jauger (cette phrase pourrait prendre un article entier à expliquer).

Sans ce temps, nous n'aurions pas pu mettre en avant une solide expérience.

Conclusion

En cinq ans, le processus de développement de WildStar est passé par énormément d'états (déception, succès, apprentissage, et la sauce Sriracha apparemment). Le système utilisé a permis de livrer à temps, de gérer les étapes de manière coordonnée et suivie de créer du contenu et d'apporter de l'amusement !