Zoom sur l'interface utilisateur dans Wildstar

Notre visite des locaux du studio Carbine, à Aliso Viejo en Californie, en avril dernier, s'est avérée particulièrement riche en informations. Nous y avons notamment rencontré Jon Wiesman, ingénieur en charge du client de jeu de WildStar, qui s'est attaché à nous présenter son programme « Apollo ». Derrière ce nom énigmatique se profile la volonté d'un partage des outils de création d'interface avec les joueurs, les développeur s'appuyant sur le principe du « peer-level ». Jon Wiesman, fort de ses quatorze années d'expérience dans le développement de jeux vidéo, nous en fait la présentation.

Jon Wiesman, qui se présente comme le Lead Client Engineer du studio Carbine, a intégré les équipes de Carbine en 2007 pour travailler sur le programme d'interface utilisateur (UI) de WildStar. Il nous présente ainsi les intentions du développeur concernant l'interface de WildStar ainsi que ses projets liés aux addons, qui ont engendré le système « Apollo-Houston » du MMORPG.

La philosophie derrière la conception de l'UI

Dans l'optique de respecter la politique des studios Carbine qui souhaite entretenir une relation de proximité durable avec sa communauté, la ligne de conduite adoptée pour l'interface utilisateur dans WildStar est pensée pour favoriser l'échange participatif.
Il était donc peu surprenant que les studios aient choisi de laisser aux joueurs la possibilité d'utiliser et de créer des addons, et d'en encourager le développement communautaire. Par ailleurs ce projet avait déjà été annoncé il y a un an dans une communication officielle, projet qui avait donné lieu à une discussion à laquelle l'équipe de la section JOL-WildStar avait participé. Lors de cette annonce, Jon Wiesman nous avait fait savoir qu'il comptait fournir à la communauté une documentation riche afin de mettre à la portée du plus grand nombre la personnalisation de l'UI (interface utilisateur).

A l'époque l'annonce avait davantage l'allure d'une promesse que d'une présentation concrète de mise en application. Entre temps, le projet d'une interface programmable et personnalisable s'est précisé autour de la volonté de développer un jeu de qualité, en tenant compte des nouveaux enjeux du secteur du MMO .
Jon Wiesman nous rappelle que cette décision devait être prise rapidement dans le processus de développement de WildStar afin de concevoir une architecture cohérente du moteur d'interface, ce qui explique sans doute pourquoi il avait intégré l'équipe deux ans après l'ouverture des studios Carbine.

Par ailleurs, le projet de laisser aux utilisateurs le soin de personnaliser et même de programmer leur UI soulève d'autres questions. Il faut délimiter le champ d'action des joueurs, prendre en compte les moyens liés aux partages et bien entendu, observer en quoi cet investissement s'avère être justifié.

Il est important pour nous de laisser aux utilisateurs la possibilité de personnaliser leur interface comme ils le veulent, et à partir de cette constatation il nous a paru fondamental de pouvoir laisser à la disposition de milliers ou de millions d'utilisateurs les outils, l'API [Application Program Interface] ainsi que le système approprié. Contrairement à certains jeux, nous avons fait un choix : 100% de l'UI devait être personnalisable.

Les bases sont enfin posées, les utilisateurs disposeront de tous les moyens nécessaires pour personnaliser la totalité de leur interface grâce à des outils — ce qui est lié au système — et grâce à leur accès à des fonctionnalités qui permettent aux logiciels client d'interagir avec le programme du jeu (API).

Outre les outils, la mise à disposition de l'API n'est pas quelque chose de nouveau, c'est une condition nécessaire pour permettre à un « programme consommateur » d'interagir avec le « programme fournisseur » mais, afin d'éviter de donner un pouvoir trop grand aux utilisateurs, elle n'est généralement jamais laissée intégralement à leur disposition.
Un autre élément peut aussi attirer notre attention. S'il n'est pas exceptionnel de pouvoir entièrement personnaliser une UI, il est en revanche plus rare de pouvoir modifier des éléments d'une interface utilisateur fournie dans un jeu. Soumis à des droits d'utilisation, les éditeurs proposent de les remplacer plutôt que de laisser l'accès à certains, voire à la totalité des éléments.

Quant aux intérêts de Carbine à respecter cette ligne de conduite, qui suppose un investissement important, Jon Wiesman s'en explique : à partir du moment où des utilisateurs sont prêts à prendre du temps pour personnaliser leur interface, ou pour développer des addons, il est donc sage de croire que ceux-ci sont susceptibles de rester dans le jeu. Une façon de fidéliser les joueurs autour d'une communauté que l'on sait importante sur d'autres jeux.

Nous avons vraiment le désir de voir naître une véritable communauté autour de l'UI dans WildStar, et c'est aussi pourquoi nous avons fait un partenariat avec Curse, un des sites les plus importants en matière d'addons. Rien que pour World of Warcraft on compte deux millions de téléchargements d'addons sur ce seul site, ce qui est là pour nous conforter dans l'idée que la population concernée est représentative chez les joueurs. Or, nous partons du principe qu'avec cette communauté nous serons toujours amenés à améliorer notre jeu.

Présentation d'Apollo

Au cœur de la volonté de laisser aux joueurs la possibilité de personnaliser et programmer leur interface se trouve le système « Apollo-Houston ».

Nous avons développé un outil pour aider la communauté, c'est notre moteur d'interface utilisateur dont le nom est tiré du programme lunaire américain bien connu : « Apollo », comme pour répondre au langage que nous utilisons qui se nomme « lua », ce qui signifie « lune » en portugais. Cette association était plutôt appropriée pour WildStar et nous avons par conséquent appelé notre logiciel « Houston » puisque c'est la ville de lancement d'Apollo.

En d'autres termes, « Apollo » c'est l'API de WildStar, le moteur qui fera la transition entre le programme client et celui du jeu. Il est prévu qu'il soit placé à la disposition des utilisateurs par le biais de l'application « Houston » fournie dans le client du jeu.

Houston est un outil exclusivement dédié à la création et la modification d'addons. Conçu pour démocratiser le développement de ces scripts, il est pourvu du mode WYSIWYG (« What You See Is What You Get ») qui permettra d'éditer les fichiers xml pour paramétrer facilement l'apparence d'un objet, car ce système consiste à intervenir directement sur un support visuel. D'après Jon Wiesman, son ergonomie est conçue pour être accessible au plus grand nombre.

Nous avons remarqué que plus nous aurons réussi à élargir la communauté capable d'intervenir dans les codes, plus nous aurons des chances d’intégrer dans ce processus des personnes qui n'auraient probablement jamais osé commencer un jour alors qu'elles peuvent parfois faire preuve de beaucoup d'ingéniosité.

C'est une idée qu'on peut aisément définir comme très ambitieuse. En effet, il ne s'agit pas seulement de s'adresser aux joueurs qui expriment leur désarroi lorsqu'ils essaient simplement d'utiliser des addons « clefs en main » — il n'est pas toujours simple de les paramétrer pour des besoins personnels — mais à tous ceux qui voudraient coder eux-mêmes leurs addons sans avoir de connaissances en programmation.
Le langage lua, que d'autres MMO utilisent aussi — on pensera entre autres à World of Warcraft — est très simple d'utilisation, et surtout il est rapide à prendre en main. Mais il n'en demeure pas moins qu'il faut y être initié pour pouvoir prétendre coder des addons. C'est pourquoi Houston possède une interface simplifiée qui permet de générer des scripts en lua à partir de l'édition du fichier xml associé et grâce à son mode WYSIWYG, c'est du moins ce que l'on doit en comprendre d'après notre analyse.

Il y avait un point essentiel sur lequel nous pouvions nous interroger durant la première partie, à savoir à quel point les utilisateurs auront accès à l'API de WildStar. Jon Wiesman ne prend pas de gants, et nous l'annonce clairement :

Nous n'avons aucune API cachée ni aucune API sans documentation, et l'utilisation de nos « Addons-Carbine » ne requiert aucune permission particulière.

Il va même plus loin en nous révélant qu'il était prévu d'utiliser le « peer-level functionality » qui consiste à mettre au même niveau les addons de Carbine et ceux des utilisateurs ; avec les mêmes outils et les mêmes règles. Autrement dit, et contre toute attente, le Lead Client Engineer l'affirme, les utilisateurs pourront faire exactement la même chose que les studios du développeur, l'interface utilisateur étant composée par défaut d'Addons-Carbine que n'importe qui peut éditer, modifier, ou remplacer en disposant de l'API complète.

Le fait que l'interface par défaut de WildStar soit constituée d'addons du développeur n'est pas un détail et s'inscrit dans le principe du peer-level. En effet, il y a deux choses qui sont à prendre en considération. D'abord, les utilisateurs ne sont pas soumis à des autorisations particulières pour les utiliser. De plus, ils peuvent désactiver les éléments de l'UI par défaut fournis avec le jeu pour limiter des baisses de performances en installant de nouveaux addons.
Pour comprendre ce dernier point, habituellement lorsqu'on installe un addon, celui-ci s'ajoute aux éléments de l'UI qui donne un ordre de priorité aux éléments actifs. Par exemple, en adoptant un script qui modifie les barres d'action, celui-ci fonctionne correctement parce qu'il est traité en priorité par le programme du jeu. Mais l'élément de base reste actif, au moins partiellement et entraîne une utilisation de la mémoire inutile. Bien que très relative cette sollicitation inutile de la mémoire peut provoquer des ralentissements du programme et explique le choix des utilisateurs d'addons à contrôler généralement les performances liées à leurs interfaces utilisateur. Une précaution qui ne sera plus nécessaire en désactivant les éléments par défaut de l'UI lors de leur remplacement.

Apollo, ou plutôt le système « Apollo-Houston » offre aux utilisateurs un outil puissant qui pourrait bien attirer les amateurs de développement d'addons, mais aussi de nouveaux talents, grâce à la simplification qu'il propose. De ce point de vue, on peut d'ores et déjà imaginer que l'objectif de Carbine est sur le point de se concrétiser. L'accès à la totalité de l'API et à une documentation complète, associées à la mise en « open-source » de l'intégralité de l'interface utilisateur sont autant de facteurs qui vont en ce sens, mais qui peuvent également nous interpeller sur les risques auxquels les développeurs seront probablement confrontés.

Les difficultés liées à ce choix

Pour Carbine Studios

Même si WildStar est loin d'être le seul MMO à faire le choix de laisser aux joueurs la possibilité d'utiliser des addons, cette initiative est rare. Pour se faire une idée on compte moins de dix MMO sur l'un des sites spécialisés les plus populaires — et partenaires de Carbine studios — Curse, fort de vingt-deux millions de visiteurs uniques par mois sur les derniers résultats de mai 2013(?). Nous avons déjà cité le plus célèbre, WoW, mais on peut aussi mentionner des jeux récents tel que Minecraft.

Jon Wiesman nous fait part des difficultés liées à ce choix pour les entreprises de développement   :

• L'une des plus grandes raisons [pour lesquelles les développeurs ne tiennent généralement pas à suivre cette direction] s'explique par le fait que c'est une réelle contrainte dans le développement, car il faut que les codes soient accessibles et surtout, qu'ils répondent à une logique stricte. Or, ce n'est pas simplement une question d'absence de volonté, mais aussi de moyens techniques. Je pense entre autres aux développeurs qui travaillent sur des langages du type C++, ils auront forcément recours à des optimisations pour travailler le plus rapidement et le plus efficacement possible, et c'est quelque chose qui complique considérablement cette démarche. Il faut donc prendre en considération que c'est un vrai investissement de départ, et que ça ne peut pas s'improviser en cours de développement.

• Parmi les autres raisons qui peuvent compromettre ce type d'initiative, et nous en sommes parfaitement conscients, c'est la mauvaise image que ça peut potentiellement faire naître. Prenons un des exemples les plus courants, un joueur est très fier de la victoire de son groupe contre un boss de raid. Et il va vouloir la partager à la communauté en hébergeant sa capture d'écran sur internet. Il se peut, c'est fréquent, que son interface soit terriblement laide, même en étant optimisée. Les gens qui vont tomber sur cette image et qui ne connaîtront pas le jeu trouveront que l'UI que propose WildStar est absolument affreuse et passeront peut-être leur chemin.
En ce qui nous concerne, nous avons confiance en nos utilisateurs ce qui ne veut pas dire que ça ne nous préoccupe pas. C'est aussi une façon, et même une motivation supplémentaire pour nous rapprocher de la communauté autant que des utilisateurs eux-mêmes pour constituer le plus possible des bases de données fournies, ou encore, de travailler sur l'esthétique de certains addons. Il faut donc bien considérer les relations importantes des individus entre eux, mais aussi avec nous.

Ce manque de confiance en la communauté justement est quelque chose qu'on retrouve fréquemment et que j'ai moi aussi bien connu dans mon expérience professionnelle au sein de l'industrie du jeu vidéo. Elle est tout à fait compréhensible car ça évite de prendre certains risques, et c'est pourquoi la politique de Carbine vis-à-vis de son UI devait être précisée. Pour les individus qui font preuve de bon sens, et qui tiennent à s'investir dans le processus, nous nous devons de croire en notre communauté.

Mais ne croyez pas que nous ne sommes pas nous-mêmes intéressés, car nous tirons un bénéfice certain à voir progresser les UI. Dans une certaine mesure ça peut même nous ouvrir les yeux sur certains aspects auxquels nous n'aurions peut-être pas songé. Nous croyons donc aussi en cette relation dans le cadre d'une amélioration de l'expérience de jeu.
Mais là, j'ai envie de revenir sur quelque chose que Troy Hewitt avait évoqué il y a quelques mois. Imaginons un utilisateur qui met au point un superbe addon, et que celui-ci est très populaire. Pourquoi ne l’encouragerions-nous pas par une récompense ? Nous pourrions par exemple envisager d’intégrer cet addon à WildStar, contribuant à la reconnaissance de son auteur, et pourquoi pas même aller plus loin ?
C'est un programme complexe qui prendra du temps mais on continue à réfléchir à comment nous allons pouvoir le mettre en place.

Pour résumer, nous comptons motiver les utilisateurs à s'investir dans notre système et comptons bien faire fructifier cette relation avec la communauté.

Pour les utilisateurs

Durant ces deux dernières années, les studios Carbine ont souvent interrogé la communauté via les réseaux sociaux sur plusieurs aspects généraux dans les MMO. Jon Wiesman a sélectionné des questions fréquemment posées à propos des addons, et même si certaines restent encore en suspens pour le moment, il est vrai qu'elles avaient été abordées lors de notre discussion sur WSC, ainsi que sur notre propre forum.

Voici les questions que Jon Wiesman a sélectionnées pour y répondre :

• Est-ce que ça va vraiment motiver Carbine à faire la meilleure UI que possible ?
Comme je représente moi-même les studios, ma réponse ne vous surprendra pas. Oui nous le sommes, et à titre personnel, j'aime vraiment beaucoup l'UI actuelle qui plaira sans doute à un certain nombre de joueurs. Elle est propre, travaillée et surtout, elle est déjà modulable ce qui n'est pas non plus quelque chose de fréquent dans les autres MMO. Je suis tout à fait confiant dans cette architecture de l'interface utilisateur que nous proposons par défaut.

• Est-ce que certaines guildes, ou certains groupes ne risquent pas de rendre des addons obligatoires comme par exemple un DPS-meter ?
Ma réponse est si, car c'est inévitable. Ce problème a soulevé de nombreuses réflexions, mais nous en sommes arrivés à la conclusion que au fond, si vous vous retrouvez confronté à ce problème, et que vous refusez d'utiliser un tel addon, c'est probablement parce que vous n'êtes pas à votre place dans cette guilde, ou dans ce groupe. C'est une question communautaire, or nous n'allons pas changer la nature humaine, ni même essayer.
En revanche on peut rendre les choses plus faciles d'accès pour les joueurs. Certains se passionnent pour l'optimisation et rechercheront toujours à optimiser leurs dégâts dans des donjons. On soutient ce type de joueurs et on considère qu'on doit leur donner les moyens de faire ça.
Certains au contraire préfèreront plutôt s'amuser et prendre du plaisir. Il y a beaucoup de joueurs qui sont ainsi et qui ne sont pas forcément intéressés par l'utilisation d'un DPS-meter, nous les soutenons tout autant.

• Est-ce que les addons ne risquent pas de limiter la difficulté des donjons ou des raids ?
Non définitivement nous refusons de tomber dans ce travers. Les addons n'ont pas vocation à faciliter le contenu du jeu, même si vous pouvez en faire de superbes, que ceux-ci améliorent votre confort et dans une certaine mesure qu'ils améliorent votre expérience de jeu grâce à leur fonctions. Nous avons chez Carbine des équipes qui travaillent sur les combats et sur les donjons, ceux-là ajustent les niveaux de difficulté en se basant sur des critères particuliers. Ils n'est donc pas question que les addons portent atteinte à leur travail et puissent en plus de ça provoquer un écart injustifié entre les joueurs.

• Est-ce que ceux qui refusent d'installer des addons ne risquent pas de se retrouver en marge de la communauté ?
Non évidement, même sans jamais avoir téléchargé le moindre addon les joueur ont la garantie qu'ils peuvent profiter pleinement du contenu de WildStar. C'est même une chose que nous pouvons observer, les joueurs qui n'ont jamais utilisé d'addon profitent parfois mieux du contenu d'un jeu.

Conclusion

La philosophie derrière la conception de l'UI dans WildStar telle qu'elle nous est présentée dispose en effet des moyens de se matérialiser grâce au système « Apollo-Houston ». L'architecture du moteur d'interface est entièrement conçue pour favoriser la participation communautaire au développement d'addons, donnant ainsi la possibilité de contribuer à l'amélioration durable de l'UI du jeu. Présenté comme très permissif, ce dispositif qui s'appuie sur le « peer-level functionality » dispose malgré tout d'un certain encadrement. Alors que les studios Carbine nous annonçaient qu'ils considéraient comme essentiel de laisser cet aspect entre les mains expertes de Curse, nous comprenions que les développeurs ne tenaient pas à prendre de risques avec les problèmes qu'on est en droit d'imaginer à propos de la sécurité dans l'échange des fichiers entre les utilisateurs.

Nous attendons encore de connaître les procédés prévus pour prémunir les joueurs contre des applications malveillantes que certains pourraient inclure dans leurs fichiers. Il est probable, à l'instar d'autres MMO, qu'il ne soit pas possible de partager de dossiers contenant un exécutable par le biais de Curse, et que la communication soit renforcée pour permettre aux joueurs de prendre leurs responsabilités quand ils téléchargent des addons. Si c'est confirmé, il sera alors important d'observer malgré tout une certaine prudence puisque le site de partage des addons ne sera pas la seule plateforme concernée.
D'autre part, on peut encore soulever des questions à propos par exemple des risques d'abus, tel que le « botting » (par le biais de logiciels tiers il est généralement possible d'automatiser des actions qui peuvent déséquilibrer le jeu et son économie). Ce n'est pas un problème lié directement à la personnalisation de l'interface utilisateur puisque ce problème est généralisé, cependant, WildStar y sera fortement exposé. Outre les précautions que les studios Carbine prévoient tout en indiquant qu'ils ne feront pas exception dans la lutte contre les « bots », Jon Wiesman nous explique que l'API, par définition, ne permet d'appeler des fonctions que si celle-ci sont prévues. Par exemple, il ne serait pas possible de contourner la restriction sur les compétences actives du système « LAS » (pour « Limited Action Set ») car aucune fonction ne pourra faire appel à des compétences en dehors de la barre d'action active des sorts. Il ajoute que les addons ne peuvent interagir qu'avec les éléments de l'interface.

C'est en ces mots que cette présentation s'est conclue :

Voici notre ligne de conduite ainsi que les moyens que nous mettons en œuvre afin de pouvoir adopter de nouveaux standards pour l'interface utilisateur telle que nous la prévoyons pour WildStar. Nous avons une philosophie qui n'est pas meilleure qu'ailleurs, mais à laquelle nous croyons fermement pour faire naître une communauté autour des addons et de l'UI pour construire ce qu'il y a de mieux dans ce domaine.
C'est une relation que nous cherchons à construire avec les utilisateurs et qui doit être bénéfique autant pour eux que pour nous. Et pour que nos projets se réalisent nous avons placé la confiance au centre de cet échange par le biais des outils, mais aussi par la liberté qu'offre l' « open-source » et la fonctionnalité du « peer-level ». C'est notre programme Apollo-Houston et nous comptons bien faire de ce symbole une caractéristique importante de WildStar.