Dans un article de 2024, le développeur Freddie W a documenté la difficulté de faire communiquer deux instances de jeu via Steam Networking sur la même machine. Cette expérience reflète une tendance plus large. D'après une expérience directe de développement avec le Steam Online Subsystem d'Unreal, tester localement un serveur dédié intégré à Steamworks implique plusieurs exigences qui se chevauchent, et un réseau domestique n'est pas configuré pour toutes les satisfaire.

La réponse n'est pas un contournement Steam. Il s'agit de repenser dès le départ l'environnement de test : en ligne.

À quoi ressemble réellement un bon test multijoueur

Avant d'aborder la contrainte spécifique à Steam, il est utile de définir la norme par rapport à laquelle vous testez.

Un bon test multijoueur présente trois caractéristiques. Il s'exécute sur la même infrastructure que celle avec laquelle vous publierez le jeu, de sorte que les différences d'environnement ne masquent pas les bugs jusqu'à la sortie. Il s'exécute dans de vraies conditions réseau, afin que les problèmes sensibles à la latence apparaissent en développement plutôt qu'après le lancement. Et il impose rapidement une configuration correcte, de sorte que l'écart entre votre configuration locale et une build packagée ne s'accumule pas silencieusement jusqu'à casser au pire moment.

Les tests locaux avec deux fenêtres sur la même machine échouent sur les trois points. Localhost a une latence nulle et aucune perte de paquets. Votre build de l'éditeur se comporte différemment de la version packagée de votre serveur. Et ce qui passe en local peut ne rien refléter de ce que les joueurs rencontrent réellement.

Un bon test ne consiste pas seulement à se demander « est-ce que ça se connecte ? ». C'est : « est-ce que ça se connecte, sur une infrastructure réelle, dans de vraies conditions, avec la configuration que vous expédierez réellement ? »

Pourquoi les tests locaux Steamworks sont particulièrement difficiles

Le problème central est qu'un serveur dédié Steamworks hébergé localement a besoin de plus qu'un code correct pour être testable. Plusieurs éléments doivent s'aligner en même temps.

L'authentification du serveur vient en premier. Le serveur dédié doit s'initialiser avec Steam via SteamGameServer_Init et terminer sa séquence de connexion avant que les clients puissent établir correctement la négociation de connexion. Si cette authentification n'est pas entièrement résolue, la connexion échoue sans message d'erreur clair expliquant pourquoi.

La visibilité dans le navigateur de serveurs est l'endroit où le réseau domestique crée le plus gros obstacle. Les serveurs maîtres de Valve doivent pouvoir atteindre votre serveur hébergé localement depuis Internet pour le lister et le vérifier. La configuration NAT d'un routeur domestique standard bloque ces requêtes entrantes par défaut. Votre serveur peut apparaître dans la liste locale des serveurs LAN tout en restant complètement invisible dans le navigateur de serveurs Internet, même avec des ports ouverts manuellement. C'est la raison la plus courante pour laquelle les développeurs passent des heures à déboguer une configuration techniquement correcte.

L'ouverture des ports ajoute une couche supplémentaire. Le serveur a besoin qu'un port de jeu et un port de requête soient ouverts. Le port de requête est distinct, et l'oublier casse l'enregistrement dans le navigateur de serveurs et peut briser silencieusement la négociation de connexion, même lorsque le port de jeu semble accessible.

Aucune de ces exigences n'est inhabituelle prise isolément. Ensemble, sur un réseau domestique, elles créent une configuration qu'il est vraiment difficile de valider sans infrastructure réelle.

Le contournement Steamworks existe, mais il ne suffit pas

Le contournement pratique vers lequel la plupart des développeurs se tournent est la connexion directe par IP : contourner complètement le navigateur de serveurs et connecter le client au serveur via une adresse IP brute. Cela contourne le problème de visibilité des serveurs maîtres et fonctionne assez bien pour des tests fonctionnels de base sur un réseau local.

Cela ajoute ses propres exigences. La connexion directe par IP via la couche réseau Steamworks nécessite une configuration correcte de l'API ISteamNetworkingSockets et une désactivation explicite du relais afin d'éviter de faire transiter involontairement le trafic par l'infrastructure de Valve. Le cas d'une seule machine ajoute encore des frictions : le serveur et le client qui se disputent les mêmes liaisons de sockets Steamworks peuvent provoquer des échecs d'initialisation. C'est le problème précis documenté par Freddie W, et le même fil de discussion de la communauté le confirme : sur une seule machine, les contournements s'accumulent.

L'IP directe vous mène à une connexion. Elle ne vous mène pas à la parité avec la production ni à de vraies conditions réseau. Et la configuration sous-jacente doit toujours être correcte avant que tout cela ne fonctionne.

La solution : tester sur de véritables serveurs dédiés

La solution n'est pas un contournement Steam. C'est de retirer complètement le serveur de l'équation du client Steam.

Un serveur dédié n'a pas d'identifiant Steam. Ce n'est pas un client Steam. Il n'a pas besoin d'un compte connecté pour fonctionner. Lorsque votre machine locale se connecte à un serveur dédié déployé dans le cloud, la contrainte Steamworks devient d'une simplicité triviale : une machine, un client Steam, un compte. Exactement la configuration pour laquelle Steam a été conçu.

C'est aussi le bon modèle mental pour le développement. Votre client communique avec un serveur. Le serveur est une infrastructure. C'est l'architecture que vos joueurs vivront, et tester contre elle dès le premier jour signifie que ce qui fonctionne en développement est réellement livré.

Cela valide aussi la configuration dans le bon contexte. La configuration du Steam Online Subsystem d'Unreal, les entrées DefaultEngine.ini , l'emplacement de steam_appid.txt, tout cela est mis à l'épreuve face à une vraie version packagée du serveur, et pas seulement dans l'éditeur. La dérive de configuration, l'accumulation silencieuse des différences entre les environnements local et de production, est stoppée avant même de commencer.

L'orchestration de serveurs de jeu d'Edgegap déploie des serveurs dédiés dans plus de 615 emplacements dans le monde. Votre serveur de test est hors de la contrainte du client Steam et fonctionne dans de vraies conditions réseau, dans un véritable site edge, avec une vraie latence entre le client et le serveur. Les bugs que vous trouvez sont ceux qui comptent.

Y parvenir en quelques minutes, sans compilation à partir des sources

L'objection historique aux tests de serveur dédié pendant le développement actif, c'est le temps de mise en place. Compiler Unreal à partir des sources, configurer les cibles de serveur Linux, empaqueter, téléverser : le processus pouvait prendre la majeure partie d'une journée avant même que le premier test ne s'exécute.

L'extension Docker pour Unreal Engine d'Edgegap supprime cet obstacle. Elle élimine entièrement la nécessité de compiler à partir des sources, gère automatiquement la build du serveur Linux et le Dockerfile, et déploie en quelques minutes un serveur dédié opérationnel sur le réseau edge d'Edgegap. Aucune expertise DevOps requise. Pas de deuxième machine.

Le résultat est un environnement de test qui remplit dès le départ les trois critères : la même infrastructure que la production, de vraies conditions réseau, une configuration correcte imposée dès le premier test. Et contrairement au contournement à deux machines ou à l'astuce du nom IPC, ce flux de travail passe à l'échelle. Chaque développeur de l'équipe teste de la même manière, contre le même type de serveur, dès le premier jour du développement multijoueur.

L'environnement de test n'est pas non plus un travail jetable. Le serveur que vous déployez pour tester est celui avec lequel vous livrez.

—

Cet article s'appuie sur une expérience directe de développement avec le Steam Online Subsystem d'Unreal, et fait référence à un article de blog de Freddie W publié sur What is TsFreddie Doing? en septembre 2024, ainsi qu'à la documentation de l'API Steamworks de Valve. Tous les droits sur le contenu original appartiennent à leurs propriétaires respectifs.