Optimiser le netcode de Source

La console

Le moteur Source, comme la plupart des FPS, permet d'utiliser une interface pour envoyer des commandes, ou modifier les paramètres du moteur de jeu. Cette interface est appelée console. Pour faire simple, il s'agit d'un bloc dans lequel défile du texte vous donnant des indications sur l'état actuel du moteur. En dessous de ce bloc se trouve un champ de texte permettant d'entrer des commandes. Ceux qui ont déjà vu une invite de commandes sous Windows ou un terminal Linux sauront de quoi je parle ; pour les autres, vous comprendrez quand vous la verrez.



Il existe plusieurs moyens de l'afficher : je vais ici vous présenter celui que j'utilise ; bien évidemment, si vous utilisez un autre moyen, ne changez pas vos habitudes pour moi.

• Allez dans la section "Jeux" de Steam.
• Faites un clic droit sur le jeu concerné (par exemple, Counter-Strike Source).
• Cliquez sur "Propriétés".
• Cliquez sur "Définir les options de lancement..."
• Entrez "-console -dev" (sans les guillemets bien entendu), puis validez.

Ensuite, pour accéder à la console, il vous suffira d'appuyer sur la touche "echap" lorsque vous jouez, et vous aurez alors la console sous les yeux.

Les fichiers de démarrage

Lorsque vous démarrez votre jeu, celui-ci doit définir un certain nombre d'options, telles que votre nom dans le jeu, votre configuration des touches, la sensibilité de votre souris, etc. Ces options sont en réalité des commandes console, qui sont stockées dans des fichiers spécifiques, lesquels sont exécutés au démarrage du jeu.



Tous ces fichiers de démarrage sont situés dans le sous-répertoire "cfg" du répertoire où est stocké le jeu (par exemple : C:\program Files\Steam\steamapps\e-t172\counter-strike source\cstrike\cfg). Il y a 4 fichiers lancés au démarrage, les voici dans l'ordre dans lequel ils sont exécutés :

• userconfig.cfg
• config.cfg : on ne modifiera jamais ce fichier, car il est effacé et réécrit par le moteur à chaque fois que vous modifiez les paramètres du jeu via le menu Options.
• valve.rc
• autoexec.cfg (lancé par le précédent : en effet, le fichier valve.rc contient la ligne "exec autoexec.cfg")

Ainsi, placer des commandes dans le fichier userconfig.cfg doit être fait avec précaution, car ces commandes risquent d'être écrasées par le fichier config.cfg généré par le moteur. Par conséquent, je vous recommande de placer toutes les commandes que vous souhaitez exécuter au démarrage dans le fichier autoexec.cfg, qui, de cette manière, ne risque pas d'être "écrasé".

Commandes et CVARs

Il y a deux types d'instructions que vous pouvez donner à la console (que ce soit en jeu, ou dans un fichier de démarrage) : les commandes et les CVARs.

Les commandes

Une commande est un simple mot qui demande au moteur d'effectuer une action précise. Elle prend parfois des paramètres. Nous n'utiliserons aucune commande dans ce tuto. Exemple : "echo Texte à afficher dans la console" ou "connect 193.27.10.33:27015" ou encore "retry".

Les CVARs

Une CVAR, pour Configuration VARiable, est comme son nom l'indique, un paramètre que l'on peut modifier.

En entrant simplement le nom de la CVAR dans la console, par exemple : "cl_interp" (que l'on étudiera plus loin dans ce tuto), on obtient des informations intéressantes sur son contenu et son fonctionnement :

Code : Console

Comme vous pouvez le voir, le moteur nous indique plusieurs informations au sujet de cette CVAR, notamment sa valeur actuelle (0.01), sa valeur par défaut (0.1), sa valeur minimale (0.01) et sa valeur maximale (1.0), ainsi qu'une brève description.



Pour définir une CVAR à une certaine valeur, il suffit d'écrire le nom de la CVAR suivi de la valeur qu'on souhaite lui faire prendre, exemple :

Code : Console

Cette fois-ci, la console ne vous répondra rien - ceci est normal.

Lorsque vous jouez en multijoueur sur un FPS, trois types de problèmes peuvent survenir : les problèmes de latence, de choke et de loss. Il faut également veiller à obtenir une simulation (c'est-à-dire un jeu) la plus fidèle possible à celle du serveur.

La latence

La latence, aussi appelée ping, désigne le temps que prend un paquet de données pour passer d'un ordinateur à un autre : dans notre cas, de votre jeu au serveur.



Contrairement à une idée répandue, lorsque vous avez un ping de 200 par exemple et que vous tirez, le tir ne sera pas pris en compte 200 millisecondes plus tard. En effet, le serveur dispose d'algorithmes lui permettant de déterminer à quel moment vous avez réellement tiré, et de "remonter le temps" jusqu'à cet instant, pour revenir à une image de jeu plus proche de celle que vous aviez lorsque vous avez tiré. Ce procédé est appelé lag compensation.



La modification de la configuration du netcode ne peut en aucun cas vous aider à obtenir un meilleur ping, qui ne dépend que de la qualité de votre connexion au serveur.

Le choke

Le choke est un autre problème pouvant survenir au cours du jeu. Avoir du choke signifie que le jeu n'a pas assez de bande passante disponible pour échanger les paquets de données à la fréquence voulue (soit parce que le jeu dispose de trop peu de bande passante, soit parce que les paquets à transmettre sont de tailles trop importantes). En pratique, cela signifie que les paquets arrivent en retard. De plus, si le problème persiste, cela peut provoquer une réaction en chaîne qui allonge encore plus les temps de transmission.

Le choke est en général un phénomène de courte durée (2-3 secondes). Si vous avez du choke en continu, alors vous avez un gros problème, et ce tuto va vous aider à le résoudre.

Le choke peut avoir pour causes :

• Une mauvaise connexion avec le serveur
• Une mauvaise configuration du Netcode du jeu
• Les limites du moteur

Le loss

Le loss est probablement le phénomène le plus simple à comprendre, mais paradoxalement le plus difficile à résoudre : avoir du loss signifie tout simplement que tous les paquets n'arrivent pas à destination ; autrement dit, qu'ils se perdent en chemin ou deviennent corrompus.

Fidélité de la simulation

Le serveur de jeu a le plein contrôle sur ce qui se passe dans la partie ; c'est lui seul qui possède la version la plus fidèle du jeu - on dit qu'il a autorité sur le jeu.

Le client (c'est-à-dire votre jeu) reçoit une "mise à jour" de l'état actuel du jeu à une certaine fréquence, appelée updaterate réel. Plus votre jeu reçoit de mises à jour, plus sa représentation sera fidèle à celle du serveur, donc plus le jeu sera précis.



De la même manière, votre cmdrate réel constitue la fréquence à laquelle vous envoyez les informations sur ce que vous faites au serveur. Là encore, plus cette fréquence est élevée, plus le serveur aura une représentation précise de ce que vous faites.

Pour illustrer ces notions de choke, loss et fidélité, nous allons utiliser un outil très pratique fourni par le moteur Source : le netgraph.

Pour l'activer, il suffit de régler la valeur de la CVAR net_graph à 3 (net_graph 3).



Cela fait apparaître un tas d'informations en bas de votre écran :



Voici comment les interpréter, de gauche à droite, et de haut en bas :

• votre framerate actuel (en images par seconde)
• votre ping (rappel : peu fiable)
• la taille du dernier paquet reçu
• la bande passante consommée en réception (en Ko/s)
• l'updaterate réel (fidélité de la simulation)
• la taille du dernier paquet envoyé
• la bande passante consommée en émission (en Ko/s)
• le cmdrate réel (fidélité de la simulation)
• le loss
• le choke.

Ces informations vous seront très utiles pour diagnostiquer vos problèmes, et pour configurer au mieux le Netcode.

La première CVAR que nous allons étudier, qui est probablement la plus connue des CVARs de contrôle du netcode de Source, est la CVAR "rate". Il s'agit probablement aussi de la CVAR la plus controversée. En effet, beaucoup de personnes se font de fausses idées à son propos.

Pour commencer, voyons la définition qu'en donne le moteur :

Citation : Moteur Source

Traduction : "Débit maximum en octets/seconde auquel le moteur peut recevoir des données".

Beaucoup de gens pensent bien faire en réglant cette CVAR en fonction de la vitesse de leur connexion (56K, ADSL 512, ADSL 8096...). Eh bien NON !



En effet, le seul rôle de cette CVAR est de limiter la bande passante consommée par le jeu ; en aucun cas elle n'optimise le jeu pour une certaine quantité de bande passante disponible.

Forts de cette information, et sachant que nous ne voulons pas limiter la bande passante consommée par le moteur (bien au contraire), il faut donc placer la valeur de la CVAR rate à 1048576, soit la valeur maximale autorisée par le moteur, et correspondant à un débit maximal de 1 Mo/s.

Cette CVAR contrôle l'interpolation, ou plus précisément, la durée pendant laquelle se fera l'interpolation entre deux positions d'une entité.

Pour faire simple, disons que plus la durée d'interpolation est élevée, plus votre décalage avec le serveur sera grand (ce qui, en pratique, équivaut à augmenter son ping), mais moins les déplacements des entités seront saccadés, et vice-versa.



Cependant, dans la plupart des cas, vous devriez pouvoir définir une interpolation de 0,01 s (cl_interp 0.01, le minimum) sans problèmes.

Ces deux CVARs sont, comme leurs noms l'indiquent, directement liées à l'updaterate réel et au cmdrate réel.



En effet, un cl_updaterate de 50 par exemple voudra dire : "ne reçois pas les mises à jour à une fréquence plus élevée que 50".



Cependant, cela augmente également la fidélité de la simulation. Pour trouver les valeurs optimales, il faut donc procéder par tâtonnement : d'abord commencer avec un updaterate et cmdrate de 100, puis les baisser progressivement, jusqu'à obtenir un choke de 0 (souvent, vous pouvez les garder à 100 sans choke).