La documentation officielle d'Iron Gate Studio sur le serveur dédié offre un regard plus approfondi sur les décisions d'infrastructure derrière l'un des jeux de survie les plus joués sur Steam. Le guide est rédigé pour les opérateurs, pas pour les ingénieurs. Mais, en le lisant attentivement, il révèle des choix architecturaux délibérés (à savoir, deux configurations de serveur, une limite stricte de joueurs et une philosophie d'hébergement d'abord communautaire) dont tout développeur multijoueur peut tirer des leçons.

Indirectement, l'approche de Valheim montre ce qui se passe lorsqu'un petit studio prend des décisions d'infrastructure qui dépassent de loin ce que son équipe aurait pu gérer seule.

Deux configurations de serveur, un seul jeu

La plupart des jeux livrent un seul backend réseau et vivent avec ses limites. Iron Gate en a livré deux, et cette distinction compte pour quiconque essaie de jouer sur plusieurs plateformes.

Le backend Steam connecte les joueurs directement via la couche réseau de Valve. Il est propre, peu gourmand en ressources et ne nécessite aucun intermédiaire. Il ne fonctionne toutefois que pour les utilisateurs Steam sur PC. Un groupe d'amis qui sont tous sur Steam, tous sur la même plateforme, peut lancer un serveur direct sans configuration supplémentaire. Mais dès que quelqu'un sur Xbox ou PC Game Pass veut rejoindre la partie, cette voie se ferme.

Le backend crossplay change la donne. En faisant transiter le trafic par les serveurs relais PlayFab Party d'Azure de Microsoft, il ouvre le jeu aux joueurs Xbox et PC Game Pass en plus des utilisateurs Steam. Les serveurs dédiés exécutés en mode crossplay n'exigent pas de redirection de port, et le relais gère automatiquement la connectivité externe. Pour les opérateurs qui font tourner un monde persistant accessible à des amis sur plusieurs plateformes, un serveur dédié avec le crossplay activé est la seule option.

Le choix se fait au lancement à l'aide d'un seul drapeau : -crossplay. Ajoutez-le et vous obtenez le crossplay. Omettez-le et vous obtenez des connexions directes réservées à Steam. Iron Gate a documenté ouvertement les deux configurations sur sa page d'assistance officielle, y compris les compromis de chacune.

Le relais d'Azure

PlayFab Party est le réseau de relais de Microsoft pour le multijoueur de jeux. Lorsqu'un serveur Valheim fonctionne en mode crossplay, il se connecte à l'un des nœuds relais régionaux d'Azure plutôt que d'accepter directement les connexions des joueurs. Les joueurs se connectent à ce relais, pas au serveur lui-même. Le relais gère le routage entre eux.

La documentation d'Iron Gate est franche quant à ce que cela coûte. Le wiki Valheim note que les joueurs en crossplay sont plus susceptibles de subir des latences, des délais d'attente et des déconnexions que sur le backend Steam direct. Le relais ajoute un saut réseau, et son emplacement est choisi automatiquement par le serveur en fonction de la proximité avec l'une des quelque 17 régions Azure. Les opérateurs n'ont aucune prise sur le relais sur lequel tombent leurs joueurs. Un serveur dans une région peut finir par acheminer le trafic via un relais situé loin d'une partie de son groupe de joueurs, sans aucun recours.

Il s'agit d'un compromis courant dans les architectures fondées sur des relais. Les relais simplifient la connectivité et éliminent les frictions de configuration, mais le trafic emprunte toujours un chemin plus long que ne le ferait une connexion directe. Pour les studios confrontés au même choix, une alternative consiste à remplacer un relais polyvalent par une petite instance de serveur dédié déployée près du groupe de joueurs. Un serveur de jeu de moins de 0,25 vCPU dans un emplacement en périphérie offre l'autorité serveur sans le saut relais supplémentaire. Des plateformes comme le réseau d'orchestration d'Edgegap rendent les déploiements fractionnés viables dans plus de 615 emplacements mondiaux, offrant aux studios un moyen de combiner l'accessibilité des configurations de type relais avec le profil de latence d'une connexion directe.

Crossplay ou mods : choisissez l'un des deux

La double configuration du serveur a une conséquence que les opérateurs doivent anticiper : le crossplay et les mods ne peuvent pas fonctionner simultanément.

Le chargeur de mods BepInEx, largement utilisé, s'accroche à la couche réseau Steam de Valheim. Activer le crossplay remplace entièrement cette couche par la pile PlayFab, et lorsque cela se produit, BepInEx ne se charge pas. Aucun mod ne fonctionne. Les deux piles réseau ne partagent pas de couche d'abstraction commune, il n'existe donc aucune option hybride.

Le choix correspond clairement à la composition de votre groupe de joueurs. Un groupe sur Steam peut faire tourner un serveur moddé sur le backend Steam, avec des connexions directes et la prise en charge complète des mods. Un groupe qui inclut des joueurs Xbox ou Game Pass a besoin du crossplay activé, et avec lui, d'un serveur vanilla. Les opérateurs qui le savent dès le départ peuvent planifier leur configuration de serveur, leur liste de mods et leur groupe de joueurs en conséquence. C'est une contrainte pratique, pas un échec de conception.

La limite de 10 joueurs

Le système de synchronisation des objets de Valheim utilise une structure appelée ZDO (Zone Data Object). Chaque entité du monde — joueurs, créatures, pièces de construction, animaux apprivoisés — est représentée par un ZDO. Lorsqu'un ZDO change d'état, l'objet complet est renvoyé plutôt que les seuls champs modifiés. Plus simple à implémenter et plus adapté aux mods, mais gourmand en bande passante. À mesure que le nombre de joueurs augmente, le volume de ZDO actifs dans une zone donnée augmente aussi, et le volume total de données d'état par tick augmente avec lui.

L'analyse communautaire de l'assemblage réseau du jeu, documentée en détail sur le blog de James A. Chambers, a mis au jour des limites codées en dur sur les taux d'envoi et de réception dans le gestionnaire ZDO. Les mods peuvent lever ces limites, mais les tests de la communauté ont montré que même avec des mods réseau, les performances se dégradent sensiblement à l'approche de 5 à 6 joueurs simultanés. Le plafond de 10 joueurs est la surface visible d'un budget de bande passante plus profond. Les grandes structures construites par les joueurs et les populations d'animaux apprivoisés exercent une pression supplémentaire sur ce budget, indépendamment du nombre de joueurs, ce que la propre documentation d'Iron Gate reconnaît.

Un binaire gratuit, un écosystème florissant

L'une des décisions d'infrastructure les plus importantes d'Iron Gate n'était pas technique. Elle était économique.

Le binaire du serveur dédié est gratuit et disponible pour tout le monde via Steam Tools, sans achat du jeu requis. Iron Gate publie le guide d'installation complet sur son site officiel, y compris les instructions Docker, les paramètres de lancement, les commandes administrateur et la configuration des sauvegardes. Ils ont remis aux opérateurs tout ce dont ils avaient besoin puis se sont effacés.

Le résultat est qu'Iron Gate a déchargé entièrement les coûts et les opérations de serveur sur la communauté et sur les fournisseurs d'hébergement commerciaux. Des sociétés comme G-Portal, BisectHosting et Nitrado hébergent désormais des milliers de serveurs Valheim, gèrent la protection DDoS, fournissent des panneaux de contrôle et assurent le support client — autant de choses qu'Iron Gate ne paie pas. Ce qui aurait pu être un centre de coûts est devenu une chaîne d'approvisionnement d'hébergement distribuée financée par des joueurs prêts à payer environ 10 à 15 $ par mois plutôt qu'à faire tourner leur propre matériel.

Pour les studios qui réfléchissent aux serveurs communautaires, ce modèle mérite d'être examiné. La stratégie du binaire gratuit fonctionne parce qu'elle crée un marché qui sert les joueurs sans obliger le développeur à l'exploiter. Les studios qui veulent une implication plus directe, y compris la possibilité de proposer la location de serveurs depuis le jeu lui-même, avec un provisionnement géré automatiquement et des revenus revenant au studio, peuvent explorer des plateformes d'orchestration conçues exactement pour cela. L'infrastructure existe. Qu'elle corresponde ou non au modèle économique d'un studio donné est une autre question, mais l'option est réelle et de plus en plus accessible.

Des mondes portables

Un détail de conception qui renforce le modèle hébergé par la communauté se trouve discrètement dans le guide d'installation d'Iron Gate : l'état du monde de Valheim est stocké dans deux fichiers locaux. Un fichier .db contient toute la progression du monde, et un fichier .fwl contient la graine. Les deux suivent l'opérateur.

Il n'y a aucun verrouillage par le cloud. Un groupe qui s'auto-héberge peut migrer vers un serveur loué en copiant deux fichiers. Un groupe louant chez un fournisseur peut passer à un autre en téléchargeant une sauvegarde puis en la réimportant. La documentation d'Iron Gate traite cela comme une procédure courante, en l'expliquant de façon très concrète.

Pour les joueurs, cela signifie une véritable propriété de leur monde. Pour les développeurs, c'est un rappel que l'architecture de persistance façonne la confiance des joueurs. Les mondes que l'on peut conserver, déplacer et sauvegarder sont des mondes dans lesquels les joueurs investissent sur le long terme. Verrouiller l'état du monde à un service propriétaire peut simplifier le développement, mais cela crée exactement le type de dépendance que les joueurs remarquent quand les choses tournent mal.

---

[Note de l'éditeur] Contrairement aux autres articles de cette série, cet article s'appuie sur la documentation officielle du serveur dédié d'Iron Gate Studio et sur le Wiki communautaire de Valheim plutôt que sur une conférence de développeurs ou un post-mortem. Les enseignements architecturaux sont réels et vérifiables, et sont extrapolés de nos connaissances plutôt qu'énoncés directement par Iron Gate.

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