DOOM tumbaba redes enteras: por qué lo prohibieron en los 90

Por

Fotograma del Short de MatchCode sobre DOOM: mapa de una red con grupos de computadores conectados

Sí, es real: DOOM tumbaba redes de universidades y oficinas enteras. No porque fuera un juego pesado, sino por a quién le mandaba sus datos. Sus primeras versiones le hablaban a toda la red a la vez, y con un par de partidas bastaba para frenarla.

Aquí va el porqué, paso a paso.

Qué era DOOM y por qué se jugaba en red

DOOM salió en diciembre de 1993 y traía algo que en su momento era una locura: multijugador en red local. Si usted estaba en un campus o en una oficina, podía jugar contra los compañeros conectados a la misma red.

El modo red usaba IPX, el protocolo típico de las redes Novell de la época. Hasta ahí, todo bien. El problema estaba en cómo enviaba los paquetes.

Por qué DOOM tumbaba redes: el broadcast

Las primeras versiones de DOOM (antes de la 1.2) mandaban sus paquetes por broadcast. Es decir, cada paquete iba a todos los computadores de la red, estuvieran jugando o no.

Piénsalo así:

Es como gritarle a un auditorio entero para hablar solo con tres amigos.

El efecto multiplicador

Un juego de acción no manda un mensaje de vez en cuando: manda paquetes sin parar, porque la posición de cada jugador cambia todo el tiempo. Y cada jugador gritaba.

Así que con un par de partidas de cuatro, el tráfico se disparaba y la red completa quedaba frenada. En campus grandes, con cientos de equipos, el golpe se sentía en todos lados.

Lo prohibieron (y hasta crearon una herramienta para cazarlo)

La reacción de muchos administradores de red fue directa: prohibir DOOM. Y hubo quien fue más lejos.

En marzo de 1994 apareció KILLDOOM, una utilidad para redes Novell que buscaba las partidas de DOOM en la red y las cerraba. Su documentación todavía se puede leer hoy, y es un buen retrato de lo que fue esa época.

Ojo: circulan historias muy famosas, como un memo interno de una gran empresa prohibiendo el juego o avisos de universidades concretas. Algunas aparecen citadas en libros, pero no encontramos dos fuentes independientes que las confirmen, así que aquí no las damos como dato duro.

La solución: de broadcast a unicast

Lo curioso es que la solución no fue hacer el juego más liviano. Fue cambiar a quién le hablaba.

Desde la versión 1.2, id Software dejó de usar broadcast y DOOM empezó a mandarles los paquetes solo a los otros jugadores. Eso se llama unicast: un mensaje con destinatario concreto.

| | Broadcast (antes de la 1.2) | Unicast (desde la 1.2) | |---|---|---| | A quién llega cada paquete | A todos los equipos de la red | Solo a los jugadores | | Equipos que no juegan | Reciben y descartan todo | No se enteran | | Efecto en la red | Se satura con pocas partidas | Carga mucho menor |

La misma idea que en el local de Halo 2

Es el mismo principio de cualquier local de videojuegos con consolas conectadas: el switch le lleva cada paquete solo a la consola que lo necesita, y las demás siguen jugando sin interrupción. DOOM lo aprendió a las malas.

Si te interesa cómo funciona todo esto en los juegos de hoy, está explicado en el video largo de MatchCode: ¿Cómo FUNCIONAN realmente los JUEGOS MULTIJUGADOR?.

Preguntas frecuentes

¿Por qué DOOM saturaba las redes?

Porque sus primeras versiones enviaban los paquetes del modo red por broadcast, a todos los computadores, aunque no estuvieran jugando.

¿En qué versión se corrigió?

En la versión 1.2, que dejó de usar broadcast y pasó a enviar los paquetes solo a los jugadores (unicast).

¿Qué era KILLDOOM?

Una utilidad de 1994 para redes Novell que detectaba partidas de DOOM en la red y las cerraba.

Míralo en 80 segundos

En esencia, DOOM no era un juego pesado: era un juego que le gritaba a toda la red. Mira la historia animada en el Short de MatchCode sobre DOOM y sigue a @MatchCodeOficial en YouTube, TikTok e Instagram, y en matchcode.dev.

Fuentes