Premium
Le blog de Tiris, game designer chez Ivory Tower

Le blog de Tiris, game designer chez Ivory Tower

Par Tiris Blog créé le 03/01/10 Mis à jour le 22/03/15 à 23h15

Plongez dans les coulisses du jeu vidéo et de son développement avec Tiris, game designer chez Ivory Tower.

Ajouter aux favoris
Signaler
Articles (Jeu vidéo)

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.

 

Voir aussi

Sociétés : 
Ankama, Ivory Tower
Ajouter à mes favoris Commenter (8)

Commentaires

Tiris
Signaler
Tiris
@Kirub : Désolé, vous trinquez de notre faute amis programmeurs :D.

@Johan26 : En fait, ils ont au contraire un coté "créativité dans la méthode" je pense. Ce sont des pros et chacun à la liberté de créer sa façon de travailler. Après j'peux te dire qu'ils travaillent sûrement pas chacun comme ils le veulent, sinon sans communication et organisation, je vois pas comment ils pourraient sortir de si bon jeux ^^. Par exemple la façon qu'il ont de bosser sur leur scénario et dialogues et avec leurs acteurs, c'est clairement une méthode Agile, avec pas mal d'itération et non pas un processus linéaire genre "On a le scénar, on écrit les dialogues, on enregistre les acteurs".

Alors "bordélique" ça fait certes plus rock and roll, mais ils ne le sont pas tant que ça ;).
johan26
Signaler
johan26
Et quand Christophe Balestra vient nous expliquer que lui et son équipe travaillent de manière bordélique organisée ça te fais quel effet xD ?

Mais eux n'ont pas vraiment de contraintes de temps on dirait.
kirub
Signaler
kirub
"c'est donc le design qui en est "la cause" mais du coup tout le monde plonge et tu peux écrire un code parfait qui sera à jeter le lendemain quand ces **** de GD diront que finalement, c'est pas terrible cette fonctionnalité xD."

Amen.
Tiris
Signaler
Tiris
@Khan-amil : on a commencé très clairement waterfall sur Arena puis j'ai essayé de faire tourner du Scrum. Sur les autres projets où je suis passé après Arena, il y avait du bon (du Scrum ^^ et du moins bon, un espèce de Waterfall). Si je pouvais reprendre certain projet directement avec mes connaissance de méthodologie actuelle, ça serait clairement bien différent, on aurait éviter de grosses perte de temps et oui, ce serait du Scrum, surtout pour les petites équipes où ça s'adopte très facilement :).

Merci pour ton commentaire :).

@N3o : Merci ^^. Moi aussi j'étais programmeur à mes débuts et ça a forcément influencé ma vision :).Le plus dur dans un jeu vidéo vient du fait que généralement on a une vision au final très floue du produit final comparé par exemple à la conception d'un logiciel de suivi de facture (oui, j'ai fais ça ^^), c'est donc le design qui en est "la cause" mais du coup tout le monde plonge et tu peux écrire un code parfait qui sera à jeter le lendemain quand ces **** de GD diront que finalement, c'est pas terrible cette fonctionnalité xD.
N3o
Signaler
N3o
Je n'ai jamais trop aimé la conception (ouai je préfère programmer :P) mais tu expliques bien. Le développement d'un jeux-vidéo doit vraiment être compliqué car les différentes phases sont très éloignées les unes des autres je trouve.
En tout cas les méthodes agiles c'est la vie.
Khan-amil
Signaler
Khan-amil
Article sympa, les deux approches sont exposées clairement pour ceux non familier avec les principes, sans être inintéressant pour les autres :)

J'en déduit qu'a Ankama vous utilisiez le mode waterfall? Du coup avec le recul, essaierais tu de mettre en place un scrumm si tu devais retravailler sur un projet avec les mêmes conditions initiales que Arena?
Tiris
Signaler
Tiris
Merci, ça me fais plaisir parce que j'ai l'impression d'avoir été un peu long (et chiant) sans pour autant en dire assez. Mais si ça tu as trouvé ça intéressant, c'est cool ! ^^
Nickie
Signaler
Nickie
Article fort intéressant, j'ai adoré. ;)

Édito

L'univers du jeu vidéo m'a toujours fasciné et a toujours été source de débats passionnants pour moi, en tant que joueur, puis encore plus en tant que game designer.

Après presque 6 années chez Ankama où j'ai eu l'occasion de travailler sur pas mal de jeux et surtout de diriger le développement de Dofus Arena, j'ai rejoins Ivory Tower à Lyon afin de relever de nouveaux défis.

Tenir un blog est un exercice intéressant. En plus d'être un lieu d'échange avec des gens passionnés, cela me  pousse à essayer de toujours mieux structurer mes idées, de vulgariser des concepts parfois très techniques ou d'essayer de rendre intéressant des sujets qui de prime abord ne le sont pas forcément. C'est en fait un exercice de communication parfait pour un game designer.

J'espère que vous vous plairez à lire ce blog autant que j'ai plaisir à l'écrire !

Hervé Gengler Aka Tiris.

 

 

 

 

Archives

Favoris