TP Multimédia

Sébastien Boyer ([email protected])
Guillaume Faussard ([email protected])
Ing 5 groupe 4
TP Multimédia :
Le multicast appliqué aux jeux en réseau
Technologies employées :
•
protocole réseau UDP/Multicast,
•
Traitement de texte OpenOffice.
•
Paint.exe pour l'édition de captures d'écran.
Décembre 2003
I. Quelques rappels sur les jeux en réseau et leur moteur
réseau («netcode»)
1. Introduction
Le domaine des jeux en réseau est de plus en plus étudié avec la montée
grandissante de l’Internet. Actuellement, on peut jouer en réseau, mais en nombre peu
élevé à l'exeption des MMORPG (Massive Multiplayer Online rôle Playing Game) qui sont
apparu depuis deux ans et qui bénéficient de moteur réseau novateurs mais pas assez
robustes pour l'instant.
La problématique principale est que les jeux en réseau, en général, fonctionnent
dans une architecture centralisée où un serveur se charge de calculer, comme pour
Quake, la majeure partie des modifications du plateau de jeu qu’il doit renvoyer au client,
ce qui permet de maintenir un état de cohérence forte entre chaque client. Ce système
fonctionne, mais toute la complexité et le travail se situant au niveau du serveur, il est clair
que cette méthode ne passe pas à l’échelle ou du moins ne tient pas dans le cas où il y a
un très grand nombre de participants.
Le serveur a en général la charge de la retransmission des données provenant d'un client
vers les autres clients (si par exemple, le joueur se déplace, il faut avertir les autres
joueurs d'un changement d'état).
Le serveur est également l'arbitre et le maitre du jeu. Il peut avoir la capacité de
déclencher un événement sur l'un des clients et de décider de la victoire ou de la défaite
de l'un des participants. De son coté, le client a la charge de la gestion de l'affichage, de
l'interactivité avec le joueur mais aussi de certains traitements (animation,
événements, ...).
Si l’on veut pouvoir jouer en réseau de façon massive, il faut donc réussir à
distribuer les différentes tâches entre toutes les machines qui participent au jeu, comme
par exemple dans le jeu Diablo. La majeure partie des études qui se font dans le domaine
des jeux en réseau se place dans une architecture distribuée pour justement permettre
d’augmenter le nombre de joueurs sur le jeu. Le problème vient du fait que, si on distribue
les différentes tâches entre les différents clients, il risque d’apparaître des états
incohérents entre les différentes simulations.
Nous ne nous focaliserons point sur les aspects de cohérence temporelle et spatiale, qui
dépendent plus de la robustesse des alpgorithme de prédiction et de synchronisation des
données. Les notions de rapidité et de bande passante seront les critères essentiels de
ce TP.
2. Différents types d'architectures réseau
Actuellement, nous pouvons différencier deux types d’architecture dans les jeux en
réseau : d’une part, nous avons les architectures centralisées avec des jeux « à la »
Quake et d’autre part, des architectures distribuées comme on peut les trouver en jouant
à Warcraft3 par exemple. Les avantages d’une des architectures sont les inconvénients
de l’autre.
a. Architecture centralisée
Donc d’un côté, nous avons un serveur qui supporte toutes les connexions des clients
et qui se charge de faire la majeure partie des calculs. La seule tâche du client est de
transmettre au serveur les réactions du joueur et d’afficher le résultat.
Avantages :
•Dans
une architecture centralisée, on n’a pas à s’occuper de l’état de cohérence
générale, car, tout étant calculé sur une seule machine, il n’y a qu’une seule décision
prise pour chaque cas de figure, donc il n’y a aucun risque de trouver deux versions
différentes sur deux simulations qui se trouvent dans le même monde sur le même
serveur.
•Un des avantages que l’on peut noter, c’est qu’une architecture centralisée est bien
plus simple à mettre en œuvre, bien plus sécurisée et bien plus simple au niveau de la
cohérence globale. Il n’est pas nécessaire, par exemple, de mettre en place des
synchronisations puisqu’elles existent de manière naturelle.
•De plus, la puissance de la machine n’a pas forcément besoin d’être très élevée, car la
majeure partie des calculs est effectuée par le serveur. Dans un jeu « à la » Quake,
c’est le serveur qui a toute la charge de calculs alors que le client ne fait que
transmettre des informations et d’afficher les résultats calculés par le serveur.
•Enfin, on peut aussi remarquer qu’une architecture centralisée est bien plus sûre,
puisque toutes les informations proviennent d’une seule machine, le serveur. Donc, il
est beaucoup moins évident d’introduire des erreurs.
Inconvénients :
•Si
le serveur plante, la partie est finie, puisque c’est lui qui se charge de calculer toutes
les simulations, donc on peut noter une faible tolérance aux pannes.
•Un autre inconvénient de l’architecture centralisée est que tout dépend du serveur (et
des connexions qui permettent d’atteindre le serveur) qui devient le « goulot
d’étranglement » des performances, puisque, plus il y a de machines, plus il doit gérer
de connexions et de calculs.
•On peut aussi dire que l’on perd beaucoup du temps dans les communications réseaux
puisque les informations transitent d’abord par le serveur avant d’aller vers le client.
•En plus, le serveur doit simuler l’ensemble du monde et pas uniquement la partie où se
trouve les joueurs.
•Le nombre de joueurs qui peuvent participer à un jeu en réseau dans cette architecture
sont limités par ce que le serveur peut fournir.
b. Architecture distribuée
D’un autre côté, nous avons une architecture qui distribue les tâches entre les
différentes simulations ou plus généralement entre les différentes ressources de calculs.
Pour tout ce qu’il en est des calculs, ils sont effectués sur chacune des machines à partir
des informations échangées entre chacun des participants.
Il faut quand même un serveur qui, en général, permet d’accepter les connexions à la
partie et qui met en relation tous les joueurs. Il faut tout de même préciser que l’utilisation
du serveur peut être remplacé par la mise en place d’adresses multicast.
Avantages :
•Le
premier point à noter est une grande tolérance aux pannes, puisque toutes les
tâches sont distribuées, si une machine disparaît, les autres peuvent continuer à
tourner avec un minimum à faire pour redistribuer les tâches.
•Dans cette architecture, il n’y a pas de goulot d’étranglement comme l’est le serveur
dans une architecture centralisée. Puisque les tâches sont distribuées, les calculs le
sont évidemment aussi.
•Enfin, on peut aussi dire que l’on perd beaucoup moins de temps sur les architectures
distribuées dans les communications réseaux puisque les informations sont
directement transmises aux clients alors que dans une architecture centralisée où
toutes les informations transitent d’abord par le serveur avant d’aller vers le client.
Par contre, on peut noter qu’une simulation distribuée n’est pas forcée de calculer les
modifications qui ont lieu dans tout le monde simulé, il lui est seulement nécessaire de
calculer ce que le joueur voit.
Inconvénients :
•Un
des premiers problèmes à noter est que, puisque chaque simulation calcule ses
propres modifications du monde, il est très difficile d’avoir un état de cohérence
générale
•Pour palier au premier problème, il faut mettre en place des mécanismes qui
permettent de garder au mieux un état cohérent, donc cela entraîne des difficultés
supplémentaires dans la programmation d’un système distribué. Il faut aussi mettre en
place, par exemple, des systèmes de synchronisations puisque les différentes
simulations ne tournent pas forcément au même rythme.
•De plus, on peut noter un problème de sécurité, puisque chacune des simulations
possède tout le code du monde, donc peut le modifier à son aise.
3. 3 Catégories principale de jeux en réseau :
a) FPS: First Person Shooter (Exemple: Quake3)
Ce type de jeu en réseau place le joueur dans un environnement en trois
dimension qui apparaît à l'écran à la première personne. L'immersion est totale puisque le
joueur voit exactement ce que son personnage voit. D'autres informations sont affichées :
le « Hud » détaille l'état de santé et d'équipement du personnage (vie, armure, armement
et munitions) et éventuellement des informations sur ses coéquipiers (« team-overlay »).
Enfin, les joueurs peuvent communiquer entre eux grâce à un système de chat.
Les jeux de « fps » requièrent un moteur réseau optimisant le temps de latence (« Ping »)
afin d'être jouables. En effet, les déplacements sont rapides, que ce soit celui des joueurs
ou des projectiles, et un temps de réaction trop long handicape fortement la jouabilité.
Etudions maintenant comment se présente généralement le moteur réseau de ce
type de jeux et ce qui est fait pour contrecarrer le temps de latence causé par le jeu sur
Internet.
Outre la contrainte de rapidité, la notion de protection contre la triche est un
paramètre important dans la conception du moteur réseau. En effet, si le calcul des
déplacements et des projectiles est effectué uniquement du coté client, et sans
vérifications externes par exemple, il est difficile d'empecher des joueurs de coder un
programme de « cheat » visant automatiquement ses adversaires (« aimbot ») ou lui
ajoutant de l'équipement, etc.
Le netcode («code réseau ») utilisé est donc souvent basé sur une architecture
centralisée : un moteur réseau client/serveur avec du coté client, le stricte minimum en
matière de calcul et d'information à envoyer au serveur, tout en s'aidant d'algorithme de
prédiction pour lutter contre le délais de réponse du serveur : le client extrapole les
informations qu'il va recevoir dans la mesure du possible et corrige ensuite en fonction
des informations reçues du serveur.
Ce modèle est lourd niveau serveur : ce dernier vérifie la cohérence des actions de
chaque joueur et confirme leur deplacements, et il envoie à tous les participants toutes les
informations de la partie. On pourrait envisager de limiter les informations envoyées au
joueurs en fonction de la zone où ils se trouvent. Cependant ce concept de « zoning » des
joueurs n'est point possible avec ce type de jeu : les dimensions relativement petites des
environnements (« map ») par rapport à la vitesse de déplacements limitent la possibilité
de restraindre la quantité d'information à envoyer.
Au final, le netcode employé pour les jeux de fps utilise beaucoup de bande
passante et de charge processeur, et nous envisagerons dans la dernière partie
l'intégration ou non du protocole multicast.
b) RTS: Real Time Strategy (Exemple: Warcraft3)
Les jeux de stratégie en temps réel n'ont pas à faire face au même type de
contraintes réseau. En effet, la rapidité et la précision, caractéristique des jeux de FPS,
laisse place au soucis de lisibilité et de fiabilité avec un nombre d'unités présent à l'écran
pouvant dépasser la centaine. Nul question ici d'extrapoler le déplacement des unités en
fonction de leur vecteur vitesse, du terrain, etc. Le temps de réponse est important, afin
de s'assurer de la fiabilité des informations à afficher.
Puisque les contraintes de délais de réponse ne sont pas primordiales, et que le
nombre d'unités engagées peut être important, le moteur réseau est généralement plus
lourd : gestion de la perte d'information, de la perte de connexion et des temps de latence
importants,...
En général, comme dans le cas de Warcraft3, le moteur réseau repose sur une
architecture distribuée. Chaque client calcule les actions de ses propres unités et envoie
le résultat aux autres joueurs. Toutefois, ce système favorise la triche online et de
nombreux « hack » existent sur Internet et permettent de voir l'ensemble de la carte par
exemple (« map-hack ») ou de disposer de ressources illimitées (« money-hack »).
Enfin, si l'un des joueurs possède une connection de particulièrement mauvaise
qualité, ou que son ordinateur n'est pas assez puissant pour calculer l'affichage et les
déplacements des unités, cela pénalise tous les joueurs car la partie est mise en pause, le
temps que le client en difficulté récupère la connexion ou termine ses calculs.
c) MMORPG : Massively Multiplayer Online Role Playing Game
Introduction :
Née dans les années 90/95, cette catégorie de jeu a vu son catalogue s'étoffer
rapidement. En effet, pour les éditeurs, ce type de jeu est une véritable aubaine. Plutôt
que de devoir développer un jeu pendant une ou deux année, puis financer le
développement d'un nouveau produit grâce aux ventes de ce jeu, les éditeurs
développent une première version au bout d'une année. Ils procèdent au test et affinent le
gameplay durant une année grâce à des milliers de beta-testeurs bénévoles. Enfin, ils
sortent le jeu pour le même prix qu'un jeu normal, perçoivent des sommes importantes
d'abonnements de joueurs chaque mois, et peuvent continuer à améliorer leur produit tout
en finançant le développement de nouveaux jeux.
Car, outre le jeu à acheter, vous aurez à vous acquitter d'un abonnement mensuel
pour accéder aux serveurs officiels et pouvoir profiter de votre nouvel achat. Le monde
des MMORPG est un monde persistant (le monde continue à évoluer même si vous n'êtes
pas connecté). Dans les RPG en ligne, l'union fait la force et divers guildes et clans se
montent, avec chacune leurs valeurs et objectifs propres.
Qu'est-ce qu'un MMORPG ?
–
Massively Multiplayer Online Role Playing Game
–
Jeux de Rôle Online Massivement Multi-joueurs
Le MMORPG plonge un personnage créé de toute pièce par le joueur dans un
univers bien défini. Des centaines, voir des milliers de personnanges-joueurs, mènent
simultanément leur vie plus ou moins agitée dans un monde persistant au milieu de
personnages, de monstres et de lieux qui constituent le monde ainsi que son ambiance et
contexte.
Tous les MMORPG (ou presque) demande des notions de rôle-play, afin que les
joueurs incarne leur personnage. Il s'agit d'interpréter un rôle avec les autres joueurs de
façon à créer un univers plus réaliste (un "role player" ne parle plus de son PC qui rame
mais se plaindra sans nul doute de son armure qui commence à rouiller). Cet engagement
de la part des joueurs facilitera le contact entre inconnus ainsi que la création de clans ou
de guildes clamant plus ou moins fort leurs idéaux. On verra alors l'entraide, la formation
de groupe pour les missions difficiles, l'apparition de mariage entre joueurs, des fêtes,
etc...
Généralement un MMORPG est constitué de plusieurs canaux de dialogue (chat) :
un général, un pour l'échange ou la vente d'objets, un pour chaque clan ou guildes, un
pour
le
groupe
auquel
appartient
actuellement
le
joueur,
un
pour
l'assistance/modérateurs, un pour le role-play et bien d'autres suivant le jeu dans lequel
nous évoluons. Le contact entre joueur devient plus facile et agréable même, les
débutants osent d'avantage s'exprimer...
Les univers de jeu :
Il existe plusieurs types d'univers persistants (statics en anglais) :
– médiéval fantastique : peuplé de dragons, orques, géants, nains, sorciers, mages,
guerriers et voleurs où les guerres font souvent rage n'importe quand et pour n'importe
quoi.
– historique : époque du passé déterminé dans un pays ou une ville lequels il est
possible de faire évoluer un personnage.
– réaliste : orienté vers la gestion comportementale du personnage et de l'interaction
avec les autres joueurs.
– futuriste : basé sur l'électronique comme cyberpunk
– space opera : orné de combat spaciaux et de voyage interstellaire
– Parfois on peut trouver un MMORPG qui fait une combinaison entre deux types.
La vie et les animations des MMORPG :
Chaque monde connait des manifestations qui ne font pas véritablement partie du jeu de
base. Ses évènements ne seront donc vécus que par un nombre limité de joueurs
présents à ce moment là. Ses évènements sont un intermédiaire pour renforcer
l'ambiance ou le contexte de l'univers. Suivant le monde, ces évènements peuvent
s'avérer être une invasion d'un peuple voisin ou lointain, un personnage semant la
discorde au sein d'un village, le roi qui se marie, la femme du président qui est kidnappé
lors d'un meeting, un renversement politique ou une rebellion... Tout dépend donc du
monde et des idées qui fusent chez les développeurs ou les animateurs.
Votre avatar plongé dans un monde persistant :
Une fois l'univers intégré, il faut désormais faire évoluer votre personnage. Il faut bien
comprendre que l'expérience du personnage lui permettra d'entrer toujours plus en
profondeur dans le jeu. Les missions et les quêtes seront d'autant plus intéressantes
qu'elles seront difficiles (pas tout le temps c'est vrai, mais dans l'absolu, si !). Alors à vous
de gagner de l'argent, marchander, voyager, coordonner, se débarrasser de ses ennemis,
trouver des trésors, voler, prier, corrompre, tricher, discuter, remplir vos poches de
n'importe quoi trouver sur la route afin de le revendre, faire des alliances tactiques ou
sympathiques, intégrer un clan, revendiquer, juger, guerroyer, mourrir ou tout ce qui vous
fera plaisir et que le jeu vous permet de faire...
Les moteurs réseau employés :
Les contraintes techniques pour les MMORPG concernent en priorité le nombre
simultané de clients que peuvent accepter les serveurs de jeux. Le temps de réponse
n'est pas une priorité. Les clients sont limités au simple affichage du jeu, tous les calculs
sont effectués du coté des serveurs afin de minimiser la triche. La quantité d'information
que doit traiter et envoyer le serveur est impressionante et l'utilisation du multicast est tout
à fait envisageable.
Par contre, dans ce type de jeu, puisque l'environnement est de dimensions
colossales, et que les déplacements des joueurs sont assez lents, le zonage des joueurs
est utilisés au maximum : le serveur envoie les mêmes informations à tous les joueurs
d'une zone et ces informations ne couvrent que les évènements se déroulant dans cette
zone.
II.Les modes de diffusion de TCP/IP
Le multicast est un des trois modes de diffusion de TCP/IP, les deux autres sont
– l'unicast
– le broadcast
1. Diffusion unicast
L'unicast est le type de diffusion le plus utilisé en réseau local. C'est aussi le seul mode de
diffusion que propose Internet. En unicast, chaque flux a un unique émetteur ainsi qu'un
seul récepteur.
Emetteur
Message
Destinataire
2. Diffusion broadcast
Le broadcast, quand à lui, permet à un emetteur de diffuser un message à l'ensemble
d'un réseau.
Réseau A1
Emetteur
ge
ssa
e
M
M
es
s
ag
e
Me
ssa
ge
Mes
sage
Réseau A1
Les messages diffusés en broadcast ne sont pas relayés par les routeurs, pour des
raisons de sécurité. En effet, dans le cas contraire, n'importe qui pourrait saturer un
réseau entier. Les messages de broadcast ne sont donc diffusés qu'à l'intérieur du sous
réseau à partir duquel il a été émis, et y est confiné.
3. Diffusion multicast
La diffusion multicast ressemble au broadcast. Un émetteur unique peut envoyer un
message vers N destinatires. Cependant, le multicast est plus fin que le broadcast car il
met en oeuvre une notion de groupe, lequel est à priori complètement différent de
l'ensemble des ordinateurs d'un réseau (cas du broadcast).
Groupe A
Destinataire
Emetteur
Message
Destinataire
Destinataire
Chaque ordinateur d'un réseau a la possibilité de demander à faire partie d'un groupe
multicast, définit par son adresse IP. Dans l'exemple ci-dessus, trois destinaires
appartiennent au groupe A. Il reçoivent donc tous le flux émis à destination de ce groupe.
Contrairement au broadcast, les trois distinataires n'ont pas à être dans un sous-réseau
identique car le flux multicast est relayé par les routeurs.
Un autre avantage du mutlicast par rapport au broadcast est qu'avec ce dernier, toutes les
stations sont obligée de recevoir ce qu'un emetteur envoi en broadcast, même s'ils ne
sont pas interessés, alors qu'avec le multicast, si une station n'est plus interessé par un
flux multicast qu'elle reçoit, elle peut se désabonner du groupe associé à ce flux.
Enfin, dans le cas de diffusion d'un flux multimédia, l'utilisation du multicast se justifie en
terme de bande passante. Par exemple, en unicast, une radio MP3 doit envoyer autant de
flux qu'il existe d'auditeurs. En admettant que le débit soit de 32 Kbits par seconde
(qualité moyenne), un abonné ADSL en France – qui dispose donc à priori de 128KBps
en émission – ne peut diffuser qu'à quatre stations réceptrices au maximum: 128 / 32 = 4.
Si cette même personne décidait de diffuser en mutlicast, sa faible bande passante
n'influerait pas sur le nombre d'auditeurs simultanés possible car un seul flux (à
destination du groupe d'auditeurs) est envoyé par la radio. La radio pourrait même être
reglée pour diffuser un flux de qualité 64 Kbps voire même 128KBps.
4. Gestion des groupes multicast
Puisque chaque station d'un réseau TCP/IP a le choix de faire partie ou non d'un groupe
multicast, plusieurs protocoles ont été mis au point pour que celles-ci puissent notifier au
réseau leur appartenance à un ou plusieurs groupes.
5. Echelle LAN (Local Area Network)
A l'intérieur d'un réseau local, la diffusion en multicast nécessite un (ou plusieurs) routeurs
dont l'interface réseau est configurée en multicast. C'est à ce routeur que chaque station
enverra ses requête d'abonnement/désabonnement aux groupes multicast. Le protocole
mis en oeuvre est Internet Group Management Protocol: IGMP.
Internet
Routeur
T r a f i c
Station
Station
I G M P
Station
Station
Dans un LAN, chaque station fait automatiquement partie du groupe 224.0.0.1. De même,
chaque routeur est dans le groupe 224.0.0.2. Dans le cas ou plusieurs routeurs multicast
sont disponible dans un LAN, alors l'un d'entre eux est élu routeur désigné (Designated
Router).
Pour connaître l'état d'appartenance de chaque station de son LAN, le routeur envoie
périodiquement une sollicitation aveugle, à destination du groupe 221.0.0.1 (environ
toutes les 60 ou 120 secondes): « Quels sont les groupes auxquels vous désirez vous
abonner ? ».
Chaque station répond alors avec un IGMP Report, contenant les adresses des groupes
auquels il appartient. Si le routeur ne reçoit aucune demande pour un groupe dont
l'émetteur est sur Internet, alors il arrête la rediffusion de ce flux à l'intérieur du réseau
local.
Dans la version 2 du protocol IGMP, les stations réceptrices voulant se désabonner d'un
groupe ont la possibilité d'emmetre une requête IGMP Leave à destination du routeur. Le
temps de réponse est donc amélioré puisqu'avec IGMP v1, elle aurait reçu le flux jusqu'à
ce que le routeur fasse sa demande IGMP périodique.
6. Echelle Internet
IGMP est suffisant pour gérer le trafic multicast au sein d'un LAN, mais il n'est pas
utilisable pour router les fluxs multicast à travers Internet. Pour diffuser ou recevoir des
flux mutlicast sur Internet, il convient d'utiliser des protocoles de routage.
Deux modes de fonctionnement existent pour les protocoles de routage multicast:
–
le mode dense: DVMRP, PIM-DM, ...
–
le mode clairsemé: PIM-SM, ...
En mode dense, un station qui ne se manifeste pas est considérée comme une station qui
désire recevoir. Ce mode est très utile dans les cas ou la plupart des stations désirent
effectivement recevoir les flux multicast. Dans ce cas, l'utilisation d'un protocole de
routage en mode clairsemé serait une erreur car le trafic généré par le protocole sera non
négligeable, puisque toutes les stations enverront sans cesse des requête d'abonnement
vers les routeurs.
Le mode clairsemé est utilisé dans le cas inverse. Chaque station qui désire recevoir un
flux doit s'abonner explicitement auprès de son routeur.Un des protocole les plus utilisé
est DVMRP à cause de sa facilité de configuration, cependant PIM-SM est de plus en plus
utilisé car bien qu'il soit construit pour gèrer le trafic multicast, il s'appuie sur la diffusion
unicast pour échanger les information de routage entre les routeurs mutlicast. Il est très
fiable et très robuste.
III.Intégration du multicast aux moteurs réseau de jeux vidéo.
Dans le cadre des jeux de FPS ou de RTS utilisant une architecture centralisée,
l'utilisation du multicast n'est pas réellement avantageuse, car le nombre de clients
connecté est trop faible pour obtenir un gain de bande passante satisfaisant et d'un point
de vue de la sécurité, on doit toujours faire appel à un serveur.
Toutefois, dans le cadre d'une architecture distribuée, le multicast est avantageux à
condition que des protocoles de sécurité robustes soient mis en place.
Pour les MMORPG, le gain de bande passante peut être très important : on peut
imaginer de regrouper tous les joueurs d'une zone sous la même adresse multicast. Le
serveur de cette zone n'aurait qu'a envoyer toutes les informations à cette adresse
multicast, économisant de la bande passante et la gestion de la connexion avec chaque
client.
De plus, on pourrait regrouper les services de chat de chaque groupe d'amis ou de
guilde sous une même ip multicast. Bien que les débits utilisés par le chat ne soient pas
trop important, toute économie de bande passante n'est pas à negliger.
Exemple de jeu en réseau employant le multicast : Minimaze :
Chaque joueur envoie aux autres ses déplacements et calcule la trajectoire de ses
projectiles. Le serveur de jeu ne fait qu'initialiser la partie.
Le client affiche l'environnement en VRML.
http://www-sop.inria.fr/rodeo/MiMaze/
IV.Lexique :
Lag
Bien connu par les joueurs réseaux, le lag désigne un temps d'attente entre la réception
et l'envoi de données. Ainsi, les parties par LAN ou Internet se voient interrompues
pendant une durée plus ou moins longue. Bref, le lag est l'ennemi du joueur online.
Interpolation
Technique consistant à calculer à l'aide de formules mathématiques des informations
manquantes à partir de valeurs connues. Par exemple, l'interpolation de pixels rajoute des
points dans une image, mais ne rajoute pas de détails. C'est souvent un moyen de gonfler
artificiellement la résolution d'une image.
FPS (Frame Per Second)
Les FPS désignent le nombre d'images par secondes distillées par un jeu ou une
animation quelconque. Si pour un film, on se contente de 25 FPS pour obtenir un résultat
fluide, un jeu nécessitera une moyenne bien supérieure.
FPS (First Person Shooter)
A ne pas confondre avec l'autre FPS, ce FPS-ci désigne les jeux de tir à la première
personne plus communément appelés Quakelikes ou Doomlikes.
Map
Le terme "map", introduit par les shoots 3D, désigne une aire de jeu. Pour les parties en
solo, il faut parfois plusieurs maps pour constituer un seul niveau. En ce qui concerne le
mode multi joueur, une map représente tout simplement une arène. De plus en plus de
jeux utilisant des moteurs 3D, le terme s'est peu à peu démocratisé.
MMORPG (Massively Multiplayer Online Role-Playing Game)
En bon français : "Jeu de Rôle en Ligne Massivement Multi-Joueurs". Type de jeu,
généralement proche du jeu de rôle, ayant pour champs d'action internet et permettant à
de nombreux joueurs (plusieurs milliers) d'évoluer simultanément dans un univers
imaginaire. Chacun peut endosser le rôle d'un personnage qui interagit avec les autres.
"Dark Age of Camelot", édité par Wanadoo, a été le premier MMORPG a rencontrer un
véritable succès commercial en France.
Ping
Le ping, autre grand ami/ennemi du joueur online, désigne le temps de réponse (en
millisecondes) d'un serveur vers la machine d'où part la requête. Attention, plus le ping est
petit, meilleure sera la connexion, qu'on ne s'y trompe pas.
RTS (Real Time Strategy)
RTS est la version anglaise/américaine de STR, qui désigne donc les jeux de type
stratégie en temps réel (Warcraft, Command & Conquer, etc.)