L'excellente chaîne YouTube d'Outscal a publié une analyse comparative de la fréquence de rafraîchissement des serveurs (tick rate) sur Counter-Strike, VALORANT et PUBG.

Cela nous a incités à discuter de la manière dont le tick rate n'impacte pas seulement l'expérience en ligne des joueurs, mais aussi les coûts d'hébergement liés à l'exploitation de serveurs de jeu dédiés à une autre échelle de la plage de tick rate. Car l'impact peut être substantiel.

Dans cet article, nous mettrons en lumière certains des exemples soulignés par Outscal, mais aussi de nouveaux, et la manière dont chaque type de tick rate influence les coûts. Ce qui amène chaque développeur de jeux à se poser la question : que vaut cette précision ?

Qu'est-ce que le tick rate ?

À la base, le tick rate est le rythme de traitement du serveur. Chaque tick représente un cycle complet : le serveur collecte les actions de chaque joueur depuis la dernière mise à jour, exécute la simulation physique, vérifie la détection des tirs (hit detection) et diffuse l'état du monde mis à jour à tous les clients connectés. Cette boucle entière constitue un tick.

Le tick rate, mesuré en hertz, correspond au nombre de fois par seconde que ce cycle se répète. Un serveur à 64 Hz l'exécute toutes les 15,6 millisecondes. Un serveur à 128 Hz l'exécute toutes les 7,8 millisecondes. Le calcul est simple : 1 000 ms divisées par le tick rate donnent la fenêtre de traitement par cycle.

Pour les joueurs, un tick rate plus élevé signifie que l'image du monde de jeu par le serveur est plus actuelle. La détection des tirs est plus précise. Les mouvements sont plus réactifs. Les situations où un joueur semble mourir à l'abri parce que l'instantané du serveur était en retard par rapport à la réalité se produisent moins souvent. Chaque tick est une fenêtre, et ce qui tombe dans cet intervalle a son importance.

L'équation du coût du tick rate

C'est là que la décision devient difficile.

Doublez votre tick rate et vous doublez approximativement votre charge CPU et votre consommation de bande passante.

Chaque joueur dans chaque match actif reçoit des mises à jour d'état deux fois plus souvent, ce qui signifie deux fois plus de données sortantes par seconde. Ces données sortantes représentent le trafic réseau sortant (egress), et l'egress coûte de l'argent (sauf si vous utilisez des serveurs qui incluent l'egress dans le prix, comme un hôte Bare Metal ou Private Fleet).

À grande échelle (par exemple, des dizaines de milliers de matchs simultanés sur des serveurs mondiaux), l'écart entre 64 Hz et 128 Hz n'est pas une simple erreur de calcul. C'est une part importante des dépenses d'infrastructure. Étant donné que l'egress représente 20 à 30 % des dépenses globales d'hébergement pour le cloud, doubler le tick rate peut augmenter (ou diminuer) ce montant.

Ensuite, l'impact sur l'utilisation du vCPU peut aggraver ce coût.

Exécuter la simulation de jeu plus fréquemment signifie que le processeur du serveur a plus de travail à faire par seconde : plus d'évaluations physiques, plus de vérifications de tirs, plus de comparaisons d'états. Respawn l'a exprimé clairement dans sa présentation technique officielle sur Apex Legends :

"Les serveurs à 20 Hz entraînent environ cinq images de retard, et les serveurs à 60 Hz entraînent trois images de retard. Ainsi, pour trois fois plus de bande passante et de coûts CPU, vous pouvez économiser deux images de latence dans le meilleur des cas."

Ce calcul a été leur justification pour que APEX: Legends reste à 20 Hz.

C'est pourquoi le tick rate est l'une des décisions les plus lourdes de conséquences dans la conception de jeux multijoueurs. Et c'est pourquoi l'industrie n'a pas convergé vers une réponse unique.

Payer le prix fort : VALORANT à 128 Hz

Riot Games a clairement affiché sa position dès le début du développement de VALORANT : chaque joueur, dans chaque match, bénéficie de serveurs à 128 Hz. Pas d'accès différencié, pas de séparation entre les files occasionnelles et compétitives.

Comme l'a décrit Brent Randall, ingénieur au sein de l'équipe Gameplay Integrity de VALORANT, dans le blog technique officiel de Riot : "'Rendre le serveur 20 fois plus rapide' n'est pas un problème très facile à résoudre." Le temps de trame initial de leur serveur était de 50 millisecondes. À 128 Hz, l'objectif était de 2,34 millisecondes par trame. Cet écart a nécessité de reconstruire la manière dont le moteur utilisait les ressources du serveur, sur presque tous les systèmes.

L'animation a été l'un des principaux facteurs de coût. L'équipe l'a réduit en calculant les animations des personnages toutes les quatre trames et en interpolant entre elles, ce qui a réduit le traitement de l'animation de 75 %. Pendant la phase d'achat, où aucun combat ne peut avoir lieu, ils ont entièrement désactivé les animations côté serveur, économisant ainsi 33 % de plus. Ils ont également remplacé la couche réseau par défaut d'Unreal Engine par un système personnalisé basé sur les RPC qui, lors de leurs propres tests documentés, a permis d'améliorer les performances de 100 à 10 000 fois selon le type d'action. Même la sélection du matériel a été passée en revue, un changement de serveur pour des différences d'architecture de cache apportant un gain supplémentaire de 30 %.

Et même après tout cela, une mise à jour du moteur en 2022 a dégradé leurs performances pendant la saison compétitive, nécessitant une intervention de toute l'équipe quelques jours avant les Champions. Ils ont résolu le problème. Le système est revenu plus performant qu'auparavant. Après le patch 5.07, Riot a signalé que 99,3 % ou plus des trames de serveur respectaient leur budget strict de 128 Hz.

C'est le coût réel de l'engagement envers le 128 Hz. Pas seulement des factures de calcul et d'egress plus élevées, mais une obligation d'ingénierie continue pour défendre ce budget contre chaque nouvelle fonctionnalité, chaque mise à jour du moteur, chaque patch saisonnier.

C'est réalisable. Riot l'a prouvé. Cela nécessite un investissement soutenu que tous les studios ne sont pas en mesure de reproduire pour une entreprise d'une telle envergure.

Repenser le principe : le système Subtick de Counter Strike 2

Valve a examiné l'engagement d'ingénierie du 128 Hz et a posé une question différente. Et si un tick rate plus élevé résolvait le mauvais problème ?

Le problème fondamental des systèmes de ticks à intervalles fixes est la quantification. À 64 Hz, deux joueurs qui tirent presque au même instant sont traités dans le même tick. L'action de celui qui se rapproche le plus de la limite du tick est traitée en premier. L'autre joueur peut perdre un duel en partie à cause du hasard du timing plutôt que du talent. Augmenter le tick rate réduit la fenêtre mais n'élimine pas le problème.

Le système Subtick de CS2 résout ce problème différemment. Au lieu de traiter toutes les actions à des limites de ticks fixes, le serveur enregistre un horodatage précis à la microseconde près pour chaque action du joueur.

Un tir effectué au milieu d'un cycle de tick est enregistré à son moment précis. Un contre-tir effectué plus tard dans le même cycle obtient son propre horodatage. Le serveur traite ensuite ces événements dans un ordre chronologique réel, indépendamment du taux de diffusion de base de 64 Hz.

Valve a décrit l'objectif directement sur la page d'annonce de CS2 : "Le tick rate n'a plus d'importance pour se déplacer, tirer ou lancer des grenades. Les mises à jour sub-tick sont le cœur de Counter-Strike 2." Le serveur fonctionne toujours à 64 Hz pour la diffusion de l'état, mais les événements qui se produisent à l'intérieur de chaque tick sont résolus avec une précision à la microseconde près. Une précision temporelle, déconnectée du coût d'infrastructure.

Valve a également verrouillé les services tiers, y compris FACEIT, sur le même taux de base de 64 Hz, éliminant ainsi les serveurs communautaires à 128 ticks sur lesquels la scène compétitive s'appuyait depuis des années. L'argument technique en faveur du Subtick est solide. Les frictions qu'il a générées étaient réelles. C'est un rappel utile que les décisions d'architecture dans le multijoueur ne vivent pas isolées des attentes des joueurs et de l'histoire de la communauté.

Trouver le juste milieu : Marathon à 60 Hz

Tous les studios ne se positionnent pas à un extrême.

Le jeu Marathon de Bungie, un extraction shooter sorti en 2026, fonctionne sur des serveurs à 60 Hz. Dans un genre où perdre un affrontement signifie perdre tout son équipement pour une partie, la précision du serveur n'est pas une préoccupation théorique. Un critique a décrit le tick rate de 60 Hz comme "facilement la fonctionnalité la plus sous-estimée de Marathon", notant qu'une détection des tirs rigoureuse est essentielle pour l'intégrité compétitive du jeu dans les duels à enjeux élevés.

En comparaison, ARC Raiders, un extraction shooter concurrent, tourne à 20 Hz. La différence se manifeste surtout lors des affrontements intenses en PvP, où la latence ou la désynchronisation puniraient autrement les joueurs injustement. Le choix de Marathon se situe bien au-dessus de la référence de la plupart des extraction shooters, sans pour autant s'engager dans la lourde charge d'ingénierie qu'exige le 128 Hz.

C'est un juste milieu délibéré. Pour un genre construit autour d'affrontements à fortes conséquences avec un temps pour tuer (time-to-kill) faible, le 60 Hz offre suffisamment de précision pour que les combats à l'arme à feu semblent équitables, tout en maintenant les coûts d'infrastructure en dessous de ce qu'exigerait un engagement de type VALORANT. Le bon tick rate n'est pas toujours le plus élevé disponible. C'est celui qui correspond aux exigences de précision de votre jeu par rapport à ce que votre infrastructure peut réellement supporter.

Il n'y a pas de bonne réponse : juste le bon compromis

APEX: Legends tourne à 20 Hz, VALORANT à 128 Hz, CS2 à 64 Hz avec Subtick, Marathon à 60 Hz. Arc Raiders à 20 Hz, et d'après les informations, Hunt Showdown à 30 Hz et Escape from Tarkov à 12-16 Hz.

Chaque choix reflète un calcul différent de ce que le jeu exige et de ce que le studio peut soutenir sur le plan opérationnel.

La logique sous-jacente est cohérente pour chacun d'eux. Des tick rates plus élevés envoient plus de données à plus de joueurs plus souvent. Ils exigent plus de temps vCPU par cycle de simulation. Ils coûtent plus cher à grande échelle.

Pour certains jeux et genres, cette précision en vaut la dépense. Pour d'autres, l'amélioration marginale de la détection des tirs ne justifie pas de doubler la facture d'egress.

Il convient également de noter que le tick rate n'est pas le seul levier. Déployer des serveurs plus près des joueurs réduit la latence de base que les décisions de tick rate tentent en partie de compenser. Un serveur à 64 Hz bien placé peut probablement surpasser un serveur à 128 Hz déployé loin de sa base de joueurs. Les plateformes comme le réseau d'orchestration de serveurs de jeu d'Edgegap se déploient dans plus de 615 emplacements à travers le monde et offrent une réduction moyenne de la latence de 58 %. Or, il est prouvé que la latence est la principale cause de frustration des joueurs avec les jeux en ligne.   

En d'autres termes, le tick rate et l'emplacement réseau fonctionnent ensemble. Aucun d'eux ne raconte toute l'histoire à lui seul.

La décision est un compromis. Prenez-la délibérément, en ayant une vision claire du genre de votre jeu, des attentes de votre base de joueurs et de la capacité de votre équipe à maintenir la norme que vous vous êtes engagée à respecter.

Si vous souhaitez voir comment les décisions de tick rate interagissent avec vos coûts réels de serveur, le calculateur de prix d'Edgegap vous permet de modéliser cela par rapport à votre nombre de joueurs et à vos régions. --

Cet article est basé sur et cite la vidéo "64 vs 128 Tick Servers: CS2 vs Valorant vs PUBG" par Outscal, publiée sur YouTube, ainsi que la documentation technique principale de Riot Games, Respawn Entertainment, et de Valve pour Counter Strike 2. Tous les droits sur le contenu original appartiennent à leurs propriétaires respectifs.