La documentation officielle du serveur dédié d'Iron Gate Studio, publiée en avril 2024 et constituant toujours la référence sur laquelle s'appuient les opérateurs, explique comment faire fonctionner un serveur Valheim. Elle est rédigée pour les opérateurs, pas pour les ingénieurs. Pourtant, si on la met en parallèle avec les notes de mise à jour et la FAQ de la sortie 1.0 de Valheim le 9 septembre 2026, l'architecture derrière ces instructions devient évidente : deux configurations de serveur, une limite stricte de joueurs et un modèle d'hébergement qui s'appuie délibérément sur la communauté.

Indirectement, l'approche de Valheim montre ce qui se passe lorsqu'un petit studio prend des décisions d'infrastructure qui se développent bien au-delà de ce que son équipe aurait pu gérer seule.

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, éléments de construction, animaux apprivoisés) est représentée sous la forme d'un ZDO. Lorsqu'un ZDO change d'état, l'objet complet est réexpédié plutôt que simplement les champs modifiés. C'est plus simple à implémenter et plus adapté aux mods, mais très gourmand en bande passante. À mesure que le nombre de joueurs augmente, le volume de ZDO actifs dans une zone donnée s'accroît également, et les données d'état totales par tick augmentent proportionnellement.

Une analyse communautaire de l'assembly réseau du jeu, documentée en détail sur le blog de James A. Chambers, a révélé des limites strictes de taux d'envoi et de réception codées en dur dans le gestionnaire de ZDO. Les mods peuvent lever ces limites, mais les tests de la communauté ont révélé une dégradation notable des performances à l'approche de 5 à 6 joueurs simultanés. Le plafond de 10 joueurs n'est que la partie émergée d'un budget de bande passante plus profond. Les grandes structures bâties par les joueurs et les populations d'animaux apprivoisés pèsent sur ce même budget, indépendamment du nombre de joueurs.

Cette limite est aussi le chiffre auquel la version 1.0 n'a pas touché. Iron Gate a déployé le jeu sur quatre plateformes supplémentaires, mis à niveau le moteur et réécrit la manière dont les mondes sont sauvegardés, mais la limite reste exactement là où elle a toujours été. « Tout comme aujourd'hui, Valheim 1.0 sera un jeu pour 1 à 10 joueurs », indique la FAQ de la 1.0. Une limite qui perdure à travers une mise à jour de cette envergure n'est pas un simple paramètre temporaire en attente d'ajustement. C'est la structure même du modèle de synchronisation, et la modifier impliquerait de réécrire la façon dont l'état est répliqué plutôt que de simplement changer un chiffre dans une configuration.

C'est le point sur lequel il vaut la peine de s'attarder. Les limites de joueurs définies tôt dans le développement ont tendance à se figer, car au moment où elles commencent à poser problème, l'architecture sous-jacente supporte déjà des années de contenu accumulé.

Un binaire gratuit, un écosystème florissant

L'une des décisions d'infrastructure les plus lourdes de conséquences d'Iron Gate n'était pas technique. Elle était économique.

Le binaire du serveur dédié est accessible gratuitement à tous via les outils Steam, répertorié dans la bibliothèque de l'utilisateur en tant qu'outil, sans nécessiter l'achat du jeu. Iron Gate publie le guide d'installation complet sur son site officiel, y compris les instructions Docker, les paramètres de lancement, les commandes d'administration et la configuration des sauvegardes. Ils fournissent aux opérateurs tout ce dont ils ont besoin, puis se mettent en retrait.

Il en résulte que les coûts et l'exploitation des serveurs reposent sur la communauté et sur les fournisseurs d'hébergement commerciaux. Des entreprises comme G-Portal, BisectHosting et Nitrado hébergent des milliers de serveurs Valheim, gèrent la protection anti-DDoS, fournissent des panneaux de contrôle et assurent le support client, sans qu'Iron Gate ne débourse un centime. Ce qui aurait pu être un centre de coûts devient à la place une chaîne logistique d'hébergement distribuée, financée par des joueurs prêts à payer un abonnement mensuel plutôt que d'exploiter leur propre matériel.

Pour les studios qui envisagent des serveurs communautaires, ce modèle mérite d'être étudié. La stratégie du binaire gratuit fonctionne parce qu'elle crée un marché au service des joueurs sans obliger le développeur à le gérer. Les studios qui souhaitent une implication plus directe, notamment la possibilité de proposer la location de serveurs directement depuis le jeu avec un approvisionnement automatique et des revenus reversés au studio, peuvent explorer des plateformes d'orchestration conçues précisément à cet effet.

Mondes portables

Un monde Valheim est un dossier. Chacun se trouve dans son propre répertoire nommé d'après le monde, et une sauvegarde n'écrit que les zones qui ont été modifiées. Les notes de mise à jour de la 1.0 décrivent un « nouveau système de sauvegarde » qui « divise les données du monde en chunks afin de réduire la quantité de données sérialisées et écrites pour améliorer les performances, et est conçu pour résister aux pannes en cours d'écriture ».

Cette conception répond à deux problèmes à la fois. Réécrire un monde entier à chaque sauvegarde automatique est anodin sur une carte vierge, mais pénalisant sur une carte couverte de structures de joueurs, et un plantage en cours d'écriture peut corrompre l'ensemble du fichier. Les écritures par chunks limitent ces deux risques.

Ce qui importe pour les opérateurs, c'est que le monde est un dossier sur le disque, conservé par la personne qui gère le serveur. Un groupe qui s'auto-héberge peut migrer vers un serveur loué simplement en le copiant. Un groupe qui loue auprès d'un fournisseur peut basculer vers un autre en téléchargeant une sauvegarde et en la téléversant à nouveau. Il n'y a aucun verrouillage dans le cloud, et la documentation d'Iron Gate traite le transfert de mondes comme une opération de routine.

Pour les joueurs, cela signifie une réelle propriété de leur monde. Pour les développeurs, cela rappelle que l'architecture de persistance forge la confiance des joueurs. Les mondes qui peuvent être conservés, déplacés et sauvegardés sont des mondes dans lesquels les joueurs s'investissent sur le long terme. Verrouiller l'état d'un monde au sein d'un service propriétaire peut simplifier le développement, mais cela crée exactement le type de dépendance que les joueurs remarquent lorsque les choses tournent mal.

Deux configurations de serveur, un seul jeu

La plupart des jeux intègrent un seul backend réseau et composent avec ses limites. Valheim en intègre deux.

Le backend Steam connecte directement les joueurs via la couche réseau de Valve. Il est propre, génère peu de surcharge et ne nécessite aucun intermédiaire. Il ne concerne en revanche que les utilisateurs de Steam sur PC.

Le backend crossplay achemine le trafic via les serveurs relais Microsoft Azure PlayFab Party, et c'est lui qui réunit dans un même monde les joueurs de Steam, du Microsoft Store, du Mac App Store, de Humble, de la Xbox, de la PlayStation 5 et de la Nintendo Switch 2. La FAQ de la version 1.0 d'Iron Gate est claire : « Valheim prendra en charge le crossplay entre toutes les plateformes. »

Un seul argument permet de choisir entre les deux. L'option -crossplay est activée par défaut dans les exemples de scripts de lancement fournis avec le serveur dédié, ce qui fait de l'accès à toutes les plateformes la voie de moindre résistance, et de l'exécution directe via Steam un choix délibéré. Pour un jeu dont le public se situe en grande partie en dehors de Steam, cette valeur par défaut résume toute la stratégie en un seul paramètre.

Le relais d'Azure

PlayFab Party est le réseau de relais de Microsoft pour le multijoueur de jeux vidéo. Un serveur Valheim en mode crossplay se connecte à l'un des nœuds de relais régionaux d'Azure plutôt que d'accepter directement les connexions des joueurs. Les joueurs se connectent à ce relais, et non au serveur lui-même. Le relais gère le routage entre eux, ainsi que la visibilité publique du serveur et l'identité des joueurs interplateformes.

La documentation est transparente quant aux coûts induits. Les joueurs en crossplay sont plus susceptibles de subir des latences, des dépassements de délai et des déconnexions que les joueurs utilisant le backend direct de Steam. Le relais ajoute un saut réseau, et son emplacement est choisi automatiquement en fonction de la proximité avec l'une des quelque 17 régions Azure. Les opérateurs n'ont aucun contrôle sur le relais attribué à leurs joueurs. Un serveur situé dans une région donnée peut finir par acheminer le trafic via un relais très éloigné d'une partie de son groupe de joueurs, sans aucun recours possible.

Il s'agit d'un compromis classique dans les architectures basées sur des relais, et il est important de le comprendre avant d'en choisir une. Pour une analyse détaillée de la comparaison entre les relais, les serveurs faisant autorité et le peer-to-peer, consultez le guide explicatif d'Edgegap sur les types de réseaux.

Une alternative consiste à remplacer un relais généraliste par une petite instance de serveur dédié déployée à proximité du groupe de joueurs. Un serveur de jeu hébergé sur une fraction de vCPU sur un site en périphérie (edge) assure l'autorité du serveur sans le saut supplémentaire du relais. Des plateformes comme le réseau d'orchestration d'Edgegap rendent viables les déploiements fractionnés sur plus de 615 emplacements dans le monde, combinant l'accessibilité des configurations de type relais avec le profil de latence d'une connexion directe.

Crossplay ou mods : il faut choisir

La double configuration entraîne une conséquence que les opérateurs doivent anticiper : le crossplay et les mods ne fonctionnent pas ensemble.

Le chargeur de mods très répandu BepInEx se greffe sur la couche réseau Steam de Valheim. Activer le crossplay remplace cette couche par la pile PlayFab, et BepInEx ne se charge pas. Les deux piles réseau ne partageant aucune couche d'abstraction commune, il n'existe aucune option hybride.

Iron Gate est catégorique sur la situation des mods. Comme ils n'offrent aucun support officiel pour les mods, ils « ne peuvent garantir le fonctionnement d'aucun mod », et les versions consoles n'en intègrent aucun. La mise à niveau du moteur de la 1.0 a rendu cela très concret pour les opérateurs qui ont passé la semaine de lancement à reconstruire des listes de mods face à une cible mouvante.

La décision dépend directement de la composition de votre groupe de joueurs. Un groupe exclusivement sur Steam peut faire tourner un serveur moddé sur le backend Steam. Un groupe comprenant des joueurs sur console a besoin du crossplay, et donc d'un serveur vanilla. Il s'agit d'une contrainte pratique, et non d'un défaut de conception.

—

[Note de l'éditeur] Contrairement à d'autres articles de cette série, ce texte s'appuie sur la documentation officielle du serveur dédié d'Iron Gate Studio, la FAQ et les notes de mise à jour de Valheim 1.0, ainsi que sur le wiki de la communauté Valheim, plutôt que sur une conférence de développeurs ou un post-mortem. Les faits architecturaux sont documentés et vérifiables. L'interprétation des raisons ayant motivé ces décisions nous est propre et n'est pas formulée directement par Iron Gate.

Cet article est basé sur et cite la documentation originale ainsi que les notes de mise à jour d'Iron Gate Studio, publiées sur valheimgame.com, avec des analyses réseau complémentaires réalisées par James A. Chambers. Tous les droits sur le contenu original appartiennent à leurs propriétaires respectifs.