Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

31/10/2009

La nature du travail...

En ce moment, je suis plongé dans les notions d’organisation du travail. Du coup, le poste qui suit est à l’image de mes réflexions : un joyeux bordel ^_^

 

Vous avez tous entendu parler de l’organisation scientifique du travail (le taylorisme), le toyotisme ou encore l’organisation hiérarchique, etc etc. Ces notions, qui viennent pour la plupart des industries « lourdes », sont bien évidemment relativement inadaptées à notre industrie (dans un cadre général bien sur).

 

La plupart d’entre nous savent que faire un jeu vidéo nécessite beaucoup de travail : rien de surprenant à cela et franchement, pas très instructif. On sait qu’il faut designer un jeu, écrire un scenario ou des règles, coder un moteur et du gameplay, modeliser des objets, créer des textures et des shaders, mettre en place des pipelines de productions, des machines de compilations, etc etc…

 

En fait, prise indépendamment et par corps de métier, les taches à accomplir sont relativement bien documentées et explicites. Et même prise dans leur globalité i.e dans l’organisation de ces différentes taches ou dans la gestion d’un projet, il existe des dizaines de documents au sujet de la gestion d’un pipeline, et des milliers de livres sur le management.

 

Toutefois, prenons un peu de recul, le temps d’essayer établir une sorte de dichotomie du travail en soi, hors de son contexte ou de son propos : établir la nature du travail.

 

Quelles sont les différents types de travaux qui sont réalisé dans les studios de jeu ?

 

Pour rendre les choses plus claires, voici ma liste, probablement très partielle, mais que vous allez m’aider à compléter. C’est encore un peu confus, j’en suis désolé, mais n’hésitez pas à me reprendre.

 

Dans un studio de jeu, nous effectuons des taches qui peuvent être qualifiées comme suit :

 

Création : J’ai toujours eu l’impression que les mots « créations » et « créativités » sont lourds à manipuler. Ils véhiculent tellement de choses, et sont tellement survalorisés dans notre société qu’ils sont souvent l’objet de débats passionnées et intenses.

 

Pour moi, au sens le plus pur, il y a création quand à un instant T il n’y a rien, et qu’à l’instant T+1 quelque chose à remplacé ce rien (création effective).

 

Du coup, a ce titre, quasiment tout les corps de métiers sont créatifs, puisqu’en transformant le travail en quelque chose il y a création de valeur ajouté. Et il nous faut donc pousser un petit peu plus loin le raisonnement.

 

Communication : La production d’un jeu est un défi humain, on le sait tous. Du coup évidemment, on passe un temps conséquent à communiquer. D’ailleurs, certaines taches tombent résolument sous le sceau de la communication (les réunions, les concertations, etc etc). On communique avec son équipe, avec sa hiérarchie, avec les autres équipes ou avec les autres corps de métier de l’entreprise, ou encore avec l’extérieur.

 

Il y a somme toutes très peu de taches qui ne nécessite pas communication à un moment ou à un autre, mais c’est une dimension que l’on ne peut pas ignorer. Par exemple, il faut rappeler que documenter, c’est aussi communiquer avec un futur lecteur.

 

Analyse : Analyser, c’est lever le voile sur des incertitudes. Le travail d’analyse se fait en règle générale par de la collecte d’informations, du travail de synthèse et de data mining.

 

L’analyse se fait à tous les niveaux. On la fait évidemment au niveau du marketing ou des ressources humaines, mais on la fait aussi à un niveau stratégique (quels jeux produire à l’avenir), ou à un niveau tactique (quels process à mettre en œuvre).

 

L’information est au cœur de ce que l’on produit (après tout, faire un jeu, ce n’est que créer une chaine intéressante de 0 et de 1) , mais aussi au cœur de l’organisation du travail.

 

Prise de décision : La prise de décision n’est pas en soi un acte créatif (quoique cela  puisse s’argumenter), mais c’est probablement l’acte productif le plus important dans un studio. Il y a prise de décision quand un choix est fait parmi une liste de possibilités définie.

 

Evidemment, toutes les décisions ne sont pas égales (choisir qui embaucher n’a pas le même impact que de choisir entre prendre un café ou un chocolat), et elles ne sont pas forcément parfaite i.e on a pas toujours toutes les cartes en mains pour prendre une décision.

 

Mais c’est probablement l’un des actes les plus communs dans un studio : une production de jeu est une chaine de prise de décision.

 

Design : Le design est un acte de création qui se fait à partir d’un certain nombre de contraintes, ces contraintes correspondant à un mandat ou à un contrat de design. Par exemple de mandat pour un game designer : un jeu (fun évidemment), qui s’adresse à tel frange de la population, dans tel ou tel genre de jeu (fps, rts…), destiné à tel ou tel éditeur (dans le cadre des designs ciblés), pour tel ou tel licences, qui peut éventuellement réutilisé le moteur interne ou une autre technologie, etc etc.

 

A une échelle plus micro, on peut demander à un artiste de designer un personnage répondant à tel ou tel spécificité physique ou dans un univers précis. De même, un programmeur peut designer un système dédié aux contraintes de tels ou tels machines, ou pour tel gamme de performances…

 

En somme, ces contraintes définissent un espace fini dans lequel la création va se déployer. Le design ne répond pas à un problème spécifique, mais va bel et bien définir un objet qui fera lieu de production.

 

D’ailleurs, la définition des contraintes du mandat de design est souvent le résultat du travail d’analyse et décisionnel qui aura été effectué en amont du travail du design.

 

Problem solving : La résolution de problèmes est un travail de design un peu particulier, puisque on ajoute à l’espace de contraintes prédéfinis une question bien précise à résoudre. Résoudre un problème est donc un travail de design particulièrement dirigé.

 

C’est une tache commune chez les programmeurs : la résolution des bugs et des crashs. Mais c’est aussi  un type de travail qui se retrouve à tous les niveaux de l’entreprise.

 

Ce qui est intéressant avec ce type de taches, c’est que certains problèmes sont récurrents (les bugs par exemple), tandis que d’autres sont de l’ordre de l’exceptionnel (mon GD vient de faire une dépression !). Il y a donc une diversité des solutions qui enrichissent d’autant plus la qualité du travail.

 

Résoudre un problème revient donc à proposer des solutions autour desquelles une décision sera prise (parfois automatiquement, parfois après concertation).

 

Production : La production effective d’une asset, d’un document, d’un système moteur, d’un disque… en somme, la production relève de tout ce qui peut être identifié « physiquement » i.e sous une forme réelle (enfin, dans la mesure où un fichier puisse être considéré comme un objet).

 

C’est somme toute ce qui est le mieux défini et le plus documenté, ce que les gens savent faire le mieux.

 

Ce qui est intéressant à ce niveau là, c’est la distinction entre les productions individuelles, et celles nécessitant un travail collectif (ces dernières étant bien évidemment bien plus difficile).

 

Contrôle : Qui dit production dit contrôle. Par exemple, les fameux QA (assurance de la qualité en amont et pendant la production) et QC (contrôle de la qualité après la production).

 

Mais le contrôle, c’est aussi s’assurer que les ressources sont bien alloués et qu’elles ne sont pas gaspillées : ressources financières (comptabilité), ressources humaines (RH), ressources temporelles (management de projet)…

 

Le contrôle est donc une sorte de tache d’analyse, servant souvent à la prise de décision, en fonctionnant comme une sorte de boucle de feedback (on produit, on contrôle, on décide de changer la production ou la procédure de contrôle, on recommence).

 

Management : Evidemment, tout cela ne peut se faire sans une notion de management. Le rôle principal du management c’est de s’assurer de l’efficacité optimale des différentes taches à réaliser avec les ressources (principalement humaines) disponibles.

 

Le rôle du manager regroupe plusieurs types de taches que l’on a déjà évoquées : analyse, problem solving, communication, prise de décision, contrôle… Toutefois, c’est un rôle suffisamment important pour mériter sa propre dimension.

 

Gestion : La gestion est une dimension particulière du management et principalement du contrôle. Je la distingue du contrôle en soit, parce que la gestion a un aspect quotidien et continue que n’ont pas les processus de QA et QC.

 

Formation : Enfin, une « nouvelle » dimension se rajoute, cette de la formation continue. Il s’agit là d’accroitre le capital humain. Beaucoup de société semble considérer cette tache comme étant de lors du privé. Et de fait, quand un employé se forme, c’est son capital humain à lui qui augmente.

 

Ceci dit, c’est ignorer le fait que le capital de l’entreprise est aussi en partie constitué de la somme du capital humain des employés. Il est donc vital que ce capital continue d’augmenter.

 

De même, nos technologies et nos organisations sont en permanentes évolutions, nous demandant donc de continuellement réactualiser notre savoir, notre savoir faire et notre savoir être.

 

En conclusions, même si nous pouvons définir la nature de chacune de nos actions prises une à une, le travail d’un studio est un perpétuel mélange de ces différentes taches.

 

Du point de vue individuel, une même journée peut être consacré à N différents types de taches (j’écris du code deux heures, puis j’ai une réunion d’une heure, puis j’écris une documentation, puis je design un nouveau composant, je fixe un bug pour débloquer quelqu’un etc etc…). De même sur le long terme, puisque les taches varient en fonction de la phase actuelle de la production (prototypage, pré prod, prod…).

 

Du point de vue structurelle, le travail des différents membres d’un studio tisse un patchwork de choses qui fonctionnent en parallèle, en pipeline ou en séquence (ou qui ne fonctionne pas, les fameux blocages).

 

Au regard de tout ça, on peut se pencher sur  l’organisation effective du travail. Par exemple, on pourrait remettre en question la notion de fiche de poste de travail associé à un titre : après tout, au vue de la diversité des taches que quelqu’un est appelé à effectué au fil du temps, on peut se dire que les postes sont bien difficile à définir à partir d’une division scientifique hérité du temps d’Henri Ford.

 

De même, on peut s’interroger autour de la quantification de la valeur ajouté produite par autant de taches quand autant de taches ne produisent effectivement rien de physique. Par exemple, on peut logiquement se dire que la rémunération devrait être à l’aulne de cette valeur ajouté. Hors il est très difficile de calculer cette même VA au niveau individuel.

 

On pourrait même aller plus loin en questionnant l’organisation de l’entreprise en grandes fonctions distinctes (RH, Marketing, Production, Management…). Ces fonctions font bien sur appel à des compétences différentes, mais constituent elle la division naturelle ou optimale des ressources dans le cadre d’un studio de jeu vidéo ? A voir…

21/10/2009

La production outsourcée...

Au détour d’un énième article sur la fermeture de Midway Newcastle, l’auteur revient sur la fin des « mega studios » :

 

Employing just four in-house designers as well as a hand-picked pool of freelancers, Atomhawk may well be indicative of a new era of game development.


The introduction of outsourcing has gradually chipped away at the notion of the one-stop-shop model, where a single studio produces a whole game from conception to completion. In the increasingly competitive economy, that is not viable.

Instead, things are beginning to resemble another area of the entertainment media.

"I believe the industry is moving toward a movie studio model," says Ashtiani. "There, only the key individuals like the director, the producer and the actors are on staff for the duration.

CG, cinematography, lighting are all provided by specialist companies brought in to do the job before moving on to the next contract.

This means that productions can hire very specialist firms that contain expertise and talent that they would normally struggle to hire direct or would be a financial burden when they are not needed."

Not all struggling games companies will be bailed out at the last minute. "Small developers are more likely to survive if they have access to expert advice and help," says Wilson.

"TIGA has recognised this and we are building up a network of business advisors including accountants, lawyers, and outsourcers who can provide expert help to studios facing difficulties. We also have a number of initiatives called 'Play Together' designed to help studios manage things like recruitment costs and avoid potential redundancies.

For example, via our website we offer a 'Job Sharing' service which allows developers to loan staff for a period of time to other developers, this helps studios manage the resource swings brought about by the nature of game development."

[ Guardian]

 

Ce qui est intéressant, c’est la diversité des initiatives et des modèles de développements. Comme en France, la « crise » pousse les studios Anglais a recherché des moyens de partager leurs ressources (en particulier les ressources humaines, les plus couteuses), et à en outsourcer autant que possible.

 

Ce que l’article ne précise pas, c’est que cette remise en cause des structures s’accompagne aussi d’une refonte des montages financiers finançant la production des jeux. Dans un environnement ou chacun essaye de minimiser les risques au maximum, on se dirige vers un marché ou des structures éphémères se créeront autour d’un projet unique.

 

Ca ne veut pas dire que les mastodontes vont disparaitre, loin de là : leur capacité à accéder au capital (le nerf de la guerre pour le développement des jeux console) fait que le marché restera la chasse gardée des gros éditeurs.

 

Par contre, c’est la fonction de développement qui semble appelée à se disperser dans une galaxie de petites structures hautement spécialisées. A la suite logique du développement des ressources middlewares (qui externalise la R+D en quelque sorte) et à celle des entreprises d’outsourcing graphique (qui externalise la production des assets), c’est la fonction de production elle-même qui semble voué à la dispersion...

10:09 Publié dans Business | Lien permanent | Commentaires (10)

14/10/2009

Développeurs stars ?

Il y a une tendance qui commence a émerger en ce moment: la vidéo de bureau. EA utilise ce mode pour communiquer sur ces prochains titres par exemple:

 

 

 

 

D'autres ont une approche un peu plus "barré", comme cette vidéo de ouf qui nous vient des devs d'Eve Online ^_^

 

 

En France pour l'instant, on s'en tient a du classique, comme cette présentation du studio Ankama.


Ankama - Vivre ANKAMA

In game advertising: You're doing it wrong...

gam_pizzaphantasy_580.jpg

13/10/2009

The Ready At Dawn Engine

Tiens, après Insomniac qui partage une partie de sa base de code (a.k.a Nocturnal), c'est au tour de Ready At Dawn qui, si j'en juge par le pitch à peine voilé, se verrait bien à la place d'Epic ^_^

 

Tired of PC engines shoe-horned into game consoles?


Tired of engine middleware forcing you to run around to other vendors and integrate even more middleware in order to get your game done?


Tired of sales hype and flashy demos that do not deliver in the real world?


Introducing the Ready At Dawn Engine.


The complete game development platform

 

[ RAD:E ]

 

En soi, évidemment, ce n'est pas un mal. Nombre de studios essaient de rentabiliser leurs couts R+D. De plus, il est probablement trop tard dans le cycle de développement pour démarer un moteur from scratch ^_^

 

shapeimage_7.png

13:37 Publié dans Code | Lien permanent | Commentaires (5)

12/10/2009

Focus Opportunity

Je suis un peu débordé en ce moment: il faut dire que je suis aussi sous les cartons, vu que je déménage bientôt.

 

En tout cas, petit retour sur cette interview de Cedric Lagarrique, qui détaille son opinion après le rachat de Nadeo par Ubisoft. Apparement, la communauté hardcore n'a pas vraiment apprécié la nouvelle, et il est possible que Focus ait en effet perdu un titre phare.

 

Ceci dit, ça veut aussi dire qu'il y a une opportunité pour un petit studio ambitieux, vu que Focus ne va pas s'arreter là...

 

Je pense qu'il est important de préciser au regard des nombreuses réactions déclenchées suite à cette annonce, que nous n'avons pas découvert ce rachat en lisant les annonces presse de lundi. Nous sommes au courant des discussions entre Nadéo et plusieurs éditeurs depuis un long moment.

 

Cela s'est fait progressivement, nous avons appris en décembre dernier, par l'équipe de Nadéo avec qui nous entretenons des rapports uniques, que l'actionnaire majoritaire de Nadéo voulait se désengager du jeu vidéo pour se concentrer sur le cinéma. Nous sommes forcément très déçus de la tournure des évènements et de l'absence de communication de cet actionnaire majoritaire.

 

On aurait pu penser au regard de notre historique qu'il prendrait le temps de nous expliquer la situation. Il n'a même pas cherché à nous mettre en concurrence avec les autres éditeurs. Quand je vois le montant final de la transaction [estimé à environ 6 millions d'euros selon EasyBourse, ndlr], très éloigné de ce qu'on nous avait laissé entendre à un moment, j'ai forcément des regrets.

 

Je pense qu'on aurait eu notre mot à dire en proposant des solutions qui auraient pu laisser au studio son indépendance. Alors forcément, c'est une déception de voir si peu de reconnaissance.

 

[ Gamekult ]

20:26 Publié dans Business | Lien permanent | Commentaires (1)

08/10/2009

Photosketch

ME. WANT. THIS. NOW !!! ^_^

 

 

PhotoSketch: Internet Image Montage from Tao Chen on Vimeo.

14:36 Publié dans PAPERS | Lien permanent | Commentaires (4)

07/10/2009

La SACD offre un voyage à la prochaine GDC...

La SACD (si si) organise un concours pour offrir une participation à la prochaine GDC à deux auteurs multimédias: candidature à renvoyer avant le 26 Octobre ^_^

 

Nous remercions l’ENJMIN pour sa participation à l’élaboration de ce dossier de candidature. L’ensemble du dossier sera constitué de :


IMPERATIF ET DETERMINANT :


Une courte vidéo qui permettra au jury de mesurer l’enthousiasme et la détermination du candidat à participer aux différentes manifestations.


La SACD recherche avant tout des auteurs de jeux vidéo, futurs Peter Molyneux, Sid Meier ou Will Wright de cette industrie. Il nous a donc semblé important, au-delà des maquettes de jeux vidéo, d’essence collective, de bien identifier des personnalités fortes, qui défendront les couleurs de la création française outre-Atlantique ! Cette vidéo sera donc déterminante pour mieux cerner la personnalité des futurs lauréats.

 

[ SACD ]

06/10/2009

Ubisoft rachète Nadeo...

Bon, évidemment, à moins de vivre dans une cave, vous êtes déjà au courant qu'Ubisoft vient de racheter la petite équipe de Nadeo, pour 6 millions d'Euros. A mon avis, à ce prix là et vu le talent de l'équipe, c'est une vraie affaire pour Ubi, et une réelle chance pour les futurs projets de l'équipes ^_^

 

39048_large.jpeg

21:11 Publié dans Business | Lien permanent | Commentaires (1)

01/10/2009

Data driven engines, data driven bugs...

La plupart des moteurs de jeu modernes sont dit “data driven” i.e la majorité de l’expérience de jeu est défini par les données, pas par le code.

 

 

Evidemment, c’est beaucoup plus facile à dire qu’à faire.

 

 

Déjà, ces données doivent provenir de quelque part, et emmener ces données dans le jeu est le rôle principal du pipeline. Il y a 3 façons de produire les données qui vont composer une asset : par production avec un outil « externe » (3DSMax, Maya…), par production avec un éditeur interne (en général, l’éditeur de jeu), ou enfin par production automatisé de type batch (génération des light map ou du mesh de navigation, etc etc).

 

 

Jusqu’ici, tout va bien.

 

 

Le hic, c’est que comme le moteur est data driven, beaucoup de bugs ou de problèmes sont data driven aussi. En d’autres termes, il est plus ou moins aisé de créer des cas pathologiques, des problèmes de performances ou encore de réels bugs complexes dus à l’interaction entre ces données.

 

 

Du coup, quand on a identifié un de ces problèmes, on a souvent besoin de pouvoir remonter à la donnée source qui a produit l’asset. C’est l’une des qualités premières d’un bon pipeline que de simplifier ce travail d’investigation.

 

 

Et évidemment, ce n’est pas si simple que ça, car il n’y a pas une relation unitaire entre une asset donnée et un fichier source.

 

 

Un fichier source peut par exemple générer plusieurs assets. Il est ainsi fréquent que les animateurs stockent leurs animations dans un seul fichier pour Motion Builder afin de simplifier leur travail. Du coup, un fichier source va permettre de générer N animations, ces N animations pouvant parfois être utilisé dans M banques d’animations.

 

 

Le problème inverse existe aussi : une asset peut parfaitement être le produit de l’interaction entre plusieurs données. Par exemple, une texture compressée est le produit d’une texture d’origine et d’un fichier de configuration de compression. La qualité d’un mesh de navigation résulte de l’interaction entre les éléments de collisions et les informations de design posés dans tout un niveau.

 

 

Ces considérations de dérivations (retrouver le ou les sources qui ont produits l’assets), de dépendances (lister toutes les assets qui dépendent les unes des autres) ou d’interactions (retrouver les assets qui peuvent influer sur la production ou le comportement d’une asset donnée) forment le cœur des problèmes « data driven ».

 

 

Il n’y a pas de solutions idéales, mais il y a des outils et des process qui peuvent aider à se dépatouiller.

 

 

- Etre à même de tracer l’origine d’une assets, les différentes dépendances directes ou indirectes pour cette asset, et l’historique des fichiers sources concernés.

 

 

- Pouvoir reconstituer facilement tout ce qui a participé à la création d’une asset à un instant T donnée, ce qui signifie de pouvoir retrouver toutes les sources ainsi que tout les process qui ont participé à la création de l’asset.

 

 

- Permettre de versionner les assets, en autorisant (ou pas, voir au cas par cas) la rétro compatibilité. Permettre aussi de synchroniser ces versions afin de « labelliser » un ensemble d’assets et de fichiers sources pour archivage et/ou récupération postérieure.

 

 

- Etablir des mécaniques permettant d’identifier « gracieusement » les données manquantes ou mal formées : assets par défaut ou de secours permettant au runtime de continuer à fonctionner malgré une erreur dans une donnée, log et emailing automatisé, machine de tests unitaires ou de tests de stress…

 

 

L’essentiel, c’est de garder le contrôle sur ce qui va constituer le corps du jeu. Personne n’a envie de se retrouver à rechercher en vain un fichier 3dsmax contenant la modélisation d’un personnage qui a été ajouté 6 mois plus tôt. De même, découvrir par hasard une dépendance caché entre deux types d’assets disjoints peut être fatal à la bonne humeur quand on a nettoyé l’une de ces assets ^_^

14:28 Publié dans Code | Lien permanent | Commentaires (18)