Exportar a WebGL: jugar en el navegador

Jugar sin instalar nada#

La build WebGL convierte tu juego en algo que corre dentro del navegador: el jugador entra a una URL y juega, sin descargar ni instalar. Es perfecta para demos, game jams, portfolios y portales como itch.io. Pero tiene reglas propias que conviene conocer antes de contar con ella.

Cómo funciona#

Unity compila tu código C# a WebAssembly (wasm) y renderiza mediante la API WebGL del navegador sobre un elemento <canvas>. El resultado de exportar es una carpeta con:

• index.html (la página que lo aloja)
• una carpeta Build/ con el wasm, el código y los datos
• una carpeta TemplateData/ (estilos e imágenes de la plantilla)

Todo eso, subido a un servidor web, es tu juego jugable.

Las limitaciones (léelas antes de empezar)#

• Memoria limitada: la pestaña del navegador tiene un presupuesto de RAM mucho menor. Juegos grandes se quedan sin memoria. Optimiza como si fuera móvil.
• Sin acceso al sistema de archivos: no puedes leer/escribir archivos con System.IO como en escritorio. El guardado va por PlayerPrefs (que en web usa el IndexedDB del navegador) o soluciones propias; File.WriteAllText no sirve igual.
• Multihilo restringido: el soporte de hilos es limitado; muchas cosas corren en un solo hilo. Cuidado con lo que dependa de threading.
• Sin networking directo por sockets: solo protocolos web (WebSockets, HTTP). El multijugador con UDP directo no funciona; necesita relays/WebSockets.
• Tiempo de carga: el jugador descarga el juego entero antes de jugar. Cada MB cuenta.
• Audio y algunos shaders pueden comportarse distinto.

Compresión: clave para la carga#

Como el jugador descarga todo, el tamaño manda. En Player Settings → Publishing Settings eliges la compresión:

• Brotli: la mejor compresión (archivos más pequeños), recomendada para producción. Requiere que el servidor envíe las cabeceras correctas.
• Gzip: alternativa más compatible si no controlas el servidor.

En tu propio servidor, si usas Brotli/Gzip tendrás que configurar las cabeceras Content-Encoding o algunos navegadores no cargarán la build. Es el fallo típico de "me funciona en local pero no al subirlo".

Ajustes que importan#

• Resolución del canvas y si se adapta a la ventana.
• Exception support: bájalo (a Explicitly Thrown Exceptions Only o ninguno) para builds más pequeñas y rápidas en producción.
• Strip Engine Code activado para reducir tamaño.
• Texturas y audio comprimidos y a resolución sensata: es lo que más pesa.

Comunicarse con la página (JS ↔ Unity)#

A veces necesitas que el juego hable con la web que lo aloja (o al revés). Unity permite llamar a JavaScript desde C# y viceversa mediante plugins .jslib y SendMessage. Útil para integrar el juego con tu portfolio, guardar en un backend, o adaptar la web alrededor del canvas.

Errores frecuentes#

• Esperar que un juego de PC pesado funcione igual en WebGL (memoria/rendimiento).
• Usar System.IO para guardar (no funciona; usa PlayerPrefs u otra vía web).
• Subir una build Brotli a un servidor sin las cabeceras y que no cargue.
• No comprimir texturas/audio y que la carga tarde una eternidad.
• Contar con multijugador por UDP directo (solo WebSockets/HTTP en navegador).

Ponte a prueba#

Resumen#

WebGL hace tu juego jugable en el navegador (compila a WebAssembly + canvas), ideal para demos, jams y portfolios. Pero es un entorno restringido: memoria limitada, sin sistema de archivos (guarda con PlayerPrefs), multihilo y networking limitados (solo WebSockets/HTTP). Optimiza como en móvil, comprime con Brotli/Gzip (configurando las cabeceras del servidor) y, para lo rápido, sube a itch.io, que gestiona todo por ti. Parte del proceso general de exportar.