Quatrième partie – Solutions de design pour répondre aux contraintes techniques et ouverture du jeu multijoueur aux joueurs occasionnels

Partie 1 : Les contraintes spécifiques du level design multijoueurs
Partie 2 : Les règles de design des maps
Partie 3 : Le défi de l’équilibrage du jeu

Solutions de design pour répondre aux contraintes techniques

Le goulet d’étrangement de la bande passante

Nous avons vu précédemment que les développeurs doivent effectuer un arbitrage entre le nombre de joueurs pouvant être supportés dans une session et la complexité des actions (animations, événements de map, effets spéciaux, etc.) pouvant s’y dérouler. Aujourd’hui, le choix effectué par l’industrie au sens large est de favoriser le nombre de joueurs plutôt que la richesse des interactions dans la map. Je suis convaincu que ce choix va évoluer car les joueurs chercheront à retrouver en mode multijoueur les expériences qu’ils apprécient actuellement en mode solo comme les animations de map, les décors destructibles, la gestion de la physique, etc. Voici donc quelques solutions pour faire face au problème posé par la bande passante.

Masquer derrière un flash ou un nuage de fumée une animation très complexe permet de ne pas la montrer, donc de surcharger la bande passante. Nous avons utilisé cette technique à un niveau extrême dans la map Factory développée pour Splinter Cell – Chaos Theory ou une salle complète peut être détruite suite à une explosion pouvant être déclenchée par un des défenseurs. La salle est remplie de bidons d’explosifs pouvant exploser si un des défenseurs les touche avec une balle ou y lance une grenade. Ce n’est évidement pas son intérêt de le faire car la topologie de la pièce est alors complètement modifiée et les déplacements des défenseurs en sont fortement pénalisés. Il aurait été impossible d’exécuter un tel événement de map sans mettre à genoux la bande passante. Le level designer responsable de la map a réussi à gérer un tel effet spécial de la manière suivante : Lorsque la salle explose, tous ses occupants sont tués. Ils ne peuvent donc pas voir l’explosion et si un petit malin a l’idée de tirer à partir de l’extérieur de la salle, la topologie l’empêche de voir le résultat de son action.

Dans cette salle de la map Factory (Splinter Cell – Chaos Theory), la circulation est facilitée pour les défenseurs : Le sol est peu encombré d’obstacles et une passerelle fait le tour complet de la salle…
...mais si un des défenseurs y déclenche la détonation des barils d’explosif, la topologie de la pièce change complètement. Les déplacements au sol sont ralentis par des pans de mur effondrés et la passerelle n’est plus qu’un amas de ferraille. La défense de la pièce devient alors beaucoup plus compliquée.

Une seconde solution consiste à disperser les événements gourmands en bande passante dans toute la map. L’idée est de s’assurer que deux événements complexes ne pourront jamais être vus en même temps. De plus il est impératif de s’assurer qu’ils ne pourront pas interagir entre eux.

On peut aussi chercher à masquer le déplacement de certains objets mobiles comme des ascenseurs dont les translations peuvent être occultées par des murs opaques. N’oubliez pas de prévoir qu’un joueur peut lancer une grenade dans une cabine d’ascenseur alors que cette dernière s’apprête à se déplacer. L’explosion ne doit pas interférer avec son déplacement.

Enfin, une dernière solution consiste à travailler sur la compression des données échangées entre les machines de jeu.

La nécessité de synchroniser les événements

Les problèmes de synchronisations représentent le premier sujet de mécontentement des gamers. Lorsqu'un bon joueur place son curseur sur une cible en mouvement et qu'il appuie sur la gâchette, il s'attend à ce que sa balle touche sa cible immédiatement et exactement là ou il a visé. Si vous travaillez sur un FPS, ce problème doit être au cœur de votre développement. Je vois deux solutions possibles pour y répondre :

Développer une architecture décentralisée. Traditionnellement, dans une session multijoueur une des machines de jeu fait office de serveur et synchronise toutes les interactions résultantes des actions sur les machines-clients. Cette architecture garantie la synchronisation entre toutes les machines mais ralenti le transfert des données puisque les informations afférentes à une interaction entre les clients A et B doivent d’abord transiter par le serveur. Avec une architecture décentralisée, toutes les machines sont à la fois serveur et client. Ainsi, si le joueur A interagi avec le joueur B et que les autres joueurs ne sont pas concernés, les données sont échangées directement entre A et B. Cette solution a probablement été utilisée dans la version Xbox de Soldier of Fortune, un jeu apprécié des « pros » du FPS multijoueur pour sa précision. L’architecture décentralisée offre également un autre avantage par rapport à une architecture classique ou la perte de connexion avec le serveur met fin à toute la session. Avec une architecture décentralisée, les joueurs peuvent entrer et sortir de la session à volonté.

Une seconde solution, moins élégante du point de vue technique, consiste à n’utiliser que des armes ayant une large zone d’effet comme un fusil à pompe, un lance-rocket, un lance-grenade, etc.

L’absence de contrôle sur les actions des joueurs

L’objectif est d’éviter que trop de joueurs se retrouvent à un endroit donnée de la map afin de limiter le nombre d’interactions entre eux. Les solutions sont une fois de plus à la fois liées au game et au level design.

Multipliez et répartissez les objectifs de missions dans toute la map. Ces deux mécanismes ont été intégrés avec succès dans Splinter Cell ou les jeux de la série Battlefield. Ainsi dans ce dernier, les joueurs ayant sélectionné un profil d’ingénieur ont accès à de nouveaux objectifs secondaires comme la destruction de stations radar.

Une autre méthode pour inciter les joueurs à s’éloigner les uns des autres est de leur donner accès à des armes qui les forceront à garder une distance entre eux. Battlefield fait aussi appel à ce mécanisme en permettant aux joueurs de piloter un avion ou de contrôler une tourelle.

Enfin, ma dernière recommandation est d’éviter les maps trop petites. L’équilibrage entre la taille de la map et le nombre de joueurs qu’elle peut abriter est cependant une décision délicate à prendre car si la map est trop grande par rapport aux nombre de joueurs, ces derniers vont vite s’ennuyer.

Ces différentes solutions sont des pis-aller et sont loin de répondre durablement aux problèmes techniques spécifiques au multijoueur. D’autres solutions existent. Mon objectif est essentiellement d’attirer votre attention sur ces problèmes qui doivent être traités très en amont dans le cycle de développement d’un jeu. J’encourage d’ailleurs mes lecteurs qui ont une solide expérience technique à ouvrir le débat et à proposer des solutions dans le forum.

Ouvrir le jeu multijoueur aux joueurs occasionnels et le sortir de son ghetto de hardcore gamers

Je termine cette chronique sur ce qui est probablement le principal défi à relever : Ouvrir le jeu multijoueur au plus grand nombre d’entre nous.

L’essence même du jeu multijoueur permet à des joueurs de tous niveaux de se retrouver et de jouer les uns contre les autres. C’est là tout l’intérêt de cette forme de jeu mais c’est aussi ce qui la rend aussi difficile pour les débutants. Jouer contre de vrais humains, même sous le couvert de l’anonymat, est intimidant. Or, c’est bien souvent ce qui se passe lorsqu’un joueur occasionnel s’aventure dans une session multijoueur. Face à des joueurs qui maîtrisent le jeu mieux que lui, il doit passer sous les fourches caudines des défaites à répétition. Il n’est alors pas surprenant que le multijoueur demeure la chasse gardée des joueurs confirmés. Personne n’aime se faire humilier en subissant défaite après défaite. Si nous voulons ouvrir le multijoueur au marché de masse, il nous faut faire face à ce problème. Les solutions se trouvent aussi bien dans le game que dans le level design et je couvrirai donc ces deux points sans distinction.

Je vois deux stratégies pour adresser ce problème :

• Rajouter des fonctionnalités destinées à aider les joueurs peux expérimentés
• Développer un jeu conçu pour ces joueurs tout en apportant assez de profondeur au jeu pour satisfaire les joueurs expérimentés

Des fonctionnalités pour les joueurs peu expérimentés

Commençons par passer en revue les fonctionnalités que nous pouvons rajouter dans un jeu multijoueur traditionnel pour le rendre plus accessibles à tous. C’est ce que nous avons essayé de faire avec le mode multijoueur de Splinter Cell – Chaos Theory.

La première solution est simple et particulièrement efficace. Elle consiste tout simplement à rajouter des modes coopératifs. Les joueurs jouent non pas contre d’autres joueurs en chair et en os mais contre des adversaires, les bots, pilotés par l’IA du jeu. Cette solution permet à des joueurs de tous niveaux de s’amuser ensemble sans courir le risque d’être humilié par les autres joueurs car les bots sont rarement aussi dangereux que leurs homologues humains. Elle permet aux joueurs expérimentés de se mettre en valeur en partageant leur expérience avec les débutants. Enfin, le jeu en coopératif peut être une extraordinaire source de plaisir car travailler ensemble à atteindre un but commun est un des moteurs de l’aventure humaine. Un mode multijoueur « coop » a été développé pour Splinter Cell – Chaos Theory par le studio Canadien d’Ubisoft. Ce mode a eu un immense succès.

La seconde solution est tout aussi classique. Elle consiste à développer un mécanisme de classement des joueurs en fonction de leurs victoires et à laisser aux joueurs le soin de choisir de ne jouer qu’avec d’autres joueurs de même niveau. Ce mécanisme se retrouve dans presque tous les jeux multijoueurs mais son efficacité laisse souvent à désirer. Il est ainsi fréquent de se retrouver face à des joueurs bien meilleurs que soi même si ces derniers ont le même classement. Il suffit en effet de jouer sur une map peu connue pour être assuré de perdre. Développer un système de classement suffisamment fin pour évaluer correctement le niveau d’un joueur est beaucoup plus difficile qu’il n’y parait. Microsoft, conscient du problème, propose cependant TrueRanking, un mécanisme innovant de classement.

La troisième solution consiste à apprendre le jeu au nouveau joueur en développant des tutoriaux. De nombreux types de tutoriaux peuvent être imaginés, hors jeu ou intégré à ce dernier. Dans le mode « versus » de Chaos Theory nous avons été très loin dans cette voie car nous savions que le jeu est hardu. Ainsi, le jeu comprend un tutoriel classique composé de mini-missions dans lesquelles le joueur apprend à manipuler son personnage. Nous avons rajouté un mode permettant de visiter les maps du jeu et d’en découvrir les principales caractéristiques, le joueur n’ayant qu’à suivre un chemin lumineux en surimpression ponctué de commentaires (voir illustration ci-dessous). Nous avons rajouté des explications sur chaque élément d’équipement mis à la disposition des joueurs. Nous avons même été jusqu’à imposer au joueur de passer une map d’examen afin de s’assurer qu’il comprenait les bases du jeu avant de lui donner accès aux sessions multijoueurs.

Le tutoriel de découverte des maps de la version multijoueur de Splinter Cell – Chaos Theory. Le chemin à suivre est indiquée par un ruban lumineux et des explications s’affichent à intervalle régulier.

Quelles ont été les résultats de cette débauche d’aide ? Elles se sont révélées adéquates pour mettre le pied à l’étrier aux nouveaux joueurs et leur éviter le sentiment d’être complètement perdu dans les maps et le jeu en général mais insuffisantes pour leur donner la moindre chance contre des joueurs expérimentés. En fait on n’apprend pas à conduire en lisant le manuel d’une voiture. Une meilleure solution a été ébauchée dans Battlefield 2 ou certaines aides de jeu sont contextuelles. Ainsi, lorsqu’on saute (tombe ?) du haut d’un bâtiment ou qu’on s’éjecte d’un avion le joueur peut éviter une chute mortelle en ouvrant son parachute. Mais si le joueur ne le fait pas et se tue, un message lui rappelle l’existence du parachute et sa commande lorsque le joueur reprend le jeu. Cette approche offre un important potentiel en matière de tutorat.

Une quatrième solution peut être d’intégrer un système de handicaps, positifs ou négatifs. Ainsi, selon le classement du joueur, ce dernier peut bénéficier de points de vie en plus ou de munitions en moins. Un tel mécanisme permettrait d’équilibrer partiellement le jeu entre des joueurs de différents niveaux. Cependant pour être accepté des joueurs expérimentés, il faudrait apporter des compensations à ces derniers comme de nouvelles animations ou de nouveaux équipements.

Enfin la dernière solution que je propose est de prévoir une interface de contrôle à géométrie variable. Certains jeux, comme ceux de la série Splinter Cell, demande au joueur de maîtriser une interface particulièrement complexe. Pour ces jeux, on peut envisager de proposer deux versions de l’interface, une version « allégée » pour les nouveaux joueurs et une version complète pour les autres. Cette idée ne peut pas être appliquée à tous les jeux mais cela peut valoir le coup de l’expérimenter.

Des jeux pensés pour être accessible au plus grand nombre

Rajouter des fonctionnalités destinés à aider un joueur peu expérimenté à faire face à des hardcore gamers peut aider jusqu’à un certain point mais je pense que si nous voulons rendre le jeu multijoueur accessible au plus grand nombre il faut développer le jeu en ce sens dès sa conception. Voici les trois problèmes auxquels fait face tout nouveau joueur :

• La maîtrise de l’interface
• La connaissance des maps
• La compréhension des tactiques gagnantes

Voyons comment nous pouvons adresser ces trois problèmes.

Commençons par l’interface. Elle doit être conçue autours de principes faciles d’accès. Nous sommes tous habitués à contrôler un personnage avec les deux sticks analogiques d’un pad mais est-ce un mécanisme facile à maîtriser pour un débutant ? Des playtests à vocation expérimentales apporteraient probablement beaucoup d’information sur la façon dont les débutants appréhendent une interface de jeu. Une solution à expérimenter consisterait à développer une interface adaptative qui permettrait aux joueurs débutant d’accomplir les actions basiques et qui s’enrichirait de nouvelles fonctions au fur et à mesure de la progression du joueur. L’utilisation de commandes vocales ou de la Wiimote vont révolutionner la façon dont nous interagissons avec nos jeux. Et si ces solutions vous paraissent trop utopiques, il est toujours possible de simplifier l’interface. L’interface de Halo 2 est intuitive car elle est n’est pas surchargée de commandes.

Passons maintenant aux maps. J’ai décris dans une précédente chronique consacrée au level design de nombreuses solutions destinées à faciliter la compréhension d’une map. En voici quelques unes : Favoriser les grands volumes plutôt que les topologies complexes, utiliser des objectifs de mission faciles à identifier, créer un lien fort entre les objectifs de mission et la topologie de façon à ce que la simple compréhension de cette dernière permette aux joueurs de comprendre ou se situent les objectifs, développer un maillage de navigation simple à identifier, permettre aux joueurs d’avoir une vision globale de la map ou d’une partie de cette dernière, favoriser les maps dissymétriques, etc. Notez que les jeux de la série Battlefield offrent de très grandes maps mais que la navigation et la compréhension des objectifs en est très simple. La taille de la map n’est pas l’ennemi !

Enfin, il y a la tactique. C’est la dimension d’un jeu qui est le plus difficile à maitriser. Dans un jeu comme Splinter Cell, c’est vraiment elle qui fait la différence entre les joueurs. Je vois deux approches possibles pour gérer ce problème.

La première est d’ordre technique. Elle repose sur le développement d’un agent intelligent qui analyserait le jeu d’un joueur et lui ferait des recommandations en conséquence. Par exemple, si un joueur dans un FPS reste statique trop longtemps, l’agent intelligent lui rappellerait qu’il est alors très vulnérable à un tir de sniper. L’agent pourrait aussi faire découvrir au joueur de nouveaux chemins s’il se rend compte que le joueur emprunte toujours les mêmes. Séduisant sur le papier, cette approche serait probablement complexe à développer. Cependant, l’idée d’amener au joueur des informations contextuelles fonctionne comme nous l’avons vu dans Battlefield 2.

La seconde approche est d’ordre conceptuel. Il existe déjà des jeux multijoueurs relativement ouvert à des joueurs occasionnels comme Counter Strike et les jeux de la série Battlefield. Cette simplicité repose sur plusieurs choix de design : Un style de jeu familier à presque tous les joueurs PC, le FPS, des objectifs de missions simples à comprendre, une topologie facilitant la navigation dans les maps (du moins pour Battlefield), de grandes maps et des sessions pouvant abriter de nombreux joueurs. Ces deux derniers facteurs me paraissent particulièrement intéressants dans l’optique de rendre un jeu multijoueur accessible à tous. La grande taille des maps donne plus d’opportunités aux joueurs d’observer et de se soustraire plus facilement aux attaques, distantes, des adversaires. On le constate dans Battlefield ou les joueurs perdent souvent progressivement leur vie en raison du manque de précision des tirs ennemis. Le second facteur, le grand nombre de joueurs dans une session, me semble aussi favorable à l’intégration des joueurs occasionnels. En effet, lorsqu’on appartient à un grand groupe, on peut avancer en équipe, voire se contenter de suivre un équipier qui connaît la map et les tactiques du jeu.

Conclusion

J’ai voulu cette série de chroniques aussi concrète que possible pour montrer que la conception d’une map multijoueur doit suivre sa propre grammaire, à l’instar, d’une map pour un jeu solo. La compréhension des facteurs de succès d’une map multijoueur est d’autant plus importante que ces maps sont jouées des milliers de fois et que leurs éventuels défauts finissent par ressortir.

 Sommaire de la rubrique Game Design de Pascal Luban

 Donnez votre avis sur le forum de l'afjv