L’excellente chaîne YouTube d’Outscal a publié une analyse comparative du taux de tick des serveurs dans Counter-Strike, VALORANT et PUBG.

Cela nous a amenés à discuter de la manière dont le tickrate n’a pas seulement un impact sur l’expérience en ligne des joueurs, mais aussi sur les coûts d’hébergement liés à l’exploitation de serveurs de jeu dédiés, à une échelle différente du taux de tick. L’impact peut être considérable.

Dans cet article, nous mettrons en avant certains des mêmes exemples qu’Outscal, mais aussi de nouveaux, et verrons comment chaque type de tickrate influe sur les coûts. Ce qui pose à tout développeur de jeu la question suivante : que vaut cette précision ?

Qu’est-ce que le taux de tick ?

À la base, le taux de tick est le rythme de traitement du serveur. Chaque tick correspond à un cycle complet : le serveur collecte toutes les entrées des joueurs depuis la dernière mise à jour, exécute la simulation physique, vérifie la détection des impacts et diffuse l’état du monde mis à jour à tous les clients connectés. Toute cette boucle constitue un tick.

Le taux de tick, mesuré en hertz, correspond au nombre de fois par seconde où 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 taux de tick vous donnent la fenêtre de traitement par cycle.

Pour les joueurs, des taux de tick plus élevés signifient que la vision du monde du jeu qu’a le serveur est plus récente. L’enregistrement des impacts est plus précis. Les déplacements sont plus réactifs. Les situations où un joueur semble mourir derrière un couvert parce que l’instantané du serveur a pris du retard sur la réalité se produisent moins souvent. Chaque tick est une fenêtre, et ce qui tombe dans cet interstice compte.

L’équation du coût du taux de tick

C’est là que la décision se complique.

Doubler votre taux de tick double à peu près 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 sont de l’egress réseau, et l’egress coûte de l’argent (à moins d’utiliser des serveurs qui incluent l’egress dans le prix, comme Bare Metalv ou Private Fleet hébergeur).

À grande échelle (par ex., des dizaines de milliers de matchs simultanés sur des serveurs mondiaux), l’écart entre 64 Hz et 128 Hz n’est pas un simple arrondi. C’est une part importante des dépenses d’infrastructure. Puisque l’egress représente 20 à 30 % des dépenses d’hébergement globales dans le cloud, doubler le taux de tick peut augmenter (ou réduire) ce montant.

Ensuite, l’impact sur l’utilisation des vCPU peut aggraver ce coût.

Exécuter la simulation du jeu plus fréquemment signifie que le processeur du serveur a plus de travail à accomplir par seconde : davantage d’évaluations physiques, de vérifications d’impact et de comparaisons d’état. Respawn l’a expliqué très clairement dans sa plongée technique officielle sur Apex Legends :
"Des serveurs à 20 Hz entraînent environ cinq images de retard, et des serveurs à 60 Hz entraînent trois images de retard. Donc, pour un coût trois fois supérieur en bande passante et en CPU, vous pouvez économiser deux images de latence dans le meilleur des cas."

C’est ce calcul qui a justifié qu’APEX: Legends reste à 20 Hz.

C’est pourquoi le taux de tick est l’une des décisions les plus déterminantes de la conception des 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, obtient des serveurs à 128 Hz. Pas d’accès par paliers, pas de séparation entre les files occasionnelles et compétitives.

Comme l’a expliqué Brent Randall, ingénieur 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 tractable. » Leur temps de frame initial côté serveur était de 50 millisecondes. À 128 Hz, la cible était de 2,34 millisecondes par frame. Cet écart a nécessité de reconstruire la façon 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éduite en calculant les animations des personnages toutes les quatre frames et en interpolant entre elles, ce qui a réduit le traitement des animations de 75 %. Pendant la phase d’achat, lorsqu’aucun combat ne peut avoir lieu, elle a désactivé complètement les animations côté serveur, économisant encore 33 %. Ils ont également remplacé la couche réseau par défaut d’Unreal Engine par un système RPC personnalisé qui, selon leurs propres tests documentés, a permis des gains de performance de 100x à 10 000x selon le type d’action. Même le choix du matériel a été réexaminé, avec un changement de serveur dû à des différences d’architecture de cache apportant encore un gain 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 mobilisation complète de l’équipe quelques jours avant Champions. Ils ont corrigé le problème. Le système est revenu meilleur qu’avant. Après le patch 5.07, Riot a indiqué que 99,3 % ou plus des frames serveur respectaient leur budget strict de 128 Hz.

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

C’est faisable. Riot l’a prouvé. Cela exige un investissement soutenu que tous les studios ne sont pas en mesure de reproduire à une telle échelle.

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

Valve a examiné l’engagement technique du 128 Hz et a posé une autre question. Et si un taux de tick plus élevé résolvait le mauvais problème ?

Le problème fondamental des systèmes de tick à intervalle fixe est la quantification. À 64 Hz, deux joueurs qui tirent presque au même instant sont traités dans le même tick. Celui dont l’action tombe le plus près de la limite du tick est traité en premier. L’autre joueur peut perdre un duel en partie à cause du hasard du timing plutôt que de son habileté. Augmenter le taux de tick réduit la fenêtre, mais n’élimine pas le problème.

Le système Subtick de CS2 s’attaque à cela différemment. Au lieu de traiter toutes les entrées aux limites fixes des ticks, le serveur enregistre un horodatage précis à la microseconde pour chaque action du joueur.

Un tir effectué au milieu d’un cycle de tick est consigné à son moment exact. Un tir de riposte effectué plus tard dans le même cycle obtient son propre horodatage. Le serveur traite ensuite ces événements dans leur véritable ordre chronologique, 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 taux de tick n’a plus d’importance pour se déplacer, tirer ou lancer. Les mises à jour Sub-tick sont au cœur de Counter-Strike 2. » Le serveur fonctionne toujours à 64 Hz pour la diffusion d’état, mais les événements qui se produisent à l’intérieur de chaque tick sont résolus avec une précision à la microseconde. Une précision temporelle découplé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 les serveurs communautaires à 128 ticks sur lesquels la scène compétitive s’appuyait depuis des années. Le cas technique du Subtick est solide. La friction qu’il a générée était réelle. C’est un rappel utile que les décisions d’architecture dans le multijoueur ne vivent pas isolément des attentes des joueurs et de l’histoire de la communauté.

Trouver un juste milieu : Marathon à 60 Hz

Tous les studios ne se retrouvent pas dans un extrême.

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 session, la précision du serveur n’est pas un sujet théorique. Un critique a décrit le taux de tick de 60 Hz comme « de loin la fonctionnalité la plus sous-estimée de Marathon », notant qu’un enregistrement précis des impacts est au cœur de l’intégrité compétitive du jeu dans les duels à gros enjeux.

À l’inverse, ARC Raiders, un extraction shooter concurrent, tourne à 20 Hz. La différence se voit surtout dans les affrontements PvP intenses, où la latence ou la désynchronisation pénaliseraient autrement les joueurs de manière injuste. Le choix de Marathon se situe bien au-dessus du niveau de base auquel la plupart des extraction shooters fonctionnent, sans s’engager dans la surcharge d’ingénierie complète qu’exige 128 Hz.

C’est un point médian délibéré. Pour un genre construit autour d’affrontements à fort enjeu avec un temps pour tuer faible, 60 Hz offre assez de précision pour rendre les fusillades équitables tout en maintenant des coûts d’infrastructure inférieurs à ce qu’exigerait un engagement à la VALORANT. Le bon taux de tick 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 soutenir.

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

APEX: Legends fonctionne à 20 Hz, VALORANT à 128 Hz, CS2 à 64 Hz avec Subtick, Marathon à 60 Hz. Arc Raiders à 20 Hz, et, selon les rapports, Hunt Showdown à 30 Hz et Escape from Tarkov à 12-16Hz.

Chaque choix reflète un calcul différent de ce qu’exige le jeu et de ce que le studio peut prendre en charge opérationnellement.

La logique sous-jacente est la même pour tous. Des taux de tick plus élevés envoient davantage de données à davantage de joueurs, plus souvent. Ils exigent davantage de temps vCPU par cycle de simulation. Ils coûtent plus cher à grande échelle.

Pour certains jeux et genres, cette précision vaut son coût. Pour d’autres, l’amélioration marginale de l’enregistrement des impacts ne justifie pas de doubler la facture d’egress.

Il convient aussi de noter que le taux de tick 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 taux de tick cherchent en partie à compenser. Un serveur 64 Hz bien placé peut probablement surpasser un serveur 128 Hz déployé loin de sa base de joueurs. Des plateformes comme le réseau d’orchestration de serveurs de jeu d’Edgegap déploient dans plus de 615 emplacements à travers le monde et offrent une réduction moyenne de latence de 58 %. La latence est la principale raison de la frustration des joueurs face aux jeux en ligne.   

Autrement dit, le taux de tick et le placement réseau fonctionnent ensemble. Aucun des deux ne raconte toute l’histoire à lui seul.

La décision est un compromis. Faites-la délibérément, avec une vision claire du genre de votre jeu, des attentes de votre base de joueurs et de la capacité de votre équipe à maintenir le niveau que vous choisissez d’assumer.

Si vous voulez voir comment les décisions de taux de tick interagissent avec vos coûts réels de serveur, le calculateur de tarifs d’Edgegap vous permet de modéliser cela selon votre nombre de joueurs et vos régions. --

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