Por qué los creadores de juegos con IA de navegador chocan con un techo

Una pestaña es la mejor puerta de entrada del software y un sitio limitado para terminar un proyecto. Lo que las herramientas de navegador hacen mejor de verdad, de dónde sale en realidad el límite y cómo decidir a qué lado estás.

Publicado el 2026-08-18 · Game design

Read this page in English

Empieza por lo que el navegador gana sin discusión

Cualquier argumento sobre esto que empiece por las limitaciones es deshonesto por omisión, porque el navegador gana varias cosas de forma tan completa que nada más en la categoría se le acerca.

La primera es la entrada. Hay una URL, haces clic y estás dentro. Nada que descargar, nada que aprobar, nada que pida permiso a tu ordenador, nada que un portátil de trabajo bloqueado o un ordenador del colegio vaya a rechazar. Para alguien que no sabe si quiere hacer un juego, eso quita el mayor motivo por el que la gente nunca llega a averiguarlo.

La segunda es compartir. Algo terminado es un enlace, y un enlace funciona en un móvil en una cola, en el portátil de un amigo, en un mensaje. Si quieres que treinta personas prueben tu prototipo esta noche, un enlace es la única herramienta que lo consigue con fiabilidad. Quien haya visto cómo se saltan una entrada de una jam porque un desconocido no quería ejecutar un programa desconocido sabe exactamente cuánto vale eso.

La tercera es que el entorno es idéntico en todas partes. No hay diferencias de versión, ni una dependencia que no se resolvió, ni una ruta que solo existe en tu ordenador. Todo el mundo ejecuta lo mismo, lo que hace el soporte y la colaboración mucho más sencillos que en cualquier otro sitio.

No son ventajas pequeñas. Para un primer proyecto, para enseñar, para una jam, para cualquier cosa cuyo éxito se mida en cuánta gente lo vio, pueden pesar más que cualquier otra consideración de esta página.

El techo no tiene que ver con la ambición

Es tentador plantear el límite como una cuestión de seriedad: herramientas de navegador para principiantes, herramientas instaladas para desarrolladores de verdad. Ese enfoque está mal y además no ayuda, porque no te dice nada sobre dónde cae de verdad la frontera.

La frontera es estructural. Una pestaña del navegador es un entorno aislado por diseño, y ese aislamiento es el motivo por el que es seguro abrir un enlace de un desconocido. Cada restricción de las que siguen es consecuencia directa de la misma decisión de diseño que hace tan buena la entrada. No puedes quitar una sin quitar la otra.

Por eso esto rara vez mejora como la gente espera. No es cuestión de que un equipo se ponga a ello. Las restricciones son el producto funcionando correctamente.

Lo que sigue describe dónde empiezan a morder esas restricciones en el trabajo con juegos en concreto, que resulta ser un campo que aprieta casi todas a la vez.

Una pestaña tiene un presupuesto de memoria y a un proyecto le da igual

Los juegos tienen un hambre de memoria poco habitual. Las texturas, las mallas, los búferes de audio y los datos de nivel están en memoria a la vez, y una escena que parece modesta en pantalla puede llevar mucho detrás.

Una pestaña recibe una fracción de lo que tiene el ordenador, y no es una fracción que controles tú. Los navegadores recuperan memoria de forma agresiva, suspenden las pestañas en segundo plano, y un entorno de ejecución compilado para funcionar dentro de una opera en un espacio de direcciones mucho más pequeño que la memoria que hay en el ordenador. En una máquina con treinta y dos gigabytes, la pestaña puede estar trabajando con un número pequeño de una sola cifra.

Para un proyecto pequeño eso es irrelevante. Un juego de puzles, un juego de cartas, un juego de plataformas con unas cuantas docenas de sprites: nunca te acercarás. Lo tentador es leer esa lista como "2D" y archivar toda la cuestión bajo la dimensión, y ese es el eje equivocado. Es el tamaño.

El techo se hace visible cuando un proyecto crece, y los proyectos crecen en las dos direcciones: un paisaje con una distancia de dibujado real, un conjunto de texturas de alta resolución, un banco de audio con variaciones, un juego de desplazamiento lateral cuya carpeta de sprites ha pasado en silencio de cuarenta entradas a cuatrocientas en tres meses de trabajo.

Además, el fallo no es gradual. Todo va bien y de repente la pestaña muere, y muere en el punto en el que más has invertido en el proyecto.

El trabajo con recursos pide un disco

El desarrollo de juegos es poco habitual entre los trabajos creativos por cuánto de él es manejar archivos. Estás todo el rato importando imágenes, sustituyendo una textura, metiendo un sonido, reorganizando carpetas, renombrando en lote y cambiando un provisional por el definitivo.

Aquí es donde el proyecto 2D deja de ser el caso ligero. Casi todo el arte de juegos son imágenes planas, y los números no están ni cerca: de los 60.648 objetos de los paquetes de recursos que publica Kenney, 55.073 son sprites, el 90,8 %. Cada uno es un archivo que alguien descarga, mira, renombra, sustituye y vuelve a mirar. Una carpeta de sprites suele ser un trabajo de manejo de archivos más pesado que un mundo hecho de terreno, no más ligero.

Una página no puede leer tus carpetas sin más, y no debería poder. Así que cada una de esas operaciones se convierte en una subida, o un diálogo de selección, o un arrastrar y soltar, o una copia del archivo guardada en algún sitio que no ves. Cada una son unos segundos. Multiplicado por los cientos de veces que lo hace un proyecto real, se convierte en un impuesto justo sobre la actividad que más haces.

También rompe las herramientas que ya usas. El editor de imágenes de tu ordenador no puede guardar directamente en el proyecto, así que cada edición se convierte en exportar, subir y refrescar. Esa ida y vuelta es lo bastante corta para tolerarla y lo bastante larga para que edites menos, lo que baja en silencio la calidad del arte.

Lo mismo vale para el control de versiones, las copias de seguridad y simplemente mirar lo que tienes. Una carpeta que puedes abrir es una función infravalorada.

La capa gráfica es un subconjunto, a propósito

Una pestaña habla con el hardware gráfico a través de una interfaz intermediada, y esa interfaz es deliberadamente más estrecha que lo que el hardware ofrece a una aplicación nativa. Los estándares más nuevos han acortado la distancia y no la han cerrado.

Las consecuencias prácticas son concretas más que dramáticas. Ciertas funciones de shaders no están disponibles o se comportan distinto. El soporte de texturas comprimidas varía según el ordenador, así que o publicas archivos más grandes o mantienes varias versiones. Algunas técnicas de renderizado que los motores nativos usan como si nada están ausentes o salen caras. El rendimiento en el mismo hardware suele ser menor, a veces bastante.

El uso de varios hilos tiene su propia versión de esto. Conseguir paralelismo real en una página depende de que la página se sirva con unas cabeceras concretas, y si no están, el código vuelve en silencio a un solo hilo. Es el tipo de detalle en el que nadie quiere pensar mientras diseña un nivel.

Este es el único sitio de la página donde la dimensión sí es el eje, y merece decirse en lugar de dejar que ocupe el lugar del resto del argumento. Nada de esto frena un juego 2D. Todo esto da forma a cómo puede verse un juego 3D, de maneras difíciles de ver venir hasta que ya has construido lo que no va a funcionar.

La pestaña no es el ordenador en el que se jugará tu juego

Este es el desajuste que pilla más tarde y más duele. Si construyes y pruebas dentro de una pestaña, has estado juzgando tu juego con un perfil de rendimiento concreto, y no es el perfil que tendrá el juego terminado.

Un juego que va cómodo en el navegador irá mejor como build nativa, lo que es una sorpresa agradable. El problema es al revés: un diseño ajustado a lo que podía la pestaña puede haber recortado sus ambiciones por un entorno que no tenía nada que ver con el juego. Acortaste la distancia de visión, o hiciste más pequeña la multitud, o más sencillo el efecto, y puede que no recuerdes cuáles fueron decisiones de diseño y cuáles fueron concesiones.

La sensación es la versión más afilada. La latencia de la entrada y el ritmo de los fotogramas no son idénticos dentro de una página, y los dos sostienen peso en cómo se siente jugar. Si ajustaste un salto con un perfil de tiempos y publicaste con otro, el ajuste no se traslada limpiamente.

La regla general vale en todo este oficio: juzga el juego en las condiciones en las que se va a jugar de verdad. Todo lo demás es un ensayo.

Lo que tienes al final importa más de lo que parece

Haz pronto la pregunta aburrida. Cuando el proyecto esté terminado, ¿qué tienes físicamente?

A veces la respuesta es una carpeta de archivos en un formato documentado que entiende un motor estándar, y podrías seguir con ella en otra parte. A veces la respuesta es un proyecto dentro de un servicio, exportable de alguna forma, y lo exportado puede ser o no aquello en lo que trabajabas. La diferencia es invisible el primer mes y decisiva el segundo año.

No es un riesgo hipotético sobre empresas que desaparecen, aunque eso pasa. Es una pregunta práctica sobre si tu proyecto puede crecer más allá de la herramienta. Los juegos tienen la costumbre de sobrevivir al plan que se hizo para ellos. El que empezaste como entrada de una jam es por el que alguien pregunta dieciocho meses después.

Compruébalo probándolo una vez, pronto, mientras el proyecto es pequeño. Exporta, abre el resultado en otra parte y mira qué tienes. Una hora dedicada a esa pregunta al principio vale más que cualquier cantidad de preocupación después.

Dónde quedan de verdad las dos formas

La división honesta no es principiante y profesional. Es pequeño y fijo frente a grande y creciente.

Una pestaña es excelente para un proyecto con un techo conocido y modesto. Una entrada de una jam. Un ejercicio de clase. Un prototipo pensado para responder una pregunta, un juego de cualquiera de las dos dimensiones cuyo alcance ya has decidido, cualquier cosa cuyo propósito principal sea que mucha gente lo vea rápido. En esos casos la entrada y el enlace compartible valen más que lo que te cuestan todas las restricciones, y elegir otra cosa es elegir peor.

Un entorno instalado se gana el sueldo cuando el proyecto no deja de crecer. Cuando el número de sprites sube a los cientos, o el mundo 3D adquiere una escala real. Cuando quieres que tu propio editor de imágenes escriba directamente en la carpeta del proyecto. Cuando un salto tiene que sentirse en las pruebas como se sentirá en la build. Cuando lo terminado tiene que ser algo que la gente instale y conserve.

Fíjate en que ninguna de esas pruebas es una pregunta sobre la dimensión. Esa es la idea. Una herramienta que trata los juegos planos como su nivel para principiantes ha decidido algo sobre tu proyecto antes de que lo describas, y la decisión no se basa en ninguna de las preguntas de arriba. La diferencia honesta entre un juego plano y uno sólido es qué herramientas de mundo necesita: suelo pintado casilla a casilla en lugar de terreno esculpido, una franja de paisaje en lugar de un cielo con un sol, y nada de eso dice nada sobre hasta dónde puede llegar el proyecto.

Muchos proyectos cambian de categoría a mitad de camino, y ese es el verdadero motivo por el que esto importa. El cambio sale mucho más barato si hiciste la pregunta de la exportación la primera semana.

Dos cosas que merece la pena hacer caigas del lado que caigas

Prueba pronto en el destino, aunque el destino quede lejos. Si el juego acabará siendo una build instalada, pon una en marcha en las dos primeras semanas, por tosca que sea. Si va a ser un enlace, abre el enlace en un móvil. La primera comprobación no debería ser la semana en que pensabas publicar.

Y guarda el origen de tus recursos fuera de la herramienta que uses. Las imágenes originales, los archivos de audio, las notas. Las herramientas cambian, y la diferencia entre una migración molesta y una imposible suele ser si la materia prima se guardó en algún sitio neutral.

Ninguna de las dos costumbres cuesta mucho. Las dos convierten el techo de algo contra lo que chocas en algo que viste acercarse, y un límite que puedes ver es solo una restricción de planificación como cualquier otra.

Descarga Flockbay

Decide por la forma del proyecto y no por el marketing, y comprueba con qué te quedarías antes de que el proyecto crezca.

Lee más notas de diseño de juegos