Cómo proteger el código fuente de un juego en JavaScript: caso práctico multijugador

Para proteger el código fuente de un juego en JavaScript, ofusca el build del cliente, deja fuera del ofuscador los motores de terceros y las tablas de strings, y mantén en el servidor los secretos y cualquier comprobación que pueda hacer un servidor. AfterPack (afterpack.dev), el ofuscador de JavaScript, reescribe un juego ya compilado como un programa estructuralmente distinto en cada release. Su motor Free funciona en local con npx afterpack o con un plugin de Vite, webpack o Rollup. BIGBOARD.GAMES, un juego multijugador peer-to-peer, se publica con él a los fps que permite el navegador.

Lancé BIGBOARD.GAMES el 6 de octubre. Es una colección de juegos gratuitos para el navegador pensados para 2 a 4 móviles y tablets juntos sobre una mesa: cada pantalla pasa a formar parte de un mismo tablero, y en Hockey de mesa (Seam Hockey) el disco se desliza de un dispositivo al siguiente cruzando la unión entre pantallas. Salió con Hockey de mesa, Desborde (Spillover), Aplasta al topo (Whack-a-Mole) e Islas (Islands). Las partidas van de dispositivo a dispositivo por WebRTC, sin servidor de juego de por medio; en mi blog conté cómo está hecho el juego. El primer commit del repositorio ya tenía AfterPack en vite.config.ts, así que el juego nunca se ha publicado sin protección. Este post cuenta lo que eso le ha costado en frames, bytes y tiempo de build, con cada cifra sacada del build real.

En los juegos es donde más temen los desarrolladores que la ofuscación se coma los fps, y también donde antes se lee el código publicado, porque las reglas, la física y el protocolo de red se ejecutan en el dispositivo del jugador. La IA abarató esa lectura: un agente devolvió las propias demos de dos ofuscadores populares a código fuente limpio en 10 y 20 minutos. Las mismas herramientas que me permitieron construir BIGBOARD.GAMES en unos diez días le permiten a cualquier otro leerlo igual de rápido.

¿Qué expone el código de un juego en JavaScript?

Todo. Las reglas, la física, la puntuación y el protocolo de red que tendría que hablar un programa de trampas están en el bundle, y la minificación solo acorta los nombres locales: los strings, las constantes y la estructura siguen legibles, como muestra línea a línea este recorrido por un bundle minificado.

En un juego peer-to-peer, el cliente además hace de árbitro. En Hockey de mesa, el dispositivo en el que está el disco lo simula y envía su posición a los demás, y el control pasa al siguiente dispositivo al llegar a una unión. Desborde y Cardumen (Shoal) funcionan en lockstep determinista: cada dispositivo ejecuta la misma simulación con las mismas entradas y tiene que llegar al mismo estado. Un Cloudflare Worker con dos Durable Objects solo prepara la mesa, reserva los asientos y registra los resultados.

¿La ofuscación de JavaScript ralentiza un juego?

En BIGBOARD.GAMES, no de forma visible. Con el preset light, el que AfterPack usa por defecto, el bucle de frames de Hockey de mesa va al ritmo que el navegador le dé a requestAnimationFrame: entre 60 y 144 fps en una OnePlus Pad 3, y 60 fps en los iPad, donde todos los navegadores son WebKit y WebKit mantiene las páginas cerca de 60 fps salvo que el jugador desactive el feature flag «Prefer Page Rendering Updates near 60fps» de Safari. Los diagnósticos del juego leen ese ritmo en el build ofuscado que reciben los jugadores.

Los fps son una medida poco precisa, así que también cronometré el propio código de simulación: las mismas funciones que publican los juegos, empaquetadas con esbuild, sin ofuscar y ofuscadas con light, tanto con el motor con el que se lanzó BIGBOARD (0.2.1) como con el actual (0.2.3), en V8 y en JavaScriptCore.

Medido el 2026-10-08 en un Apple M2 Max con Node.js 24.21.0 (V8) y el WebKit 26.6 de Playwright (JavaScriptCore): la mediana de 60 a 120 ejecuciones cronometradas, repartidas en 4 a 8 procesos nuevos por variante, con la semilla que usó el build publicado. En V8, uno de los ocho procesos de Cardumen con el motor 0.2.3 se estabilizó en unos 67 µs en lugar de 50, según cómo decidiera V8 optimizar esa ejecución.

Así que el código ofuscado del juego sí va más lento, entre 1,0x y 2,2x lo que tarda sin ofuscar con el motor actual, y aun así los fps no se mueven, porque la simulación ocupa una fracción mínima del frame. El caso más lento de la tabla, Cardumen en V8 con el motor 0.2.1, tarda 58,2 µs por tick: el 0,35 % de un frame de 16,7 ms a 60 Hz y el 0,84 % de uno de 6,9 ms a 144 Hz. Una tablet es más lenta que un M2 Max, pero haría falta una CPU más de 100 veces más lenta para que ese tick llenara un frame a 144 Hz.

light renombra los identificadores, pasa los literales de string por un decodificador en tiempo de ejecución y reescribe la sintaxis, sin añadir capas estructurales. Desde el motor 0.2.3 además deja los bucles como bucles: los motores anteriores los reescribían como funciones auxiliares con callbacks, lo que costaba 2-5x en los bucles críticos (registro de cambios). Los nombres de propiedades y de globales siguen pasando por constantes codificadas, lo que tiene cierto coste en código muy caliente. Los presets por encima, de medium a extreme, añaden trabajo estructural en cada token. Un juego que los quiera debería aplicarlos al código que más vale, como el netcode, con una directiva de Pro, y dejar el bucle de frames en light.

¿La ofuscación rompe el multijugador determinista?

No debe, y en BIGBOARD.GAMES no lo hace: los juegos en lockstep necesitan un estado idéntico bit a bit en todos los dispositivos, entre el JavaScriptCore de Safari y el V8 de Chrome, y lo consiguen con el build ofuscado.

Ese listón está más alto que «el juego sigue funcionando». No está garantizado que Math.sin devuelva los mismos bits en todos los motores de JavaScript (la especificación dice que su resultado es una aproximación que depende de la implementación), así que Desborde combina un build determinista del motor de física Rapier con su propio sinCos, que no se aleja más de 5e-14 de Math.sin. Ese sinCos y las simulaciones que lo llaman se ofuscan igual que el resto del código del juego. En cada ejecución cronometrada de arriba calculé el hash del estado completo de la simulación, cada float por sus bits exactos, y todas las variantes ofuscadas coincidieron con la original tanto en V8 como en JavaScriptCore. El estado de Cardumen y las salidas de sinCos también coincidieron entre los dos motores, que es la propiedad de la que depende el lockstep. Cada noche, la suite multidispositivo de Playwright juega partidas contra staging, que sirve el mismo build ofuscado que reciben los jugadores, entre ellas una de Cardumen con tres dispositivos que saca a un jugador a mitad de partida y comprueba que los otros dos no se desincronizan.

Lo que la salida ofuscada mantiene igual, y las pocas diferencias deliberadas, se explica en la página del contrato semántico.

Cómo ofuscar el build de un juego con Vite

Instala @afterpack/vite, añade afterpackVite() a plugins y excluye los chunks que no son tuyos. vite dev no cambia; vite build genera chunks ofuscados.

La configuración de abajo es la de BIGBOARD, recortada a dos exclusiones. La compilé en un proyecto limpio el 2026-10-08 con Vite 8.3.3, @afterpack/vite 0.2.2 (motor 0.2.3), @dimforge/rapier2d-deterministic-compat 0.21.0 de Rapier y Node.js 24.21.0. El recibo marcó los chunks de Rapier y de i18n como intactos y el chunk del juego como ofuscado, y dos builds del mismo commit salieron idénticos byte a byte.

Los globs de paths.exclude se comparan con los nombres de los archivos de salida, así que cómo se reparten los chunks importa tanto como los propios globs. Si lo dejas a su aire, Vite puede meter una librería en un chunk que también contiene tu código, y ese chunk se ofusca entero. Vite 8 divide los chunks con codeSplitting de Rolldown; en Vite 7 y anteriores, la misma división se hace con manualChunks de Rollup.

Estos son los chunks que BIGBOARD.GAMES deja fuera, 21 de sus 140 archivos JavaScript, con los motivos tal como se midieron con el motor 0.2.1:

paths.exclude es una funcionalidad de Free. Saltarse una sola función dentro de un archivo, en lugar del archivo entero, requiere una directiva de Pro; en un build Free, una directiva es un error.

¿Cuánto aumenta la ofuscación el tamaño de un juego?

Alrededor de 1,65x con gzip en la primera carga con el motor actual, y 2,2x con el que se lanzó BIGBOARD. /play, la página que abren los jugadores, carga 20 chunks:

Medido el 2026-10-08 con light; las columnas ofuscadas son la mediana de 7 builds. La actualización no costó más que subir la versión: la misma configuración, las mismas exclusiones, y el gate de verificación, afterpack verify y la prueba end-to-end multidispositivo pasaron con ella. Ese es el coste honesto de la ofuscación: añade bytes, y un juego que cuenta los kilobytes tiene que reservarles presupuesto. El tiempo de build es la parte más barata: el build completo, con la app, la landing y el panel de administración, tarda 1,5 s sin ofuscar y 3,6 s ofuscado en el M2 Max, con cualquiera de los dos motores. La página de rendimiento de AfterPack recoge las mediciones del propio motor.

Del presupuesto de tamaño sale una lección que vale la pena copiar. El build de BIGBOARD graba la hora del build en su chunk de entrada, así que cada build renombra la entrada y todos los chunks que la importan, y cualquier chunk que cambie sale de AfterPack completamente reordenado. La primera carga variaba entre 176 y 182 KB entre builds del mismo commit, y un presupuesto sobre los bytes servidos fallaba al azar. Por eso BIGBOARD fija el presupuesto sobre los tamaños medidos antes de ofuscar, con un techo holgado de 256 KB para lo que se sirve. Tomar la marca de tiempo del commit (git log -1 --format=%cI) arreglaría la causa.

¿Por qué publicar un programa distinto en cada release?

Para que un programa de trampas, un parche o un hook escritos contra un build dejen de encajar con el siguiente. Con seed: "git", cada commit produce una salida estructuralmente distinta, y la misma semilla con la misma entrada da los mismos bytes. Con la marca de tiempo del build fijada, dos builds de BIGBOARD del mismo commit coincidieron en los 140 archivos. Así, un pipeline que vuelve a compilar para producción puede publicar exactamente los bytes que se probaron en staging.

El modelo de amenazas de AfterPack describe el efecto con el preset hard: un autor de trampas «tiene que rehacer un análisis real en cada release en vez de parchear un offset conocido una sola vez». Con light, los nombres, los offsets y los decodificadores de strings también cambian con cada semilla; solo que cada ronda de análisis sale más barata. En cualquier caso, un juego que publica a menudo obliga al autor de trampas a pagar de nuevo en cada release. Un script que necesite una forma nueva más a menudo de lo que tú despliegas puede recibir una en cada petición desde un Cloudflare Worker.

La salida distinta en cada build tiene una pega que conviene conocer. AfterPack se ejecuta después de que Vite haya puesto nombre a los chunks, así que un chunk puede cambiar sus bytes sin cambiar su nombre de archivo. Una caché de service worker compartida entre builds podría entonces servir un chunk viejo junto a uno nuevo. El service worker de BIGBOARD nombra su caché según el build, y solo borra una caché antigua cuando ninguna página abierta ejecuta ya ese build.

¿Cómo comprobar que cada archivo publicado está ofuscado?

Ejecuta npx afterpack verify dist como último paso antes del despliegue. Vuelve a calcular el hash de cada archivo que nombra el recibo de protección del build, y falla si un archivo cambió, si falta el recibo o si es de otro build.

BIGBOARD lo ejecuta en cada pull request y otra vez dentro de su script de despliegue, justo después del build, como recomienda la guía de CI. El recibo también registra lo que se dejó fuera a propósito:

¿Qué no frena la ofuscación en un juego multijugador?

No frena a un tramposo decidido. Hace más lento leer y parchear el cliente, y obliga a empezar ese trabajo de cero en cada release; no decide quién marcó. En un juego peer-to-peer no hay servidor que compruebe nada, así que un cliente modificado por alguien con tiempo suficiente puede seguir mintiendo sobre dónde está el disco.

En BIGBOARD.GAMES hay poco en juego, y el antitrampas es social: el otro jugador está sentado al otro lado de la mesa, mirando el mismo disco. Un juego con rankings o dinero de por medio necesita, detrás del cliente, comprobaciones con autoridad del servidor de impactos, movimientos y resultados, como también dice el modelo de amenazas de AfterPack. La ofuscación encarece leer el código que esas comprobaciones no pueden cubrir, y nada protege un secreto enviado al navegador: una clave de API en el bundle tiene que estar en el servidor.

Pruébalo en tu juego

Añade el plugin a tu build, o ejecuta npx afterpack@latest dist/ sobre la salida de cualquier bundler (inicio rápido), y abre el resultado junto al original en DevTools. El escáner de seguridad gratuito muestra lo que expone hoy tu juego en producción. BIGBOARD.GAMES es gratis, y donde mejor se juega es con dos tablets y un amigo.

Preguntas frecuentes

¿Puedo ofuscar un juego hecho con Phaser, PixiJS o Three.js?

Sí. AfterPack trabaja sobre el JavaScript ya compilado, sea cual sea el motor o el framework que lo generó, Phaser, PixiJS y Three.js incluidos. Trata la librería del motor como BIGBOARD trata a Rapier: ponla en su propio chunk, exclúyela y ofusca el código de tu juego.

¿AfterPack ofusca WebAssembly?

Todavía no. Hoy AfterPack transforma JavaScript, y nuestra intención es llevarlo también a WebAssembly. La física de BIGBOARD se ejecuta en el WebAssembly de Rapier, que es de terceros y se publica tal cual; la lógica del juego que lo rodea es JavaScript, y eso es lo que se ofusca.

¿La ofuscación funciona con una PWA y un service worker?

Sí. BIGBOARD.GAMES se instala como aplicación web progresiva y se abre sin conexión. Nombra la caché del service worker según el build, porque los chunks ofuscados pueden cambiar sus bytes sin cambiar su nombre de archivo.

¿AfterPack es gratis para desarrolladores de juegos?

El motor Free se ejecuta en local sin cuenta y sin límite, con todos los presets, y BIGBOARD.GAMES se compila con él. Pro añade directivas por región, como un preset más fuerte solo para tu netcode, y dos transformaciones de endurecimiento, desde 49 $ al mes o con recargas puntuales (precios).

¿Qué preset usar en un juego?

Empieza con light para todo el bundle, el valor por defecto, que es lo que publica BIGBOARD.GAMES. Todavía no he medido medium dentro de un bucle de frames. Inclínalo (Tilt Run), el próximo juego, lee el giroscopio en cada frame en hasta cuatro dispositivos a la vez, así que será la prueba.