Introduction
Le contenu créé par les utilisateurs porte un poids de plus en plus important dans les jeux et présente un argument de choix pour la vente: il suffit de regarder Half-Life dont le succès a été porté par CS, ou même pour d’autres jeux tels Quake, OFP et ArmA.
Cela fait depuis plus de deux ans que je crée des missions - d’abord OFP, circa 2003/2004, puis ArmA, depuis sa sortie.
Autant l’aspect purement technique et la création en elle-même se faisait naturellement, les problèmes exposés puis résolus au fur et à mesure, il s’avère que tout ceci fait partie d’un processus créatif dont je ne m’étais jamais aperçu et donc auquel je ne m’étais jamais intéressé.
Étant maintenant élève-ingénieur, j’entends parler de choses comme les WBS, OBS, PERT, GANTT, et ainsi découvre la structuration d’un projet. En quoi une création de contenu devrait-elle être différente?
Je dis bien création de contenu, car je sais très bien que ce que je vais dire s’applique très bien à d’autres choses, comme un mod ou simplement la création d’un modèle ou d’une map. On restera malgré tout sur l’exemple de la mission ArmA, tout en essayant de ne pas rentrer trop dans le détail technique.
Dans ce billet, nous verrons donc que la création de mission est proche dans sa création à un projet industriel; mais aussi, de manière plus spécifique à l’exemple, nous observerons que le niveau technique n’est pas le plus important dans le processus.
Début de la création: la réflexion
La volonté de créer une mission peut venir de deux choses: soit un besoin ressenti en tant que joueur, soit une poussée créative.
Dans le premier cas, ce besoin est analysé en tant que créateur de missions et mis en place de manière intellectuelle.
Il faut savoir que dans ArmA on ne joue que sur l’île du jeu original - d’autres îles ont été créées, telles Uhao, ou encore United Sahrani, qui vient avec l’extension Queen’s Gambit, mais seule Sahrani assure une compatibilité optimale.
Malgré la taille importante de cette île (220km²), les endroits intéressants sont limités. En effet, il faut un endroit qui convienne à l’ébauche de mission, qui présente une topographie singulière (une plaine ne conviendra jamais), dont le graphisme soit plaisant (le Sud et le Nord de Sahrani sont très différents et souvent le Sud est complètement délaissé des créateurs) - tout en proposant de la nouveauté.
Seuls quelques endroits restent; on isole facilement un unique point selon la manière dont on imagine l’action. Trouver un endroit est une phase absolument incontournable: il m’est arrivé souvent d’avoir une idée qui me semblait parfaite au niveau gameplay mais de ne pas avoir d’endroit où la placer. Il faut qu’elle arrive au plus tôt dans le processus de conception.
Le reste de la réflexion se passe à 80% dans la tête et à 20% dans l’éditeur du jeu: à savoir, on passe 80% du temps à imaginer la scène de l’action principale, et 20% à tester deux trois positions ou scènes, et ceci dans le seul but d’aider l’imagination à créer une image.
Enfin, dans l’autre cas, c’est-à-dire dans le cas d’une poussée créative, j’aime me balader dans la carte pour essayer de repérer des endroits différents; alors le processus s’inverse et c’est de l’endroit que l’on tirera les éléments de gameplay.
On notera que souvent ce genre d’approches ne débouchera pas: souvent parce que je connais l’île par cœur, ou alors parce que ce que les endroits m’inspirent sont des scènes d’action que j’ai déjà faites ou jouées, qui ne sont pas intéressantes, voire tout simplement infaisables.
Dans un projet industriel, on retrouve dans 99% des cycles de vie une phase de conception: et c’est exactement celle-ci que l’on retrouve dans ArmA. C’est normal, il vaut mieux savoir ce que l’on fait avant de se lancer. Une mission est un projet long et ne pas avoir d’idée bien définie ne mène qu’à une perte de temps. De même, un projet mal défini ne mène qu’à l’abandon et donc une perte d’argent pour l’entreprise. Néanmoins, comme je travaille seul, je n’ai pas besoin de mettre sur papier, de diviser les tâches ou autre; tout est dans ma tête.
Afin de vous donner un ordre d’idée, du début de la réflexion au bouclage de la première version de la mission, il peut s’écouler entre deux semaines et deux mois. Ensuite, vient tout ce qui est débuggage, étant donné que le créateur ne peut décemment pas trouver tous les bugs seul dans une mission prévue pour 15, En prenant l’exemple de ma dernière mission, « Effort de Guerre », la conception a débuté en mai 2008; la première version est sortie mi-juin, et la version finale vient juste d’être finie. Si l’on exclut les mois de juillet à décembre, où j’ai repris la mission, le tout aura pris entre deux et trois mois.
Revenons-en à notre mission en cours; imaginons que nous avons notre scène d’action bien en tête, et que nous avons l’endroit rêvé pour. La logique du créateur veut…
Le cœur de la création: les fondations de la mission
Dans ArmA, le cœur est également le début de la réalisation du projet - la mise en place, ou positionnement, des unités. C’est souvent la partie la plus fastidieuse du projet, surtout lorsque l’on souhaite placer beaucoup d’éléments.
L’éditeur d’ArmA permet de placer des objets - unités, bâtiments, objets, etc. - aisément. C’est-à-dire, définir leur position dans l’espace - un array [x,y,z], leur direction en degrés, au temps initial. C’est de ce positionnement que découlera toute la saveur de l’action.
Cette phase requiert beaucoup de temps et d’essais pour tout perfectionner.
De plus, il faut absolument ajouter des objets divers (tentes, sacs de sable, véhicules, etc.) pour rendre l’univers crédible et vivant. Tous ces objets rajoutent de la valeur à la mission et sont extrêmement bénéficiables à l’expérience du joueur. C’est très souvent ce qui fait la différence entre une mission de qualité et une mission bâclée, à gameplay égal.
Une autre solution est l’usage de scripts pour la création dynamique d’unités tel le DAC de l’équipe MAPfact. Un positionnement dans l’éditeur permet une mission déterminée, tweakée pour l’expérience du joueur, mais ne permettant qu’une rejouabilité très limitée. L’utilisation du DAC ne permet qu’un tweak limité par rapport au positionnement, mais permet une rejouabilité optimale.
Imaginons maintenant que ce n’est pas une mission que nous sommes en train de créer, mais un système mécanique complexe. La phase précédente consistait à dresser les plans; cette phase consiste maintenant à usiner les différentes pièces. C’est ainsi une étape de fabrication, ou de réalisation.
Cela représente environ 35% du temps de création de la mission (entre le début et la sortie de la première version).
Fin de la phase de réalisation: le cerveau de la mission
Nous avons donc nos différentes pièces usinées. Séparément, elles ne servent à rien; pour pouvoir former le système voulu, il faut les assembler, donner aux pièces une raison d’être en les liant les unes aux autres. Dans la mission, c’est la même chose: il faut dire aux unités pourquoi elles ont été créées, c’est-à-dire: allez ici, faites ceci, etc. L’IA du jeu se chargera du reste.
Ceci peut sembler dérisoire, mais c’est le nerf du jeu. A chaque interaction apparaît une probabilité d’échec - l’IA fait rarement ce qu’on lui dit, mais miraculeusement en général tout va pour le mieux. Tout doit être testé, à chaque étape.
Pour rajouter encore plus de valeur ajoutée à notre produit, il faut lui attribuer plus de dynamisme, rallonger sa feature list. C’est ici qu’entre en jeu la rédaction de scripts pour mieux contrôler le jeu en lui même et parfois la manière de réagir l’IA. C’est réellement la partie la plus dangereuse de la création, étant donnée que cela peut parfois être très technique mais surtout parce que les probabilités d’échec sont extrêmement élevées - ArmA est une science parfaitement inexacte et dont les performances d’exécution de script sont exécrables. Un script ne marchera souvent pas du premier coup, ni après la première réécriture.
Pour notre système mécanique, cela revient à faire changer un embrayage sur une voiture par un maître d’hôtel. Ça sera forcément catastrophique au début, et quand ça marchera, la solution ne sera pas élégante. Parfois elle le sera; c’est l’exception du maître d’hôtel surqualifié. Mais cela confère une valeur ajoutée incroyable à notre produit; si je devais la quantifier, je dirais que sans les scripts, ma dernière mission perdrait 80% de sa valeur.
Les problèmes qui sont posés pendant cette phase font qu’elle représente près de 60% du temps passé sur la mission. De plus, tous les bugs rencontrés entre la première version et la version finale sont quasiment exclusivement des bugs de scripts.
Après la réalisation: la vente.
Notre système mécanique est maintenant révolutionnaire. Mettez-le dans une boîte en carton, peignez-le en noir, faites-le en plastique cheap, vous en ferez le plus grand flop de l’histoire de l’industrie.
Que ce soit une mission, un système mécanique, peu importe: il faut vendre.
Comment peut-on faire pour une mission? Ajout de marqueurs sur la carte, création d’un briefing fourni, ajout de dialogues en jeu, utilisation de voix d’acteurs, création de cutscenes… Tous les moyens sont bons.
Vient également un problème récurrent: l’ajout de musique.
Alors que celle-ci peut être un élément-clé dans l’atmosphère de l’action, elle peut aussi être l’élément qui la détruira. Ainsi, la solution choisie est souvent de ne pas en ajouter. Mais on trouvera certaines perles qui conviennent à l’action. En général, ce sont des musiques douces, d’ambiance, le métal, rap ou autres se prêtant mal même à une action soutenue. En revanche, on sélectionnera toujours une instrumentale. Je vous conseille de visiter le blog de __MaX__ qui crée des musiques se prêtant tout à fait à ce genre d’intégrations - sa dernière création est d’ailleurs utilisée dans ma mission.
Une mission commune (entendez: bâclée, ou faite par un créateur inexpérimentée) contiendra en moyenne 2 marqueurs, un briefing de 300 caractères environ, une ou deux lignes de dialogues en jeu, pas de voix, encore moins de cutscenes.
Dans ma dernière mission: le nombre de marqueurs s’élève à 67, le briefing contient plus de 4200 caractères, 25 lignes de dialogues toutes réalisées par des acteurs, et des cutscenes dont une vidéo scriptée.
Ne croyez pas les chiffres mais croyez-en l’expérience du joueur: la sensation que l’on a en démarrant une mission bâclée et une mission finalisée est entièrement différente. L’immersion est inexistante dans le premier cas et totale dans l’autre.
Cette phase de « marketing » prend environ 5% du temps total de la mission pour une valeur ajoutée relativement modeste mais non négligeable.
Conclusion
On voit bien que, sans rentrer dans les détails techniques, la comparaison création amateur/industrielle est tout à fait viable. D’ailleurs, les studios de moddeurs deviennent parfois des sociétés de développement à part entière, créant des produits professionnels!
Malgré le fait que mon analyse soit tronquée - je travaille seul - je suis persuadé que la planification du travail avec les outils habituels est un incontournable.
Pour ce qui est de la création de mission en elle-même, on retrouve toutes les étapes « classiques » d’un projet industriel, alors même que je ne m’en étais jamais rendu compte. Dans mon esprit, avec l’expérience, le découpage du travail se faisait naturellement et toutes les étapes se suivaient dans un ordre logique.
On peut alors se demander si un tel découpage du travail n’est en fait qu’une analyse de la manière de penser humaine voire logique, comme on peut le voir dans la vie professionnelle mais aussi la vie de tous les jours…