Le développeur James Monger (jkm.dev) a décompilé un client RuneScape 2 de 2004 pour montrer comment Jagex faisait tourner un RPG multijoueur en direct sur un modem 56k, qui ne fournissait qu'environ 5 Ko/s en réception. L'article suit un simple clic, "avancer d'une case vers le nord", octet par octet, depuis la souris du joueur jusqu'au serveur puis jusqu'à l'écran d'un autre joueur.

this.outboundStream.putOpcode(ClientToServerOpcodes.WALK_TILE);
this.outboundStream.putByte(4 + 2 * (pathLength - 1) + 1);
this.outboundStream.putShort(this.playerPositionX + firstX);
this.outboundStream.putShort(this.playerPositionZ + firstZ);
for (int i = 1; i < pathLength; i++) {
 this.outboundStream.putByte(this.pathX[i] - firstX);
 this.outboundStream.putByte(this.pathZ[i] - firstZ);
}

Trois contraintes ont façonné cette conception: la faible bande passante du modem, le fait que le jeu tournait dans une applet Java confinée à une seule connexion TCP sans sockets bruts ni UDP, et un serveur qui avançait par cycles fixes d'environ 600 millisecondes, recalculant à chaque tick ce que chaque joueur pouvait voir.

Avant tout échange de données de jeu, client et serveur mettent en place un chiffrement de flux ISAAC qui ne chiffre que l'octet d'opcode en tête de chaque paquet, jamais le corps. Deux flux tournent en parallèle, un par direction, tous deux dérivés de quatre entiers échangés lors de la connexion; le flux serveur vers client ajoute 50 à chaque valeur de graine pour que les deux directions ne partagent jamais le même flux de clés.

Un paquet "marcher vers une case" contient un opcode, un octet de longueur, les coordonnées de départ absolues sous forme de deux valeurs 16 bits, puis uniquement les points d'angle du chemin sous forme de deltas signés d'un octet, plutôt que chaque case traversée. Un dernier octet indique si Ctrl était enfoncé, ce qui forçait le mode course dans les premières versions et inversait ensuite le basculement de déplacement. L'ordre des champs et les décalages d'octets étaient aussi mélangés d'une version à l'autre, en guise de protection anti-triche.

Le serveur traite chaque cycle de 600 ms dans un ordre fixe: lire les paquets entrants, exécuter la logique de jeu, construire les mises à jour sortantes, puis les envoyer. Un paquet arrivant juste avant le début d'un cycle est traité presque instantanément, un autre arrivant juste après attend jusqu'à 600 millisecondes.

Le serveur répond à chaque client, à chaque cycle, par un unique paquet composite de "mise à jour des joueurs", couvrant le joueur local, les joueurs proches déjà suivis et les nouveaux arrivants. L'essentiel est compressé bit par bit plutôt qu'octet par octet: un joueur inchangé coûte un seul bit, un joueur qui vient de marcher coûte environ sept bits, et la position d'un joueur nouvellement visible est stockée sous forme de deux deltas signés de 5 bits par rapport à l'observateur, au lieu de coordonnées mondiales complètes sur 16 bits. Seuls les changements détaillés, comme une nouvelle animation ou un équipement modifié, basculent vers des champs alignés sur l'octet, ajoutant de 44 à 80 octets par joueur lorsque les données d'apparence sont transmises.

Selon les calculs de Monger, le paquet de marche sortant coûte environ sept octets, et la mise à jour reçue par un autre joueur proche décrivant ce pas coûte environ neuf octets, le tout dans une fenêtre de 600 ms avec une large marge sur les 5 Ko/s disponibles pour des dizaines de joueurs simultanés.

La conclusion plus large de l'article: le client et le serveur RuneScape se comportent comme un seul programme scindé par une liaison réseau. Les deux côtés s'accordent à l'avance sur les valeurs par défaut, les distances de visibilité et les formats de paquets, si bien que presque rien n'a besoin d'être explicité sur le fil. Les API web modernes échangent cette efficacité contre un couplage lâche et des déploiements indépendants, un compromis pertinent quand la bande passante est bon marché et que la vitesse de changement compte plus que les octets.