> Le Site du Zéro - Informatique > Cours > Tutoriels > Jeux Vidéo > HL & ses mods > Optimiser le netcode de Source > Lecture du tutoriel

Optimiser le netcode de Source

Par

e-t172

Mise à jour : 21/04/2009

105 visites depuis 7 jours, classé 565/795

Le sujet pour le moins houleux du Netcode des FPS fourmille d'idées reçues et autres affirmations gratuites. Ainsi, on trouve souvent sur les forums des recommandations de ce style : "Règle ton cl_updaterate / cl_cmdrate à XX et tu lagueras 10 fois moins / ton ping descendra de 10 ms / tu seras intouchable", alors que leurs auteurs n'ont en réalité effectué que des tests très subjectifs, souvent dénués de toute méthodologie, alors qu'eux-mêmes n'ont souvent aucune idée de ce dont ils parlent.

Dans le but de changer cet état des choses, j'ai réalisé une étude poussée et méthodique du comportement de la partie réseau de Source. Je livre dans ce tutoriel le fruit de mon travail, c'est-à-dire la réponse à la question "Quelle est la configuration optimale ?" que se posent beaucoup de joueurs.

Ce tutoriel est très orienté pratique : il vous expliquera uniquement comment obtenir la meilleure configuration possible pour votre jeu. Si vous souhaitez plus d'informations théoriques (si vous avez envie de comprendre comment tout ce shmilblick fonctionne) je vous invite à vous reporter à mon document original.

Retour en haut

Sommaire du tutoriel :

La console de Source et les CVARs
Latence, choke, loss et fidélité de la simulation
Le netgraph
La CVAR "rate"
La CVAR "cl_interp"
Les CVARs "cl_updaterate" et "cl_cmdrate"
Q.C.M.

Retour en haut

La console de Source et les CVARs

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.

Comment accède-t-on à cette console ?

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.

Le paramètre "-dev" n'est pas obligatoire pour obtenir la console. Il demande juste à cette dernière de donner plus d'informations. En réalité, on n'en a pas besoin pour la suite de ce tuto ; si vous n'en voyez pas d'utilité, vous pouvez le retirer.

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.

"Au démarrage du jeu" signifie que ces fichiers sont exécutés au moment où les menus du jeu sont affichés, et non lorsque vous lancez ou rejoignez une partie.

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")

Cet ordre est important, car si une directive de configuration est présente dans deux fichiers de démarrage, c'est celui qui a été exécuté en dernier qui l'emporte sur l'autre.

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".

Vous pouvez obtenir une liste complète des commandes disponibles en utilisant la commande cmdlist.

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

] cl_interp

"cl_interp" = "0.010000" ( def. "0.1" ) min. 0.010000 max. 1.000000

 client

 - Interpolate object positions starting this many seconds in past

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.

Les CVARs décrites dans ce tuto sont toutes assez bien documentées par le moteur, mais si vous vous aventurez en dehors des sentiers battus, vous risquez d'obtenir moins d'explications.

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

] cl_interp 0.1

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

Vous pouvez obtenir une liste complète des CVARs disponibles en utilisant la commande cvarlist.

Retour en haut

Latence, choke, loss et fidélité de la simulation

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.

La latence affichée dans le tableau des scores ou dans le netgraph (que nous verrons plus loin) est un chiffre peu fiable, qui représente plus un indice de la qualité du jeu que la latence proprement dite. Qui plus est, ce chiffre peut se révéler totalement faux avec certaines configurations. Pour obtenir le "vrai" ping réseau, vous devez utiliser la commande ping de Windows.

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.

Malgré ce procédé, le ping a une influence importante sur la qualité du jeu. De plus, le lag compensation, de par sa nature même, induit des effets secondaires nuisant à la crédibilité de la simulation (par exemple, lorsque vous vous faites tuer alors que vous veniez de vous mettre à couvert).

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.

Seule la mauvaise qualité de votre connexion au serveur peut causer des problèmes de loss. Si vous avez du loss sur tous les serveurs sur lesquels vous jouez, contactez votre FAI.

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.

Si vous avez un framerate de 85 images par seconde, et que votre updaterate réel est de 20, vous n'aurez qu'une mise à jour toutes les 4,25 images. Pour éviter les saccades, le jeu dispose d'un procédé appelé interpolation, qui "invente" les positions des entités (joueurs, objets) entre deux mises à jour. Néanmoins, ces points sont "inventés" et nuisent donc à la fidélité de la simulation.

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.

La fidélité (ou précision) de la simulation est aussi appelée "touchabilité" par beaucoup de joueurs (par exemple, "je touche que dalle aujourd'hui").

Retour en haut

Le netgraph

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).

Le netgraph comporte 3 modes : 1, 2 et 3. Cependant, seul le 3 nous sera utile.

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

Image utilisateur

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.

Retour en haut

La CVAR "rate"

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

Max bytes/sec the host can receive data

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 !

La CVAR rate n'optimise pas le netcode, elle le limite.

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.

Pendant longtemps, la valeur maximale du rate était de 81920, soit 80 ko/s, ce qui pouvait provoquer du choke sur les serveurs avec un grand nombre de joueurs ; la mise à jour du moteur Source du 12 juin 2007 a relevé cette limite et élimine ainsi ce problème.

Plus la valeur de cette CVAR sera basse, plus les risques de choke seront élevés.

Retour en haut

La CVAR "cl_interp"

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.

Le bon réglage de l'interpolation dépend de la qualité du serveur sur lequel vous jouez, et de la qualité de la configuration du Netcode des autres joueurs présents.

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.

Désactiver entièrement l'interpolation (cl_interpolate 0) est une mauvaise idée, car le jeu devient alors très sensible aux fluctuations du réseau, ce qui provoque dans beaucoup de cas des saccades permanentes et un jeu inconfortable.

Plus l'interpolation est élevée, plus l'intensité du lag compensation est élevée, d'où des effets secondaires plus marqués dans le jeu.

Retour en haut

Les CVARs "cl_updaterate" et "cl_cmdrate"

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

Ces CVARs ne contrôlent pas, comme beaucoup le pensent, l'updaterate ou le cmdrate réel. Elles ne font que poser des limites maximales à ces deux valeurs. L'updaterate réel et le cmdrate réel dépendent également d'autres facteurs.

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".

Plus les valeurs de ces CVARs sont élevées, plus la bande passante consommée est élevée, ce qui augmente les risques de choke.

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).

Les valeurs optimales varient selon les serveurs, voire selon le nombre de joueurs présents sur le serveur. D'une manière générale, être obligé de baisser son updaterate/cmdrate à cause de choke provoqué par le serveur, alors que votre connexion peut supporter plus, témoigne d'un serveur de mauvaise qualité, ou mal configuré.

Retour en haut

En conclusion, j'ose espérer que ce tutoriel vous aura permis de mieux configurer votre jeu, et par là même d'exploiter au mieux votre matériel.

Ce tutoriel est une version épurée et plus accessible (conçue pour les Zéros

) de mon document théorique. Si vous vous posez des questions, que vous souhaitez en savoir plus, ou que vous cherchez à optimiser un serveur de jeu, je ne peux que vous conseiller la lecture du document original.

Retour en haut

Retour en haut

22 commentaires pour "Optimiser le netcode de Source"

Note moyenne : 3.63 / 4 (8 votes)

Pseudo	Commentaire
Viper95	# Posté le 25/01/2009 à 19:50:15
	C'est un bon tuto, mais il n'y a un truc que je n'ai pas trop aimé. Le chiffre super elevé pour les rates ne sert à rien car au dessus de 30000 ça ne change rien. Les vrai rates sont (à taper dans la console) : rate 30000 cl_cmdrate 101 cl_updaterate 101 Et la vous toucherez et vous prendrez bien
Sh4d	# Posté le 26/02/2009 à 15:52:05
Ville : Montpellier Pays : France métropolitaine Études : Université de Perpignan (UPVD)	Très bon tuto, tout devient plus clair sur ce sujet. En effet sur les serveurs CSS on entend souvent de tout et n'importe quoi là dessus... Je testerai sur ma machine et je te dirais. Viper95 je trouve ta remarque un peu déplacée... En effet tu dis que la CVAR rate ne sert à rien au dessus de 30000 mais c'est une affirmation un peu gratuite... Je pense que e-t172 après l'étude qu'il a réalisé ne doit pas raconter que des bêtises... Quand à la configuration que tu donnes: cl_cmdrate 101 cl_updaterate 101 rate 30000 C'est la combinaison classique que n'importe quel joueur pourrait te donner. T'as la chance d'avoir une explication un peu plus raffiné alors profites en . Sur ce A+ et GG pour le travail! Projet Fast-War
Sergeswi	# Posté le 10/09/2009 à 11:50:28
Fan obligé de zingwai.	Faudrait penser à changer l'avancement du tuto, non ? Je n'ai que survolé le tutoriel mais il semble très intéressant à vue de nez ! Les calculs en binaire Secret (cliquez pour afficher) Se tutarielle à èté zcaurigeai
Shex_	# Posté le 14/03/2011 à 18:53:07
1 ou 0 là est la question ! Études : Université Paul Sabatier Toulouse	Merci baucoup je cherche cela depuis un moment. Gardez à l'esprit que copier coller du code ne vous apportera rien alors que de comprendre et d'y mettre du votre vous amènera à une certaine fierté même pour un simple "Hello world". Etre débutant ne signifie pas être mauvais
sniperstreak	# Posté le 24/08/2011 à 09:46:29
Avis : Très bon Ville : Nice Pays : France métropolitaine	Je mets 20, très bon tutoriel expliqué de 0 à Z. Génial. Ce n'est pas une question de possibilités mais toujours une question de volonté