La documentation officielle du serveur dédié CS2 de Valve, hébergée sur le wiki de la Valve Developer Community, offre aux opérateurs un aperçu des décisions d'infrastructure derrière l'un des jeux compétitifs les plus joués de Steam. Publiée lors du lancement du jeu en septembre 2023, elle est rédigée pour les administrateurs de serveurs et non pour les ingénieurs. Mais à y regarder de plus près, elle révèle des choix architecturaux délibérés dont tout développeur de jeux multijoueurs peut s'inspirer.

Un second fil conducteur traverse le travail de Valve sur l'anti-triche. La conférence de l'ingénieur John McDonald à la GDC 2018 sur VACNet, que nous avons déjà abordée dans notre analyse approfondie de l'anti-triche dans CS:GO, reste directement pertinente pour CS2, où le système a continué d'évoluer. Ces deux sujets méritent d'être étudiés pour aider les développeurs de jeux multijoueurs à évaluer leurs propres choix d'architecture.

Fusionner le Client et le Serveur

Le détail le plus marquant et le plus immédiat de la documentation semble de prime abord anodin : le serveur dédié CS2 et le client de jeu partagent désormais le même ID d'application Steam (App ID). Dans CS:GO, le client utilisait l'appid 730 et le serveur dédié l'appid 740. Deux téléchargements distincts, deux pipelines de mise à jour, deux sources potentielles d'écarts de version. Dans CS2, les deux coexistent sous l'appid 730.

Cette consolidation simplifie grandement le travail opérationnel. Les opérateurs de serveurs gèrent une seule installation. Les scripts de mise à jour ciblent un seul ID. La documentation communautaire converge au lieu de s'éparpiller. Pour les équipes qui gèrent des parcs d'instances, l'élimination d'une dépendance divergente représente un réel gain de confort de travail.

Le revers de la médaille est visible dans cette même documentation : l'image du serveur contient désormais des ressources réservées au client qu'il n'utilisera jamais. En conséquence, le téléchargement d'un serveur CS2 pèse environ 60 Go. C'est un coût d'infrastructure bien réel, en particulier pour les studios qui déploient de nombreuses instances simultanément.

Valve a privilégié la simplicité opérationnelle à l'efficacité du stockage, et la documentation ne cache pas cet inconvénient. Ce type de reconnaissance honnête des compromis est un exemple à suivre.

Hébergement axé sur les conteneurs

CS2 est arrivé dès son lancement avec un support Docker natif. La documentation présente une configuration en une seule commande : un unique appel docker run qui récupère l'image, lie les ports requis et met automatiquement à jour le serveur au redémarrage du conteneur chaque fois que Valve publie un correctif. Pas de scripts de mise à jour manuels. Pas d'écarts de version entre un binaire obsolète et un jeu en cours.

La communauté s'est rapidement emparée de cette base. Quelques semaines après le lancement, des projets comme CS2 Pterodactyl avaient déjà intégré le jeu directement au panneau open source que de nombreux opérateurs communautaires utilisent déjà. Cette rapidité d'adoption témoigne d'une volonté délibérée de la part de Valve : publier une documentation claire et stable et prendre en charge des outils standards est en soi une décision d'infrastructure. Valve a rédigé la documentation une fois. L'écosystème qui s'est construit autour a été créé par d'autres.

Pour les développeurs qui se demandent s'il convient d'investir tôt dans Docker et dans une conception de serveurs native pour les conteneurs, la trajectoire de CS2 constitue une référence utile. L'investissement initial dans la documentation s'avère payant sur le long terme.

Sub-Tick : Découpler la précision de la fréquence d'actualisation

La documentation évoque l'architecture sub-tick de CS2 sans toutefois l'expliquer en détail. Elle mériterait un article dédié, et la vidéo officielle de lancement de Valve "Moving Beyond Tick Rate" en sera la source principale. Mais l'idée centrale mérite d'être brièvement posée ici.

Dans CS:GO, comme dans la plupart des jeux de tir compétitifs, chaque action de joueur était traitée à la limite de chaque tick du serveur. À 64 Hz, les ticks surviennent toutes les 15,6 ms. Si vous tiriez 1 ms avant la limite d'un tick, le serveur traitait ce tir comme s'il s'était produit 14,6 ms plus tard. Des plateformes compétitives comme FACEIT utilisaient des serveurs à 128 Hz spécifiquement pour réduire de moitié cet écart, ce qui explique pourquoi la communauté accordait tant d'importance au tick rate.

Le système de sub-tick de CS2 contourne le problème différemment. Chaque action du client comporte désormais un horodatage précis. Le serveur reçoit ces horodatages et reconstitue l'ordre exact des événements, quel que soit le moment où ils se sont produits au sein du tick. Le tick rate perd de son importance en tant que mesure de la précision des commandes — du moins en théorie.

En pratique, le débat au sein de la communauté depuis le lancement s'avère plus complexe. Certains joueurs professionnels, dont Robin "ropz" Kool de l'équipe FaZe, ont souligné que le ressenti subjectif ne correspond pas encore tout à fait à celui de CS:GO à 128 Hz pour un joueur expérimenté. Cet écart entre la justesse technique et la réactivité perçue constitue en soi un enseignement précieux pour les développeurs : la perception de la latence par les joueurs n'est pas la même chose que la latence mesurée. Nous y reviendrons dans un prochain article.

L'anti-triche comme système d'apprentissage automatique

La documentation du serveur étant axée sur l'installation et la configuration, elle traite peu de l'anti-triche de manière directe. Pourtant, impossible d'évoquer l'infrastructure de CS2 sans l'aborder.

VACNet, initialement conçu pour CS:GO et fonctionnant désormais sur CS2 sous le nom de VAC Live, a été pensé comme une boucle d'apprentissage continu. John McDonald, qui a présenté le système à la GDC en 2018, a expliqué que l'idée maîtresse a consisté à réaliser que le système de révision par les pairs Overwatch de CS:GO générait silencieusement des données d'entraînement étiquetées depuis des années avant que quiconque ne pense à les exploiter. McDonald a souligné un point similaire concernant les données : plutôt que de mettre en place un service dédié à l'étiquetage des données, son équipe a construit le modèle à partir des signaux dont elle disposait déjà. Les métadonnées de match associées à chaque joueur, combinées aux verdicts de bannissement déjà rendus par un jury de joueurs, ont servi d'étiquettes d'entraînement.

Le choix de conception clé de cette architecture a été de maintenir l'humain dans la boucle de décision. VACNet ne bannit pas directement les joueurs. Il soumet les cas hautement suspects à des jurés humains d'Overwatch, qui analysent et tranchent. Ces verdicts alimentent ensuite la prochaine session de réentraînement du modèle. Un développeur de triche qui comprendrait précisément quels schémas le modèle surveille, et adapterait son outil en conséquence, ferait toujours face à un juré humain capable de reconnaître la triche. Ce verdict devient une nouvelle donnée d'entraînement. Le système s'enrichit de chaque attaque plutôt que d'être neutralisé par elle.

Depuis le lancement de CS2, le système a acquis une capacité de détection en temps réel. Le VACNet d'origine signalait les joueurs après la fin d'un match pour examen ultérieur. VAC Live peut désormais annuler un match en cours dès qu'un tricheur est détecté. Ce passage d'une analyse par lots à une inférence en direct correspond exactement à l'évolution que McDonald qualifiait de « travail en cours » à la fin de sa conférence de 2018. La boucle continue de tourner. Elle le fait simplement en temps réel désormais.

L'analyse complète de l'architecture, y compris le pipeline de données, le système de Trust Score et les principes de conception visant à maintenir l'humain dans la décision finale, est abordée dans notre analyse approfondie de l'anti-triche dans CS:GO.

Serveurs communautaires et question de l'hébergement

Valve a toujours permis aux joueurs d'héberger leurs propres serveurs Counter-Strike depuis CS 1.6. Cette continuité n'est pas un hasard. Les serveurs communautaires ont été essentiels à la longévité de Counter-Strike : cartes personnalisées, serveurs d'entraînement à la visée (aim), communautés de surf et de KZ, et l'infrastructure compétitive qui a fini par donner naissance à FACEIT et ESEA. Cet écosystème s'est construit sur un modèle d'hébergement que Valve a rendu possible et documenté de manière claire.

Pour Valve en particulier, l'hébergement ouvert est un compromis qu'ils peuvent se permettre. Les revenus issus de l'hébergement des serveurs vont aux opérateurs communautaires, pas à Valve. En échange, Valve bénéficie d'un écosystème qui maintient l'intérêt des joueurs, le jeu compétitif et l'engagement à long terme nécessaires pour soutenir une franchise vieille de 25 ans.

Pour un studio ne disposant pas de la plateforme Steam, le calcul est différent. L'hébergement communautaire représente un coût pour quelqu'un ; la question est de savoir qui le prend en charge. Les studios peuvent intégrer la revente de serveurs dédiés à leur modèle économique, en proposant des serveurs privés hébergés comme une gamme de produits aux côtés des cosmétiques ou des pass saisonniers. Les infrastructures de conteneurs en tant que service (CaaS) rendent cela plus accessible qu'il y a encore quelques années. Des plateformes comme l'orchestration de serveurs de jeu d'Edgegap permettent aux studios de proposer ce type de revente sans avoir à concevoir eux-mêmes l'infrastructure d'hébergement, transformant ce qui est traditionnellement un pur coût en une source potentielle de revenus.

La décision d'ouvrir l'hébergement doit découler des besoins réels de la communauté et de ce que le studio peut assumer financièrement. L'histoire de Valve est instructive. Mais c'est une histoire bâtie sur des avantages spécifiques qui ne se transposent pas automatiquement.

—

Cet article s'appuie sur et cite la documentation officielle du serveur dédié CS2 de Valve, publiée sur le wiki Valve Developer Community, ainsi que les enseignements de la conférence de John McDonald à la GDC 2018 sur VACNet, disponible sur la chaîne YouTube de la GDC.

Tous les droits relatifs au contenu original appartiennent à leurs propriétaires respectifs.