GD, Production : Sortir de la crise par l’incrémentiel

Par le avril 13th, 2010

Ce petit texte est une théorisation de plusieurs techniques en vogue. Ne le considérez donc pas pour ce qu’il n’est pas. Il n’est pas novateur, il n’est pas brillant, il n’est pas original.

Mais mon texte a l’envie de relancer le débat et de proposer une idée : généraliser quelque chose qui existe, et le rendre plus fréquent.

Un contexte : la crise

Face à la crise, l’industrie est désarmée : les risques crèvent le plafond, les retours sur investissement de plus en plus rare. Faire un jeu coute de plus en plus cher, et est de plus en plus risqué. Bref, on va droit dans le mur. D’autant plus que les consommateurs sont frileux, il faut donc les séduire et les accrocher, alors que nos technologies mettent du temps à se développer.

Des pistes

Certains jeux fonctionnent sur le mode épisodique (c’est le cas de Sam & Max de Telltale Games, qui est loin d’être un échec) ou sur le mode « bêta ouverte » (c’est le cas des jeux Blizzard). L’idée au fond est la même : faire tester le jeu par ses joueur avant que l’on ai fini de développer tout le contenu narratif (la saison, la campagne, peu importe son nom).

En faisant de l’épisodique, on peut facilement limiter le prix de chaque épisode (le premier va coûter cher, les suivants, de moins en moins). En faisant des bêta test, on limite le risque d’échec.

Il existe d’autres formes de correction/ajout postériori : l’addon (souvent vu dans les RTS avec plus ou moins de bonheur) et le patch (qui, excepté dans les MMO et les RTS d’exception, est généralement signe que y a de bons vieux bugs à corriger).

Et un jour est né SCRUM

Comme chacun sait, SCRUM est orienté sur des scripts courts, avec un développement rapide, des tests rapides. On organise souvent le jeu en fonction d’un client : le producer.

Et si on tentait d’utiliser SCRUM différement. Après tout, le client, c’est les joueurs, non ?

SCRUMized Incremential User-oriented Developpement

Partons du principe que l’architecture de votre jeu est prévue pour être incrémentielle. Que votre plateforme finale (idéalement le PC) supporte l’incrémentiel, via par exemple un patcher. Par incrémentiel j’entend que vous pouviez y ajouter facilement des plugins conséquents et idéalement, clos. Et il faut avoir une structure permettant les retours (forums, statistiques…)

Délivrez la structure de base le plus tôt possible aux joueurs. Vous pourriez alors délivrer ces plugins supplémentaires petit à petit (disons 1 toutes les 2 à 4 semaines… Comme par hasard la durée d’un sprint) à la communauté, en faire le client de votre SCRUM. Vous délivrez un plugin, obtenez des retours, corrigez et délivrez un second plugin. Et ainsi de suite.

Selon le cas, et votre jeu, vous pourriez rendre chaque plugin payant, développer un système d’abonnement, ou déclarer le jeu en bêta, et délivrer le tout une fois que les plugins ont atteint un niveau de qualité donnée.

L’avantage c’est que si le jeu est mauvais, vous pourrez corriger rapidement le tir, et avec réactivité, tant que votre équipe est mobilisée. De plus vous gagneriez en bêta test, plutôt que de rester dans le vase clos des testeurs internes (qui ne manquent pas de compétence – et c’est bien là le problème : ce ne sont pas des joueurs lambda).

Ami développeur rassure toi : si cette technique nécessite moins de QA, il en faudra toujours, et en revanche il faudra plus de communiquants pour assimiler, trier les retours et aider l’orientation intelligente du développement.

L’avantage qui pourrait faire pencher la balance en faveur de ce système c’est le buzz actuel : en faisant parler de votre jeu à chaque plugin qui sort, en ajoutant quelques bêta testeur à chaque phase, vous gagnerez vite en popularité sur le net (Google aime les infos redondantes !). Bref vous créerez un mouvement d’intérêt beaucoup plus régulier que le rythme de parution des média classiques (j’entends : papier).

Des limites

Un tel système est limité par les structures actuelle. Rien n’est fait pour aider au développement incrémentiel, à des bêta fermées ou autres sur PS3 et XBox. Il existe bien des patchers, mais c’est lourd, peu pratique, incomplet. Et le risque de piratage n’est pas encore évacué.

Que manque-t-il? Probablement que les développeurs le demandent très fortement aux fabriquants de consoles, tout simplement. Ces derniers ne le feront pas d’eux même (des jeux sur CD ça rapporte plus à Microsoft qu’une distribution numérique via Internet), le lobby devra donc être sacrément motivé.

Question d’image

Le patch est généralement mal vécu : il s’agit de corriger des bugs. L’addon est vécu comme un moyen de rentabiliser davantage un jeu, voire de le rentabiliser à outrance. Concrètement, ces moyens ont vécu, et ont mal vécu.Une logique de développement, de production et de design incrémentiel, qui permette des plugins, va sortir de ces logiques. Les plugins sont testés tôts, moins massifs, donc sont majoritairement moins buggés, on évite donc bon nombre de patchs. Les plugins permettent des Downloadable Contents plus fréquents, mais moins cher, mieux considérés des joueurs.

Le problème est qu’actuellement, le Downloadable Content est vu comme un moyen de faire de l’argent, mais pas d’ajouter une réelle valeur au jeu, et on commence à vivre les premières vrai couillonnades (voir ici :http://www.canardpc.com/news-44786-c_est_l_histoire_d_un_dlc_deja_present_sur_le_disque___.html et http://www.canardpc.com/news-34239-Resident_Evil_5___Capcom_se_met_en_rogne_a_propos_du_DLC.html par exemple). Le journaliste est acide sur le ton, mais il n’a pas tord.

Exemple concret

Dans cette idée, Assassin’s Creed aurait été développé totalement différement. Supposons que vers le milieu de son développement, Ubisoft ai délivré la base du jeu a une poignée de joueurs. Puis chaque 2 à 4 semaines ajoute un plugin et des bêta testeurs. Tel plugin, une arme et un mouvement, tel autre, le début de l’arc narratif. Ubisoft prend les retour, corrige les défauts, et renvoie des plugins.

Certaines critiques du jeu auraient pu être adressées beaucoup plus tôt (la répétitivité notamment) avec un développement incrémentiel.

Et on aurait pu penser ainsi Assassin’s Creed 2 comme un arc narratif (plugin) supplémentaire, payant. Un Downloadable Content avec plus de valeur ajoutée (dans la mesure où AC 2 est basé sur la même techno que le 1 améliorée…)

(Je ne dit pas qu’Ubisoft ne teste pas ses jeux, au contraire, ils ont toute la batterie de testeurs, QA, playgroups et autres, et ils le font bien. Seulement ils interviennent plus tard, vers la fin, lorsque les fondement du jeu sont très solidement établis. Ca se voit notamment sur Red Steel.

Un développement incrémentiel, orienté vers les vrais joueurs,  aurai pu permettre d’ intégrer les tests plus tôt, et aurai permis des changements plus profonds). Et de plus si les développement sont mieux prévus, le DLC post-sortie sera mieux perçu.




Articles connexes

Catégorisé sous : Production.
Mots clefs associés : , , , , , .

Laisser un commentaire