Jeremy Chatelaine

Bien finallement, cet article fut plus long a accoucher que je ne le pensais initiallement. Non qu’il fut si complique que ca a ecrire, apres tout ce n’est qu’une collection de mon vecu, mais j’ai pris la “mauvaise” habitude de continuer a coder mon jeu dans le train et pour le coup mon prochain article concernera peut etre mon jeu.

Je tenais egalement a remercier chaleureusement les eleves de Creajeux pour avoir voulu m’inviter a venir les voir et je m’excuse d’avoir du refuser l’offre pour cette annee, le timing n’etant pas vraiment ideal avec ma fille et mon changement de pays. Mais promis si vous insistez je viendrais pour la prochaine annee scholaire

Sur ce, place a l’article…

Avec mon nouveau travail, je me suis rapidement rappele que travailler dans une petite equipe n’etait vraiment pas la meme chose que de travailler dans une grande.

Contrairement a ce que l’on pourrait penser de prime abord, le travail de programmeur dans une grande equipe de jeu video est sensiblement le meme quel que soit le produit final (jeu video ou pas) d’apres mon experience mais on va voir ca un peu plus en detail plus loin.

Dans le jeu video, etre dans une petite ou grande equipe a des repercutions non negligeables sur votre environement de travail et je me suis dit qu’il serait interessant de vous faire partager mon experience la dessus.
Comme souvent, tout est histoire de compromis et de trouver ce qui vous va le mieux, meme si j’ai quelques idees tranchees sur le sujet je ne verse jamais dans le fatalisme et je crois que tout reste possible.

Pour simplifier et structurer un peu mon approche, j’ai coupe ma reflection en trois categories:

La premiere relation ‘A’ indique une “petite” equipe travaillant dans une grand infrastructure. C’est le cas de tous les editeurs qui ont egalement des studios de developement. Soit du point de vue de mon experience: Electronic Arts, UbiSoft et les ragots des collegues d’autres grosses boites.

Chaque equipe est assignee a un projet (generallement une grosse license) et produit un jeu a intervalle plus ou moins regulier. Les considerations sont purement financieres, orientees vers le buiness developement, positionnement strategique, part de marche et autres trucs financiers.

La tendance n’est pas d’avoir le plus d’equipe ou d’avoir des equipes efficaces mais de sortir le jeu a temps, aussi les equipes peuvent atteindre des grosses tailles pour boucler les echeances car c’est bien connu, lorsqu’on a un probleme, il suffit d’ajoutter plus de personnes et de les faire travailler plus longtemps (propos sarcastique bien sur :)).
On parle d’ailleurs ici de resources au lieu de personne en tant qu’humain a part entiere et l’esprit creatif, la capacite d’initiative ou d’innovation n’entre pas vraiment dans l’equation (sinon le discours sur la magie de la creativite, evoquee dans ce blog precedemment n’aurait pas lieu d’etre).

En management y’a un triangle bien connu d’ailleurs pour jongler avec la sortie d’un produit: Resource/Etendu du travail/Temps de travail.

L’idee principale etant ici qu’on peut jouer sur ces 3 facteurs pour sortir un jeu.
Par exemple, on peut ajoutter plus de resources (machines/personnes), reduire ce que l’on doit faire (on supprime quelques niveaux sur les 20 initiallement prevus), ou on peut tout simplement donner plus de temps pour terminer le produit (on repousse les echeances de quelques semaines), ce qui au final nous donne un autre triangle comme j’ai fais avec le gris par exemple.

Dans les grosses boites, les coups d’infrastructure sont enormes (departement finance, marketing, distribution, legale…) et les penalites sont grosses en cas de delais a la completion.
Du coup, comme on ne peut pas donner plus de temps, on en prend tout de meme un peu plus en instaurant la semaine de 6 jours par exemple ou en faisant venir les employes les week-ends ou rester plus tard le soir. C’est malheureusement courant.

Comme le disait Jack Welch pourtant dans son livre sur General Electricity que j’ai lu recemment (et bien aime qui plus est), le plus important dans tout travail ce sont les gens qui l’accomplissent. La meilleur des strategies ne produira qu’un resultat moyen voir mediocre si ce ne sont pas les bonnes personnes qui l’executent. Et oh combien de fois j’ai pu verifier ca de mes propres yeux.

Donc, le triangle, aussi interessant soit-il comme outil, il ne tient pas compte de qui sont ces personnes. C’est dommage car il n’y a que les gens qui reussissent les choses.

Le cas le plus extreme de grosse equipe que je connaisse est The GodFather de EA avec plus de 350 personnes sur le projet. Biensur, cela ne s’etant pas averre tres rentable (EA ne le clame pas sur tous les toits, evitant le sujet tout en disant officiellement plus de 100), les tailles des equipes ont depuis ete revu a la baisses pour finallement revenir osciller entre 50-80 voir 100 personnes (avec petite vague de licenciement qui va bien en Amerique).

Bon tout ca c’est bien beau, mais a travailler dans de telles conditions il y a plusieurs facteurs a considerer lorsqu’on est l’un des dits developpeurs:

Tout d’abord, la taille de l’equipe elle meme rend le travail moins humain et moins personnel. C’est un gros problem, un enorme meme pour l’industrie du jeu. Il est toujours d’actualite d’essayer de reduire la taille des equipes sans la reduire. Car les grosses equipes sont “paradoxallement” plus lentes a produire.
Il faut donc trouver des compromis pour artificiellement couper les grosses equipes afin d’avoir les avantages d’etre nombreux sans les inconvenients.
C’est ainsi que sont nes les concepts de strike team (tout petit groupe dans une grosse equipe que l’on assigne a la resolution d’un problem sur le jeu comme les combats ou la physique) ou de pods (segmentation de l’equipe en groupe fonctoin de leur affectation: programmeurs gameplay, programmeurs moteurs…).

Dans ces conditions, le produit (oui j’insiste sur l’utilisation du mot ici) final est presque accessoire et on peut tres bien bosser sur X/Y/Z sans que cela ne fasse grande difference. On en est revenue a se concentrer que sur l’aspect mecanique du travail, ce qui est un comble dans une industrie dite creative. C’est le retour de la chaine de Ford parodiee par Charlie Chaplin qu’on essaye de nous imposer a nouveau.

Tiens, au passage, on pourrait fort bien croire que le manque d’expression creative ne s’applique qu’aux programmeurs… detrompez vous les amis.
Les artistes doivent reproduire a l’identique la tronche des personnages du jeu base sur des photos, les decors sont bases sur des directions bien precises, voire des photos du film (meme pas le droit de choisir le ton de couleur de la salle par exemple)… sans parler de la licence en elle meme (modeliser Barbie a la perfection doit pas etre tres excitant :)).
Pour les designers, ils doivent suivre la trame du film et sont bien souvent les marionettes des decisions stupides venant de personnes n’y connaissant rien en gamedesign mais mieux placees avec une logique economique (executif producer et autres blaireaux qui se basant sur une etude de consommateur va imposer telle ou telle direction comme: faut que ca ressemble encore plus au film!).

Bref, qu’on se le dise tout de suite, l’imagination et la creativite n’est generallement pas une des qualites “recherchee” en grande equipe et c’est aussi la plus dur a manager dans ce type d’environement. On pourrait presque avancer la theorie que seule une certaine quantite de creativite est disponible par jeu et que plus l’equipe est grande, plus la part de chacun est reduite, voire recuperee par quelqu’un d’autre…

De facon generale (de ce que j’en ai vue et entendu naturellement), on observe souvent que plus l’equipe est grosse, moins l’impacte personnelle sur le jeu est grand, et moins les personnes se sentent investies dans le projet, le tout menant a un jeu moins original.
J’aimerais croire que cela ne soit pas le cas partout, mais je n’ai pas encore entendu (et encore moins vue) l’effet inverse non plus malgre toutes les bonnes volontes initiales.

La communication est egalement un probleme majeur dans les grosses equipes (plus de 30). Il n’est pas evident que tout le monde partage la vision initiale du projet et la prise de decision est un long procede fait de meeting interminables pour que tout le monde soit au courant et d’accord. Un peu comme un tank qui devrait changer de direction, ca prend un temps monstre a tourner. Difficile de garder sa capacite de reaction ou susciter l’enthousiasme dans de pareilles circonstances.

Les personnes talentueuses et autonomes sont rares a trouver de maniere generale, il est ainsi facile d’imaginer a quel point il est rare de pouvoir trouver 80 personnes capable d’autonomie dans une equipe. Ceci expliquant cela, il y a donc fort a parier que le management soit donc bien plus present dans les grandes equipes (et rappelez vous tout le respect que j’ai pour le management dans les jeux videos…), sans compter sur la bureaucratie qui s’installe doucement mais surement (faut tout ralentir sinon on ne peut pas tout controller, ca passe par des documents, des meetings…).

Si comme moi vous etes programmeur et que le produit sur lequel vous travaillez n’a que peu d’interet pour vous (genre Catwoman au hasard), ou que vous travaillez dans l’equipe des outils loin de la production (comme moi quoi), le travail de programmeur n’est pas moins gratifiant que si vous travaillez dans un autre secteur que le jeu video. Ma gratification personelle venant generallement d’un code mieux ecrit (fierte du travail accompli) et des utilisateurs de mon code (c’est a dire: joueurs lorsque je travail sur le gameplay ou collegues lorsque je travaille sur des librairies), mais cela depend de chacun bien entendu. Imaginez donc ma gratification si j’avais travaille sur le code gameplay d’un jeu de merde

Sinon, on pourrait croire que l’on apprend plus en fonction du nombre de personnes dans l’equipe, et paradoxellement ce n’est pas ce que j’ai pu constater. Dans les grandes equipes on est confine dans un certain domaine et ceux avec qui on a une interaction susceptible de nous apprendre des choses est tout aussi paradoxallement reduite, mais j’y reviendrai plus en detail lorsque je parlerai des petites equipes.

Je crois au final que les businessmen ont reussit leur pari, a force d’effort assurant que l’industrie du jeu n’etait pas assez professionnelle (pas assez conformiste), qu’au final le jeu video est devenu une industrie comme les autres (avec des similarites vraiment frappantes).

Il y a aussi toutefois des avantages certains au fait de faire partie d’une grosse equipe.

L’argent est souvent un avantage dans les grosses structures et cela se ressent sur les salaires et equipements. EA par exemple paye relativement bien compare aux autres boites de jeu plus petites, les chaises etaient top, les PCs puissants, les fruits gratuit…

Par consequent, l’entreprise aura normallement moins de difficultes a rester debout si le jeu ne se vend pas, meme si la securite de l’emploi reste en fait tres illusoire, surtout aux USA ou on peut virer tellement plus facilement que dans nos pays europeens… mais pas que non plus.
Je me souviens a Argonaut, un petit projet de jeu mobile avait ete monte avec quelques artistes, programmeurs et un designer. Lorsque le jeu a ete annule, le designer a ete remercie, sous pretexte qu’il n’y avait pas de place de designer sur Catwoman (la boite avait dans les 200 employes a l’epoque).

J’ai eu quelquefois tendance par le passe dans ma recherche d’un emploi a vouloir remplacer la passion avec de l’argent. Clairement ce n’est vraiment pas genial comme concept, surtout passe le court terme (on ne fait plus le travail par passion mais pour le salaire en fin de mois). Ca aurait pu etre mon cas si j’etais reste a la BNP par exemple, mais j’ai prefere quitter plutot que de terminer comme la plupart la bas a attendre leur cheque de fin de mois (et c’est tant mieux!).

Un autre avantage des grosses structures, conclusion logique de leur approche mass market, beaucoup de personnes ont surement joue a votre jeu, meme si a l’oppose vous n’avez presque rien fait dessus. Ce qui n’est pas trop embetant du moment que c’est un BON jeu!
A l’inverse, si vous travaillez sur un petit jeu obscure dans une petite boite, vous aurez certes fait beaucoup de chose, mais personne n’y aura joue ou entendu parle et si en plus c’est un jeu de merde…

Car au final ce que veulent savoir les gens a qui vous dites que vous etes dans les jeux videos, c’est sur quels jeux vous avez travaille et ce que vous avez fait dessus.

Enfin, en theorie (et j’insiste sur ce mot toutefois), on peut passer d’une equipe a l’autre sans avoir a changer de travail, ce qui peut etre fort plaisant. En pratique toutefois c’est plus difficile.
Tout d’abord, les societes sont specialise dans un domaine generallement, il est pas courant qu’une entreprise fasse simulatanement des super jeu de course, d’action, de RTS…
Puis, a EA, UbiSoft, Argonaut… vous savez les resources ,tout ca, font qu’au final on ne bouge pas autant qu’on pourrait l’esperer car les envies et aspiration personnelles jouent un role secondaire dans la repartissions des personnes ici ou la en grosse equipe.
Les artistes en revanche passent plus facilement d’un crunch time a un autre (haha les pauvres :))

Le deuxieme cas ‘B’ est un cas un peu particulier. Une societe/equipe independante fait un jeu pour une autre plus grosse comme si elle faisait partie de la grosse structure.
J’ai vecu ca a Argonaut pendant 10 mois (avec des gens d’EA venant travailler avec ceux d’Argonaut au niveau du management et de la production). L’argent venait comme toujours du gros (EA), la production venait du petit (Argonaut).

L’autre cas possible etant une petite entreprise et une maison mere (comme Argonaut et Ninja Theory a l’epoque ou les deux etaient toujours debout).

Alors qu’est-ce qui change par rapport au premier scenario?

Comme l’argent vient presque toujours du gros, cela permet a la petite equipe “pour la premiere fois” d’avoir une enorme rentree d’argent et de pouvoir mettre toutes les resources voulues a disposition (et pas forcement de facon judicieuse d’ailleurs).
Les resources sont donc moins un probleme. Cela permet aussi a la petite entreprise d’avoir access aux infrastructures de la grosse telle que le marketing et/ou le reseau de distribution.
De son cote la petite garde son independance toute relative car le game design est generallement toujours avalide par la grosse entreprise (apres tout ils payent!).

Mon experience est malheureusement limite dans ce cas-ci, donc je ne peux faire que peu d’affirmations et de commentaires mais je suis sur que ceux qui sont dans ce cas ne manqueront pas de nous eclairer plus par le biais des commentaires, n’est-ce pas?!

Le dernier cas ‘C’ enfin est le cas ou la petite equipe est aussi une entreprise independante. Cela concerne les petits studios principallement qui se font editer par une plus grosse entreprise.

D’emble, il est plus facile de trouver de la passion dans ces studios. Bien que le type de projet ait un impact sur la motivation, l’equipe est tres importante et il est heureux d’avoir des collegues avec qui on se sent proche. Le travail est generallement plus personnel et les conflits egalement (untel ne peut pas saquer untel).

Les relations avec les grands est un rapport de force au desavantage des petites structures bien entendu.
Il y a generallement deux possibilites. La premiere est de miser sur les niches de marche (c’etait le cas de Carapace avec un jeu de beach volley), le deuxieme etant d’innover, car copier les grosses production est rendu difficile due au manque de resource (financiere, materielle et humaine). C’est le cas de la plupart des petits studios qui ont connu une renommee mondiale.

Un des risques majeurs en petite equipe est que tout ceux qui prennent des decisions soient des charlots car il n’y avait personne de plus qualifie.
A Carapace, ou j’ai travaille, le niveau global de competence etait assez bas a l’epoque et j’ai pu comparer la difference planetaire avec Lionhead ou a l’inverse tout le monde etait au top de l’industrie.

Ce niveau de competence determine d’ailleurs clairement a quel point vous allez apprendre, car les competences voyagent mieux dans les petites equipes. Il y a fort a parier que vous ne soyez pas confine dans un role unique (genre physique ou reseau) ce qui vous permet de recuperrer des connaissances plus diverses que dans une grosse equipe ou on cherche a vous cantonner dans un domaine precis.

Bosser dans une petite equipe est donc un excelent entrainement lorsqu’on demarre dans l’industrie, on peut ainsi voir et confronter plusieurs styles de code car chaque personne ecrit de facon differente (la pression de coding standard est moins grande que dans les grosses boites qui ont besoin de conformisme).

Un autre avantage competitif des petites structure est la capacite de reaction. Il est plus facile d’avoir une reunion pour annoncer un changement strategique lorsqu’on est 10 que lorsqu’on est 80. Le tank qui doit tourner se transforme en velo. Les grosses entreprises cherchent a recreer l’atmosphere de petite equipe pour cette reactivite avec plus ou moins de success (plus moins que plus :)).

Les desavantages sont egalement pletores avec les petites structures malheureusement, mais sont largement influences par la renommee du studio.

Les resources font souvent defaut dans les petites structures. Cela peut aller de la difficulte a recruter (elle existe cette boite?) aux petits salaires, manque d’equipements/materiels…
Le financement de ces entreprises est generallement difficile et il faut souvent chercher des fonds ailleurs ce qui peut installer une certaine precarite du a l’insertitude de recevoir sa paye en fin du mois. Dans le cas de Lionhead, Peter financait le tout de sa poche et l’equipe n’avait pas de soucis de ce cote la (seul Peter en avait).

Ensuite, a moins d’etre un des rares studios d’excellence, il est fort probable de travailler sur un jeu de niche ou un jeu de seconde zone pour un editeur ayant besoin d’ajoutter ca a son catalogue, le tout n’etant pas forcement tres excitant. De plus, et a fortiori si le jeu est commande par un editeur, il y a fort a parier que celui-ci ait son mot a dire sur les choix de game design.

Une chose que j’ai apprise est que s’il est facile de cataloguer une grosse equipe car les logiques de marche sont generallement les meme, c’est bien plus difficile pour une petite equipe qui peut varier du tout au tout en fonction de sa culture. Cela peut aller de l’escrot detournant des fonds, patron sans consideration pour ses employes a patron poule, ou ambiance militaire et j’en passe et des meilleurs….

Au dela des logiques de taille, etre petit amene plus de flexibilite et de character humain que les grosses entreprises ayant en partie “reussit” a gommee cet aspect avec leur methodes et procedes. Il faudra ainsi passer plus de temps sur l’analyse d’une petite equipe pour savoir dans quoi on va mettre le pied notamment via l’entretien d’embauche.

Voila qui conclue ce long article sur les petites et grandes equipes presentant principallement la qualite de vie dans ces structures.
Cela ne refletent evidemment en rien la qualite du jeu sur lequel on est amene a travaille.
Entre un gros studio qui par sa logique financiere va faire des licences a gogo et les petits studios qui font dans l’alimentaire (survie), c’est pas facile de trouve la perle rare.
Car sur la centaine de jeu qui sortent (ou pas d’ailleurs!) chaque annee, on ne se souviendra que d’une poignee au final.

En tout cas, personnellement, meme si cela fut plutot rude et pas toujours rose, je ne regrette pas d’avoir travaille sur Black and White. Si vous etes assez chanceux pour travailler sur un jeu a succes mondial, cela vous aidera assuremment dans votre carriere future.

Trackback URI | Comments RSS