Estas semanas internet está que arde: GTA Vice City, Halo o Black Ops funcionando en una pestaña de Chrome, cientos de juegos decompilados con ayuda de la IA… y hasta un GTA V en el navegador que duró unas horas antes de que lo tumbaran. Y claro, uno tiene su corazoncito y esa espinita de «¿y yo podría?» 🤔
Pero si vamos a bichear, vamos a bichear con el más grande. Y para mí no hay juego más grande que DOOM. El juego que se ha portado a calculadoras, impresoras, frigoríficos, tests de embarazo… a todo lo que tenga un chip y una pantalla. Faltaba mi navegador.
El problema
Bueno, «problema»… el problema es que DOOM no funcionaba en mi navegador 😎
Pero me puse una condición: nada de una réplica cutre hecha en JavaScript que «se parezca» a DOOM. Quería el DOOM de verdad, el de 1993, que se juegue exactamente igual que en aquel PC con MS-DOS.
Y aquí viene lo bueno: id Software liberó el código fuente de DOOM en 1997, y está en GitHub. Así que, siendo honestos, esto no es ingeniería inversa pura: el código lo tenemos. Es un port, que es coger un programa escrito para Linux en los 90 y hacer que funcione en un sitio para el que nunca se pensó. (Luego veremos que la ingeniería inversa aparece por donde menos te lo esperas 👀).
Vibe coding
Lo digo ya, para que nadie se lleve las manos a la cabeza: esto lo he hecho con Claude Code, en modo vibe coding total. Estoy yo para recordar cómo funcionaba el driver de Sound Blaster en 1993, o la sintaxis de C de los 90 a estas alturas (si, «recordar» porque en mis tiempos mozos ya me peleé con ellos 👴🏻)
¿Y pasa algo? Pues no. De esto se trata: de tener una idea, tirarte a la piscina y aprender por el camino. Yo pongo el problema, el criterio y las preguntas («¿pero esto es fiel?», «¿y es legal?», «¿y cómo lo ve la gente?»), y la IA pone las horas de picar código.
Las piezas del puzle
Esto es lo que he aprendido que existe, y que no tenía ni idea:
WebAssembly, «el lenguaje ese del navegador»
Los navegadores no solo entienden JavaScript. Desde hace unos años entienden WebAssembly (o wasm para los amigos), que viene a ser una especie de código máquina para la web. Muy rápido, casi a velocidad nativa. Es lo que hace posible que hoy se puedan meter juegos de verdad, o hasta Photoshop, en una pestaña.
Emscripten, el traductor
Vale, el navegador entiende WebAssembly, pero DOOM está escrito en C. ¿Cómo pasamos de uno a otro? Con Emscripten, un compilador que coge tu código C y en vez de generar un programa para Windows o Mac te escupe un fichero .wasm y el JavaScript necesario para cargarlo.
Un brew install emscripten y a correr. El motor entero de DOOM ocupa 370 KB. Menos que muchas fotos de cabecera de blogs 😅
Los WAD, o dónde está el juego de verdad
Esto me voló la cabeza. DOOM está partido en dos: por un lado el motor (el código, que es libre) y por otro los datos: mapas, gráficos, sonidos, música… todo metido en un fichero llamado WAD («Where’s All the Data?», toma ya).
El código es libre, pero los WAD comerciales no. Así que el juego viene con el DOOM1.WAD shareware, el episodio 1 que id regalaba en los 90 para que la gente lo copiara. Y si tienes el juego comprado, puedes cargar tu DOOM.WAD o DOOM2.WAD desde la web, y se queda en tu navegador sin subirse a ningún sitio. Legal y sin líos.
El esquema del tinglado
La clave es que el código de id está muy bien separado: el 95 % es el juego en sí (render, física, IA de los bichos…) y solo unos pocos ficheros hablan con el sistema operativo: pintar en pantalla, sonar, leer el teclado. Así que no tocamos el juego, solo cambiamos esa capa para que en vez de hablar con Linux hable con el navegador.
Que esto no es llegar y besar el santo
Algunas cosillas dieron guerra, y molan porque son de esas que te enseñan cómo funcionan las cosas por dentro.
El bucle infinito
DOOM, como todos los juegos de la época, es un while(1): un bucle que no para nunca. Pero un navegador no te deja hacer eso: si tu código no suelta el control, la pestaña se congela, no se pinta nada y no suena nada.
¿Reescribimos el bucle? Ni de broma, que es el corazón del juego. La solución se llama Asyncify, un truco de Emscripten que permite «pausar» el programa a mitad de ejecución, dejar respirar al navegador y seguir justo donde lo dejó. Con dos líneas añadidas el bucle de 1993 sigue intacto. Magia negra, pero de la buena.
La música no existía
Sorpresa: el código liberado venía sin música. En DOS usaba una librería comercial (DMX) que id no pudo liberar. ¿Y DOOM sin el «chun-chun» de At Doom’s Gate? Ni hablar.
Y aquí sí aparece la ingeniería inversa: emulamos el chip de sonido de las Sound Blaster (el Yamaha OPL2) con un emulador que replica el chip a nivel de circuito, y para hacerlo sonar como en DOS usamos el trabajo de la comunidad que destripó aquella librería cerrada. Ahora suena exactamente como en el PC de tu primo en el 94 🎸
¿Pero es fiel de verdad?
Esta es mi parte favorita. «Se ve igual» no me valía, quería medirlo.
Las demos que ves en la pantalla de título de DOOM no son vídeos: son grabaciones de las teclas que pulsó un jugador en 1994. El juego las vuelve a simular desde cero cada vez. Como DOOM es 100 % determinista, si el motor se desvía lo más mínimo, el marine acaba andando contra una pared.
Así que comparamos las tres demos originales con Chocolate Doom, que es el port de referencia por fidelidad al DOOM de DOS, mirando la posición, la vida y las bajas del jugador en cada segundo de juego. ¿Resultado? Idénticas. Más de 10.000 tics sin una sola diferencia. Hasta muere en el mismo sitio y en el mismo instante (sí, en las tres demos el jugador acaba muerto, los de id tampoco eran tan buenos 😂).
El resultado
Sé que quieres verlo ya. Esto es la demo original de 1994 corriendo en Chrome, con su música FM y sus efectos 👇🏻
Y además:
- Va a 35 fotogramas por segundo, el reloj interno del original.
- Imagen de 320×200 píxeles estirada a 4:3, como se veía en los monitores CRT.
- Las partidas guardadas sobreviven aunque cierres el navegador.
- Y al salir, la pantalla roja de texto de DOS («Sure, don’t order DOOM…»). Pura nostalgia 🥲
¿Lo pruebas?
Ya no tienes excusa: no hay que instalar nada, abres el enlace y a matar demonios.
Y si eres de los que les gusta trastear, el código está en GitHub, con un TECHNICAL.md donde está toda la chicha técnica: cómo funciona el bucle, el sonido, cómo se verifica la fidelidad y hasta algún bug de 1997 que nos encontramos por el camino.
Truco: escribe iddqd en plena partida. Ya sabes lo que hace 😈
Mejoras futuras
- Controles táctiles, que ahora mismo en el móvil no se puede jugar.
- Multijugador: el código de red original es de igual a igual, y encajaría de lujo con WebRTC. Un deathmatch entre pestañas… 🤤
- Mods (PWADs): la comunidad lleva 30 años haciendo mapas, sería un pecado no poder cargarlos.
A ver si la vida me da un rato libre 🥵
Conclusión
Lo que empezó como un «¿y si…?» viendo el hype de los juegos en el navegador ha acabado siendo un viaje alucinante: WebAssembly, Emscripten, ficheros WAD, chips de sonido de los 90 y una lección de ingeniería de id que, 30 años después, sigue siendo de quitarse el sombrero. Que un código de 1993 se pueda llevar al navegador cambiando solo la capa que habla con el sistema dice mucho de cómo estaba hecho.
Y sobre todo, que no hace falta ser experto en nada para meterte en un fregado así. Parte del problema (aunque el problema sea «quiero DOOM en mi navegador»), apóyate en la IA sin complejos, bichea, rompe cosas y aprende por el camino. Si tienes algún proyecto loco de estos rondándote la cabeza, ya sabes dónde estoy 😎