Glossaire des serveurs de jeux multijoueur

Glossaire des serveurs de jeux multijoueur

Vous vous demandez ce que signifient réellement la désynchronisation, le tick rate ou le fill rate pour votre jeu ? Voici les termes clés du multijoueur, expliqués par l'équipe qui gère des serveurs pour des millions de joueurs.

L'infrastructure multijoueur a un problème de vocabulaire : le même mot a souvent trois significations différentes selon la personne qui l'utilise (*tousse* salons *tousse*).

Parcourez les définitions couvrant l'hébergement de serveurs de jeu, l'orchestration, le netcode, le matchmaking et l'architecture réseau.

Infrastructure et coûts

Les machines, les emplacements et les modèles de tarification associés au serveur de jeu multijoueur.

Un serveur bare metal est une machine physique entière, louée au mois. Ce qu'il coûte à un jeu multijoueur, en quoi il diffère du cloud et quand il est adapté.

Les serveurs cloud sont des machines virtuelles facturées pendant leur exécution. Ce qui détermine le coût des serveurs de jeu, pourquoi l'arrêt est important, et la différence entre les instances à la demande, réservées et spot.

Le trafic sortant du réseau correspond aux données qui quittent le réseau d'un fournisseur. Découvrez ce qui le génère dans les jeux multijoueurs, pourquoi le cloud le facture à l'usage alors que le bare metal l'inclut, et comment l'estimer.

Un vCPU est généralement un thread matériel, et non un cœur complet. Découvrez pourquoi les vCPUs diffèrent, combien de vCPUs un serveur de jeu nécessite, et comment se comparent la tarification à la minute et celle sur réservation.

Un « voisin bruyant » est un locataire dont la charge peut ralentir la vôtre. Découvrez comment les limites de conteneurs l'empêchent d'impacter votre partie, ce que coûte cette prévention, et pourquoi les grandes flottes mutualisent leurs ressources.

Hébergement et orchestration

Comment les serveurs de jeu sont packagés, démarrés, mis à l'échelle et arrêtés.

Agones exécute des serveurs de jeux dédiés sur Kubernetes. Comment il protège les matchs en direct, ce que son exécution implique, et ce que KRAFTON avait mis en place pour PUBG.

L'auto-scaling ajuste la capacité des serveurs de jeu en fonction de la demande. Ce qu'une politique décide, pourquoi la réduction d'échelle est la partie la plus coûteuse, et comment les démarrages rapides changent la donne.

Un pool chaud conserve des serveurs de jeu prêts avant même que les matchs ne le demandent. Ce qu'il contient, comment le dimensionner, et pourquoi le provisionnement à la demande transforme cela en une décision de coût, et non en une obligation.

La colocation signifie le partage d'infrastructures. Pourquoi partager un hôte avec les serveurs de jeu d'autres studios est sûr, pourquoi cela coûte moins cher, et quand posséder ses propres baies devient rentable.

Un conteneur exécute un seul serveur de jeu pour un match. Ce qu'il isole, pourquoi le mappage de ports complique les premiers déploiements, où vont les journaux et les résultats, et comment le recycler.

Docker construit l'image dans laquelle votre serveur de jeu est livré. Découvrez en quoi il diffère d'une VM, quatre pièges de build à éviter localement, et pourquoi WebAssembly ne peut pas encore le remplacer.

Un démarrage à froid (cold start) correspond à l'attente nécessaire pour qu'un nouveau conteneur de serveur de jeu soit prêt pour un match. Découvrez ce qui s'y passe, pourquoi les temps de démarrage divergent et le coût des pools de serveurs actifs (warm pools).

Un déploiement correspond à une version de serveur de jeu en cours d'exécution. Découvrez ce qu'il contient, comment il démarre et s'arrête, comment les versions se mettent à jour sans interruption de service, et ce qui détermine son coût.

La gestion de flotte détermine sur combien d'hôtes vos serveurs de jeu s'exécutent, et à quel endroit. Flottes réservées vs à la demande, et comment cela s'associe à l'orchestration.

L'hébergement de serveurs de jeux comprend quatre couches : les machines, le placement, l'orchestration et les opérations. Là où les serveurs fonctionnent, réservés vs à la demande, et quand construire le vôtre.

Kubernetes automatise les conteneurs pour les services web. Découvrez sa place dans un backend multijoueur, ainsi que ce que nécessite l'hébergement autonome de serveurs de jeu par région et par version.

Un orchestrateur est le système qui décide où et quand chaque instance de serveur de jeu s'exécute, et l'arrête lorsque la partie se termine.

Comment l'orchestration gère chaque match, du placement au démantèlement. Hubs régionaux vs placement par match, capacité fixe vs cloud, et pourquoi la plupart des jeux optent pour un modèle hybride.

L'orchestration hybride exécute des serveurs de jeu sur des hôtes fixes et dans le cloud sous un plan de contrôle unique. Découvrez le fonctionnement du débordement, comment dimensionner la ligne de base, et la comparaison avec le multi-cloud.

Un serveur de jeu multi-salon exécute plusieurs matchs au sein d'un seul processus. Quels netcodes le prennent en charge, comment le backfill remplit les salons, où le positionner, et quel est le coût d'un match.

Ce que le « serverless » signifie pour les serveurs de jeu : fonctions, serveurs par match ou relais. Les composants de l'architecture, ce qui la fait fonctionner et les cas où elle n'est pas adaptée.

Un serveur dédié gère la partie sans aucun joueur dessus. En quoi il diffère d'un serveur écoute (listen server), comment chaque moteur le conçoit, et pourquoi la portée en détermine le coût.

Un serveur headless (sans interface graphique) exécute le jeu sans rendu visuel ni audio. Découvrez ce qui pose problème lors de leur suppression, pourquoi cela s'intègre parfaitement dans un conteneur et comment cela influence les coûts d'hébergement.

A small dedicated server gives one match its own game server, sized to a fraction of a vCPU and placed near its players. How it compares to multi-room.

Regroupement de joueurs (Matchmaking, navigateur de serveurs, salons, sessions)

Tout ce qui concerne le regroupement de joueurs avant un match et le maintien des places occupées au cours d'une session.

L'allocation de serveur lie un match créé à un serveur de jeu. Découvrez son rôle entre le matchmaker et les joueurs, la différence entre réserver et démarrer un serveur, et les raisons de ses échecs.

Un système de matchmaking regroupe les joueurs dans des parties : comment il est structuré, les règles qu'il utilise, ce que son fonctionnement implique et comment le taux de remplissage influence les coûts d'hébergement.

Le matchmaking basé sur le niveau regroupe les joueurs selon leurs compétences. Découvrez sa place dans un système de matchmaking, ce que révèlent les données d'un jeu comme Call of Duty, comment définir la tolérance de niveau, et quand cette méthode est la plus appropriée.

Le MMR est l'estimation numérique cachée du niveau d'un joueur, utilisée par le système d'association pour créer des parties équilibrées.

Un navigateur de serveurs répertorie les serveurs de jeu actifs parmi lesquels les joueurs peuvent choisir. Découvrez comment cette liste reste à jour, comment le ping est mesuré et quand un jeu devrait en intégrer un.

Le remplissage automatique (backfill) permet d'intégrer de nouveaux joueurs dans des matchs en cours. Comment le serveur les demande, à quoi sert le remplissage, les règles qu'il applique et quand l'ignorer.

Les régions de serveurs divisent votre file d'attente de matchmaking et votre flotte par zone géographique. Découvrez ce que cela coûte, comment fonctionne le placement par ville pour chaque match, et quand une région fixe est rentable.

Le taux d'occupation des sessions correspond à la proportion de sièges de joueurs occupés au cours d'un match. Découvrez comment le mesurer, à quel moment il chute, les références par genre et pourquoi les bots masquent les sièges vides.

Netcode

Synchronisation, transfert de données, retour en arrière et impact global sur l'expérience en ligne du joueur.

La désynchronisation se produit lorsque la vision d'un match par un joueur ne correspond plus à celle du serveur. Découvrez les deux types de désynchronisation, pourquoi le tickrate n'est pas la solution, et quand elle s'apparente à de la triche.

Le rubberbanding est l'effet de retour en arrière lorsqu'un serveur corrige une position mal prédite. Découvrez ses causes, pourquoi il ne s'agit pas simplement de lag, et comment le réduire côté serveur.

Le tickrate est le nombre de fois par seconde qu'un serveur de jeu recalcule l'état de la partie, mesuré en hertz.

L'interpolation dessine les autres joueurs entre les mises à jour du serveur. Ce que cela coûte, pourquoi Source est configuré par défaut à 100 ms, et quand les jeux font des prédictions au lieu d'interpoler.

Pourquoi la migration d'hôte continue d'interrompre les parties, ce qui doit être transféré lorsque l'hôte s'en va, ce que cela coûte à mettre en place, et comment les serveurs dédiés permettent de l'éliminer.

Le netcode maintient la cohérence d'un match multijoueur. Voici les sept composants, les compromis de chacun, et pourquoi un « mauvais netcode » relève souvent d'une autre couche.

Le netcode de rollback prédit, annule et rejoue. Découvrez pourquoi la latence détermine l'ampleur de chaque correction, pourquoi les jeux y intègrent du délai d'entrée, et ce que cela coûte à développer.

La perte de paquets correspond aux données qui n'arrivent jamais. Découvrez ce qu'une mise à jour ou une commande perdue fait à un jeu, comment le netcode le masque, et pourquoi la structure de la perte est importante.

Le ping est le temps d'aller-retour entre un joueur et un serveur. Comment il façonne le netcode, pourquoi l'écart entre les joueurs importe davantage, et ce que les développeurs contrôlent.

La prédiction côté client affiche les actions d'un joueur avant que le serveur ne les confirme. Découvrez ce qui est prédit, comment la réconciliation rejoue les actions et pourquoi la latence est importante.

L'UDP envoie des paquets sans garantir leur livraison ni leur ordre, tandis que le TCP garantit les deux au prix d'un délai supplémentaire.

Architecture réseau

Comment les clients, les serveurs et les relais se connectent.

L'architecture client-serveur achemine chaque joueur via un serveur unique. Découvrez le fonctionnement de la boucle de jeu, pourquoi les clients effectuent des prédictions et de l'interpolation, et quel est le coût du hub.

Le crossplay rassemble les joueurs sur console, PC et mobile dans une même partie. Découvrez pourquoi le peer-to-peer pose problème, pourquoi les versions doivent correspondre et comment préserver l'intégrité de la file d'attente.

Le multijoueur en peer-to-peer n'engendre pas de frais d'hébergement. En contrepartie, il coûte en connexions échouées, en triche de la part de l'hôte, en parties perdues lorsque l'hôte quitte, et en support technique.

Un serveur faisant autorité est l'unique source de vérité pour l'état de la partie, aucun client ne peut donc dicter les résultats.

Un serveur relais redirige les joueurs pour contourner le NAT sans pour autant héberger la partie. Découvrez ce qu'il résout, ce qui reste en peer-to-peer, le coût des relais gratuits et quand passer à l'étape suivante.

Joueurs

Tout ce qui concerne les fonctions de maintien d'un jeu en ligne, son exploitation et la garantie d'une expérience en ligne équitable et excellente pour les joueurs.

Intégrer Edgegap facilement en quelques minutes

Commencez l'intégration maintenant!

Mettez votre jeu en ligne facilement
& en quelques minutes