Serveur de jeu multi-salles
Un serveur de jeu multi-salons est un processus serveur unique qui héberge plusieurs matchs à la fois, chacun dans son propre salon avec son propre état et ses propres joueurs. Les coûts fixes du processus, tels que le moteur et les données de jeu chargées, sont payés une seule fois et partagés entre tous les salons, de sorte que chaque match n'a besoin que d'une fraction de vCPU. Cela convient aux jeux avec des simulations légères, tels que les jeux de cartes, au tour par tour, occasionnels et mobiles, et leur confère l'autorité du serveur à un coût proche de celui d'un relais.
Aussi appelé
serveur multi-pièces, serveur multi-session
,
Quelle est la différence entre un serveur multi-salon et un serveur multi-processus ?
« Est-ce que chaque match dispose de son propre serveur de jeu ? » est une question fréquente lorsque l'on débute dans le multijoueur. Ce n'est pas une obligation. Plusieurs matchs peuvent partager une même machine de deux manières :
Multi-processus. Chaque match dispose de son propre processus de serveur, et plusieurs processus s'exécutent côte à côte sur un même hôte, chacun sur son propre port.
Multi-chambre (Multi-room). Un seul processus héberge plusieurs matchs à la fois, chacun dans une chambre virtuelle avec son propre état et ses propres joueurs.
La différence réside dans ce qu'un nouveau match reçoit : un nouveau serveur ou une chambre libre dans un serveur déjà en cours d'exécution. À l'intérieur de celui-ci, le code propre au jeu sépare les différentes chambres.
Quels moteurs et netcodes peuvent exécuter plusieurs matchs dans un seul processus ?
De nombreux frameworks basés sur les salons le font par conception. Unreal va dans l'autre sens.
Colyseus. « Une classe de salon peut générer de nombreuses instances (par exemple, plusieurs parties d'un même type de jeu) » (Documentation Colyseus).
Nakama. Exécute de nombreuses parties faisant autorité par nœud, chacune avec sa propre boucle (Documentation Heroic Labs).
Mirror (Unity). Son exemple Multiple Additive Scenes attribue à chaque partie une sous-scène avec sa propre scène physique (Documentation Mirror).
Unreal. Son serveur dédié exécute généralement une carte et un mode de jeu par processus ; le conseil habituel est de lancer plusieurs processus par machine (Forums Epic Developer Community, 2016). Les jeux Unreal évoluent principalement par processus plutôt que par salon.
Le choix est plus facile au début : convertir un serveur à partie unique signifie que chaque élément d'état partagé, des singletons au monde physique, doit être géré par salon.
Comment les joueurs entrent-ils dans une salle ?
Les serveurs en cours d'exécution affichent leurs emplacements disponibles, et les joueurs les rejoignent de l'une des deux manières suivantes.
Une liste de serveurs. Les joueurs choisissent un serveur en cours d'exécution avec des emplacements disponibles, ce qui convient aux jeux persistants et communautaires. Voir le navigateur de serveurs.
Le matchmaker. Il prend un groupe de joueurs et décide de : les réintégrer par backfill dans une salle ouverte, ou déployer un nouveau serveur si aucune salle ne convient. Rejoindre ressemble à n'importe quelle partie avec matchmaking.
Dans les deux cas, vous adaptez l'échelle par salle. Pour retirer un serveur, arrêtez d'y envoyer des joueurs et laissez ses salles se terminer (la section sur les conteneurs traite du recyclage).
Où devrait fonctionner un serveur multi-pièces ?
L'emplacement d'un serveur multi-salles est choisi une seule fois, lors de son démarrage, et chaque salle joue depuis cet endroit. Le placement par match choisit quant à lui un emplacement pour les joueurs de chaque match (orchestration de serveurs de jeu).
Les salles sont rentabilisées lorsqu'elles sont pleines, c'est pourquoi les serveurs multi-salles se regroupent là où la densité de joueurs est élevée. Répartissez-les davantage et chacune se remplira plus lentement ; gardez-les en petit nombre et les joueurs éloignés se connecteront de plus loin.
Les jeux au tour par tour, de cartes, de réflexion et occasionnels, ainsi que les salons, tolèrent quelques millisecondes supplémentaires. Les modes où la latence détermine le résultat conservent leur propre serveur. De nombreux jeux proposent les deux.
Un mot de notre sponsor (nous-mêmes !)
Le jour du lancement est un bien mauvais moment pour découvrir les cas limites d'un orchestrateur. L'orchestration automatisée d'Edgegap a géré 135 millions de déploiements de serveurs de jeux depuis février 2019 à travers son réseau multi-cloud distribué, et déploie aujourd'hui quotidiennement pour le compte de milliers de jeux et de plusieurs millions de joueurs.
Combien coûte un match sur un serveur multi-salles ?
Un processus serveur comporte des coûts fixes avant même le début d'un match : le moteur, les données de jeu chargées, la mémoire de base. Le multi-chambre les partage entre les chambres, c'est ainsi qu'un serveur dédié se rapproche du coût d'un relais tout en hébergeant le match.
Une estimation, pour un jeu de cartes avec des matchs de 15 minutes :
Serveur. 2 vCPUs hébergeant 40 chambres, chaque match utilise donc 0,05 vCPU.
Heure. 2 vCPUs × 60 minutes × 0,00115 $ = 0,138 $ sur Edge Cloud (données de la plateforme, 18 septembre 2026).
Match. Avec 85 % de chambres occupées, cette heure comporte 136 matchs : environ 0,001 $ par match.
Vient ensuite le trafic sortant (egress) : le calcul reste stable par serveur, tandis que le trafic sortant augmente avec chaque joueur. À 0,10 $ le Go sur Edge Cloud, le trafic sortant d'un serveur à 2 vCPUs équivaut à son calcul pour environ 150 joueurs envoyant chacun 20 kbps, ou environ 3 000 joueurs à 1 kbps. Plus les chambres sont denses, plus le trafic sortant devient la ligne la plus importante de la facture.
Cela vaut la peine d'envisager Private Fleet : des hôtes réservés dans 58 emplacements avec trafic sortant inclus, et un débordement automatique vers Edge Cloud lorsqu'ils sont pleins. Le compromis réside dans la portée, puisque Edge Cloud fonctionne dans plus de 615 emplacements. Une base dense sur Private Fleet, avec Edge Cloud pour les pics et les régions plus éloignées, permet d'obtenir les deux.
Limitez le nombre de chambres par processus à ce qu'une version profilée a mesuré, et recyclez les serveurs selon un calendrier planifié. Découvrez comment le taux de remplissage affecte vos coûts d'hébergement.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
L'autorité du serveur au prix d'un relais
Les équipes ont généralement choisi les relais et le peer-to-peer parce qu'un serveur par match coûtait trop cher, et rarement parce qu'un relais offrait un meilleur match. Un serveur multi-salons change la donne : chaque match dispose d'un salon dans un mini-serveur, soit environ 0,05 vCPU de plus, et le serveur conserve toujours l'état.
C'est une amélioration majeure par rapport à un relais. Le serveur décide de ce qui s'est passé, chaque joueur est à un seul saut de celui-ci, personne ne bénéficie de l'avantage de l'hôte, et le match survit au départ de n'importe quel joueur. Bloody Bastards, un jeu mobile avec 40 millions de téléchargements, est passé du peer-to-peer à des serveurs dédiés et un système de matchmaking, avec « zéro tricheur depuis » (étude de cas, 2026).
C'est le choix le plus rentable lorsque la tâche du serveur est légère : règles du tour par tour, table de cartes, arbitrage d'un résultat. Une simulation lourde mérite son propre serveur de taille adaptée.
,
