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] Barakat SA, Douala, Cameroun
