Mark Frohnmayer et Tim Gift ont écrit sans doute l'un des articles les plus influents sur le networking multijoueur dans l'industrie du développement de jeux en tant que développeurs sur TRIBES chez Dynamix – disponible intégralement ici.

Bien que daté, il souligne les meilleures pratiques que tout studio de jeu, grand ou petit, peut ajouter à son multijoueur pour contribuer à améliorer son architecture en ligne. Jetons un "œil" à leurs idées.

Examinons le modèle de networking multijoueur de TRIBES rocking, jeu de mots intentionnel.  

Repenser les Priorités de Données

Le modèle de networking de TRIBES a pris du recul par rapport à la recherche de bande passante brute. Il s'est plutôt demandé quelles mises à jour importaient réellement et quand elles devaient arriver. En assignant des niveaux d'urgence et de fiabilité à chaque élément de l'état du jeu, il a déplacé l'attention de l'inondation des canaux vers la livraison des bonnes données au bon moment.

Ce changement a redéfini l'efficacité dans le jeu en temps réel. Les développeurs ne traitaient plus tous les paquets de la même manière mais adaptaient la livraison aux exigences de chaque type de données, garantissant que les entrées critiques avançaient tandis que les mises à jour moins vitales attendaient leur tour.

Quand la Vitesse Rencontra la Fiabilité

A sa base se trouvait un gestionnaire de connexion léger basé sur UDP qui ne rapportait que le succès ou l'échec. Les tentatives automatiques ont été supprimées, laissant aux couches supérieures le soin de décider si et comment récupérer d'une perte.

Cette séparation des préoccupations a permis à des gestionnaires spécialisés d'imposer uniquement les garanties dont chaque flux avait besoin. C'était un mouvement délibéré loin des protocoles universels vers un système plus précis.

Le résultat était une architecture réseau qui restait en arrière-plan jusqu'à ce que quelque chose nécessite une attention – et ensuite donnait à ces données le traitement qu'elles méritaient.

Gestionnaires de Flux Modulaires

Cinq gestionnaires de flux distincts se trouvaient au-dessus de la couche de connexion, chacun avec son propre travail et ordre dans le paquet. Événements, fantômes, mouvements, blocs de données et chaînes avaient tous des voies dédiées pour éviter les interférences.

Ils remplissaient les paquets dans une séquence fixe pour que les entrées urgentes ne soient jamais éclipsées par des données de masse. Cette chorégraphie transformait le réseau en un ensemble bien rôdé plutôt qu'en un chaos total.

Prédiction et Synchronisation

Les clients et serveurs avançaient à des intervalles fixes de 32 ms. Entre les arrivées, les clients interpolent des objets fantômes pour créer un mouvement fluide même lorsque les mises à jour prenaient du retard.

Les entrées des joueurs se sont appuyées sur trois paquets consécutifs pour maximiser les chances de livraison. Du côté client, des algorithmes de prédiction testaient en amont des données fraîches, tandis que le serveur validait chaque mouvement et réconciliait les différences à l'arrivée.

Cette approche duale maintenait le gameplay impressionnant, avec des artefacts de réconciliation cachés aux yeux de tous sauf du joueur concerné.

Efficacité de Bande Passante et Évolutivité

Les actifs statiques—géométrie de carte, plans de véhicules, et similaires—ne circulaient qu'une seule fois sur le flux “Datablock” et restaient ensuite mis en cache. Cela signifie que les transferts de routine restaient minimaux, libérant de l'espace pour des mises à jour en temps réel.

Les fantômes reflétaient l'état des objets en envoyant uniquement les bits modifiés, évitant ainsi les instantanés obsolètes qui gaspillaient des cycles et des octets. Avec chaque paquet transportant uniquement des informations fraîches, le système contournait le piège de renvoyer ce que tout le monde savait déjà.

Ce design stratifié s'est avéré adaptable, que ce soit sur un modem à composer ou un haut débit moderne, et a posé les bases de grandes cartes extérieures avec de nombreux joueurs simultanés.

Héritage du Réseau TRIBES

Lorsque Starsiege TRIBES a été lancé en 1998, son cadre de networking a alimenté des batailles tentaculaires et a contribué à définir les tireurs en ligne de l'époque. Plus tard, TRIBES II a perfectionné les en-têtes, compressé les chaînes, et ajusté les retransmissions pour une performance encore plus légère.

Les développeurs de l'époque ont expérimenté avec des débits de paquets dynamiques, des E/S multithreadées, et une première intégration vocale – tout en s'appuyant sur la leçon fondamentale que les données doivent voyager selon des règles conçues pour leur rôle unique.

Des décennies plus tard, le modèle TRIBES reste un témoignage du pouvoir de la séparation des préoccupations et de l'adaptation des stratégies de livraison aux véritables besoins du multijoueur en temps réel.

---

Cet article est basé sur et cite l'article original de Mark Frohnmayer et Tim Gift, publié sur gamedevs.org. Tous les droits sur le contenu original appartiennent à leurs propriétaires respectifs.