Quote:
Pourquoi le problème du "netcode" [code réseau] existe, et pourquoi cela ne peut pas être corrigé
J’ai travaillé pendant plusieurs années en tant que programmeur système dans un datacenter qui abritait plusieurs MMO. Je peux peut-être offrir quelques perspectives sur ce problème.
Le problème dont tout le monde se plaint provient d’une décision prise par SE au niveau de la conception architecturale, durant les premières étapes du développement du jeu. La décision prise fut de concevoir le jeu d’une manière qui donne au serveur, et non pas au client, l’autorité de décider de « l’état du jeu » [live-state en anglais, c’est-à-dire (je suppose) la situation à chaque instant, en temps réel, des différents éléments du jeu comme les ennemis, les casts, etc.] Que ce soit dans le passé ou actuellement, c’est contradictoire avec une grande majorité des jeux en ligne sur le marché. J’explique ci-dessous les différentes méthodologies.
Client Live-State [état du jeu décidé par le client] :
La plupart des actions du jeu sont dirigées par le client. Cependant, les entités et l’environnement sont contrôlés par le serveur. Lorsque l’on effectue la commande de sauter, le client envoie une commande au serveur, qui la prend en compte, et renvoie au client la réponse de sauter. Une fois la communication effectuée, le personnage saute à l’écran. Disons par exemple que le joueur est en train de combattre un monstre. Il attaque le monstre mais sa connection réseau est de mauvaise qualité. Voici ce qui se produit : il envoie la commande d’attaquer. Il y a un délai à l’envoi de la commande au serveur. Le monstre continue de l’attaquer (avec succès), puisqu’il est contrôlé par le serveur. Lorsque la connection du joueur est rétablie, ce dernier effectue enfin son attaque. Ceci résulte en l’expérience suivante pour le joueur: « J’envoie des commandes mais elles sont décalées sur mon écran ». Cependant, si un monstre lance un « cercle d’AoE », il sera en temps réel sur le client puisque le serveur envoie la commande : « Monstre A fait une attaque AoE à tel et tel moment ». Lorsque le client reçoit cette information, il se synchronise avec le moment spécifié par le serveur, donc l’AoE peut apparaitre en retard, mais la réaction du joueur sera en temps réel puisque l’état du jeu est décidé par le client. Donc si le joueur sort de l’AoE sur son client, lorsque celle-ci est lancée, le client dira au serveur « L’AoE fut lancée, mais le joueur était hors de portée » et donc finalement, même si ce joueur a un peu de lag, il peut éviter l’AoE.
Server Live-State [état du jeu décidé par le serveur] :
La plupart des actions sont dirigées par le serveur. Lorsque l’on effectue la commande de sauter, le personnage saute à l’écran, mais dans l’état [du jeu] du serveur, le personnage n’a pas sauté tant qu’il n’a pas reçu la commande de sauter. Donc si le joueur a du lag, il semble qu’il ait sauté sur son écran, mais pour le serveur, il est encore immobile. Cela donne au joueur une fausse sensation de ce qui se passe dans le jeu. En quoi cela est différent du modèle où le client décide de l’état du jeu [Client Live-State] ? Eh bien, pour des choses telles que sauter ce n’est pas très différent, mais lorsqu’on considère le combat et des actions très sensible au temps (au timing), c’est une toute autre affaire. Disons, par exemple, que le monstre A lance une AoE. L’AoE est active sur le serveur mais le joueur a du lag et n’a pas encore reçu l’information (le monstre semble immobile). Dès qu’il reçoit l’information, le monstre semble être en train de faire son cast et le cercle de l’AoE apparait. La différence est que le joueur est désynchronisé du serveur, et le serveur décide de tout, donc même si le joueur sort de l’AoE, si son client n’envoie pas l’information au serveur avant que l’AoE ne soit lancée, il est touché par celle-ci. Et cela, chers amis, est la raison pour laquelle vous êtes tous morts sur les attaques de Titan (par exemple) alors que vous vous voyiez hors de danger sur votre écran.
Les raisons pour lesquelles SE a pu choisir le modèle où le serveur décide de l’état du jeu (Server Live-State) :
— Empêche des bugs de désynchronisation (au niveau du serveur)
— Empêche des bugs potentiels de triche ["duping" en anglais - je ne suis pas sûr de ce terme]
— Empêche (en théorie) la téléportation et autres commandes interdites au niveau du client d’être acceptées
— Si le joueur a une bonne connection au serveur [faible latence], presque aucun délai n’est observé par le joueur
Les inconvénients du modèle Server Live-State :
— Une mauvaise connection entraine des conditions quasi-injouables, particulièrement les conditions qui demande un temps de réaction rapide
— L’infrastructure serveur est plus coûteuse (les serveurs doivent effectuer beaucoup plus de traitement de données)
Auparavant, les Server Live-State étaient extrêmement rares parce que les connections étaient encore mauvaises / à faible bande passante.
Cela peut-il être changé ?
Réponse courte: Non.
Réponse longue: Techniquement, oui, mais cela extrêmement coûteux et demanderait beaucoup de temps. SE y perdrait des millions et cela prendrait plusieurs mois, voire plus d’un an, pour être réalisé.
J’espère avoir pu expliquer les choses suffisamment bien pour que la plupart des gens puissent comprendre. Dites-moi si vous voulez des clarifications sur quoi que ce soit.