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.

23/05/2007

Onl'on reparle du jeu épisodique...

Le jeu épisodique, c'est comme le Graal, tout le monde en parle, mais personne ne l'a vu pour de vrai. Pourtant, c'est une idée qui semble porteuse...

 

Halper’s company has produced 120 episodes of games over the past five years including a series of shooters tied to the History Channel and fast-turnaround levels based on news events, almost always violent.



He said that episodic gaming is “incredibly immature” but emerging as a valid alternative to full-priced retail games. “It has many promises but also it has problems,” he conceded. “Episodic games are relatively inexpensive.

 

You can spend $500,000 on four episodes and you know very quickly if you want to proceed, or make changes or pull back. The games can be turned around quickly, in just three weeks, so we can react to events elsewhere.

 

They engender loyalty and appointment-to-play. Our players know when a new episode is coming up. And the games are not subject to the same [critical] dissection as boxed games, as players have a different set of expectations.”



But he said there are drawbacks. Right now the market is in flux as companies seek to find the right model. Episodic games might include very large titles like Sin or Half Life 2: Episode 1, with long lead times, or they might be paid-for content like Sam & Max. But he believes in the ad-supported model.

 

 

[ Next Gen

Commentaires

Bon j'ai pas fait une analyse poussée du jeu épisodique, genre c'est pas le truc qui me branche actuellement le plus *mais* mon opinion est que la notion d'épisode colle assez mal avec la façon actuelle de coder un jeu.

Genre tu as la création de toute la techno qui consomme énormément de ressources et celle là que tu fasses un épisode ou cinq c'est un cout fixe. Ok tu peux rajouter des fonctionnalités de gameplay par la suite, améliorer le moteur etc... mais au départ tu as quand même un gros coup fixe ce qui avec un système d'épisode s'avère très risqué.

Alors toujours à mon avis c'est jouable si tu utilises des techniques de guerilla man c'est à dire du jeu à l'introversion, du BFI des trucs dans le genre où tu utilises la faiblesse de tes ressources comme une force créative. (ca fait très judo tout ça).

Écrit par : Whirly | 24/05/2007

Lol, j'aime l'analogie avec le sport de combat ^_^

Je suis en tout point d'accord avec toi, pour que ce modèle fonctionne, il faudrait changer de structure de production.

J'avais fut un temps emis l'idée de "production avec 0% code". sur le papier, l'idée est simple. Tu choisi ou crée une plateforme technologique complète, outils, pipeline et moteur, et tu la figes.

Puis, en s'appuyant sur cette plateforme, tu déclines ton jeu en produisant uniquement des données, données que tu peux dès lors délivrer de façon épisodique.

En somme, il y a 3 étapes:

1 - La création et la mise en place de la plateforme.
2 - Le pilote: la production du premier "épisode" mettant en place TOUTES les mécaniques présentes et à venir du jeu.
3 - La déclinaison du pilote dans la production d'une saison du jeu.

C'est évidemment très utopique. Déjà, l'investissement upfront est absolument collosale, puisqu'à priori, il n'y a pas de revenu avant la sortie du pilote.

Par contre, les possibilités d'amortissement de la chaine sont considérable. Par exemple, le cout de production des épisodes suivant le pilote devrait aller naturellement à la baisse (réutilisation des assets oblige). Le QA devraient également bien s'amortir (pas de code, donc moins de possibilité de bug d'un épisode à l'autres).

De plus, une même plateforme technique pourrait etre utilisé pour produire diférent titres similaires et ainsi limité le risque par la diversification.

Enfin, la plateforme technique peut évoluer de façon parralèle d'un pilote à un autre, puisque la production ne dépend pas des codeurs pour la production des séries en cours.

Bref, c'est peut être utopique, au sens que jamais une telle organisation ne pourrait concurrencer le niveau de qualité d'un Halo ou d'un MGS. Par contre, elle pourrait s'avérer diablement efficace sur certain segment.

En tout cas, la clef du succès d'une série - et cela que ce soit à la télé, au cinéma, en roman ou en bédé - c'est la régularité. Un à deux épisodes par semaine à la télé, un tome tout les mois en libraire, un film tout les deux ans au cinéma...

Trouver la bonne granularité, et surtout savoir tenir les délais, voici deux autres challenges à la distribution épisodique...

Autant dire que l'on est pas sorti de l'auberge ^_^

Écrit par : Daz | 24/05/2007

Ce que tu dis correspond a acheter 1 license d'un moteur et de l'utiliser sans coder de nvelles features dessus non?
Ca ressemble aux FIFA/splintercell/prince of persia.
Avec une granularité d'un an.
Personnellement, je ne crois pas au contenu episodique. Par contre, dans le JV, il y a des communautés qui font les MOD (personne ne modifie/cree/rajoute des elements dans 1 serie TV) . Ca me semble etre plus la source de revenus reguliers (abonnement, petit contenu, goodies payantes, artbook,...) comme le fait valve.

Écrit par : skaven | 24/05/2007

Acheter un moteur n'est souvent pas suffisant, mais l'exemple des FIFA est intéressant.

sur ce type de jeu, la base technologique évolue peu d'une version à un autre. Par contre, chaque édition contient un set complet de contenu ( 32 équipes, 20 stades... ).

Une approche épisodique du problème serait un peu différente. Le "pilote" du jeu serait mis à disposition du public avec 4 équipes et 2 stade (une poule de coupe du monde par exemple).

Tous les mois, 4 nouvelles équipes seraient modélisés avec 2 stades de plus.

Au bout du 4ième mois, de nouveaux stades seraient proposés avec une notion de compétition de coupe du monde (1/8, quart puis demi final).

Le dernier épisode offre le stade de la finale, plus toutes les animations de victoire, etc etc...

Au final, en un an, tu as réalisé le même contenu qu'un FIFA, mais tu n'as fait que distribuer de le data, puisque le code ne change pas depuis le pilote.

Ca n'est pas non plus juste des add-ons. Les add-ons viennent juste compléter une offre ludique déjà réalisé. Dans notre cadre, chaque "épisode" est nécessaire puisqu'il permet d'avancer dans le jeu.

Dans l'exemple que j'ai pris, si tu es malin, tu peux même prévoir de mettre le dernier épisode en même temps que la vraie finale de coupe du monde.

Bref, ca serait vraiment un business model différent...

Écrit par : Daz | 24/05/2007

"Dans notre cadre, chaque "épisode" est nécessaire puisqu'il permet d'avancer dans le jeu."
c'est super dangeureux. si tu as loupé 1 ou 2 episodes et que tu as envi de jouer au jeu, tu peux perdre le fil et ne pas etre motivé a acheter et jouer ces episodes. c'est pour ca que dans les series (et meme spiderman 3) ta 1 resumé des precedents episodes. en outre, ca oblige a avoir 1 jeu a scénario linéaire ce qui n'est pas le cas de tous. et si tu fais des episodes qui peuvent etre joués indifferement, ca ressemble a des addons.
Sinon, pour du contenu a découpage, je m'orienterais vers du virtools.
Ca peut etre un bon exercise d'ailleurs. je ne fais que de la techno (moteur ps3/360) et quand je pense a la production, je pense seulement a la techno derriere et pas au gameplay. Je trouve que c'est une tres mauvaise habitude. j'aimerais reflechir sur le gameplay et porté ca artistiquement grace a la techno....je pense que dans les autres studios c'est comme ca non?
c'est une sale habitude de codeur Amiga ca xD

Écrit par : skaven | 24/05/2007

La fidélisation du public est en effet un problème clef ^_^

C'est tout un art d'ailleurs, qui impact la nature même du produit que tu crée, que ce dernier soit un jeu, une voiture ou des brosses à dent. Le jeu par épisode dépend de sa capacité à fideliser, mais comme tout les autres jeux d'ailleurs. Le nième Lara Croft a le même problème, juste à une autre échelle.

Le jeu "épisodique" n'impose pas non plus une linéarité scénaristique, ca n'est qu'un modèle parmis d'autre. Par contre, cette linéarité est un atout majeur en terme de fidélisation du public.

Par exemple, essayer de comprendre ce qui ce passe en plein millieu de saison dans Heroes ou Lost par exemple relève de la migraine garantie (ou de la torture, selon les gouts...)...

Est ce que ça nuit a leurs succès ? Au contraire...

Ceci dit, tu as parfaitement raison, à l'heure actuelle, aucun studio ne crée de séparation aussi clair entre le code (la techno) et le gameplay. C'est bien pour ça que le modèle du jeu par épisode me semble intenable dans le cadre actuelle sans un changement radical de philosophie.

Mais il ne faut pas perdre de vue que la création du pilote est une oeuvre commune allant de pair avec l'écriture du code. Le pilote définit le gameplay, ET la techno permettant de décliner celui ci au cour d'une saison.

Il ne s'agit donc pas d'exclure le programmeur du game design ^_^ Mieux, je ne crois pas à la techno "universelle". Un bon moteur de FPS permet de faire des FPS sans trop de prise de tête, point.

Chaque plateforme technologique fourni donc un cadre très restrictif.

Ceci étant dit, les programmeurs font de mauvais game designer en général, et d'encore plus mauvais scénariste de toute façon.

Etablir une isolation propre entre ce qui relève de la technologie et ce qui relève du gameplay ne me semble par conséquent pas être une si mauvaise chose ^_^

Écrit par : Daz | 24/05/2007

"Ceci étant dit, les programmeurs font de mauvais game designer en général, et d'encore plus mauvais scénariste de toute façon. "
j'ai pas d'exemple autour de moi. on ne demande pas de feedback aux techniciens chez nous. Ce qui fait qu'on est tres loin du jeu en fait (/me frustré).
"Chaque plateforme technologique fourni donc un cadre très restrictif."
c'est vrai mais je pense qu'on peut faire 1 fps avec n'importe quel moteur...du moment qu'il fournis 1 minimum de methodes/outils de base.
Dela les performances par rapport a un vrai moteur FPS seront médiocres( et encore, pas toujours).
Tim sweeney prefere avoir 10% de performances en - que 10% de productivité en - (tu m'etonnes).
Ankama a fait le choix d'une techno flash. Il y a 2 ans, si j'avais du faire 1 mmorpg 3D iso, j'aurais commencé par ecrire des classes de gestion de sprites en DX9. Et je n'aurais surement pas eu leur succes.
Tout ca pour dir que le contenu episodique peut marcher mais seulement si les studios font clairement le choix de ne pas re-creer de pipes graphique, d'essayer 1 nouvelle techno prometteuse, etc...
Dans un sens, Nintendo a fait ce choix aussi. et le fait que les technos soient si simples a fait baisser les couts de prods et augmente l'accessibilité. Idem pour Dofus, il est super simple d'acces.
On dirais que pour les responsables de studio, utiliser 1 techno simple, c'est faire du super budget, du simpliste.
Quand une serie TV est tournée, leur methode de production ne change pas chaque année...ni meme d'une serie a une autre. nous, ca change a chaque jeu (voir pendant une production).

Écrit par : skaven | 24/05/2007

Encore une chose (je suis tres bavar aujourdhui). Les stats de Valve sur l'episode 1 disaient qu'une grosse partie des joueurs ne terminaient pas le jeu. Le joueur se lasse vite a priori. Et ca va en faveur du contenu episodique. 60/70€ pour 12h de jeu alors que dans la majorité des cas, seulement 50% du jeu sera "utilisé", c'est dommage.

Écrit par : sk | 24/05/2007

Désolé de constater que ton studio a si peu de considération pour votre travail :-)

Les exemples que tu donnes sont pourtant les bons. Tim a raison, et Dofus a aussi fait le bon choix technologique.

C'est aussi pourquoi je suis un grand fan de XNA et de C# en général (même si j'en fait pas tout les jours).

Sur le fond, on est parfaitement d'accord.

L'avenir du jeu épisodique ne se trouve de toute façon pas dans la techno pur et dur, mais bel et bien dans le contenu. C'est le contenu qui crée l'attrait du jeu, pas le nombre de polygones affichés à la frame (sauf pour le public de Crysis, mais c'est une niche à part).

L'avenir est donc a des plateformes complètes, pas forcement simpliste (Flash, c'est pas simple), mais efficace en terme de productivité.

Et fait est que coder est un acte hautement improductif (et c'est un programmeur qui le dis). En moyenne, en C/C++, 80% du code écrit n'a pas d'impact productif immédiat. Ce code est indispensable, mais ne sert pas la valeur ajouté du produit (les gens n'achetent pas les jeux pour leurs gestionnaires mémoires).

Il semble donc logique de streamliner la production en éliminant le programmeur de l'équation. En production, les programmeurs coutent chers, et il est bien plus rentable de les exploter en amont (préprod principalement). ^_^

Écrit par : Daz | 24/05/2007

Non, on ne manque pas de considérations. Je suis en train de faire 1 burnout en ce moment...si ca continue, je vais exploser en vol.

Bref.

Dans, ce cas, serais-tu a même de dir que ton travail de ne "sert a rien"?
Ou plutot, si dans heavy rain, votre boss choisissais des technos deja existantes (3rd party) a la place des technos que toi et tes collegues developpez, est-ce que le jeu serais moins bon/beau/interressant/vendeur/vendu ?

Écrit par : skaven | 24/05/2007

A l'époque on avait proposé un jeu d'enquête policière où l'objectif était de réaliser une plateforme pour faire ce genre de jeu facilement en faisant des updates réguliers mais léger sur le code. On collait pas le nom épisode dessus mais l'objectif était de pouvoir produire du jeu pour moins cher et qui soit bien. Ca recoupe ce qui était dit auparavant.

Chez nous tous le monde a voix au chapitre concernant les jeux, même s'il y a un gus pour trancher et pas des programmeurs qui bricolent ce qu'ils veulent dans le coin.

Maintennant sur PC on essaye d'évoluer au niveau techno histoire de pas toujours faire du C++ monolithique et d'arriver vers des technos plus souples, genre je testerais bien du jeu de gestion en C# + WPF pour voir si c'est possible.

Écrit par : Whirly | 24/05/2007

Je compatie Skaven, c'est le coté obscure de l'industrie... :-(

Pour revenir au sujet, participer à la réduction des couts fait partie de mon rôle premier...

Les exemples qui suivent sont hypotétiques, mais représentatif de ce que j'ai déjà vécu.

Si on me demande de définir les besoins en détection de collision et en physique, a moi de faire en sorte de bien expliquer la différence entre le faire en interne et/ou acheter une licence Havok/Novodex.

Si le ratio valeur ajouté par rapport à l'investissement pour le produit en question n'est pas favorable, je me fais une joie de proposer l'achat et l'intégration d'un middleware. Et je l'ai fait à mainte reprise.

Plus concrêtement, et sans me faire le porte parole de Quantic Dream ou faire du "corporate", il me semble que QD a pour politique d'investir là ou elle aura le plus fort retour sur investissement.

En d'autres termes, certaines technos sont développées en interne parce que cruciales pour la qualité du jeu, d'autres sont achetées. Et il en va de même pour les ressources graphiques. ^_^

Plus clairement, mon travail ne sert à Quantic que dans la mesure que QD ne peut pas acheter moins cher et d'aussi bonne qualité ailleurs (ce qui peut toujours s'argumenter, évidemment).

Pour autant, est ce que HR sera mieux avec mon code ou sans, j'ai l'audace de penser que ça aura finalement peu de poid sur l'acte d'achat du joueur :-)

A ce titre, le travail des game designers, scénaristes et artistes est autrement plus crucial pour les ventes du jeu!

Par contre, mon travail est primordial pour permettre à Quantic (la société) de maintenir son indépendance technologique et son avance dans les domaines qu'elles à jugé capitals dans le secteur très concurrentiel des jeux sur consoles de prochaines générations.

Ce sont ces choix stratégiques qui dictent les ressources humaines. Si QD faisait des casual games avec des productions de 6 mois, il en iraient surement autrement :-)

Et puis, nul n'est indispensable, au fond... ^_^

Bon courage pour ta prod en tout cas :-)

Écrit par : Daz | 24/05/2007

" Maintennant sur PC on essaye d'évoluer au niveau techno histoire de pas toujours faire du C++ monolithique et d'arriver vers des technos plus souples, genre je testerais bien du jeu de gestion en C# + WPF pour voir si c'est possible. "

Ca semble être un bon pari ^_^

Finalement, tu ne veux pas targeter les consoles de salon aussi ?

Écrit par : Daz | 24/05/2007

Si j'avais de l'argent et 1 cercle de relation qui va bien, je crois que je prendrais que des technos open source complétée par 1 ensemble de 3rd party. Le but de la chose etant de ne pas faire de techno, seulement du gamecontent. De le faire en script et en C/C++. et de faire que de l'outsourcing pour les graph/sons.

Le tout, pour faire 1 jeu dans 1 style qui est devenu desuet/ marché sans concurrence.

Tiens, ca me fait penser a Deck13 ....

2/3 gestionnaires de projets et je pourrais passer mon apres midi a faire ce que je veux.....sans doute coder.

Écrit par : skaven | 24/05/2007

Whirly est un expert dans ce domaine. Son expérience avec Ogre est des plus intéressante ^_^

Moi, je reste méfiant de l'Open Source. La prise de tête juridique doit pas être piqué des vers ;-)

Écrit par : Daz | 24/05/2007

Si j'avais de l'argent je monterais une boite pour faire un middleware qui permettrait l'utilisation du XAML directement dans les moteurs 3D communs. Voir une chaine de production complète basée sur différents techno qui vont bien et qui permettent à la fois de controller les coûts de production et surtout de garder le controlle sur le bordel histoire de pas se trimballer une boite noire qui peut ressembler à un bloc de béton genre "oh tient toute ma techno repose sur renderware".

Pour la prise de tête juridique il suffit de savoir où on met les pieds et de bien brieffer les gens pour pas avoir un plan genre à quelques jours du gold master on se rend compte qu'il y a un bout de code en GPL qui traine dans le corps du jeu (mouahahah c'était pas chez nous hein).

Écrit par : Whirly | 24/05/2007

Ah, le coup du GPL, lol ^_^

Bon allez, c'est bien bon de rêver, mais on a pas encore gagner au loto, hein ;-)

Écrit par : Daz | 24/05/2007

moi je suis pas entièrepment pour le contenu episodique mais j'en proposerai une alternative que j'appelle le jeu LEGO. On acaheterai la bse du jeu et apres on pourrai se payer des briques qui ne serai que du contenu en plus. les briques seraient peu cheres mais pourraient raporter gros, en gros ce serai une alternative aux extensions, tu acheterai des pack mission via des cartes prépayés.

Écrit par : Pedro Guanaes | 24/05/2007

Je suppose qu'il y a autant de formules que de business model possible ^_^

Écrit par : Daz | 25/05/2007

Les commentaires sont fermés.