Réinventer le Multijoueur en Temps Réel : Architectures Pub-Sub Avancées pour le Matchmaking Inter-Régional

Alors que les jeux multijoueurs en temps réel se développent à l’échelle mondiale, les modèles de mise en réseau traditionnels sont mis à rude épreuve par les attentes de faible latence, les contraintes de conformité et la distribution imprévisible des joueurs.

Dans cet article, j’explore comment les architectures pub-sub basées sur des événements—lorsqu’elles sont utilisées en combinaison avec le partitionnement des canaux, la superposition de courtiers et le routage conscient de la latence—peuvent transformer les systèmes de matchmaking en infrastructures évolutives, résilientes et accessibles à l’échelle mondiale.

Les approches décrites sont le résultat de plusieurs années de conception et de déploiement de systèmes backend en temps réel dans des titres multijoueurs casual et basés sur des cartes commercialement réussis.

Pourquoi l’industrie doit aller au-delà du “Matchmaking Simple”

La plupart des backends de jeux mobiles reposent encore sur des serveurs de matchmaking monolithiques ou des systèmes de file d’attente naïfs qui supposent la proximité géographique, une latence uniforme et un accès stable aux serveurs. Cette hypothèse se brise rapidement dans le monde réel :

• Les joueurs rejoignent depuis des régions à latence diverse.

• Les restrictions de pare-feu et de conformité limitent l’accès à certains centres de données.

• Le trafic de pointe entraîne des goulets d’étranglement dans les files d’attente ou un renouvellement des matchs.

Pour y remédier, nous devons changer notre modèle mental : le matchmaking n’est pas un processus linéaire mais un pipeline dynamique à plusieurs étapes avec des points de décision qui doivent s’adapter en temps réel.

Le Rôle du Pub-Sub dans l’Infrastructure Multijoueur Moderne

Contrairement aux sockets point à point ou aux API REST, les systèmes Publisher-Subscriber (pub-sub) permettent :

• L’orchestration asynchrone des salons, de l’état des matchs et des intentions des joueurs.

• Un couplage lâche entre les clients, les instances de jeu et la logique d’orchestration.

• Le routage des messages multi-régions sans surcharger les serveurs d’origine.

Dans ce modèle, chaque étape de l’expérience joueur est pilotée par des événements. De la découverte de salon à la soumission de mouvement, les événements sont publiés dans des canaux basés sur des sujets ou des canaux de diffusion qui gèrent le routage et la transformation de manière transparente.

Modèle d’Architecture : Sharding de Salon via des Canaux Dynamiques

Dans nos déploiements réels, nous avons évolué vers une architecture de matchmaking shardée qui assigne les joueurs à des salons via des canaux pub-sub dynamiques. Voici comment cela fonctionne :

2. La passerelle d’entrée reçoit une demande de jeu et publie une “demande de rejoindre” dans un sujet de matchmaking spécifique à la région.

3. Un service de matchmaking (sans état, évolutif horizontalement) s’abonne à ce sujet et route le joueur vers un shard de salon—un canal pub-sub éphémère.

4. Une fois qu’un shard atteint le quorum (par exemple, 4 joueurs), le service publie un événement start_game à tous les clients abonnés.

5. Chaque client passe ensuite à une session de jeu en temps réel gérée via un sujet d’état de match dédié.

Ce modèle nous permet de faire évoluer le matchmaking indépendamment des sessions de jeu et d’appliquer une logique personnalisée (comme l’équilibrage ELO, l’optimisation de la latence ou le profilage anti-triche) avant la formation des matchs.

Maillage de Courtiers Inter-Régions : Résoudre le Problème des “Serveurs Bloqués”

Un défi plus avancé que nous avons résolu concerne la conformité transfrontalière et la bascule. Dans les régions où l’accès à l’infrastructure cloud étrangère est restreint (par exemple, certains pays de la CEI), nous utilisons un maillage de courtiers :

• Les joueurs régionaux se connectent à des courtiers de périphérie locaux.

• Ces courtiers font partie d’une topologie pub-sub en couches où les sujets de match clés sont relayés en toute sécurité à travers les frontières via des tunnels cryptés.

• Cela empêche les régions bloquées de devenir des zones mortes de matchmaking sans forcer toutes les données à passer par un backbone central.

Nous avons construit un contrôleur de relais conscient de la latence qui détermine dynamiquement s’il faut faire correspondre les joueurs localement, router à travers des nœuds intermédiaires ou exclure des régions incompatibles—assurant la conformité sans compromettre l’expérience utilisateur.

Leçons Clés de l’Utilisation en Production

À travers des millions de sessions et des matchs PvP basés sur de l’argent réel, quelques insights se démarquent :

• L’hygiène des sujets est critique. Les sujets à expiration automatique ou éphémères préviennent les fuites de mémoire et les joueurs fantômes.

• La sélection des courtiers compte. Redis PubSub est simple mais manque de garanties d’ordre et de livraison ; NATS et Kafka offrent plus de contrôle au prix de la complexité de configuration.

• L’observabilité doit être intégrée. Chaque événement de message doit être traçable—OpenTelemetry nous a aidés à déceler des désynchronisations subtiles et des délais d’attente.

• Les solutions de secours côté client sont non négociables. Lorsque le pub-sub échoue (par exemple, des réseaux mobiles peu fiables), les clients passent gracieusement en mode de récupération par sondage.

Vers une Orchestration Entièrement Sans Serveur

Nous explorons maintenant une architecture d’abord sans serveur pour les futurs jeux, où

• La logique de matchmaking est exprimée sous forme de fonctions pilotées par des événements (par exemple, AWS Lambda, GCP Cloud Functions).

• L’orchestration des salons fonctionne sur des conteneurs sans état qui se mettent en route par région lors des pics de charge.

• Le pub-sub reste le tissu central pour le matchmaking et la messagerie en jeu, abstraisant les complexités du routage d’infrastructure.

Cela réduit le temps de démarrage à froid, simplifie les pipelines de déploiement et rend viable le soutien à des millions de matchs quotidiens avec un faible coût opérationnel.

Conclusion

Le pub-sub n’est pas qu’un détail d’implémentation—c’est une opportunité de redéfinir comment les jeux multijoueurs évoluent, s’adaptent et survivent dans des conditions modernes.

En l’appliquant non seulement au gameplay mais aussi à l’orchestration des salons, à la conformité régionale et à la résilience du matchmaking, nous débloquons une nouvelle génération d’expériences mobiles qui sont en temps réel, équitables et disponibles à l’échelle mondiale par conception.

L’article est un éditorial rédigé par Andrei Kulakov

Andrei Kulakov est architecte système et designer de jeux, axé sur l’infrastructure multijoueur pour les jeux mobiles et casual. Il a contribué à certains des cadres de matchmaking les plus techniquement robustes en Europe de l’Est et explore actuellement des architectures sans serveur pour le multijoueur mondial à grande échelle.

Cette histoire a été publiée à l’origine le 3 octobre 2022