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.

02/04/2009

Hideo Kojima @ GDC

Hideo Kojima @ GDC: Hardware + Design (East) / Hardware + Software + Design (West)

 

A peine le temps de rentrer de San Francisco qu’il faut déjà se remettre au travail… Enfin, au moins ai je l’impression d’avoir ramené une partie du printemps Californien avec moi ^_^

 

Comme à chaque fois que je reviens d’une conférence, ma tête bourdonne d’idées et de réflexions : game design, business model, production, platforme embarqués, Larabee, XNA, qualité d’exécution, qualité, distribution, consolidation, internalisation, performance, interfaces, QA vs QC, test unitaire, milestones, vertical slices, NDS, tissu économique, marchés, social networking, agile, common sens, jeu indépendant, PSN, Xbox Live…

 

Tellement de dimension à envisager…

 

Pour commencer cette série sur la GDC, j’aimerai revenir sur la Keynote d’Hideo Kojima, l’homme à la tête de la fameuse série Metal Gear. Par bien des aspects, Hideo a peut être donné la présentation la plus professionnelle et la plus intrigante, sinon au moins l’une des plus humoristique.

 

img_5198-3262009-580px.jpg

 

Kojima est en effet revenu sur les genèses de la série à succès, et sur les principes qui ont gouverné les choix de design. Je ne vais pas refaire la conférence, d’autres l’on fait pour moi, alors plongeons au cœur des idées que Kojima a développé :

 


-    La technologie des Metal Gear est particulièrement « hardware driven », c'est-à-dire très orientée vers l’exploitation maximale des ressources machines.



-    A ce titre, pour Kojima, le design correspond donc à un outil pour contourner les limitations inhérentes à ces technologies.



-    A contrario, les jeux « occidentaux » ont eux divergé pour exploiter la couche software au lieu du design, et ce toujours pour contourner ces mêmes limitations.



A première vue, ces idées ne font pas forcement sens, alors essayons de découvrir ce que Kojima entend quand il parle de Hardware.

 

Hardware as a rendering machine

 

 

GDC_Kojima6.JPG

 

 

 

Dissocier hardware et software semble être une gageure. Le hard n’as pas de sens sans le code qui s’exécute dessus. Pourtant, dans la bouche de Kojima, cela fait sens si on considère le moteur de jeu comme étant la couche la plus fine possible permettant au designer d’exploiter les ressources machines.

 

En effet, les taches premières d’un moteur de jeu sont d’afficher des graphs, de les animer, de jouer du son et d’accepter des entrées. A ce titre, le moteur de jeu le plus efficace est celui qui permet d’exploiter au maximum les ressources machines. Au point même de se confondre avec cette même machine aux yeux du designer.

 

Quand on repense aux jeux de la série MGS, il est aisé de comprendre à quel point ils ont toujours poussé cette philosophie. Après tout, MGS 1 sur PS1 reste toujours aussi impressionnant, et tout les MGS se sont illustrés par un rendu des plus classieux.

 

Design system as a closure tool

 

Quand le soft fait tellement et si peu à la fois, toute la tache de définition de l’expérience de jeu retombe sur les épaules du designer. A sa charge de trouver quoi faire avec toute cette puissance de rendu. Mais a sa charge surtout de trouver le moyen de palier a tout ce que le soft ne fait pas !

 

 

Rc750j1f.jpg

 

 

 

L’exemple typique que Kojima a donné correspond à l’incapacité du MSX2 a afficher plus de 8 sprites à l’écran, qui a orienté le premier Metal Gear faire un jeu d’infiltration plutôt qu’un jeu de combat. C’est à ce titre que la contrainte hardware vient en fait enrichir le jeu car agissant en contrepoint du système. Mais ça va bien sur bien plus loin que ça.

 

Quand Kojima design une expérience de jeu, il va en controller le moindre aspect, d’où un jeu particulièrement linéaire et scripté, mais au design et au rendu impeccable. Hors, dans un jeu « occidentale », le designer aura plutôt tendance à réclamer un système d’IA avancé, du spawn dynamique, des comportements émergents, un système de streaming…

 

Software as a Toy: The destruction case

 

C’est cet aspect là que Kojima envie – et critique – à la fois. Là ou Kojima contourne les limites à l’aide du design, le software agit comme une couche pour essayer de résoudre le problème d’origine. En règle générale, il s’agit de trouver des solutions pour donner l’illusion d’en faire plus, ou de donner plus d’expressivité au joueur.

 

Un des cas d’école – la destruction dynamique des environnements - a été abordé a plusieurs reprise à la GDC cette année. Par exemple, le nouveau Red Faction a implémenté la feature à l’aide d’une stratégie un peu brutale mais efficace : en pré calculant toutes les pièces détruites à l’aide d’un outil automatisé.

 

Cette technique a l’avantage d’être très efficace en production, mais l’équipe a rencontré un certain nombre de problème : imaginez que vous ayez conçu un bâtiment, vous le mettez dans le jeu, et 15 minutes plus tard, il s’effondre tout seul sans aucune aide extérieur !

 

 

red_faction_guerilla.jpg

 

 

 

Je n’imagine pas la taille de leur base de bugs !

 

A contrario, la technologie à base d’éléments finis implémenté dans le dernier Star Wars permettait de simuler à la volée un certain nombre de matériaux. Par contre, les mathématiques qui dirigent le modèle ne sont pas triviales, et le modèle nécessite pas mal de tweak pour recréer des matériaux réalistes.

 

C’est probablement cette aspect là du développement à l’occidentale que Kojima à voulu illustrer : le code en tant que feature pour - au mieux permettre au designer d’aller au-delà des capacités de la machine, - au pire à la feature de se substituer au designer.

 


Engineering Design

 

Evidemment, il s’agit d’une simplification grossière de la réalité. Mais il y a du vrai dans cette dichotomie du jeu vidéo « western vs eastern ».

 

Les jeux vidéo, comme tous les autres médias, sont régies selon les mêmes règles : smoke and mirror. L’art de faire de la magie, et d’exploiter notre incroyable capacité cérébrale à combler notre vision du monde. En anglais, on parle de « closure ».

 

Quand nous sommes en train de coder un jeu, c’est ce même art que nous devons exploiter pour parvenir au résultat souhaité. Parfois, le design suffit pour y arriver, parfois, il faut y aller nous même et concevoir ces jeux de miroirs qui feront voir au joueur ce qui n’est pas vraiment là, ce qui n’existe que dans son esprit.

 

En tant que programmeur, et en particulier quand on code du gameplay, c’est cet art de la magie à laquelle on devrait aspirer. Et quand on code du système, ce ne sont en fait que des outils pour faire de la magie plus tard, car la simulation sans propos, ce n’est pas faire un jeu.

 

Les jeux de Kojima ont beau être des merveilles de design, ce ne sont pas forcément des tours de forces techniques – en dehors du rendu en tout cas-, peut être par culture, peut être aussi par manque de réel nécessité. Mais le soft peut faire plus, libérer le designer pour créer l’expérience la plus prenante et la plus unique qui soit, et c’est là que les programmeurs interviennent…

 

J’ai hâte de voir les prochains produits de Kojima production… ^_^

Les commentaires sont fermés.