La documentation officielle de Valve sur le serveur dédié CS2, maintenue sur le wiki de la Valve Developer Community, offre aux opérateurs une fenêtre sur les décisions d’infrastructure qui sous-tendent l’un des jeux compétitifs les plus joués de Steam. Publiée en même temps que la sortie du jeu en septembre 2023, elle est rédigée pour les administrateurs de serveurs, et non pour les ingénieurs. Mais en la lisant attentivement, on y découvre des choix architecturaux délibérés dont tout développeur multijoueur peut s’inspirer.

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

Fusion du client et du serveur

Le détail le plus immédiatement notable de la documentation est celui qui paraît le plus banal : le serveur dédié CS2 et le client du jeu partagent désormais le même Steam App ID. Dans CS:GO, le client était l’appid 730 et le serveur dédié l’appid 740. Deux téléchargements distincts, deux pipelines de mise à jour, deux sources de divergence de version. Dans CS2, les deux relèvent de l’appid 730.

Cette consolidation simplifie un travail opérationnel réellement important. Les opérateurs de serveurs ne gèrent qu’une seule installation. Les scripts de mise à jour ciblent un seul ID. La documentation communautaire converge au lieu de se fragmenter. Pour les équipes qui gèrent des flottes d’instances, supprimer une dépendance divergente est un véritable gain en qualité de vie.

Le compromis apparaît clairement dans cette même documentation : l’image serveur embarque désormais des ressources réservées au client qu’elle n’utilisera jamais. Un téléchargement du serveur CS2 pèse ainsi environ 60 Go. C’est un coût d’infrastructure réel, en particulier pour les studios qui lancent de nombreuses instances simultanément.

Valve a privilégié la simplicité opérationnelle au détriment de l’efficacité du stockage, et la documentation ne cache pas cet inconvénient. Ce genre de reconnaissance honnête des compromis vaut la peine d’être prise comme modèle.

Hébergement centré sur les conteneurs

CS2 est arrivé avec une prise en charge Docker de première partie dès le lancement. La documentation montre 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 de décalage de version entre un binaire obsolète et une partie en cours.

La communauté a rapidement construit sur cette base. En quelques semaines après le lancement, des projets comme CS2 Pterodactyl avaient mis en place une intégration directe avec le panneau de jeu open source que de nombreux opérateurs communautaires utilisent déjà. Cette rapidité d’adoption reflète quelque chose de délibéré dans l’approche 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 fait une fois le travail de documentation. L’écosystème construit dessus a été créé par d’autres.

Pour les développeurs qui se demandent s’il faut investir tôt dans Docker et dans une conception de serveur native aux conteneurs, la trajectoire de CS2 est un point de référence utile. L’investissement initial dans la documentation produit des effets cumulés au fil du temps.

Sub-tick : découpler la précision de la fréquence des ticks

La documentation laisse entrevoir l’architecture sub-tick de CS2 sans l’expliquer en profondeur. Elle mérite un article à elle seule, et la vidéo officielle de lancement de Valve, « Moving Beyond Tick Rate », sera la source principale de ce texte. Mais l’idée centrale mérite d’être brièvement posée ici.

Dans CS:GO, comme dans la plupart des shooters compétitifs, chaque action du joueur était traitée à la frontière d’un tick serveur. À 64 Hz, les ticks arrivent toutes les 15,6 ms. Si vous tiriez 1 ms avant une frontière de tick, le serveur traitait ce tir comme s’il s’était produit 14,6 ms plus tard. Des plateformes compétitives comme FACEIT faisaient tourner des serveurs à 128 Hz précisément pour réduire de moitié cet écart, ce qui explique pourquoi la communauté attachait une importance si forte au tick rate.

Le système sub-tick de CS2 contourne le problème différemment. Chaque entrée client porte désormais un horodatage exact. Le serveur reçoit ces horodatages et reconstruit un ordre précis des événements, indépendamment de l’endroit du tick où ils se sont produits. La fréquence de tick devient moins importante comme proxy de la précision des entrées — en théorie.

En pratique, le débat communautaire depuis le lancement est plus complexe. Certains joueurs professionnels, dont Robin « ropz » Kool de FaZe, ont noté qu’au ressenti subjectif le jeu ne correspond toujours pas entièrement à du CS:GO à 128 Hz pour un joueur expérimenté. Cet écart entre exactitude technique et réactivité perçue est en soi un enseignement utile 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

La documentation du serveur se concentre sur l’installation et la configuration, et dit donc peu de choses directement sur l’anti-triche. Mais aucune discussion sur le backend de CS2 n’est complète sans cela.

VACNet, construit à l’origine pour CS:GO et désormais utilisé dans CS2 sous le nom VAC Live, a été conçu comme une boucle d’apprentissage continue. John McDonald, qui a présenté le système à la GDC en 2018, a décrit l’idée centrale comme la reconnaissance du fait que le système d’examen par les pairs Overwatch de CS:GO générait discrètement des données d’entraînement étiquetées depuis des années avant que quiconque pense à les utiliser. « Avant de construire un pipeline, », a observé McDonald, « auditez les données étiquetées que vous possédez déjà. »

La principale décision de conception de l’architecture consistait à garder des humains dans la boucle de verdict. VACNet ne bannit pas les joueurs. Il soumet des cas à forte confiance à des jurés humains Overwatch, qui les examinent et tranchent. Ces verdicts alimentent ensuite la prochaine phase de réentraînement. Un développeur de triche qui apprend exactement quels schémas le modèle surveille, puis adapte son outil en conséquence, devra quand même faire face à un juré humain qui reconnaît la triche quand il la voit. Ce verdict devient de nouvelles données d’entraînement. Le système se renforce à chaque attaque au lieu d’être invalidé par elle.

Depuis la sortie de CS2, le système a gagné une capacité de détection en temps réel. Le VACNet original signalait les joueurs après la fin d’une partie pour un examen a posteriori. VAC Live peut désormais annuler une partie en cours dès qu’un tricheur est détecté. Ce passage de l’analyse par lots à l’inférence en direct était exactement la direction que McDonald identifiait comme un « travail en cours » à la fin de sa conférence de 2018. La boucle fonctionne toujours. Elle fonctionne simplement en temps réel désormais.

Le décryptage complet de l’architecture, y compris le pipeline de données, le système de Trust Score et les principes de conception qui consistent à laisser les humains prendre la décision finale, est présenté dans notre analyse approfondie de l’anti-triche de CS:GO.

Serveurs communautaires et la question de l’hébergement

Valve autorise les joueurs à héberger leurs propres serveurs Counter-Strike depuis CS 1.6. Cette continuité n’est pas un hasard. Les serveurs communautaires ont été centraux dans la longévité de Counter-Strike : cartes personnalisées, serveurs d’entraînement à la visée, communautés surf et KZ, et l’infrastructure compétitive qui a fini par donner naissance à FACEIT et ESEA. Cet écosystème s’est bâti sur un modèle d’hébergement que Valve a rendu possible et a documenté clairement.

Pour Valve en particulier, l’hébergement ouvert est un compromis qu’elle peut se permettre. Les revenus de l’hébergement des serveurs vont aux opérateurs communautaires, pas à Valve. En échange, Valve obtient un écosystème qui soutient l’intérêt des joueurs, le jeu compétitif et le type d’engagement à long terme qui alimente une franchise vieille de 25 ans.

Pour un studio qui ne dispose pas de la plateforme Steam sous-jacente, le calcul est différent. L’hébergement communautaire est un centre de coûts pour quelqu’un ; la question est de savoir qui l’assume. Les studios peuvent intégrer la revente de serveurs dédiés à leur modèle — en proposant des serveurs privés hébergés comme ligne de produit, à côté des cosmétiques ou des passes saisonniers. L’infrastructure de type container-as-a-service rend cela plus pratique 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 construire eux-mêmes la pile d’hébergement, transformant ce qui est traditionnellement un pur coût en source potentielle de revenus.

La décision d’ouvrir l’hébergement devrait découler de ce dont la communauté a réellement besoin et de ce que le studio peut soutenir. L’histoire de Valve est instructive. Mais c’est une histoire fondée sur des avantages spécifiques qui ne se transfèrent pas automatiquement.

—

Cet article s’appuie sur la documentation officielle de Valve pour les serveurs dédiés CS2, publiée sur le wiki de la Valve Developer Community, ainsi que sur les analyses de la conférence GDC 2018 de John McDonald sur VACNet, disponibles sur la chaîne YouTube de la GDC.

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