Bonjour à vous champions de Battlerite !
Mon nom est Daniel “Prog” Fahlström et je suis l’un des programmeurs (Note d’éditeur: aka “Un des développeurs leaders”) travaillant chez Stunlock Studios. Je travaille ici depuis Janvier 2013. Certains d’entre vous se souviennent peut-être de moi comme un des membres actifs de la communauté de Bloodlines Champions à l’époque. Pendant le développement de Battlerite j’ai travaillé sur le développement du gameplay, l’interface utilisateur et aussi d’autres éléments….
Dans ce blog je vais vous parler du fonctionnement des déplacements des champions sur Battlerite (en essayant de ne pas être trop technique) et quels challenges nous ont forcé à adopter certaines solutions.
Nécessités et challenges
Le répondant
Tous les mouvements de Battlerite doivent avoir du répondant, puisque vous avez le contrôle direct du personnage. Tous les délais visuels doivent être évités pour rendre le jeu immersif et garder le gameplay au point. Je pense que nous avons plutôt bien réussi jusqu’à aujourd’hui. Les mouvements dans Battlerite sont tous très répondant et ce, peu importe la latence vis à vis du serveur.
Anti-Cheat
Puisque Battlerite est un jeu compétitif, nous travaillons d’arrache-pied pour bannir la triche de ce dernier. C’est pour cette raison que le serveur est la seule autorité à gérer les actions des joueurs, ce qui signifie que toutes les actions (Mouvement, Compétences lancées, Collisions des projectiles etc.) sont contrôlées par le serveur à 100%.
Cependant cette solution suppose que toutes les informations envoyées depuis un client local soient vérifiées par le serveur (Le client local étant le jeu Battlerite qui est lancé sur votre pc). Le serveur s’assure donc que ces actions soient valides, et il n’enverra que des actions valides aux autres clients.
Latence
Un des challenges majeurs quand on développe un jeu en ligne est la latence.. C’est un facteur-colère commun à plusieurs jeux en ligne, plus particulièrement lié au temps de réponse des commandes.
La latence décale toutes les actions envoyées d’un client vers les autres clients, sauf si elle est prévue ou simulée. Puisque la latence ne peut pas être évitée, nous avons pour coutume de dire “Nous n’enlevons pas la latence, nous décidons seulement de l’endroit où la cacher”.
Dans un monde parfait, tous les joueurs auraient constamment moins de 50 ms avec nos serveurs, mais puisque ce n’est pas le cas, nous avons donc comme nécessité que la solution choisie fonction avec une latence pouvant monter jusqu’à 150 ms.
Voilà donc un rendu visuel de comment marcherait la responsivité des actions avec et sans notre solution. La ligne verte représente dans quelle direction le mouvement est demandé. Evidemment le délai entre le moment où le joueur appuie et le moment où le personnage répond rend le jeu bien plus lent pour le joueur.
Inspiration
Puisque les mouvements de Battlerite reposent sur le classique ZQSD, à l’instar des jeux FPS, nous nous sommes inspiré de la solution utilisée par Valve pour leur jeu Quake. Nous l’avons adaptée à Battlerite, mais le cœur de la solution est le même.
La différence entre Battlerite et des jeux FPS, c’est que Battlerite utilise des projectiles plus lents plutôt que des lignes de projectiles instantanés. Ce qui signifie que dès qu’il y a de la latence (vous vous faites par exemple frapper alors que vous voyez un projectile vous manquer) cela se remarque beaucoup plus vite. Et le fait que ce soit une caméra avec vue de haut augmente cela.
Si vous vous intéressez aux autres solutions que nous utilisons, je vous ai listé plusieurs articles.
So how does it work?
La manière la plus simple de l’expliquer est la suivante; Le client simule un mouvement visuellement, et il envoie toutes les commandes simulées au serveur. Ce qui signifie que le client montre visuellement l’endroit où il pense que le joueur se trouve réellement. Puisque le client et le serveur marchent avec le même systême de calculs, il arrive rarement que ce qui soit demandé au client ne corresponde pas avec ce qui arrive en pratique. Dans ces cas là la simulation est modifiée pour que tout corresponde.
Voilà une autre représentation visuelle d’un personnage en mouvement en situations de très haute latence avec et sans notre solution. Les cercles apparaissant représentent l’hypothétique position du personnage pour le serveur et le client. Rouge pour le serveur et vert pour le client, la ligne verte signifie toujours la direction du personnage.
Quand un mouvement est simulé, le cercle vert est obligatoirement présent. La position pour le serveur est, elle, décalée à cause de la latence.
Problèmes
Cette solution (ou n’importe quelle autre d’ailleurs) ne sera jamais parfaite puisque la latence sera toujours présente. Et comme dit précédemment, les collisions seront plus faciles à gérer avec une vue de dessus.
Voilà un exemple visuel d’une erreur en condition de forte latence. Le cercle rouge est la position de Shifu quand une collision est détectée. Même si cela ne paraît pas vrai sur le client, c’est réel pour le serveur.
C’est un problème que les joueurs associent très souvent à un problème de hitbox mais c’est en fait un problème de latence.
En conclusion, ce genre de problèmes est inévitable. Nous voulons permettre au client de simuler les déplacements, tout en permettant au serveur de garder son autorité sur les positions. Nous savons que c’est un fait frustrant pour les joueurs de Battlerite, et nous sommes constamment en train de chercher de meilleures solutions à ce genre de problèmes afin de vous offrir la meilleure expérience de jeu possible.
Merci d’avoir lu!
Technical Articles
Voici une liste d’articles qui nous a inspiré pour créer et développer les mouvements des champions sur Battlerite.
http://fabiensanglard.net/quake3/network.php
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization