Jeremy Chatelaine

On dit de l’aigle qu’il a peut repérer une souris a 200 mètres d’altitude. Ceux qui me connaissent savent que mon un oeil a moi est doue pour repérer ce qui peut être améliore. Peut-être parce que je n’aime pas faire des trucs qui sont contraignant par nature et que j’imagine constamment comment je pourrais éviter de les faire.

Quelque soit l’explication, repérer les problèmes dans la fabrication d’un jeu vidéo est pour moi chose facile et je reste parfois abasourdis en apprenant comment certaines boites arrivent a développer des jeux (bien souvent aux dépends de ceux qui les développent d’ailleurs) et comment de simples mesures pourraient rendre les choses bien meilleurs.

Ce que j’aimerais brièvement aborder dans cet article toutefois est un problème commun a toutes les boites de jeu que je connais et bien que l’industrie du jeu se remette plus souvent en cause que certaines autres industries, peu de sociétés ont vraiment remis en cause leur façon de produire un jeu. Pourtant je vois la chose autrement.

Ma théorie se base sur le fait que l’homme a une nature adaptive. Si on lui donne 10 kilos à porter quotidiennement il va se plaindre au début mais après un moment il s’y habituera et n’y prêtera même plus attention. Si on lui donne 10 kilos de plus, le même scénario va se reproduire. De même pour les 10 kilos suivant et ainsi de suite. Appliquez cette idée a une équipe et vous aurez chaque membre habitue a porter 30 kilos. Cela les ralentis mais après tout ils y sont habitue, c’est leur lot quotidien.
En revanche, une personne qui rejoint équipe en cours va devoir se taper d’un coup les 30 kilos. L’équipe étant consciente du travail que cela demande va naturellement aider la nouvelle recrue à porter un peu ce poids jusqu’a ce qu’elle soit capable de le porter toute seul à son tour. Ceci expliquant cela, il n’est pas étonnant que certaines équipes n’embauchent pas en fin de projet car de toute façon il faudrait trop de temps pour former une nouvelle personne pour que cela soit utile pour le projet en cours avec comme conséquence que équipe doit fournir plus de travail ou dépasser la date prévue (et on sait comment cela se termine).

Si on part du principe que cette hypothèse est applicable à notre industrie, alors ce que l’on doit résoudre c’est “pourquoi on doit porter tant?”‘ et non pas “comment porter plus?”. Pourtant il y a des poids qui ne sont jamais remis en cause car on les considèrent comme faisant partie du mode de fonctionnement de l’industrie. Apres tout, avant que Ford mette en place ses lignes d’assemblage, il était acquis qu’il faillent des ouvriers très qualifier pour pourvoir faire une voiture et que ça prenait un temps monstre (plusieurs dizaines de jours) pour finir une voiture…

Les kilos dans mon exemple sont toutes ces étapes en plus du travail de base que l’on doit faire. Pour un artiste, cela peut être d’exporter un model et relancer le jeu pour pouvoir voir le résultat, pour un producteur de devoir graver un CD pour tester le jeu, pour un designer de redémarrer le jeu pour voir le résultat… On y est tellement habitue qu’on y fait même plus attention et on explique avec bienveillance comment on fait un jeu aux nouvelles recrues pour qu’a leur tour elles sachent comment on doit s’y prendre.

Pour moi le plus gros poids vient surtout de notre façon même de produire un jeu. Dans ma quête de simplification des procedes j’ai remarque la fâcheuse tendance de notre industrie à faire qu’implicitement on travaille chacun de notre cote. Je ne parle pas de personnes renfermées sur elles même ou peu communicative, mais bien de notre façon de travailler en équipe et qui paradoxalement ne nous permet pas de travailler vraiment ensemble. C’est discutable pour les programmeurs, mais sûrement pas pour des designers plaçant des objets dans une carte ou pour des artistes construisant un niveau.

Pour utiliser une métaphore connue dans notre milieu, faire un jeu c’est comme faire une maison. On fait le plan, on construit les fondations, les murs, on s’occupe de la plomberie et de l’électricité, on peint les murs… Le processus de construction est bien connu de tous et peu remis en cause.
Mais la grosse différence entre construire une maison et un jeu, c’est que ceux qui construisent la maison travaillent ensemble sur le chantier, nous non. On est chacun dans notre coin, isole des changements chaotiques de équipe pour produire sa pièce du puzzle que l’on essaye désespérément d’intégrer lorsque c’est à notre tour.

Le problème, c’est que cette approche est hautement inefficace. Elle demande une énorme autonomie de la part des developeurs (chose impossible a demander dans les larges équipes) ou un coût très élevé en management car il faut se mettre d’accord sur les objectifs a atteindre ainsi que coordonner les actions et faire le suivit des taches. Bien trop souvent l’intégration pose problème (il faut refaire ci ou ça car cela ne colle plus ou c’est pas vraiment ce qu’on voulait, ou on a change d’avis entre temps). Bref le coût de mettre en commun les pièces faite dans son coin est bien souvent oublie car implicites et accepte d’emble dans notre la production d’un jeu.

Ceci pourtant n’est pas une fatalité et j’y travaille doucement de mon cote.
Il y a quelque mois j’ai lance un projet que j’ai appelée avec ma modestie habituelle Révolution.
Révolution, car comme son nom l’indique, les choses ne se passent pas comment a l’accoutumé et implique un changement radical de comment on procédé.

Le projet a démarre avec quelques règles de base:

- Le jeu ne doit jamais avoir besoin de se relancer du jour ou le projet de jeu commence au jour ou le produit est termine.
- On doit pouvoir voir en temps réel la progression de ce que chacun fait si on le souhaite.
- Ceux qui produisent du contenu ne doivent pas utiliser un autre format que leur format source.

Ceux qui sont des professionnels de notre industrie le savent ces règles sont loin être simple a remplir avec nos outils et notre façon actuelle de travailler, mais pas impossible non plus si on fait un effort.
Je ne vais pas encore vous parler de comment j’ai décidé d’implémenter Révolution, cela prendrait trop de temps et j’y reviendrai donc dans un prochain article, mais idée est lancée et en cours de réalisation. Je me sers d’ailleurs actuellement d’une version de base de Révolution pour “Battle For Independence” qui ne satisfait pas encore pleinement les demandes, mais qui s’en rapproche pas mal et je vois déjà les avantages énormes que cela apporte!

Pour ceux qui s’en rappellent, j’avais fait une vidéo à l’époque pour présenter idée de Révolution:
Le but est d’offrir cette technologie sur le même model que le GI (open source et zlib pour la licence) afin de permettre a un grand nombre de personnes et notamment les amateurs de pouvoir profiter de cette façon de faire des jeux qui au final est bien plus adaptée au travail en groupe et a distance.

A suivre…

Trackback URI | Comments RSS