El desarrollador James Monger (jkm.dev) descompiló un cliente de RuneScape 2 de 2004 para mostrar cómo Jagex hacía funcionar un RPG multijugador en vivo sobre un módem de 56k, que apenas ofrecía unos 5 KB/s de bajada. El artículo sigue un solo clic, "avanzar una casilla hacia el norte", byte a byte, desde el ratón del jugador hasta el servidor y de vuelta a la pantalla de otro jugador.

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);
}

Tres limitaciones marcaron el diseño: el ancho de banda mínimo del módem, el hecho de que el juego corría como un applet de Java confinado a una única conexión TCP sin sockets en bruto ni UDP, y un servidor que avanzaba en ciclos fijos de unos 600 milisegundos, recalculando en cada tick lo que veía cada jugador.

Antes de intercambiar datos de juego, cliente y servidor configuran un cifrado de flujo ISAAC que cifra únicamente el byte de opcode al inicio de cada paquete, no el resto del contenido. Dos flujos corren en paralelo, uno por dirección, derivados de cuatro enteros intercambiados durante el inicio de sesión; el flujo servidor a cliente suma 50 a cada valor semilla para que ambas direcciones nunca compartan el mismo flujo de claves.

Un paquete de "caminar a una casilla" contiene un opcode, un byte de longitud, las coordenadas iniciales absolutas como dos valores de 16 bits, y después solo los vértices del camino como deltas de un byte con signo, en vez de cada casilla recorrida. Un último byte indica si se mantenía pulsada la tecla Ctrl, que en versiones antiguas forzaba el modo de carrera y más tarde invertía el interruptor de movimiento. El orden de los campos y los desplazamientos de bytes también se mezclaban entre versiones del juego como medida anti-trampas.

El servidor procesa cada ciclo de 600 ms en un orden fijo: leer los paquetes entrantes, ejecutar la lógica del juego, construir las actualizaciones salientes y luego enviarlas. Un paquete que llega justo antes de que empiece un ciclo se procesa casi al instante, otro que llega justo después espera hasta 600 milisegundos.

El servidor responde a cada cliente, en cada ciclo, con un único paquete compuesto de "actualización de jugadores", que cubre al jugador local, a los jugadores cercanos ya rastreados y a los recién llegados. La mayor parte se empaqueta bit a bit en lugar de byte a byte: un jugador sin cambios cuesta un solo bit, uno que acaba de caminar cuesta unos siete bits, y la posición de un jugador recién visible se guarda como dos deltas de 5 bits con signo relativos al observador, en lugar de coordenadas mundiales completas de 16 bits. Solo los cambios detallados, como una nueva animación o un cambio de equipo, pasan a campos alineados por byte, añadiendo entre 44 y 80 bytes por jugador cuando se transmiten datos de apariencia.

Según los cálculos de Monger, el paquete de caminata saliente cuesta unos siete bytes, y la actualización que recibe otro jugador cercano sobre ese paso cuesta unos nueve bytes, todo dentro de una ventana de 600 ms con amplio margen sobre los 5 KB/s disponibles para decenas de jugadores simultáneos.

La conclusión más amplia del artículo es que el cliente y el servidor de RuneScape se comportan como un único programa dividido por una conexión de red. Ambos lados acuerdan de antemano los valores por defecto, los rangos de visibilidad y los formatos de paquete, de modo que casi nada necesita explicitarse en el cable. Las API web modernas cambian esa eficiencia por un acoplamiento débil y despliegues independientes, una decisión acertada cuando el ancho de banda es barato y la velocidad de cambio importa más que los bytes.