Slt,
effectivement intéressant, je n'avais pas connaissance de la notion de
checksum .
Le 13/11/2014 12:26, Yannick Youalé a écrit :
Salut à tous !
Je me suis ces derniers temps posé la question de savoir comment faire
un jeu en réseau, dont les protagonistes se trouveraient de part et
d'autre de la terre, tout en s'assurant que les actions sont synchrone
entre les diverses installations du jeu.
Hé bien, j'ai trouvé au moins un début de solution dans cet article du
site gamedev que je partage avec vous ci-dessous.
Début de l'article
Gérer le réseau dans un jeu de stratégie : première approche
Posted in __Link Jeux vidéo, __Link Réflexions the October 15th, 2008
__Link Comments (1)
En voyant des captures d'écran de StarCraft II (petit bijou en
perspective, puisse t-il lui aussi durer 10 ans), je me suis demandé
comment pouvait bien être géré le réseau dans une partie multijoueur.
J'ai eu l'occasion d'aborder la partie réseau et multijoueur d'un
projet de jeu ces derniers mois, d'où mon intérêt pour la question.
Et me voilà donc à la recherche de documentation sur ce sujet.
__h2 Age of Synchronization
La première doc que j'ai trouvé a aussi été la plus utile. C'est une
sorte de post-portem sur l'aspect réseau d'Age of Empires (I & II),
__Link écrit par Paul Bettner et Mark Terrano d'Ensemble Studio pour
Gamasutra.
http://www.gamasutra.com/features/20010322/terrano_pfv.htm
D'accord, le document à presque 8 ans, mais il est toujours d'actualité.
Les mots clé ici sont synchronisation et simulation déterministe.
Le principe est de ne pas envoyer les informations sur les entités du
jeu, mais uniquement les actions des joueurs. Le but avoué est bien
sûr de préserver la bande passante, permettant d'avoir virtuellement
autant d'unités qu'on le veut en jeu.
Puisqu'on envoi que les commandes effectuées par les joueurs ( créer
unité , déplacer unité , attaquer b timent , ), il faut que ces
actions mènent systématiquement au même résultat sur les autres
machines. C'est ce qu'on appelle une simulation déterministe.
Effectuer les même actions mèneront strictement au même résultat.
Cela nécessite de tout synchroniser, y compris les nombre aléatoires
(un comble pour des nombres soi disant imprévisibles !).
Mais à cause des problèmes réseaux, notamment les temps de latence et
paquets perdus, inhérents à l'internet, il faut toujours vérifier que
les clients sont bien synchronisés.
Pour cela on fait correspondre un checksum à chaque état et élément du
jeu et on le compare régulièrement avec le checksum du joueur serveur
. Si les checksums sont différents, c'est que l'on n'est plus
synchronisés.
C'est ce qui arrive dans Age of Empires lorsque vous voyez une petite
tortue à côté d'un nom dans la liste des joueurs et leurs scores.
Le pari fait par __Link le projet open source Spring est d'ailleurs
incroyable : la partie est mise en pause lorsque ça arrive. Carrément
stoppée. Et les clients s'envoient alors leurs informations pour se
resynchroniser, et une fois que tout est bon, le jeu reprend.
On comprend qu'il vaut mieux n'envoyer qu'un nombre restreint de
données, d'où l'intérêt d'avoir plusieurs checksums, un pour chaque
élément du jeu. Ainsi on évite d'envoyer des données inutiles (par
exemple des éléments du jeu qui n'ont pas changés depuis longtemps et
reste donc valables malgré la désynchronisation, comme les b timents
construits en début de partie).
En plus, cela limite naturellement la triche, contrairement à ce que
l'on pourrait croire. En effet, un client qui triche aura un checksum
différent et sera vu comme désynchronisé, ce qui arrêtera toute la
partie (ou annulera l'effet de sa triche puisque son client sera
synchronisé aux autres).
C'est une méthode vraiment intéressante et très différente de l'aspect
client/serveur habituel. Peut être que j'essaierai de me pencher sur
la pratique un de ces quatre, dans ce cas je ne manquerai pas d'en
faire article détaillé.
Fin de l'article
Intéressant n'est-ce pas ?
Yannick Daniel Youalé
tél: (00 237) 99 73 89 27
e-mail: [email protected]
<mailto:[email protected]>
Barakat SA, Douala, Cameroun
--
LavaChri
