informatiques pour jouer à un million de joueurs
Stéphane Natkin
e jeu vidéo a trente ans. Les jeux d’aujourd’hui n’ont plus rien à voir avec ceux des premières générations de consoles et de jeux d’arcade.
De jeux purement textuels (par exemple, le premier jeu en réseau sur internet dans les années 80), nous sommes passés à la manipulation des séquences vidéo, l’animation 3D et le son spatialisé en temps réel. Au-delà des améliorations de l’interface, l’évolution des capacités des ordinateurs et des consoles, des techniques de programmation, de domaines comme l’intelligence artificielle, la simulation en temps réel de phénomènes physiques... ont permis une évolution des jeux vidéo vers une complexification de l’univers et du scénario. Autrefois exploit technique, un jeu vidéo est aujourd’hui une œuvre audiovisuelle interactive. Le développement des jeux en réseau massivement multijoueurs (Massively Multiplayers On line Games MMOG), est une étape de plus dans ce domaine qui le distingue de plus en plus des autres formes de création et de communication.
La conception et la réalisation de jeux en réseau pose des défis scientifiques et technologiques à la fois passionnants et importants pour ce domaine de la création mais également essentiels dans de nombreux autres domaines des sciences et technologies de l’information et de la communication. En effet, les jeux en réseau sont un paradigme pour de nombreuses activités sociales réalisées via un réseau informatique, du travail coopératif à l’enseignement à distance. Celui qui développera une plate-
L
forme pour jouer à un million de joueurs disposera des éléments technologiques pour faire une université virtuelle à un million d’élèves…
Dans la première partie de cet article de synthèse nous décrivons rapidement les grandes classes de problèmes scientifiques et techniques que pose la conception de très grands jeux en réseau. Nous nous concentrons plus particulièrement sur les aspects architecturaux. Dans le dernier chapitre nous présentons quelques grand thèmes de recherche : le filtrage sémantique, la prédiction d’état (Dead Reckogning), les mécanismes de contrôle réparti et les architectures envisagées.
Les défis des jeux en réseau massivement multijoueurs
Les jeux de demain
Un jeu massivement multijoueur est un univers interactif partagé. Pour pouvoir déterminer les plates-formes à même de supporter cet univers il est nécessaire de se poser deux questions fondamentales : combien de personnes au maximum peuvent se partager, à un instant donné, cet univers et quelle est la nature des interactions entre les participants. Il faut donc faire des hypothèses sur la nature des jeux qui seront développés dans les dix prochaines années. Pour cela, nous pouvons nous appuyer sur les recherches en matière d’architectures de réseau et les propositions de jeux qui s’appuient dessus.
La plate-forme unifiée
Un des grands axes de recherche et développement en matière de réseau multimédia est la plate-forme unifiée. Il s’agit de la possibilité de faire communiquer, au travers d’un internet généralisé, des usagers disposant d’appareils mobiles (téléphone, PDA...), d’ordinateurs fixes ou mobiles, et de postes de télévision interactifs. Cet environnement doit permettre de diffuser des contenus synchrones (radio et télévision numérique, téléphone et visiophone), asynchrones (fichiers), en mode de diffusion (broadcast) ou à la demande, avec différents niveau et types d’interactivité, allant des interfaces de type web au jeu vidéo en passant par tous les modes de travail coopératif. Sans rentrer dans les détails techniques, ce projet pose de nombreux problèmes d’interfonctionnement, des protocoles de réseau informatique jusqu’à la description des contenus. L’architecture MPEG4 (MPEG4 03) est un bon exemple de travaux de normalisation portant sur la plate-forme unifiée. La figure suivante représente un schéma de ce que pourrait être la plate-forme unifiée pour les jeux MMOG.
.
Protocoles réseau, en particulier protocoles de diffusion fiable, protocole de synchronisation des horloges…
Transmission et synchronisation
des données Synchronisation des flux de données Compression et décompression des données Protocoles de sécurité et de tolérance aux pannes
Moteur du jeu (Distributed Game
Engine, Game Middleware)
Gestion de l’état global du jeu, Passage à l’échelle
Filtrage sémantique, prédiction d’état
Autres composants du moteur de jeu (image, son, intelligence artificielle, physique)
Moniteur d’exécution du jeu Figure 1. Architecture de la plate-forme unifiée
Dans ce schéma, qui représente les composants logiciels qui sont supportés par un ordinateur de jeu, nous distinguons d’une part tout ce qui est nécessaire à la transmission des données (les protocoles de l’internet actuel et à venir et les mécanismes de synchronisation de flux de données) et d’autre part les mécanismes utilisés pour le jeu, qui constituent ce qui est souvent appelé un moteur de jeu.
Les jeux proactifs
A partir de la plate-forme unifiée il est possible d’imaginer une nouvelle génération de jeux massivement multijoueur dans lesquels, via son téléphone mobile, son assistant personnel, ses ordinateurs, sa télévision… le joueur reste constamment en lien avec l’univers du jeu. Il peut recevoir des
Réseau
messages de son avatar, des autres joueurs, du moteur de jeu. Il peut rechercher des indices pour faciliter ses quêtes dans les médias « du monde réel ». A contrario une station de radio ou de télévision diffuse en continu des nouvelles sur l’état de l’univers virtuel. Le joueur peut, dans la peau de son avatar, diriger un royaume ou être un parrain de la mafia. Il peut avoir une petite famille virtuelle qui lui souhaite son anniversaire avec plus de ponctualité que sa famille réelle. Relié en permanence à l’univers virtuel par toute une panoplie d’appareils, le joueur peut interagir avec le monde du jeu en utilisant toutes les interfaces dont il dispose : du clavier de son téléphone mobile au joystick de sa console. On peut également penser à des interfaces vocales ou musicales, des dispositifs spécifiques allant du tapis de danse interactif aux systèmes à retour d’effort qui permettent la perception tactile des objets virtuels…
Si cette idée est très séduisante, elle pose d’innombrables questions sociologiques, psychologiques, ergonomiques. La scénarisation des MMOG est un domaine aux règles inconnues, les jeux proactifs ouvrent encore plus les possibilités en la matière. Enfin, d’un point de vue scientifique et technique, il s’agit d’une des applications les plus complexes de la plate- forme unifiée.
Dimensionnement et interactions
Considérons quelques applications en réseau de coopération en temps réel : un jeu en salle ou de façon générale portant sur une communauté privée réunit, à un instant donné une vingtaine de joueurs au maximum, c’est également le cas de système de travail collaboratif comme la CAO d’avions (Constantini, 2001), ou du tutorat en ligne sous forme d’exercice dirigé ou d’un concert réparti (Bouillot, 2002). Le pendant virtuel d’un amphithéâtre virtuel pourrait recevoir quelques centaines d’étudiants, avec une interaction limitée entre l’enseignant et les élèves. Une visite de musée virtuel ou certaines installations artistiques relèvent du même ordre de grandeur. Un jeu persistant en réseau réunit, à l’heure actuelle quelques centaines de participants jouant simultanément dans une partie. Il est envisagé d’avoir plus d’un million d’abonnés aux jeux qui sont proposés aujourd’hui (Star Wars, les Sims). Si l’on considère que 15 à 20 % de ces abonnés peuvent être simultanément en train de jouer, on aboutit à un objectif de 200 000 joueurs.
Il est nécessaire néanmoins de s’interroger sur l’intérêt de réunir une communauté de plusieurs milliers de personnes. En dehors des applications qui relèvent de la diffusion (radio et télévision), il existe peu d’exemples de média qui mettent en jeu des groupes aussi importants dans une relation
continue. Les pratiques sociales possibles des jeux en réseau doivent être analysées finement si l’on ne veut pas construire des systèmes très complexes dont l’intérêt pratique est nul.
La nature des interactions peut être analysée selon trois aspects.
Premièrement, s’agit-il d’un échange essentiellement centralisé (d’un maître du jeu vers la communauté) ou réparti sous forme de conversation locale ou généralisée ? D’autre part, les contraintes de temps de réponse et de variabilité dans ce temps ont un impact technique important. Dans un jeu de stratégie comme Starcraft, un temps de réponse de quelques centaines de millisecondes est admissible, ce qui est rédhibitoire pour un jeu d’aventure ou d’action comme Counter-Strike. Des actions synchrones, comme celles d’un concert réparti nécessitent, outre un temps de réponse moyen bref, une très faible variabilité de ce temps pour permettre aux musiciens de se caler sur un tempo commun. Enfin, troisième aspect, l’utilisation d’un média d’échange synchrone comme la voix ou la vidéo impose des contraintes psycho-perceptives fortes.
Les principaux problèmes L’écriture et la spécification
Alors que l’analyse et les principes d’écritures pour les jeux à un joueur commence à faire l’objet de travaux (Rollins, 2000 ; Guardiola, 2000 ; Genvo, 2003 ; Gal, 2002), la conception de jeu massivement multijoueurs pose un défi d’une autre ampleur. En effet, même si le jeu classique n’a pas la structure d’un récit linéaire, il reste essentiellement contraint par la durée du jeu. Les mécanismes qui font les qualités d’immersion d’un jeu sont de trois ordres : les qualités esthétiques de l’univers construit, les tensions du récit, la qualité des règles du jeu. Il est possible de rapprocher ces trois aspects soit des règles classiques de scénarisation (Szinlas, 2001), soit des règles de construction d’un jeu de table. Les limites dans la durée de résolution des énigmes et par conséquent leurs complexités jouent sur les tensions proche du climax1 d’un scénario linéaire.
Un jeu persistant par sa nature et son économie n’a pas de limite en durée. Le concepteur du jeu doit constamment raviver l’intérêt de ses abonnés en introduisant de nouvelles énigmes ou de nouveaux mécanismes.
Cet aspect reste proche d’un feuilleton, celui-ci ne se déroulant pas par
1. Le climax est un point de tension maximum d’une écriture linéaire (roman, pièce de théâtre, scénario, pièce de musique). Il existe des systèmes de tension et de détente d’intensité qui sont des structures classiques des domaines précédents.
épisodes mais en continu. Il relève certainement en partie des mécanismes d’écriture précédemment cités. Mais, « un jeu massivement multijoueur est d’abord un lieu d’échange » (Lejade, 2002). A la dimension classique du scénario s’ajoute la construction d’un univers social qui dans le cas le plus simple est de l’ordre de la définition d’un nouveau sport et dans le cas le plus général d’une nouvelle cité virtuelle. L’élément essentiel de cette construction est de donner aux joueurs la possibilité de transformer l’univers du jeu dans une démarche individuelle ou collective. Ce principe a déjà été utilisé dans de nombreuses expériences de création collective sur internet (Balpe, 2000), mais une création artistique peut s’élaborer sans autre contrainte que des a priori esthétiques et sans objectif d’achèvement ou d’intérêt collectif. Ce n’est pas le cas des jeux (au moins des jeux commerciaux), dont l’évolution doit rester contrôlée.
Ce défi de l’écriture a un pendant technique. Pour que l’univers virtuel soit correctement traduit dans le programme du jeu, pour vérifier sa cohérence, suivre en temps réel son évolution, il est nécessaire de créer des outils de spécification, de validation et de maintenance. Il s’agit d’un problème de « génie ludique » d’autant plus difficile à résoudre qu’il n’est pas pour l’instant correctement défini, faute de pratique.
La générativité
La plus grande partie des jeux actuels évoluent dans un univers scénaristique, graphique et sonore prédéterminé. Le scénario est codé dans le programme, les objets graphiques et sonores sont des fichiers de données soit symboliques (description de scène, fichier midi2), soit de matériaux numériques (textures, fichier audio). Les jeux étant actuellement diffusés sur des supports de type DVD, on dispose d’un volume de stockage suffisant pour stocker ces informations. L’interactivité ne joue que sur l’enchaînement de ces éléments et leur cadrage (camera adoptée et déplacement du joueur).
Ceci possède un avantage essentiel : le concepteur dispose d’un contrôle sur ce qui peut arriver au joueur et sur ce qu’il peut percevoir. Cette technique a un inconvénient essentiel : le caractère limité et répétitif de l’univers construit. Tant que la durée de vie d’un jeu est elle-même limitée, la seule contrepartie est économique. Construire un univers qui, durant une centaine d’heures, offre des découvertes constantes est extrêmement coûteux en termes de main d’œuvre (Level designer, graphiste, musicien…). Un univers
2. Un fichier midi est un codage d’une partition musicale ou plus généralement sonore. Le fichier ne comporte que des commandes (jouer un la pendant 500 ms), qui sont exécutées par un synthétiseur.
persistant, n’ayant pas de limite de vie, peut coûter infiniment cher. D’autre part, un univers très grand ne peut être stocké sur un support informatique, surtout s’il doit se renouveler. Il doit donc être chargé via le réseau, ce qui peut être coûteux en termes de débit pour certains constituants (les matériaux numériques).
Une autre façon de procéder consiste à construire l’univers de façon générative. Dans ce cas, l’univers est décrit sous forme de règles comportementales et constructives traduites par un programme. Ces règles sont en général locales à une partie de l’univers : comportement d’un personnage non joueur, structure du terrain dans les montagnes du nord, transition sonore lorsque l’on passe d’une zone urbaine à une zone rurale…
L’univers est généré en temps réel en fonction des déplacements du joueur et d’aléas engendrés artificiellement. Cette génération crée d’emblée une variabilité considérable puisqu’elle résulte de toutes les interactions possibles entre toutes les règles gérant tous les objets du jeu. L’univers ainsi décrit est très compressé puisqu’il est décrit sous forme d’un langage symbolique. La contrepartie de ce choix est la difficulté de prévoir et donc de contrôler a priori les évolutions du jeu.
Donnons trois exemples de mécanismes génératifs dans les domaines de l’intelligence artificielle, du graphique et du son.
De nombreux mécanismes comportementaux pour les jeux peuvent être conçus en termes de simulation de mécanismes biologiques ou sociaux, présentés généralement sous le vocable de « vie artificielle » (Richard, 2003), (Maloron, 2003). Un système de vie artificielle est constitué d’un ensemble de règles qui régissent des agents « intelligents » et des mécanismes de communication entre ces agents. En observant la communauté artificielle ainsi construite par référence à une communauté réelle, il est possible d’en déduire la pertinence des règles. Une des premières applications de la vie artificielle fut l’étude du comportement des fourmis. Un système de vie artificielle devient à proprement parler génératif lorsque le comportement de chaque agent se transforme par apprentissage. Il est évident que ces mécanismes ont un potentiel considérable pour la construction de jeux persistants, ne serait que pour donner un caractère moins prédictible au comportement des personnages non joueurs. Un autre aspect très intéressant de la programmation par agent est qu’elle induit naturellement une architecture répartie en identifiant et matérialisant dans le code de chaque agent les objets du jeu. Ceci facilite la détermination de la part de l’univers qui doit être connue par la machine d’un joueur donné (voir paragraphe suivant).
Un générateur de terrain est un logiciel qui construit un paysage artificiel à partir de règles cartographiques décrivant la nature du paysage (montage, plaine…) et de règles esthétiques (Lecky, 2002). Cette construction peut aller de la forme générale du terrain (représentation polyédrique des surfaces), jusqu’à la construction des objets meublant ce paysage (arbre, animaux…).
Un générateur de terrain « hors ligne », fabrique le terrain une fois pour toutes, dans la phase de réalisation du jeu. Ce terrain est ensuite intégré dans les données du jeu. Cette technique est déjà utilisée dans les jeux actuellement développés. Dans le cadre des MMOG, l’ambition serait de générer un terrain en temps réel, c’est-à-dire pendant le déroulement du jeu.
La musique générative a été expérimentée bien avant son traitement numérique (Generative 03) en particulier dans le cadre de concerts ou d’installations artistiques. Une façon de générer de la musique est de construire des agents qui interagissent et génèrent une partition midi. Celle- ci est synthétisée par un ordinateur. On trouve peu de jeux qui utilisent ce principe, l’exemple le plus célèbre étant Rez (Rez 01). La construction d’une musique interactive pose des problèmes de techniques musicales (transition par exemple) et audionumérique (contrôle de la qualité de la synthèse musicale), mais également de contrôle de l’écriture en termes purement esthétiques et de rapport image/son.
L’architecture
Un jeu en réseau est un système informatique réparti, c’est-à-dire un ensemble de machines autonomes qui communiquent et font évoluer l’application informatique constituée par le jeu en échangeant des messages.
Cette application est constituée par un ensemble de données statiques et de programmes, d’une part et un état courant du jeu, d’autre part. La question posée est simple : comment répartir ces informations de la meilleure façon entre les différents ordinateurs. L’objectif est que le jeu soit cohérent et que le temps de réponse aux commandes des joueurs soit acceptable. Les contraintes à respecter portent sur le débit des échanges de messages, qui doit être compatible avec celui du réseau et la nature des algorithmes exécutés par chaque machine qui doit être fonction des capacités de calcul des ordinateurs des joueurs.
Les jeux en salle actuels utilisent un réseau local à haut débit (100 Mb/s) qui permet de transmettre naturellement les informations en diffusion (un message envoyé est reçu par tous les récepteurs). L’architecture adoptée est de type pair à pair (peer to peer) : chaque ordinateur envoie à tous les autres toutes les commandes exécutées par le joueur. Chaque ordinateur possède une copie complète du jeu et gère à partir des informations reçues une
version de l’état courant du jeu. Le grand avantage de ce type d’architecture est la rapidité de diffusion des commandes : une commande réalisée par un joueur est transmise, sur un réseau local, à tous les ordinateurs par l’envoi d’un seul message.
Figure 2. Relations entre ordinateurs dans une architecture de type pair à pair Par contre, cette solution n’est pas utilisable sur internet, même avec un nombre limité de joueurs : les délais de transmission sont trop grands et trop aléatoires et la diffusion des messages est un mode de transmission coûteux et mal implanté. Une solution en pair à pair conduirait nécessairement à des états incohérents (cf. paragraphe suivant).
Dans ce cadre, les jeux actuels utilisent un mode clients/serveur. Le jeu est implanté sur une machine centrale, serveur de jeu, qui reçoit les commandes de tous les postes des joueurs. Cette machine effectue presque tous les calculs (sauf certains aspects du calcul graphique et sonore) et renvoie le résultat à chaque ordinateur des joueurs. Cette architecture permet un contrôle plus facile de l’état du jeu. Par contre, elle est plus lente et engendre un trafic de messages beaucoup plus important que l’architecture pair à pair : il faut autant de messages que de participants pour diffuser une commande.
Figure 3. Architecture de type clients/serveur
Cette solution est applicable parce que les jeux actuels sur internet portent soit sur un groupe limité de joueurs (communauté fermée d’une dizaine de personnes) soit parce qu’ils supportent des temps de réponse relativement élevés (de l’ordre d’une demi-seconde).
Construction d’un état cohérent
Le problème de la construction d’un état cohérent dans un système informatique réparti est un des plus anciens et des plus fondamentaux du domaine. Il résulte du fait que le temps de propagation des messages n’est pas déterminé, que les messages peuvent être détruits et les constituants du réseau peuvent tomber en panne. Ne recevant pas les mêmes informations dans les mêmes temps et dans le même ordre, deux ordinateurs peuvent avoir, au même instant, une vision différente de l’état. Illustrons ceci dans le cadre d’un jeu à deux joueurs. Alain (A) poursuit Bob (B) et doit le rattraper.
A l’instant initial supposons que les deux joueurs aient la même vision de l’état du jeu : A en X=0 et B en X=1. A l’instant t=1, A et B émettent une commande d’avance d’une unité de leurs avatars respectifs. La commande de A est reçue par l’ordinateur de B à t=2 et la commande de B n’arrive pas à A (ou au bout d’un délai très long). A t=1,5 et t=2,5 chaque ordinateur recalcule l’état du jeu. A t=1,5, Alain, n’ayant pas reçu la commande d’avance de l’avatar de Bob et ayant fait avancer son propre avatar en déduit qu’il a rattrapé l’avatar de Bob et gagné la partie. Bob a vu avancer les deux avatars et pense encore à t=2,5 qu’il n’a pas perdu.
Figure 4. La course incohérente d’Alain et Bob
Notons dans cet exemple un aspect important de la cohérence dans les jeux, la gestion du temps. Une des variables d’un jeu est le « temps du jeu », un jeu ayant en général son horloge propre qui mesure le temps dans l’univers virtuel. A un instant t (mesuré en temps absolu), la date courante du jeu peut être différente sur les différentes copies, mais pour que toutes les
X=1 Vue
d’Alain à t=1,5 et 2,5
X=0 X=1
Vued’Alain et Bob à t=0
X=0 X=1 X=2
X=0 X=1 X=2
Vue de Bob à t=1,5
Vue de Bob à t=2,5
copies soient cohérentes elles doivent traiter les commandes à la même date du temps du jeu. On trouve la même contrainte dans le domaine de la simulation répartie (IEEE 95), (HLA 03), mais dans un jeu, qui est une simulation temps réel interactive, une contrainte supplémentaire impose que la durée séparant deux événements mesurée en termes de temps réel ou de temps de simulation doit être à peu près la même. Autrement dit, lorsque l’on simule un décollage d’avion pour une étude scientifique, un décollage de vingt minutes peut prendre dix heures de calcul. Dans un simulateur de pilotage ou un jeu, ce n’est pas possible.
Dans la plupart des applications informatiques, la recherche d’une solution au problème de l’état cohérent est basée sur le principe d’ordonner totalement les commandes. Par exemple, toutes les commandes transitent par un serveur central qui les numérote. Dans un premier type de solutions, appelées conservatives ou pessimistes, tous les ordinateurs qui exécutent l’application doivent effectuer le traitement dans l’ordre de la numérotation.
Ils passent donc tous par les mêmes étapes du jeu, avec éventuellement un décalage temporel. Ces solutions peuvent être contraignantes en termes de temps de réponse. En effet, pour exécuter une commande un ordinateur doit avoir reçu et exécuté toutes les commandes précédentes. Dans le cas où le réseau a des délais de transfert peu prédictibles et peut perdre des messages, cela peut être très pénalisant. Une autre approche, dite optimiste, consiste à traiter les commandes dès qu’elles sont reçues par un ordinateur et de réexécuter l’application depuis une situation cohérente si une incohérence est détectée.
Aucune de ces deux approches n’est suffisante pour les jeux vidéo. Un jeu vidéo à une contrainte de temps de réponse à certaines commandes qui résultent de la nécessité d’une fluidité des animations visuelles et sonores.
Donc le calcul des éléments synchrones (la génération des trames qui composent l’animation et du flux sonore) est nécessairement exécuté sur le poste du joueur. Cela conduit à privilégier l’approche optimiste. Mais certaines actions doivent nécessairement être perçues de façon cohérente sur tous les ordinateurs. Supposons que sur deux ordinateurs la position de deux objets ne soit pas strictement identique. Si un joueur tire sur une cible, dans un cas il semblera que la cible est touchée, dans l’autre qu’elle est ratée.
Toute décision sur le succès ou l’échec de ce tir paraîtra arbitraire à un des deux joueurs. Dans une approche optimiste il faut donc reprendre la séquence dès que l’incohérence sur la position de la cible et son effet sur le tir, est détectée. Or il n’est possible de réexécuter un jeu que pendant un délai très court (de l’ordre de 100 ms), pour que cette opération soit imperceptible.
Performance
Les performances nécessaires à l’exécution correcte d’un jeu en réseau sont de deux ordres : le débit des informations échangées et les temps de réponse entre une commande et la matérialisation de son effet sur tous les ordinateurs des joueurs.
Le problème de débit n’est peut-être pas le plus difficile. D’une part, la bande passante des connexions internet va en s’améliorant rapidement avec le développement des connexions haut débit. D’autre part, nous avons vu qu’en utilisant la générativité et, de façon plus générale, des techniques de compression de plus en plus évoluées, il est possible de réduire le volume d’informations qui sont transportées sur le réseau. Ceci a une contrepartie : chaque ordinateur doit disposer des moyens de calculs pour décompresser les données, générer les comportements, les images et le son dans un temps compatible avec les contraintes du jeu.
Les délais de transmission actuellement observés sur internet varient d’une dizaine de millisecondes à quelques secondes. Outre que les valeurs hautes sont totalement incompatibles avec un jeu réflexe, la grande variabilité de ces délais ne permet pas une réelle interactivité entre les joueurs (téléphoner sur internet reste une galère). Ce problème repose sur une suite de mécanismes allant de l’évolution des protocoles de l’internet (Melin, 2003) à la construction d’architectures et de mécanismes de cohérence de l’état efficaces en termes de latence de transmission des messages.
Pour comprendre les exigences de performance demandées par un jeu, reprenons la classification donnée par Cronin et al. pour un jeu d’action comme Quake (Cronin, 2001). Les auteurs classifient les commandes que peut émettre un joueur selon deux critères : la nécessité d’un temps de réponse court dans tous les cas (Real Time RT) et les commandes qui nécessitent une forte cohérence dans l’état du jeu, (Consistency CS). Dans le premier cas, la cohérence perceptive image/son doit être maintenue, ce qui induit un rafraîchissement synchrone avec une latence de moins de 100 ms.
Dans le second cas, la commande induit un événement qui change de façon notable l’état du jeu. Les commandes de type CS doivent être nécessairement connues et interprétées dans le même ordre sur toutes les copies de l’état du jeu. Les commandes plus complexes sont celles qui doivent répondre aux deux critères. Le tableau suivant donne le classement des quatre types de commandes de Quake.
Type Exemple Classe Commentaire Avancer Tous les
mouvements de
l’avatar TR Le joueur doit percevoir la continuité des déplacements
Tirer Une balle ou une
fusée est tirée CS/RT
Pour comprendre les deux contraintes, il faut imaginer que le joueur visé puisse esquiver l’attaque s’il réagit assez vite Toucher La balle ou la fusée
atteint un objet et
explose CS/RT
Blesser Un avatar est
blessé ou tué CS
Mourir ou renaître sont des événements importants, mais on a le temps pour matérialiser l’opération et envoyer des faire- part
Renaître Un avatar renaît dans un lieu
aléatoire du jeu CS
Tableau 1. Classification des commandes du joueur dans Quake
Mise à l’échelle (Scalability)
Il s’agit ici d’une contrainte pour l’architecture. Elle doit être capable de se reconfigurer dynamiquement en fonction du nombre de joueur présents.
En outre, si le jeu a beaucoup de succès le nombre d’abonnés croît et le nombre de joueurs aussi. Il est donc nécessaire de faire évoluer l’architecture pour satisfaire les besoins, en perturbant le moins possible le fonctionnement du jeu. Il s’agit d’une problématique très générale qui trouve son pendant sur toutes les applications de l’internet (les portails par exemple).
Tolérance aux pannes et sécurité
La tolérance aux pannes est aussi un aspect classique de l’informatique répartie : il s’agit de maintenir le service rendu en présence de pannes des éléments de l’architecture. Les solutions reposent sur une redondance du matériel et du logiciel avec un basculement automatique lors des pannes.
Cela implique également une cohérence entre les différentes copies du jeu.
Enfin, il faut concevoir les mécanismes de réinsertion des éléments réparés
sans perturber le jeu, problème déjà évoqué au paragraphe précédent. Parmi toutes les applications informatiques qui nécessitent de la tolérance aux pannes, les jeux en réseau ne sont certainement pas les plus contraignants, les systèmes de contrôle commande industriels sont, en la matière, beaucoup plus exigeants et complexes. Il existe donc des solutions viables à la tolérance aux pannes pour les jeux qui devront être intégrées dans les architectures et moteurs de jeu en réseau.
Par contre, l’aspect sécurité (protection contre les agressions) est beaucoup plus délicat et général. Il est possible de scinder cet aspect en quatre classes de problèmes :
– l’authentification des joueurs : ne peuvent participer à un jeu que les personnes autorisées (par exemple celles qui ont payé un abonnement) ;
– la protection en confidentialité et en intégrité des données contre les attaques menées via le réseau par des non-joueurs. Il existe de nombreux mécanismes qui offrent des solutions à ces deux aspects des problèmes de sécurité (Natkin, 2001). Ils font l’objet de nombreux développements car ils sont au cœur du développement du commerce électronique ;
– le contrôle des droits des joueurs sur les objets du jeu pour maintenir le respect des règles du jeu pour assurer la cohérence du monde et de la société virtuelle. Il s’agit là d’un problème de recherche ouvert de sécurisation des protocoles coopératifs, très difficile sur le plan scientifique et qui a d’innombrables facettes. Il doit être résolu sous un forme ou une autre dans le cadre des jeux. Il a d’innombrables applications dans tous les secteurs de la « cyber » société : travail coopératif, vote électronique, enchère en réseau…
– la protection des droits d’auteurs. Il s’agit là aussi d’un vaste chantier ouvert par la diffusion numérique de tous les médias. De nombreux mécanismes sont à l’étude allant de la reconnaissance des ayants droits (Watermarking) aux protocoles de gestion des droits de diffusion (Digital Right Management).
Exemple de travaux de recherche
Le filtrage sémantique
Comme nous l’avons déjà observé, l’univers d’un jeu peut représenter une très grande quantité d’information. Avoir une copie de cet univers et la tenir à jour pour chaque joueur peut être très difficile, voir impossible.
Envoyer à chaque joueur une copie de toutes les actions des autres joueurs est tout aussi délicat. Or ce n’est pas nécessaire, il suffit de maintenir la
partie de l’univers qu’un joueur peut observer et sur laquelle il peut agir.
Cette portion d’univers est la zone d’intérêt du joueur (area of interest) ou encore « aura ». De plus, il n’a pas besoin de recevoir les copies des commandes qui portent sur son aura. La véritable difficulté est justement de déterminer cette aura. C’est l’objet du filtrage sémantique (Interest management).
Le filtrage sémantique part d’un point de vue simple : un objet peut être perçu par un joueur via le regard et l’ouie, éventuellement le toucher si le jeu possède une interface à retour d’effort. Le moteur de jeu peut connaître parfaitement l’ensemble des objets perceptibles par un joueur. Cet ensemble est appelé son « focus ». Pour des raisons de performances il est nécessaire d’étendre ce focus à tous les objets que pourrait percevoir le joueur suite à une action simple (changer légèrement de position par exemple). Un second concept est l’espace dans lequel un objet peut être perçu, appelé son
« nimbus ». Un raisonnement simple conduit à dire qu’il faut maintenir dans l’environnement de chaque joueur une portion d’univers incluant son focus et prévoir des échanges entre deux joueurs A et B dès que le focus de l’un intersecte le nimbus de l’autre. En première analyse, il est possible de construire des solutions simples basées sur ces concepts et des principes de continuité géographique de l’espace.
Le principe, que nous venons de décrire schématiquement, ne fonctionne que dans des univers « très physiques », c’est-à-dire construits selon une simulation de lois naturelles. C’est par exemple le cas des jeux de sport. Dès que l’on considère des univers moins « terre à terre » apparaît une première difficulté qui résulte des notions de perception et d’action. L’aura d’un joueur ne dépend pas de sa perception physiologique du joueur ni de ce qu’il fait matériellement avec sa manette, mais de la perception virtuelle et des capacités d’action de son avatar. Or, dans ce cadre l’imagination est au pouvoir du Game Designer. Dès qu’il dote un personnage d’un téléphone, tous les joueurs à qui il peut téléphoner sont dans son espace d’action. Il peut d’ailleurs s’agir d’un télétransporteur ou d’un fusil bionique dont la portée n’a pour limite que la fantaisie du jeu. Donc, la détermination de l’aura ne peut se baser uniquement sur des considérations géométriques.
Elle s’appuie d’abord sur les principes du gameplay qui déterminent l’espace d’action d’un joueur et donc l’intégration dans les outils de scénarisation de technique déterminant l’aura, le nimbus et le focus de chaque objet.
Par ailleurs, il est possible en théorie d’améliorer cette analyse par apprentissage du comportement du joueur. Si certaines actions sont très fréquentes, les objets sur lesquels portent ces actions doivent être dans l’aura. Ceux qui ne sont que rarement touchés peuvent être inclus sur
détection d’événements. Cela suppose donc d’introduire dans le jeu un processus d’apprentissage relevant de l’intelligence artificielle, très intéressant dans son principe puisqu’il permet également de construire des règles de jeu adaptées à chaque joueur. Il s’agit pour l’instant d’un difficile problème de recherche.
L’optimisation du volume de messages échangés pose des problèmes de protocole informatique de haut niveau. Supposons qu’il soit possible de déterminer à chaque instant le focus et le nimbus de chaque objet. Un message traduisant une action de A doit être communiqué à tous les objets dont le focus intersecte le nimbus de A. Il faut donc utiliser une communication en diffusion vers un groupe d’abonnés. Il existe soit pour les couches basses de télécommunication, soit pour les protocoles plus proches de l’implantation des objets (bus à objet) des méthodes qui permettent de réaliser ce type de transmission. Mais pour l’instant elles ne sont pas conçues pour des groupes dont la composition change constamment, ce qui est le cas des jeux.
La prédiction d’état (Dead Reckogning)
Imaginons un jeu de tennis sur internet, basé par exemple sur une architecture centralisée. Un des joueurs tape sur la balle, ce qui détermine sa trajectoire jusqu’à l’instant où elle rencontrera un nouvel objet (le sol, la raquette d’un autre joueur). Le serveur va donc appliquer un modèle cinématique simple et envoyer à chaque client les positions successives de la balle à raison d’une trentaine de fois par seconde. Ne serait-t-il pas plus intelligent de laisser faire ce calcul par les postes clients, le serveur, lui, se préoccupant de la prochaine collision ? Une telle approche est appelée prédiction d’état (Dead Reckogning). Si cette solution est adoptée, alors il est nécessaire que le serveur envoie la position de collision et la nouvelle vitesse de la balle suffisamment tôt pour qu’il n’y ait pas de discontinuité dans la trajectoire de la balle, et que son mouvement semble naturel. Faire marcher en arrière une balle de tennis peut être du plus mauvais effet.
La description de la prédiction d’état est une des plus abouties que l’on puisse envisager, car elle est basée sur un modèle physique du jeu connu par le logiciel des machines qui calcule la prédiction d’état. Une version qui suppose moins d’intelligence locale se base uniquement sur les positions successives de l’objet dont on cherche à prédire la trajectoire. La position suivante est approximée en utilisant une interpolation polynomiale. De temps en temps le serveur envoie la position exacte. A partir de cette donnée le client calcule alors une nouvelle trajectoire pour l’objet et cherche une méthode permettant de ramener l’objet de sa position courante à une
position dans la nouvelle trajectoire, ceci de façon la plus « naturelle possible ».
Figure 5. Prédiction d’état d’une balle de tennis
L’efficacité de cette technique est démontrée pour une classe d’objets courants dans certains jeux en réseau (en particulier les projectiles), et tend à être incorporée dans les moteurs graphiques et physiques des jeux en réseau.
Comme le filtrage sémantique, elle est liée au « caractère physique » des règles du jeu, ce qui sous cette forme limite son usage. Nous reviendrons en conclusion sur ce point.
Un exemple d’architecture
Nous présentons à titre d’exemple une architecture qui a fait l’objet d’expérimentation dans le domaine des jeux. Elle a été développée à l’université du Michigan, Ann Arbor. Nous l’appellerons dans la suite CRIMP, du nom d’un des protocoles utilisés.
Les chercheurs de l’université d’Ann Arbor se sont fixés comme objectif expérimental de construire une version distribuée du très célèbre jeu Quake.
Quake est un des plus célèbres First Person Shooter. Il n’a pas été conçu initialement pour être joué en réseau, mais un des modes de Quake, Half
Position de la balle à l’instant t
Trajectoire initialement calculée
Trajectoire recalculée Trajectoire de convergence Position de la balle à l’instant t estimée par le client
Position de convergence des deux trajectoires estimées par le client
Life, est un des jeux les plus joués en réseau local, dans une architecture de type client/serveur. Il en résulte que les conditions de cohérence et de consistance pour que ce jeu soit jouable en réseau sont connues. Le faire jouer sur internet avec un grand nombre de joueurs est un pari difficile car il s’agit d’un jeu réflexe dans un monde complexe en termes de situations et d’objets utilisés.
Les concepteurs de CRIMP partent du principe qu’ils doivent obtenir les mêmes facilités de gestion d’un état cohérent que dans une architecture centralisée et des temps de réponse courts comme dans les architectures de pair à pair. D’un point de vue matériel, le système est constitué d’un groupe de serveurs et de postes clients. Chaque client est relié à l’un des serveurs.
Les serveurs sont liés entre eux par une architecture pair à pair. Il gère une copie complète du jeu. Les différentes copies sur les différents serveurs sont maintenues cohérentes en utilisant un protocole de diffusion fiable (CRIMP) et un mécanisme d’ordonnancement des commandes émises par tous les clients. Le serveur auquel est connecté un client reçoit les commandes de celui-ci. Il numérote localement toutes les commandes provenant des différents clients et les diffuse à tous les autres serveurs. CRIMP garantit que tous les serveurs actifs reçoivent une copie de chaque commande. La gestion de la cohérence de l’état est basée sur la classification des commandes qui a été présentée au paragraphe consacré aux performances. Les commandes sont traitées dès qu’elles sont reçues par un des serveurs. Chaque serveur gère une suite de parties du même jeu décalée dans le temps de simulation.
Si la partie courante traite à l’instant t, le temps de simulation T, la première partie de reprise traite au même instant le temps de simulation T-D1, la seconde T-D1-D2… Donc la partie la plus ancienne a le plus de chance de recevoir les commandes à traiter dans le bon ordre et avec la bonne date.
Une incohérence est détectée lorsque la partie courante a traité un événement à une date différente d’une des parties différées. Le jeu est alors réexécuté à partir de la moins ancienne partie différée ne présentant pas cette anomalie.
Le filtrage sémantique dans CRIMP est celui qui était déjà utilisé dans Quake. Il est basé sur une partition de la topologie du jeu et un mode de représentation de cet espace comme un arbre binaire permettant de trouver facilement des zones adjacentes et englobantes. Un joueur de Quake ne connaît que la zone où il se trouve et les zones voisines.
Les concepteurs de CRIMP présentent des analyses et des mesures qui semblent montrer la viabilité de leur approche dans le domaine du jeu qu’ils se sont fixés.
Figure 6. L’architecture de CRIMP avec trois serveurs
Conclusion
Dans cet article nous avons tenté de dresser un rapide panorama des problèmes scientifiques et techniques que pose la réalisation des futurs MMOG. Ces problèmes sont, comme nous l’avons signalé, des paradigmes pour de très nombreuses branches de la recherche en informatique et au cœur de la création de médias interactifs (Natkin 2003).
Il nous semble que la réalisation de solutions efficaces passe par une imbrication entre les outils d’aide à l’écriture et les mécanismes de plus bas niveau (moteur et protocole). Nous avons signalé qu’il était difficile de faire du filtrage sémantique (ou du Dead Reckogning) sans connaître… la sémantique du jeu. CRIMP semble être un compromis intelligent et efficace entre différentes solutions parce qu’il part de la connaissance et de la pratique de Quake. D’un point de vue plus général, il nous semble que chercher des solutions innovantes à des problèmes tels qu’ils sont posés par
les concepteurs (Game Designer, graphistes, musiciens, ergonomes) est une voie vers une nouvelle génération de jeu.
Bibliographie
Bettner P., Terrano T., 1500 Archers on 28.8: Network Programming the Age of Empire and beyond, http://www.gamasutra.org, 2000.
Bouillot N., Métaphore de l’Orchestre Virtuel, Etude des contraintes Système et Réseaux puis prototypage, Rapport de stage DEA SIR, CNAM, Paris, septembre 2002.
Constantini F., Toinard C., Chevassus N., Gaillard F., « Collaborative design using distributed virtual reality over the Internet », In Proceedings SPIE Internet Imaging, San José, 2001.
Cronin A., Filstrup B., Kurc A., A Distributed Multiplayer Game Server System, Ann Arbor University, 2001.
Gal V., Le Prado C., Natkin S., Vega L., « Writing for video games », Proc VRIC 02, Laval, juin 2002 (http://cedric.cnam.fr/).
Genvo S., Introduction aux enjeux artistiques et culturels des jeux vidéo, L’Harmattan, Paris, 2003.
Greenhalg C., Bendford S., « Massive a Distributed Real Virtual Reality System Incorporating Spatial Trading », 15th International Conference on Distributed Computing Systems, Vancouver, Canada, May 1995.
Guardiola E., Ecrire pour le jeu, Dixit, Paris, 2000.
Hadwiger M., Varga A., Parsec Networking Architecture, 1998, http://www.parsec.org/
Hagsand O., Interactive Multiuser VEs in the DIVE system, IEEE Multimedia, vol. 3, n° 1, 1996.
Lecky-Thompson G. W., Infinite Universe : Level Design, Terrain and Sound, Advance in Computer Graphics and Game Development, Charles River Media Ed., 2002.
Lejade O., « Le business model des jeux massivement multijoueurs et l’avenir des communautés on line », Communication aux emagiciens, Valenciennes, novembre 2002.
Melin J.-L., La qualité de service sur IP, Eyrolles, Paris, 2003.
Maloron S., Lattaud C., Cours de synthèse « Vie Artificielle », http://www.math- info.univ-paris5.fr/~latc/va/va.html, 2003.
Natkin S., Les protocoles de sécurité de l’Internet, Paris, Dunod, 2001.
Natkin S., « Computer games: A Paradigm for the of new Media and Arts in the XXI century », Proc of Art and Media Conf, Yonsei University, Seoul, Corée, septembre 2003.
Richard N., Codognet P., Grumbach A., « Créatures virtuelles », Technique et Science Informatiques (TSI), numéro spécial Vie artificielle, vol. 22, n° 2, Hermès-Lavoisier, février 2003.
Rollins A., Morris D., Game Architecture and Design, Coriolis Ed. Scottsdale, 2000.
Smed J., Kaukoranta T., Hakonen H., Aspects of Networking and Multiplayers Computer Games, Turku University, Finland, 2002.
Szilas N., « A new approach for interactive drama: : From intelligent Characters to an intelligent virtual Narrator », Proc of the spring symposium on artificial intelligence and Interactive Entertainment, Stanford CA, March 2001, AAAI Press.
Tran F. D., Deslaugier M., Gérodolle A., « A Middleware for multi-platform, multi- player video games », document France Télécom R&D, 2002.
Sites web et jeux video
(generative 03) http://www.generative.net/
(HLA 03) High Level Architecture (HLA), http://www.dmso.mil/
(IEEE 95) IEEE Standard for Distributed Interactive Simulation, Application Protocols, (IEEE 1278.1-1995), IEEE Computer Society, 1995.
(MPEG4 03) http://www.m4if.org/mpeg4/
(Rez 01) jeu Rez, UGA, 2001, version PS2.
