Aucune image   Guild Wars 2 Standard Edition
Téléchargement

Fiche détaillée

Conférence Online des Développeurs de Jeux 2012 : Cameron Dunn d’ArenaNet parle de la programmation des mondes virtuels de nouvelle génération

Par Karen Bryan


Vous connaissez peut-être tout de la Tyrie ou des Asuras, mais à la conférence de cette semaine, le Directeur Technique d’ArenaNet, Cameron Dunn, nous a donné un aperçu de ce qui se passait en coulisses, et nous a montré comment sont faits les rouages de Guild Wars 2 pour proposer le meilleur gameplay et les meilleures performances aux joueurs le jour du lancement et par la suite.

Il a dévoilé certaines des façons qu’a son équipe d’utiliser les métriques et outils pour rationaliser le gameplay, vérifier les bugs et mettre le doigt sur les zones à problème aussi efficacement que possible. Pour en apprendre plus sur l’envers du décor du jeu, poursuivez votre lecture !

Dunn a commencé par comparer ArenaNet à InGen, la compagnie fictive derrière la création de Jurassic Park. Dans sa comparaison, il évoquait le fait qu’InGen devait gérer les difficultés de faire tourner un grand parc à thème combiné à un immense zoo. Dunn a ajouté qu’il s’agissait d’un luxe comparé aux écueils techniques que les membres de son équipe ont dû braver pour construire Guild Wars 2. Il leur fallait un super moteur, un super gameplay, de supers éléments de jeu, et parce que basé sur un modèle sans abonnement, le tout devait se concentrer sur les meilleures performances possibles en restant très efficaces pour limiter les coûts.

Dunn a divisé la conception de Guild Wars 2 en trois parties : l’infrastructure des serveurs, les métriques client et les outils de contenu. Il a débuté en expliquant le système de mise à jour, qui permet à n’importe qui dans l’équipe de sortir un patch n’importe quand. Ceci a été particulièrement utile pendant la bêta, et même s’il y a des limites rapport à qui peut appliquer un patch alors que le jeu tourne, les mises à jour se font en douceur grâce à ce qui a été appris pendant la bêta. Il a montré un graphique en forme de vague, fait de pics et de creux, et illustrant le nombre de joueurs connectés en même temps au jeu, et nous a demandé si nous pouvions retrouver le moment où l’équipe avait lancé un nouveau patch d’après la courbe. Ce ne fut qu’à l’image suivante, qui agrandissait l’un des pics, que l’on pouvait repérer une légère baisse dans le nombre de joueurs, qui disparaissait en un rien de temps pour retrouver sa valeur originale. Il a alors expliqué que les joueurs disposent d’un sursis avant de devoir appliquer un patch, ainsi, un joueur se promenant dans le monde disposera de quelques minutes, alors qu’un autre dans un donjon aura droit à une période de grâce plus importante. En clair, des mises à jour peuvent avoir lieu plus régulièrement, et pourtant moins perturber le jeu

Une autre diapo montrait les statistiques d’utilisation de la mémoire pendant la bêta. L’équipe s’employait à rentabiliser au mieux la mémoire allouée, pour conserver des coûts raisonnables. Pendant la bêta, les développeurs ont remarqué immédiatement qu’ils utilisaient trop de mémoire par utilisateur dans le temps. Ils furent par conséquent capables de faire quelques ajustements. Dunn a ensuite montré un graphique de l’utilisation de la mémoire en situation de jeu normale, et il s’est révélé très différent et composé de jolies barres régulières par rapport aux pentes massives de la diapo de la bêta.

Il a ensuite expliqué que l’utilisation de bots de test avait aidé les développeurs à trouver des bugs et à vérifier le contenu. Ils ont utilisé Amazon EC2 (NdT : service de location de serveurs dans le « cloud ») pour créer des instances et générer des centaines de milliers de bots, et les ont mis au travail de toutes les manières possibles dans le jeu. Il a ajouté qu’Amazon n’avait pas tellement apprécié cette utilisation très rigoureuse de son service, et qu’ArenaNet avait dû être prévoyant, et passer d’un serveur à l’autre pour pouvoir continuer ses tests. Dans l’ensemble cependant, le test par les bots, couplé à des testeurs internes et les bêta testeurs, ont aidé l’équipe à découvrir des bugs et des problèmes de gameplay pour préparer le jeu au mieux pour son lancement.

Dunn a poursuivi en expliquant que concevoir Guild Wars 2 était un énorme challenge, car il y a 10 environnements différents sur lesquels travailler, allant de la création des personnages aux cinématiques en passant par les donjons instanciés, les zones sous-marines et les grandes cartes. Dans chacune, l’équipe devait s’assurer que les personnages seraient corrects, même si les environnements étaient drastiquement différents les uns des autres.

Les développeurs devaient aussi s’assurer que le gameplay était aussi homogène que possible pour les joueurs, et ils ont utilisé les métriques pour servir leur cause. Ils ont collecté de nombreuses informations sur les configurations des joueurs, et même si c’était totalement anonyme, ils ont pu se rendre compte de la façon dont le jeu tournait sur l’immense gamme de configurations différentes dont disposent les joueurs. Ces métriques leur ont également appris quels réglages étaient choisis par les joueurs, quand est-ce qu’ils activaient certaines options ou en désactivaient d’autres, ce qui a aidé ArenaNet à améliorer l’affichage et le taux de rafraîchissement de certaines zones à problème. L’équipe a même réalisé une carte des images par seconde sur une carte globale du monde du jeu. Les zones vertes étaient celles où les joueurs disposaient d’un bon taux de rafraîchissement, alors que les jaunes et rouges signalaient des baisses de performances. Sur la diapo, la majorité de la carte était en vert, mais vous pouviez voir de petites zones rouges de-ci de-là, qui représentaient probablement des villes ou le lieu d’évènements dynamiques. A partir de là, les analystes purent repérer les zones à problème et travailler à leur amélioration.

Même lorsqu’il s’agit de la conception et de la modification du jeu, ArenaNet a produit des outils qui aident les concepteurs à modifier puis appliquer leurs créations. Ils peuvent créer des évènements dynamiques et poster de nouveaux PNJs et objets interactifs, puis immédiatement les tester. Cela veut dire que les développeurs peuvent faire des ajustements durant leur travail, et garder une trace du nombre total d’objets (au sens large) utilisés dans n’importe quel évènement dynamique.

Dans l’ensemble, a soutenu Dunn, ArenaNet a travaillé dur pour construire une infrastructure qui permet de modifier rapidement, et de collaborer facilement. Une fois qu’un développeur a quelque chose dont il est satisfait, il peut le soumettre à un test de qualité, puis l’ajouter aux serveurs en direct par le système de mise à jour, qui offre aux joueurs les derniers ajouts virtuellement sans aucune coupure. Les outils que le studio a développé pour concevoir, modifier et tester le jeu a aidé non seulement l’équipe, mais aussi les utilisateurs, qui profitent du meilleur du gameplay.

Cet article a été vu 1259 fois

© 2008 ArenaNet, Inc. Tous droits réservés. NCsoft, le logo NC, ArenaNet, Guild Wars,
Guild Wars Factions, Factions et tous les logos et croquis associés à NCsoft et ArenaNet
sont des marques commerciales ou déposées de NCsoft Corporation.
Copyright © NCsoft Corporation. Toutes les autres marques commerciales ou déposées sont
la propriété de leurs détenteurs respectifs.

Design: Flymag, Template: Cypher, Code: JB
© 2007-2009 - Univers Virtuels