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.

10/08/2009

Obsessions

 

En ce moment, je suis obsédé par les défis posés par la création de jeu vidéo, et en particulier comment maximiser les opportunités de productivités en équipe réduite (wouah, on dirait le sujet d’une thèse !). Ce qui est intrigant, ce n’est pas tant le sujet en soit (ni les solutions que j’essaie de développer), c’est plutôt les formes que prennent cette obsession.

 

Ce n’est pas un secret, l’obsession n’est pas forcément malsaine. Cela signifie juste que mon cerveau met à profit toutes les opportunités possibles et imaginables pour se pencher sur le domaine du problème. Je sais que chez moi, ca a toujours été un signe de créativité, l’obsession entrainant le travail, et le travail conduisant en principe à l’excellence.

 

Dans « Outliers », Malcolm Gladwell défend la thèse que si le génie existe, il est surtout et en règle générale le produit d’un intense travail sur le sujet en question (A common theme that appears throughout Outliers is the "10,000-Hour Rule". Gladwell claims that greatness requires enormous time, using the source of The Beatles' musical talents and Gates' computer savvy as examples.).

 

 

Outliers.png

 

 

Accumuler 10 000 heures de travail, ça peut paraitre immense comme ça, mais ça vient vite. Et heureusement d’ailleurs, la maitrise peut apparaitre bien plus tôt.

 

Sachant cela, j’ai toujours accueilli l’obsession à bras ouvert, parce qu’il s’agit du moteur le plus puissant permettant d’atteindre ce quotas. Rien ne bas le travail fourni sous l’égide de la nécessité autoritaire, le besoin impérieux de faire quelque chose.

 

Evidemment, l’obsession est une mauvaise maitresse : elle n’admet ni repos, ni agenda, ni médiocrité. A l’excès, c’est aussi une bien mauvaise conseillère, peut être même une maladie.

 

Mais j’avoue avoir trouvé son ombre dans les pas de toutes les personnes qui m’ont impressionné, et je suis convaincu qu’elle fourni l’énergie à nombre de développeurs.

 

Et vous, qu’elles sont vos obsessions ? ^_^

 

13:18 Publié dans Idées | Lien permanent | Commentaires (9)

07/08/2009

SIGGRAPH 2009: Beyond Programmable Shading

Je n'aurai pas le temps de poster quoi que ce soit ce week end, mais voici de quoi s'occuper d'ici à Lundi (enfin, pour les codeurs). Les notes du cours "Beyond Programmable Shading" du siggraph 2009 sont disponibles en lignes, avec en particulier quelques détails au sujets du moteur FrostByte de Dice (qui fait tourner Battlefield Bad Company et Battlefield 1943), ainsi que quelques notes sur le nouveau moteur d'ID (Rage):

 

There are strong indications that the future of interactive graphics programming is a more flexible model than today's OpenGL/Direct3D pipelines. Graphics developers need a basic understanding of how to combine emerging parallel programming techniques and more flexible graphics processors with the traditional interactive rendering pipeline.

 

The first half of the course introduces the trends and directions in this emerging field. Topics include: parallel graphics architectures, parallel programming models for graphics, and game-developer investigations of the use of these new capabilities in future rendering engines.

 

The second half of the course has leaders from graphics hardware vendors, game development, and academic research present case studies that show how general parallel computation is being combined with the traditional graphics pipeline to boost image quality and spur new graphics algorithm innovation.

 

Each case study discusses the mix of parallel programming constructs used, details of the graphics algorithm, and how the rendering pipeline and computation interact to achieve the technical goals.

 

The focus is on what currently can be done, how it is done, and near-future trends. Topics include volumetric and hair lighting, alternate rendering pipelines including ray tracing and micropolygon rendering, in-frame data structure construction, and complex image processing.

 

The course concludes with a panel, moderated by the creator of OpenGL Kurt Akeley, on the future of interactive graphics programming models.

 

[ Beyond Programmable Shading ]

18:40 Publié dans Code | Lien permanent | Commentaires (0)

06/08/2009

La formation initiale dans le secteur du jeu vidéo en France

La formation est toujours un sujet populaire. D'une part parce que les pro aiment bien "bitcher" sur les formations en générales (celles qu'ils ont eux ou d'autres), et d'autre part parce que, pression démographique et économique aidant, il y a beaucoup plus d'aspirant aux métiers du jeu vidéo que de professionnels confirmés.

 

C'est marrant d'ailleurs, puisqu'au fond, un jeune qui fini ses études à 22 ans à devant lui bien, allez, 40 ans de carrière à faire  au bas mots (au moins). Au bout de combien de temps est ce que la formation initiale pert de sa pertinence ?

 

Mais là n'est pas la question ^_^. Le SNJV a publié un rapport sur la formation initiale dans le secteur du jeu vidéo en France, et ça mérite un regard:

 

Cette enquête confirme l'importance d'être formé spécifiquement aux métiers du jeu vidéo pour intégrer cette industrie créative. Aujourd'hui, 74% des entreprises du secteur ont des salariés qui proviennent de ces formations. Les professionnels soulignent également la nécessité d'acquérir une bonne culture vidéoludique et de l'expérience afin de garantir une intégration des jeunes diplômés en entreprises. L'expérience est d'ailleurs considérée par 58% des professionnels comme un élément très important pour intégrer le secteur.


Les formations initiales spécialisées constituent une première réponse adaptée aux besoins des entreprises pour 70% des personnes interrogées, même si elles suggèrent malgré tout de nombreuses pistes d'améliorations. Les entreprises sont d'ailleurs une majorité à s'impliquer à différents degrés dans les enseignements proposés en France. 24% sont présentes dans les jurys et 20% mettent à disposition des salariés pour enseigner au sein de ces formations.


Dans le même temps, les professionnels confirment leurs difficultés à recruter certains profils spécifiques, comme les Game Designer(21%) ou les Programmeurs (33%).


[ AFJV ]

 

Le développement de jeux vidéo pour consoles de salons (anciennes et nouvelles générations) représente 30% de l’activité des studios interrogés et demeure l’activité majoritaire en 2009.


Dans le même temps, le développement sur consoles portables ou sur téléphones mobiles devient le 2e marché visé par les développeurs français et représente 21% de l’activité des studios devant le développement de jeux PC qui constitue quant à lui seulement 13% de l’activité totale. Les activités d’édition (7%) ou de distribution (3%) de jeux vidéo, sont encore marginales mais reflète le changement de stratégie des développeurs sur des métiers auparavant dévolus aux seuls éditeurs internationaux.


Le développement du marché des jeux en ligne et la recherche de la relation directe au consommateur, sont deux explications crédibles de ce phénomène naissant.


Le secteur est majoritairement (42%) composé de TPE de moins de 10 salariés. Si on totalise les effectifs déclarés, 57% des entreprises du secteur emploient moins de 20 salariés dans leurs équipes.


Selon notre enquête, 75% des salariés du secteur ont une formation supérieure.


En effet, 33% des futurs employés du secteur ont déjà une première expérience professionnelle avant d’intégrer une entreprise française de production de jeux vidéo. Pour 77% d’entre eux, travailler dans une entreprise de jeux vidéo constitue la première expérience professionnelle. 15% des jeunes salariés proviennent des organismes d’enseignements spécialisés aux métiers du jeu vidéo.


Les profils de programmeurs sont majoritairement les plus difficiles à recruter et cela s’explique, selon les répondants, par la concurrence des SSII sur ce métier. Elles offrent à ce stade des rémunérations plus intéressantes et une plus grande sécurité de l’emploi.


Alors que les formations en Game design se développent, les entreprises continuent d’avoir des problèmes de recrutement sur ces profils, principalement en raison de salaires trop élevés demandés, du manque d’expérience des candidats ou encore d’une faible spécialisation. Les autres arguments invoqués par les entreprises qui estiment avoir des difficultés à recruter sont la faible culture videoludique des candidats ou encore leur manque de maturité.


Si 99% des entreprises déclarent avoir connaissance de l’existence de formations spécifiques aux métiers du jeu vidéo, elles restent 31% à déclarer ne pas disposer d’information sur la nature et les contenus de ces formations.

 

[ SNJV ]

 

Je m'arrête sur le passage au sujet des GD qui prennent - il faut bien le dire - un peu cher ^_^

 

A votre avis, c'est quoi, "avoir une culture vidéoludique" ? Est ce bien connaitre les jeux, ou comment se passe une prod, ou qui est qui dans le petit monde du jeu ? Sincèrement, c'est un terme un peu flou.

 

Quand au manque de maturité, oui, c'est fort possible. Après tout un jeune GD de 20 ans, ben, il a 20 ans quoi ^_^ Vous avez jamais eu 20 ans ?

 

Personnellement, je préfère le terme "sang-froid" à une notion de maturité un peu paternisante. Gardez la tête froide, voilà la qualité primordiale qu'il faut avoir pour bosser dans le secteur, a mon avis en tout cas ^_^

13:56 Publié dans Business | Lien permanent | Commentaires (20)

05/08/2009

Army Of Two à EA

Je suis pas un fan de la série, mais ce trailer est vraiment énorme ^_^

 

 

04/08/2009

Game Business Summit

Tiens, j’ai appris qu’il y a à Paris un « Game Business Summit » en Septembre :

 

Quel sont les objectifs ?

  • Organiser la rencontre entre les porteurs de projet et les acteurs intervenant dans le financement, l’accompagnement et le soutien de la production de jeu vidéo.
  • Apporter un éclairage concret sur les évolutions du marché, les nouveaux business models, les modes de retour sur investissement.
  • Donner une vision complète des dispositifs de financement existants.
  • Profiter de l’expérience de plusieurs acteurs du marché.

 

A qui s'adresse l'événement ?

 

  • Porteurs de projet
  • Capital Investment (Private Equity, Banques, Fonds, FCPI, FCPR, SCR…)
  • Professionnels de la finance (analystes, avocats, experts-comptables, courtiers d'assurances…)
  • Institutions publiques (CNC et DGCIS (FAJV), Oséo/ANVAR, Pôle de Compétitivité…)
  • Editeurs
  • Médias spécialisés

 

[ Game Business Summit ]

 

header.jpg

17:00 Publié dans Business | Lien permanent | Commentaires (11)

03/08/2009

Unsung heroes: Performances

Pour une raison qui m’échappe, quand on parle des performances d’un jeu entre codeurs, on tombe très vite dans un certain nombre de travers qui vont du déni le plus farouche (ce n’est pas le plus important) au délire mystique façon secte (c’est fait comme ça parce que c’est comme ça qu’il faut faire) en passant par les égos les plus sensibles qui soit (mon code est toujours le meilleur).



Sigh, c’est à vous découragez de vouloir avoir une discussion adulte ^_^



Commençons par reprendre les faits. Pourquoi les performances des applications sont elles si importantes ?



1 - On recherche les performances pour réduire la latence gameplay :



- Nous programmons des jeux i.e des programmes qui interagissent avec un être humain.


- Pour que ces programmes soient efficaces, il faut que la boucle de feedback soit la plus rapide possible i.e il faut réduire la latence au strict minimum.


- La latence acceptable varie en fonction du design du jeu. Ce qui est acceptable pour un démineur ne l’est déjà plus pour un Tetris. Ce qui est acceptable pour un Tetris ne l’est plus pour un jeu de course. Et nombre de joueurs ne peuvent pas jouer à un FPS en dessous de 60 Hz.


- Pour ce faire, la latence « gameplay » est donc la première considération de la programmation orientée performance.



2 – On recherche les performances pour délivrer une expérience :



- Beaucoup de jeux (en particulier ceux qu'on appellent les AAA) recherchent à délivrer une expérience réaliste (voir surréaliste).


- Pour ce faire, on souhaite rendre les décors et les personnages les plus beaux possibles, avec un maximum de détails et d’animations diverses.


- On cherche aussi souvent à augmenter la diversité sans augmenter le surcout en production de données.


- Enfin, on cherche parfois à créer des expériences uniques qui ne peuvent pas être sans une couche software dédié.


- Dans tout ces cas là, la considération de performance est importante, puisqu’elle défini les limites techniques de l’expérience délivrable.



3 – Les considérations de performances ne sont souvent pas dissociables de la plateforme hardware.



- Nous programmons des jeux sur plateforme embarquée (oui, les consoles sont des plateformes embarqués).


- Ces consoles, même si elles ont une couche OS relativement fine, proposent toutes des services et des composants différents, et souvent en quantité limité.


- Pour maximiser les performances de nos applications, on souhaite exploiter chacune de ces ressources du mieux possible (mémoire, parallélisations, optimisation…).


- Dans ce cadre, il y a donc deux types de performances qui nous intéresse : la performance mémoire (ou comment utiliser le moins de mémoire possible), et les performances logicielles (ou comment maximiser son throughput i.e combien de choses peut on faire à la frame).



Quand on prend un point de vue très pragmatique, ça parait simple dit comme cela, alors pourquoi est-ce un sujet si controversé ?



Pour simplifier, il y a deux dérives fréquentes : l’excès de zèle, et le déni.



L’excès de zèle est une pratique commune qui revient à mettre les considérations de performances sur un pied d’estale et à dénigrer tout le reste (lisibilité, maintenance, simplicité). C’est un travers parce qu’il oublie que la performance est au service de l’application, et pas l’inverse.



C’est une attitude de programmeur cowboy qui conduit souvent à l’arrogance ^_^



Le déni lui provient en général d’une mauvaise interprétation de la fameuse phrase « premature optimization is the root of all evil ». Il semble qu’elle soit souvent comprise comme étant une excuse pour ne considérer les performances qu’en aval de l’exécution. S’il s’agit d’une attitude saine en règle général, il ne faut pas non plus que cela devienne une excuse pour renoncer à la pensée !



Puisque l’on connait nos plateformes, nos contraintes, et nos objectifs, c’est bel et bien en amont qu’il faut penser aux performances ! En fait, ce qu’il faut comprendre de la phrase, c’est ça : « premature optimization in the implementation is the root of all evil ».



Ce sont les optimisations incertaines dans l’implémentation qui posent problème, pas le fait de s’être creuser la tête pour choisir les bons algorithmes et les bonnes structures de données dès le départ !



Programmer pour les performances, c’est savoir se poser des questions, et de préférences les bonnes questions, et ce dès le départ. Prenons quelques exemples, fournis par Mike Acton, directeur technique chez Insomniac.



Dans « Quicksort is not a concurrent algorithm », Mike reviens sur le grand cas d’école typique qui tout le monde apprend pendant ses études : le quick sort. Souvent, on passe beaucoup de temps à apprendre différents algorithmes de tri, et parfois on apprend même à les implémenter plus ou moins efficacement.



Du coup, comme on tri souvent pas mal de choses dans les moteurs de jeu, on pense naturellement à optimiser ces algorithmes là. Logique non ?



Pourtant, est ce que l’on se pose les bonnes questions ? Déjà, pourquoi est ce que l’on tri ces données ? Et c'est quoi qu'on tri au fait ? Qu’allons-nous faire de la liste une fois trier ? Ai-je vraiment besoin de construire la liste avant de faire ce que je veux faire avec ces données ? Et puis d'abord, est ce vraiment le tri qui fait bottleneck de toute façon ?

 

 

607502049_E5U3W-M.jpg
607500913_9g4QE-M.jpg
607502496_X86VV-M.jpg
607511303_ZFgZ4-M.jpg
607512040_rYeSX-M.jpg
607513958_4ycnr-M.jpg
607514302_iH8T6-M.jpg
607514643_eLhhh-M.jpg
607520763_iAUki-M.jpg
607517752_D6sDV-M.jpg
607518080_Gr9MT-M.jpg

 

[ La suite chez Mike Acton ]



Autre cas d’école, autre exemple analysé par Mike, implémentation d’un algorithme de détection de collision entre une sphère et un plan. Ca aussi, c’est du code très utilisé et balisé depuis des années dans les graphics gems.



Pour autant, ca ne nous dispose pas de savoir se poser les bonnes questions : combien de plans et de sphères ait je besoin de tester exactement ? Une, deux, mille ? Et comment se comporte mes données sur la plateforme cible ? Et dans combien de situation fait avoir à implémenter un comportement différent nécessitant une implémentation virtuelle? Est-ce que mes données sont triés, et si elles ne le sont pas, est ce que je ne gagnerai pas à ce qu’elle le soit avant ?

 

 

1.jpg
2.jpg
3.jpg
4.jpg
5.jpg
6.jpg
7.jpg
8.jpg

[ La suite chez Mike Acton ]



Programmer pour les performances pour plateforme embarquée nécessite donc un certain état d’esprit (et, il faut bien le reconnaitre, de solides connaissances au sujet de la plateforme et du compilateur). Mais il y a certains principes qui émergent toutefois, et que l’on peut garder à l’esprit quand on s’y essaye. Ce sont ce que Mike appelle les 3 mensonges :



Lie 1: Software is a platform



Something that often is being teached at schools. It comes around the idea that you shouldn't care about what hardware you are running. Software is not a platform, software is always running on hardware and even if it may be different hardware its hardware that we can understand and optimize for.



Lie 2: Code should be designed around a model of the world



In typical C++ and OOP code there is idea that you need to model your code around the real world.





The typical problem with code like this is that above all it doesn't scale. Today all code that is used during run-time needs to been designed with data layout in mind and for multicore.


...



Lie 3: Code is more important than data



I touched a bit about this in the above point as well. This is the big one. We spend way way too much time talking about code when it really doesn't matter. When doing time critical programming one can think of it as a complex DSP. We get data in, modify it and send out. We spend very little time on actually talking about how the data flows in an application. Data is what should be dictating all decisions in your application. If you don't know the data how will you know how it will perform? where the bottlenecks will be, etc. You have no idea.



If data is designed in a correct (and often simple way) you should only be able to write the code in one way.



 

[ Daniel Colin ]



Ce n’est pas que ces conseils soient définitifs ou absolus, ni qu'ils doivent s'appliquer partout pour tout, ils peuvent parfaitement être invalidés par les progrès techniques et logicielles. Mais pour l’heure, en ce qui concerne les plateformes embarquées actuelles, et à venir dans un futur proche, ce sont les meilleurs conseils qui soient.

 

Et dans tout les cas, il faut bien admettre que tout travail sérieux démarre au moment où l'on commence à se poser des questions, et c'est la qualité première en ingénierie, n'est ce pas ? ^_^

14:00 Publié dans Code | Lien permanent | Commentaires (21)

31/07/2009

So you wanna be an indy game developer

Les développeurs indy ont la côte en ce moment. Depuis l’émergence de l’AppStore sur l’Iphone, devenir indépendant semble même être devenu une nouvelle marque de bon gout. Retour sur un mouvement qui change peut être la donne.

 

 

Ah indépendance, un bien joli mot trop souvent confondu avec liberté. On l’accole à tort et à travers, on parle de studio indépendant, et même d’éditeur indépendant. Indépendant d’accord, mais indépendant par rapport à quoi ?

 

 

Par exemple, on parle de studio indépendant quand un studio n’est pas membre à part entière d’un éditeur. Mais tous les studios indépendants ne sont pas forcément des développeurs indépendants !

 

 

En fait, il semble qu’il y ait autant de définition du mot indépendance qu’il existe de business model différents !

 

 

Mais dans le cadre de cet article, un développeur indépendant, c’est un développeur qui finance, design, produit et commercialise lui-même ses jeux. Cette démarche lui permet donc de maitriser sa chaine de valeur de bout en bout (d’où le terme indépendant).

 

 

C’est une démarche qui tranche par rapport à la démarche d’un studio classique. Le studio classique lui fait financer ses produits par un éditeur, abandonnant en règle générale tout ou partie du contrôle éditoriale sur le jeu, ainsi que l’IP (quand l’IP n’appartient pas déjà à l’éditeur ou à une tierce entité). A ce titre, le gros de la prise de risques échoue sur les épaules de l’éditeur.

 

 

Le développeur indy s’auto finance. Ca signifie qu’il a besoin de trouver des fonds par lui-même pour produire, mais aussi qu’il est extrêmement sensible aux chiffres de ventes du jeu (à l’inverse du studio qui lui essaye souvent d’émarger sur le cout de la production, ce qui n’est pas forcement le meilleur des business model).

 

 

Il est du coup souvent petit (voir un seul développeur), et essaye de réduire son train de vie pour diminuer ses besoins en cash flow.

 

 

Jeff Ward revient donc sur les calculs que tout les dev indy doivent faire : combien vendre pour être « viable » (Pour rappel : 40 000 $ revient à 28 300 €) :

 

 

Today, along with Darius, I started doing a little bit of math about indie game numbers, and it's gotten me wondering, can you actually support yourself, and a company, on indie games (indie, in this case, meaning a smallish team experimenting with interesting gameplay concepts and styles).

 


How many copies of a single game does a developer need to sell per year in order to support themselves? Let's start at a base line of $40k per year for a single developer.

 


Now we need to figure in loss to distributors. Let's ignore distributors with up front cost / approval process (XBLA, PSN, and WiiWare) because even developing for these services usually requires either an already proven game or proven team, and we're assuming neither. This leaves us with iPhone, PC (in various forms, we'll focus on two as you'll see shortly) and Xbox Live Indie Games.



 


IPhone:



App Price

Gross to Dev

Number of Sales Needed / developer

$1

$.70

57,000 / year

$2

$1.40

28,500 / year

$3

$2.10

19,000 / year

$5

$3.50

11,400 / year



So at the pretty much standard rate of $1, a single developer needs to push 57 thousand copies of their game per year in order to support themselves, or push multiple applications which can come up to that number.



PC:

 


Game Price

Gross to Dev

Number of Sales Needed / developer

$5

$4.59

9000 / year

$10

$9.48

4000 / year

$15

$14.37

2800 / year

$20

$19.56

2000 / year

$30

$29.04

1400 / year

 


Looking at these numbers, it's almost obvious why most successful indie developers start on PC.

 


To be successful, you need to be in one of a few situations:

 


  • A single developer that makes a good title (Petri, for example)
  • A single or set of developers with short release cycles to keep multiple games relivant over short periods of time. (Almost all iPhone developers).
  • A developer that has an already popular game and is able to get on one of the more visible services  like XBLA, PSN, or WiiWare (That Game Company, the Behemoth, 2D boy, Number None)

 


This is why indie games experiment the way they do.  Shorten the dev cycle, concentrate on mechanics and prototypes, keep art resources and requirements low, release lots of games quickly.

 


[ Jeff On Games ]


Ces chiffres – fait à la louche on le rappelle - correspondent à l’objectif de faire 28 000€ en chiffre d’affaire. Ce qui signifie qu’il faudra déduire les taxes, et ensuite déduire les impots sur le revenu. Ouch.

 

Ceci dit, les conseils qu’ils donnent restent valides : produire plus, produire mieux. Toutefois, le focus sur le gameplay et les mécaniques de jeu est un conseil à double tranchant. C’est vrai au sens où le gameplay scale mieux que le contenu.

 

 

Mais le gameplay seul ne peut pas générer des ventes, surtout quand on s’aligne sur le secteur des achats impulsifs (jeu à moins d’1$ sur l’IPhone par exemple). Sur ce segment là, il est important de soigner sa présentation (ce qui ne signifie pas forcément faire plus de contenu d’ailleurs).

 

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

30/07/2009

Pixar, les magiciens du scénario

C’est peu dire que j’ai de l’admiration pour Pixar. Et je sais que je ne suis pas le seul. Retour sur le mythe qui autour cette société à l’occasion de la sortie de « La haut » :

 

la-haut-41457.jpg

Pixar s'est précisément structuré pour se protéger des financiers. Investisseurs et actionnaires n'interviennent jamais dans la réalisation ou le choix des films.


Les studios sont dirigés par des créateurs et le pouvoir reste, quoi qu'il arrive, entre leurs mains. Dans ce groupe homogène, stable et soudé, on compte John Lasseter ; Andrew Stanton, réalisateur du Monde de Nemo et de Wall.E ; Pete Docter, à qui l'on doit Monstres et Cie et Là-haut ; Bob Peterson, co-réalisateur de Là-haut ; Lee Unkrich, scénariste de Toy Story 2 ; Brad Bird, l'auteur des Indestructibles et de Ratatouille.


Ils sont presque tous présents depuis la création de Pixar. S'il existe une recette à la créativité des studios, elle réside dans l'anti-taylorisation du travail.


Pixar a tout d'un studio à l'ancienne, et fonctionne sur des principes similaires à ceux qui firent la fortune d'Hollywood dans les années 1940, quand réalisateurs, écrivains et techniciens, tous salariés, travaillaient dans un lieu unique et passaient indifféremment d'un film à l'autre, quelquefois sans même être crédités au générique.



Autre particularité de Pixar : le ratio entre les idées développées et les idées produites est de 100 %. Dans les autres multinationales de l'audiovisuel, seuls 10 % des projets aboutissent.


Scénaristes et réalisateurs travaillent en général pour rien, et parfois pour beaucoup d'argent. Chez Pixar, un projet n'est jamais abandonné. Il peut être mis en sommeil, mais ressortira un jour ou l'autre.



Pixar est historiquement le pionnier et le promoteur du dessin animé en images de synthèse. L'animation numérique, en opposition à l'animation traditionnelle conçue avec la seule main de l'homme, reste un art à inventer.


Elle a longtemps souffert des idées reçues liées à l'élaboration d'une nouvelle technologie. La créativité semblait n'y reposer que sur l'efficacité d'un logiciel. On vous présentait l'animateur qui avait passé deux ans à tenter de faire remuer un index, pour trois secondes de film à l'écran. Ou son collègue confronté au mouvement des cheveux – longtemps le graal de l'animation de synthèse – lancé dans un programme de plusieurs années pour aboutir, comme ce fut le cas pour Les Indestructibles.


Le succès de Pixar, lié à l'arrivée de ces " nouvelles images " qui remportent les faveurs du public, repose sur un malentendu. L'hégémonie des studios dans le monde de l'animation ne tient pas à un choix " hi-tech " en phase avec l'époque ou à la découverte d'un algorithme, mais à une stratégie " low-tech " assumée, où se joue et se rejoue l'une des plus vieilles activités humaines : l'art du récit.


[ Le Monde ]

 

Il y a deux points sur lesquelles j’aimerai revenir : En premier lieu, je ne pense pas que Pixar soit organisé comme Hollywood l’était dans les années 40. Au contraire, ils sont bel et bien organisés comme doit l’être toutes entreprise de production numérique des années 2010.

 

Pour eux, avoir et maintenir des ressources humaines ne répond pas à un besoin de productivité (les grands studios Hollywoodiens « pissaient » du film comme Bollywood aujourd’hui), mais à un réel souci de qualité i.e capitaliser sur l’expérience acquise et continuellement améliorer ses compétences.

 

Dans notre industrie, c’est un peu la même dynamique, même si les considérations de productivités ou d’économie d’échelle prime encore souvent sur le souci qualitatif.

 

L’autre point qui me semble évident, et ce qui est bien souligné par l'article, c’est que si Pixar est un pionnier dans son média (les films CG), ils ne doivent pas leur succès à la technique, mais bel et bien à la qualité de leur contenu. Entre d’autres terme, le scénario, puisque c’est ce que véhicule le film.

 

Evidemment, il ne faut pas se faire d’illusion, la technique sert le scénario puisqu’elle permet de raconter des histoires plus efficacement. Et de même, le scénario s’adapte aussi à ce que la technique peu faire.

 

Mais ce n’est pas ce que Pixar vend. Leurs produits sont des vrais films, et de bons films, indépendamment de leur réalisation (qui est aussi excellente).

 

Dans le jeu, c’est aussi la même chose : ce n’est pas la technique qui fait sert le jeu, elle sert le jeu en rendant possible ce qui ne l’était pas (je suis intoxiqué pas Kojima apparemment)…

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

28/07/2009

Le jeu vidéo, nouvel outil de management et de communication

Un sujet qui semble devenir de plus en populaire, à ma plus grande surprise (et pourtant c'est un sujet que j'aime beaucoup). Par contre, il y a-t-il vraiment une génération "digital native" ? C'est peut être un phénomène de distorsion, mais si être familier des technologies de l'information est une chose, les comprendre me semble en être une autre... Enfin...:

 

En France, les serious games ont émergé entre 2003 et 2005, comme outils de formation personnalisée ou instruments de communication. "Le jeu vidéo est resté pendant longtemps quelque chose de mal vu en France.

 

Trop violent et réservé aux jeunes garçons", rappelle Sébastien Beck, directeur exécutif de Dæsign. Aux yeux du monde professionnel, le jeu devient peu à peu un outil efficace au service de l'entreprise.


L'arrivée sur le marché du travail de la génération "digital native", qui a grandi en même temps que les nouvelles technologies, mais aussi le succès de la Wii et des jeux ludo-éducatif familiaux, ont contribué à modifier la manière de percevoir les jeux vidéo.

 

Doucement, ils gagnent en respectabilité. Selon une étude européenne (Apply Group, 2007), 66 % des grands donneurs d’ordre européens disent vouloir les intégrer dans leur formation dans les cinq ans à venir. P

 

rès de la moitié des entreprises du CAC 40 ont déjà franchi le pas. BNP Paribas, L'Oréal, PSA, ou Air France utilisent ainsi les serious games dans leurs plans de formation ou de communication. "Il y a encore deux ans, les entreprises ne voulaient pas en entendre parler et maintenant, elle écoutent", explique Olivier Lombart, responsable du développement des serious games au sein de l'entreprise Genious.


[ Le Monde ]

27/07/2009

Production diaries: la localisation chez Atlus

Quand on s'appelle Atlus et que l'on est spécialisé dans le RPG nippon, si il y a bien un domaine dans lequel on se doit d'exceller, c'est bien la localisation !

 

Pour rappel aux deux/trois du fond qui se sont trompé de blog, la localisation, c'est le process de traduire un jeu d'une langue à une autre. Et non, en fait, c'est plus compliqué que de réécrire tous les textes.

 

Déjà, il faut savoir que les langues ont le don d'être doté d'une foultitude de symbole tous divers et varié, comme les vulgaire accents chez nous. Ensuite, rien ne dit que le texte se trouve sous la forme de texte, ca peut parfaitement être une texture ou une asset 3D. Oh, et puis les voix aussi! Et enfin, pour couronner le tout, traduire des concepts qui n'ont de sens que du coté d'une petite ile à coté de la Corée, ç'est pas forçément façile.

 

Mais comme c'est Atlus, et que chez Atlus, on aime bien partager, ils ont fait toute une série d'article sur le sujet, et ç'est peu dire que ç'est très instructif:

 

 

atlus-logo.jpg

 

Previous Production Diaries have already given you a great insight into how we localize item and character names, but there's more to editing text than finding cool names and adding honorifics to them.

 

I'll be showing you how variables come into play in the editing process, and hopefully showing you some examples of things that we deal with here (and what happens when we fail to before debug catches it).


As an editor, an important part of writing for games is not only to make the text read well, but to make sure it all fits, too. Some games will give you a little leeway here or there, while others won't. For example: a currently unannounced game I'm working on now has a variable-width font.

 

If I made a line of all "W" (usually the widest character in the font), I could fit 38 of them in a single line before going out of the message box. If I had a line of all "I", I could cram in a whopping 112 of them.

 

When editing for that game, we make an assumption that the average line should have no more than 39 characters, because not every character is as wide as a W and some Is, ls, and spaces are going to be in there, too.


...


Of all the aspects of localization and all the choices a localizer has to make, the most controversial is almost always voice acting. Fans can be very particular and demanding when it comes to the voices in a game-some have even gone so far as to follow in the Japanese tradition of letting casting decisions influence their purchasing habits.

 

But while these voice acting devotees may have heard or read a lot about the acting process from the voice actor's point of view, there's not as much information out there from the angle of the production company. So settle back as we take you through each step of the voice acting process-Atlus style.


...


There's a famous saying: You never get a second chance to make a first impression. When it comes to announcing a game, the saying should be: Screw this up and you'll be doing damage control until the game's release.


No pressure.


Almost no one knows what a marketing department actually does. The most basic explanation is that we work to create demand for our product, and this starts by making an impactful announcement.

 

We want our fans to be excited enough to remember that game in the coming months, even while hundreds of other lesser titles compete for their attention. Case in point: in the month of June alone, there were 134 games released, and each one of those fought to be heard above the noise. How the heck to do that?


...


When our Japanese partners asked what we wanted do for the cover on this latest edition of Trauma Center, we looked back at the original Under the Knife with its dramatic gestural feel and asked them to take their lead from that image. Thus, Derek and Angie are back on it, front and center.

 

After a brief vacation from the series in New Blood, the thoracic duo have returned to take their rightful place in this, the most important of our marketing materials. We like character art and so do our fans so we made sure to use some of our most identifiable characters on the cover this time. In fact, one of the reasons that we did not use figural art on the front of the New Blood packaging was the absence of Derek and Angie from the game.

 

We felt Vaughn and Blaylock, at least in the art we had available, weren't enough to capture gamers' attention. That's no slight to the character art for that game though, and if you haven't tried it out, you are missing one of the best games available for the Wii system.


[ http://www.atlus.com/pd10.php ]

 

 

2.jpg

26/07/2009

Cable news: The shape of the industry...

 

14:19 Publié dans Business | Lien permanent | Commentaires (5)

25/07/2009

Developing DOFUS 2.0 : Overcoming challenges in Flash/AS3

Je ne sais plus quand exactement, mais il me semble bien avoir écrit sur ce blog que Flash était une plateforme à part entière, et même qu'il s'agissait probablement de la plateforme la plus répandu au monde. Et quand on parle de dévelopement web, on ne peut que penser au succès d'Ankama avec Dofus ^_^

 

6539_dofus.jpg

 

La présentation « Developing DOFUS 2.0 : Overcoming challenges in Flash/AS3 MMOG development» donnée durant la gamelab 2009 par Samuel Lorétan est disponible en ligne sur son blog:

 

Cette année, j’ai participé à la conférence Gamelab, en Espagne, en donnant une conférence sur le thème « Developing DOFUS 2.0 : Overcoming challenges in Flash/AS3 MMOG development»  (» Développer DOFUS 2.0 : Dépasser les difficultés dans le développement de MMOG en Flash/AS3″).


Cette présentation portait sur deux des nombreux challenges que nous avons rencontré durant le développement de DOFUS 2.0 : le moteur d’animation (» Tiphon» ), et les outils.

 

[ Tynambule ]

 

J'en profite aussi pour signaler mon plaisir de voir de plus en plus de blog Français de qualité en matière de dev ^_^ J'avoue avoir l'impression de faire office de vieux de la vieille maintenant, mais il y a de plus en plus de bon blogs.

 

Je ferai un tour de la blogosphère dans un prochain post ;-)

13:35 Publié dans Code | Lien permanent | Commentaires (1)