Cómo corre un juego de PC en el navegador: WebAssembly, y por qué los datos van aparte

Un navegador no ejecuta programas de Windows. Aun así, hay versiones de Diablo, Quake o Doom que arrancan dentro de una pestaña. Esta guía explica, sin jerga, cómo se llega ahí y por qué casi siempre el programa viaja por un lado y los archivos del juego por otro, para que puedas leer cualquier port con ese criterio.

Qué es WebAssembly

Según su sitio oficial, WebAssembly es, en traducción nuestra de su descripción en inglés, un formato binario de instrucciones para una máquina virtual de pila, pensado como destino de compilación para otros lenguajes. Dicho en cristiano: no se escribe a mano. Se escribe un juego en C o C++ y una herramienta lo traduce a ese formato, que el navegador sabe ejecutar. Su nombre se escribe «Wasm» y, aclara la especificación, no es un acrónimo.

La versión 1.0 de la especificación es una recomendación del W3C del 5 de diciembre de 2019. Dos de sus objetivos de diseño explican por qué sirve para juegos: ejecutar con un rendimiento próximo al del código nativo y hacerlo en un entorno aislado. Ese aislamiento tiene consecuencia práctica: el programa no tiene acceso libre al equipo. Cualquier entrada o salida, dice la especificación, sólo puede ocurrir mediante funciones que el navegador le entrega. El rendimiento es una meta de diseño del estándar, no una medición.

Qué hace Emscripten con el código de un juego

Emscripten es la herramienta que hace la traducción. Su compilador, emcc, está pensado como reemplazo directo de compiladores como gcc o clang, y además de producir el módulo de WebAssembly genera JavaScript que le da al programa acceso a las funciones del navegador.

No es magia ni «compilar y listo». La propia documentación dice que normalmente hay que cambiar algo del código nativo, y señala dos cambios típicos: la manera de definir el bucle principal y el manejo de archivos. Lo segundo es clave para esta guía. Un programa en una pestaña no puede leer el disco del usuario, así que Emscripten le da un sistema de archivos virtual que vive en memoria. Los archivos que el juego necesita se declaran al compilar y se descargan cuando carga la página. Lo que el juego escribe en ese espacio se pierde al recargar, salvo que el port monte un almacenamiento persistente del navegador.

Gráficos: OpenGL sí, Direct3D no

Aquí está el primer matiz. La especificación de WebGL dice que está derivada de OpenGL ES 2.0, y Emscripten aprovecha esa herencia: su portada dice, en traducción nuestra, que convierte OpenGL en WebGL. Hay tres modos. El recomendado es el subconjunto de OpenGL ES que corresponde directo a WebGL; los otros dos emulan funciones que WebGL no trae, incluida la emulación de funciones antiguas de OpenGL de escritorio, y la documentación los describe como menos eficientes.

Direct3D, la interfaz gráfica de Windows, es otro asunto. El autor de un port de GunZ: The Duel (un juego de 2003), en un texto publicado el 11 de marzo de 2026, cuenta que el motor llamaba a Direct3D 9 y que, en sus palabras, Emscripten no lo traduce por sí solo. Reescribir esas llamadas le pareció inviable, así que escribió una capa intermedia: el juego sigue llamando a Direct3D y la capa convierte cada llamada a WebGL. Esa capa está publicada como repositorio aparte. Según el mismo autor, el código original del juego quedó intacto; el sonido y la entrada sí hubo que reemplazarlos, uno por la API de audio del navegador y la otra convirtiendo eventos del navegador en mensajes de Windows.

La lectura de la casa: según su autor, el motor gráfico fue el mayor obstáculo de ese port. La idea de que el programa es la parte fácil se sostiene sólo cuando el juego ya hablaba un idioma gráfico que el navegador entiende.

El programa y los datos viajan separados

Un juego es dos cosas con dueños distintos: el programa que lo ejecuta y los archivos con gráficos, sonido y niveles. Tres casos con fuente muestran cómo se reparte.

• Diablo. El README de DiabloWeb dice que el proyecto parte de Devilution, que el código para compilar los módulos de WebAssembly está en otro repositorio y que el sitio del proyecto incluye spawn.mpq, el archivo de la versión shareware. Para jugar el juego completo, dice, hay que usar tu propio DIABDAT.MPQ. El README de DevilutionX pide lo mismo para escritorio: acceso a los datos del juego original, o spawn.mpq para la parte shareware. Ojo con la licencia: DevilutionX se publica bajo la Sustainable Use License y su README advierte que el código es para uso no comercial y que no se puede cobrar por él ni por sus derivados.
• Quake. El repositorio oficial de id Software trae un texto firmado por John Carmack: el código está bajo GPL, pero, dice (traducido del inglés), los archivos de datos de Quake siguen con copyright y con sus términos originales, así que los datos del juego original no se pueden redistribuir. Quien haga una conversión total puede crear un juego independiente sobre ese código.
• Doom. Según el proyecto Freedoom, id liberó el código de Doom en 1999 bajo GPL, pero el contenido (gráficos, audio, niveles, personajes) sigue siendo propietario. Freedoom existe para llenar ese hueco con contenido libre.

Para una lectura más amplia del lado legal de los programas y los archivos, está la guía de la casa sobre emulación.

Lo que la hipótesis no cubre

La frase «el motor es lo fácil y los datos son el problema» se sostiene a medias. Los datos, sí: en los tres casos de arriba son la parte con dueño. El motor, no siempre. El de GunZ costó una capa gráfica entera, y según el autor del port su código fuente se filtró en 2007: eso es lo que él afirma, y no es una licencia. El de DevilutionX es de uso no comercial. De los casos de esta guía, sólo Quake y Doom tienen código publicado por su propia empresa bajo GPL.

Y separar programa y datos en un repositorio no garantiza que el sitio que lo sirve también los separe. El repositorio del port de GunZ declara que no contiene ningún recurso del juego comercial, y añade que el alojamiento de los recursos del despliegue en vivo es externo e independiente del repositorio. El autor, en el texto citado, dice que los recursos se sirven desde S3 y CloudFront. En esas fuentes no aparece una autorización del titular para ese alojamiento.

Cómo leer un port en cuatro preguntas

1. ¿Qué lleva el repositorio? Código, o código y recursos. Un README suele decirlo de forma explícita.
2. ¿Con qué licencia está el código? GPL, MIT, una licencia propia o ninguna. «El código está en GitHub» no es una licencia.
3. ¿De dónde salen los datos? De tu copia, de una versión shareware con permiso de distribución, de contenido libre o de un servidor del port. Cada respuesta es una situación distinta.
4. ¿Quién lo autoriza? Si ninguna fuente lo dice, se anota como ausencia, no como permiso.

Qué no hacer

No des por legal un port porque funcione en el navegador: que corra no responde de quién es cada archivo. Tampoco des por libre un código sólo porque esté publicado. Y no subas a ningún sitio los archivos de un juego que compraste: el texto de Quake lo dice sin rodeos, los datos del juego original no se pueden redistribuir, y los README de Diablo piden usar los de tu copia. Nada de esto es asesoría legal; es lo que dicen los textos de los proyectos.

Un ejemplo con las dos partes libres

Freedoom es el caso limpio. Su página oficial lo define como contenido completo para el motor de Doom, con licencia BSD, y precisa que por sí solo es sólo contenido: hay que emparejarlo con un motor compatible. Existen motores bajo GPL, como Chocolate Doom, cuyo README declara que su objetivo es ser siempre software libre y de código abierto. La casa tiene una demo de Freedoom compilada a WebAssembly en este sitio: su contenido es Freedoom, no los archivos de Doom. Si quieres comparar con el otro extremo, el artículo sobre Quake y su shareware cuenta el papel del shareware en su reparto.