Haciendo juegos web “de tamaño bocado” con GameSnacks

Hola, y bienvenidos a todos, a la creación de juegos de tamaño reducido con GameSnacks. Soy Alex Hawker, ingeniero de software en el equipo de GameSnacks en Google. Mi principal enfoque ha sido una variedad de proyectos relacionados con la infraestructura y distribución de juegos en la web, muchos de los cuales giran en torno a este mismo desafío de optimizar el tamaño de los archivos de los juegos web.

Ahora, podrías estar pensando, ¿por qué juegos de tamaño reducido? ¿No son suficientemente buenas las velocidades de internet en estos días? Bueno, una de las principales ventajas de la web como plataforma para los juegos es su capacidad para la viralidad, perfectamente expresada en ejemplos desde los juegos io hasta el reciente éxito, Wordle. Pero esta ventaja de fácil accesibilidad se ve severamente negada cuando los tamaños de los archivos se disparan demasiado. A pesar de avances como el 5G, gran parte del mundo todavía experimenta frecuentemente conexiones más lentas, desde Australia, hasta India, hasta aquí mismo en los EE.UU. Sé que ciertamente he experimentado muchas veces en lugares donde la velocidad de internet de mi teléfono de repente se ralentiza a un ritmo de tortuga. Y en momentos como estos, cuando incluso un juego de solo 10 megabytes puede tardar más de 3 minutos en descargarse, cada byte cuenta. Nadie quiere ver esa pantalla en blanco a la izquierda, quieren jugar algunos juegos.

Bueno, esto es una de las cosas en las que estamos trabajando aquí en Gamesnacks. Gamesnacks es un nuevo equipo en Google dedicado a hacer crecer el ecosistema de juegos en la web para ayudar a hacer los juegos universalmente accesibles y útiles. Como parte de este esfuerzo, hemos experimentado mucho con la optimización de los juegos y sus tamaños de archivo. Incluso hemos llegado a construir un motor de juegos experimental para ver hasta dónde se pueden llevar estas optimizaciones, y cuán valiosos pueden ser los diferentes tipos. Estoy aquí hoy para compartir con ustedes los aspectos más destacados de estos aprendizajes. Comenzaremos con algunas consideraciones generales que se aplican a la optimización del tamaño del juego y luego nos sumergiremos en optimizaciones específicas para diferentes tipos de archivos.

En primer lugar, el uso de la codificación gzip en los archivos de juego es un primer paso fácil para mejorar el ahorro de archivos. En promedio, reduce el tamaño de los archivos de código y otros archivos aplicables en un 75%. Para aquellos que no están familiarizados, gzip es esencialmente un equivalente de código abierto a zip. Los navegadores de hoy en día soportan que los servidores les envíen estos archivos comprimidos con gzip, lo que nos permite reducir cuántos bytes necesitamos enviar. Sin embargo, debido a la forma en que funciona gzip, no funciona bien en todos los archivos. En su lugar, deberías usarlo solo en archivos sin comprimir como código, configuraciones y formatos específicos como svg o midi. A diferencia de otros consejos, el uso de gzip no es un cambio que se haga en el propio proyecto del juego, sino que tiene que ser habilitado en el servidor. Afortunadamente, esto suele ser bastante sencillo. Por ejemplo, en Google Cloud Storage, puedes simplemente añadir esta bandera Zed con la lista de extensiones que quieres comprimir con gzip.

A continuación, tenemos bueno, esto es como una pausa incómoda. No es realmente muy agradable, por eso es tan importante conseguir que se muestre algún tipo de visual a los usuarios rápidamente. Esto es crítico, porque las investigaciones muestran que solo el hecho de que el tiempo de carga de la página pase de 1 segundo a 5 segundos aumenta la tasa de rebote de la página en un 90%. Así que mostrar al usuario algún visual idealmente animado, ya sea una pantalla de inicio o una pantalla de carga, les asegura que las cosas no están rotas, y les da algo en lo que centrarse para hacer que la carga se sienta más rápida para el usuario. Así que aunque esto no mejorará los tiempos totales de carga, o probablemente incluso los empeorará ligeramente, es en general una gran victoria, ya que al final del día, lo que importa es la percepción del usuario, no las métricas crudas. En la misma línea, la carga perezosa de contenido puede ser una gran victoria.

Esto es cuando, en lugar de cargar todo con anticipación, solo se carga el contenido que se necesita en el momento actual. Entonces, si tuviéramos este juego espacial con cuatro mundos, tal vez solo cargaríamos las mecánicas de juego centrales y los activos del nivel de la nave espacial primero, y aplazaríamos el resto para ser cargado más tarde cuando el jugador llegue a él. También puedes hacer esto a un nivel más detallado, donde los activos individuales se cargan al vuelo y se representan con marcadores de posición mientras tanto.

Esta es una técnica popular en Unreal Engine con la representación de versiones de baja resolución de texturas como un marcador de posición para speed up los tiempos de carga. Con estas técnicas, aunque el tamaño total del juego almacenado en un servidor no disminuye, realmente ayuda a que el usuario entre en el juego mucho más rápido y a menudo reduce la descarga promedio requerida. Sin embargo, hay algunas compensaciones, ya que esto requiere una planificación cuidadosa y code para manejar la división del juego en segmentos autónomos, lo cual es más fácil para algunos tipos de juegos y algunos motores de juego que para otros. Además, si estás planeando incrustar este juego en el dispositivo del usuario, por ejemplo con algo como Cordova o Electron, la carga perezosa no te va a dar muchas grandes victorias ya que el usuario necesita la cosa entera de todos modos.

Ahora que hemos cubierto algunos consejos generales, vamos a profundizar en algunos contribuyentes clave del tamaño del archivo. He desglosado un juego web típico de nuestro catálogo en lo que compone su tamaño de archivo GZIPed, y podemos ver claramente tres categorías principales emergen: JavaScript, visuales, y Audio. Comencemos con JavaScript. Entonces, JavaScript es relativamente pequeño en comparación con los visuales y el Audio. Nuestro juego representativo, gracias en parte a GZIP, tenía JavaScript componiendo solo el 20% de su tamaño total, en comparación con el 43% de los visuales y el Audio. Sin embargo, aunque su tamaño de archivo bruto es más pequeño, JavaScript puede ser mucho más pesado de lo que parece a primera vista.

Como Adi Osmani lo expone en El Costo de JavaScript en 2018, byte por byte, JavaScript sigue siendo el recurso más costoso que enviamos a los teléfonos móviles, porque puede retrasar la interactividad de grandes maneras. De hecho, cargar JavaScript puede tener muchos efectos secundarios. A diferencia de recursos como imágenes, cargar JavaScript requiere no solo descargar, sino también analizar y ejecutar el script. Y si no tienes cuidado, durante todo este tiempo a menudo puede bloquear al navegador de descargar más elementos en paralelo, e incluso el renderizado inicial de la página.

Retrocedamos un momento, sin embargo, y repasemos cómo el navegador maneja HTML. Entonces, cuando vas a una página web, el navegador descarga el archivo HTML correspondiente y comienza a analizarlo. A medida que avanza, toma cada nueva etiqueta HTML y la agrega al DOM, que es esencialmente solo una representación en memoria de la página. Cuando ve CSS, comenzará a descargarlo y bloqueará el renderizado hasta que pueda cargarlo completamente, pero seguirá analizando el HTML. JavaScript es donde se pone un poco complicado. Debido a que JavaScript puede no solo cambiar, sino también leer desde el DOM de la página, técnicamente necesita ejecutarse de inmediato o el DOM estará en un estado desconocido de ejecución a ejecución. Como resultado, el JavaScript evitará no solo el renderizado, sino también cualquier otro análisis hasta que se haya descargado, analizado y ejecutado completamente.

Puedes notar el asterisco en la diapositiva. Hay algunos casos límite aquí. Las etiquetas de script que están marcadas con async, generalmente para cosas como análisis, no bloquearán el renderizado y el análisis. Y los navegadores modernos al menos pueden comenzar a cargar scripts y recursos que están todos agrupados juntos en HTML sin otros elementos del DOM en medio. Entonces, aquí hay un ejemplo de un posible peor caso. Si tu JavaScript se carga dinámicamente por JavaScript, puedes terminar en esta desafortunada situación donde todo tu JavaScript se carga y ejecuta en serie. Lo que tomará un tiempo total mucho más largo que si pudieran cargar en paralelo como las imágenes en la mitad inferior. Todo esto es para decir que definitivamente hay trampas. Y si colocas tu JavaScript incorrectamente en tu página, definitivamente puede ralentizar tu tiempo de carga. Pero afortunadamente, la solución del caso general es realmente bastante simple. Esencialmente, mantienes las hojas de estilo, las etiquetas de script asíncronas como Google Analytics y cualquier otra cosa en el encabezado. Y todo lo que haces es mover todas tus etiquetas de script regulares al final de la sección del cuerpo. Debido a que todos tus scripts ahora están agrupados al final del cuerpo, todos se descargarán en paralelo. Dado que todavía son etiquetas de script normales y no están marcadas como async, todavía se ejecutarán en orden, lo cual es genial para inicializar tu code de juego. Y dado que todo esto está al final de la etiqueta del cuerpo, todos los elementos del DOM anteriores todavía tendrán la oportunidad de cargar y renderizar, por lo que puedes obtener algo rápido para tus usuarios.

Ahora que todos nuestros scripts están en el lugar correcto, hablemos de los scripts en sí. Un atributo clave para reducir el tamaño del script es mediante el uso de la minificación. Este es un proceso donde se eliminan los caracteres innecesarios de tu code, de tal manera que todavía se ejecutará de la misma manera después. Hay una variedad de herramientas para hacer esto.

Desde Tercer hasta el Compilador de Cierre de Google, todos los cuales probablemente ejecutarías como parte de tu paso de construcción desde algo como Webpack. Sin embargo, simplemente ejecutarlo con las configuraciones predeterminadas solo te llevará parte del camino.

Una de las cosas clave que está desactivada por defecto en la mayoría de las herramientas es también entrelazar los nombres de las variables. El nombre exacto difiere dependiendo de la herramienta, pero cuando activas esto, automáticamente renombrará las variables para hacerlas más pequeñas. Bastante útil.

Sin embargo, aunque esto proporciona una reducción significativa, hay una razón por la que está desactivado por defecto. Puede causar problemas con tu código. El caso más común para esto es que ya no puedes mezclar diferentes formas de acceder a las propiedades de los objetos, ya que se entrelazan en diferentes declaraciones. Aquí, podemos ver que si estás estableciendo o accediendo a una propiedad con la notación de punto, entrelazar los nombres de las variables dará un resultado diferente al que usarías la notación de corchetes. Por lo tanto, si estás habilitando esta configuración, debes asegurarte de no mezclar estas dos notaciones para usar la misma propiedad de objeto.

Si estás minificando solo tu propio código, esto todavía es bastante factible, pero puede volverse realmente complicado al mezclar bibliotecas de terceros. En ese sentido, ten cuidado de no excederte con las bibliotecas de terceros. Aunque son bastante útiles, a menudo están escritas para manejar una amplia gama de casos de uso, lo que puede hacerlas más grandes de lo necesario. Como un ejemplo, recuerdo una biblioteca de carga .obj que ocupaba 400 kilobytes de código minificado. Escribir un código suficientemente bueno para cargar en OBJ en su lugar toma alrededor de 100 líneas. Esto no quiere decir que necesites escribir todo tú mismo, solo que deberías auditar lo que usas y asegurarte de que es la mejor opción que tienes. De hecho, a veces incluso puedes importar subsecciones más pequeñas de tus bibliotecas, en lugar de incluir todo, lo que ayuda a mitigar la cantidad de almacenamiento que requerirá.

Hablando de auditar lo que usas, hablemos de arte. Específicamente, el estilo de arte visual de un juego. Es mucho más fácil en estos días hacer juegos realistas en el navegador, lo cual es realmente impresionante. Sin embargo, es importante tener en cuenta a tu audiencia. Hay compensaciones cuando se trata de gráficos realistas, especialmente en términos de rendimiento y tamaño de archivo. Estos pipelines necesitan mucha más textura data, tamaños más grandes y muchos más tipos de texturas, además de grandes data para cálculos relacionados con la iluminación, como para sondas de reflexión o iluminación indirecta horneada.

En contraste, para un juego estilizado, puedes salirte con la suya con una colección de texturas o incluso un pequeño atlas de gradientes de 512 píxeles. De hecho, si solo estás usando materiales no iluminados, incluso puedes prescindir de los normales de tus archivos de modelo. Dicho esto, si optas por un aspecto estilizado, asegúrate de que no estás utilizando innecesariamente los materiales y pipelines de renderizado basados en física completos de los motores de juegos. Especialmente si estás apuntando a móviles, esto es más que probablemente excesivo, y tendrá impactos en el rendimiento y el tamaño del archivo. Por ejemplo, si quieres que los objetos sean de un solo color sólido o textura, no juegues con las texturas de emisión en el material de renderizado basado en física estándar. Solo usa un material no iluminado. Probablemente también será más rápido renderizar de esta manera.

Otro ejemplo aquí es un efecto de post-procesamiento llamado SSAO, o Screen Space Ambient Occlusion, que oscurece las hendiduras en los modelos 3D para simular sombras de iluminación indirecta reducida. Este efecto puede darle a tu juego un aspecto agradable, pero puede ser costoso e inconsistente en tiempo de ejecución, especialmente al intentar equilibrar para teléfonos móviles.

Una opción alternativa es intentar hornear las sombras en las texturas o colores de vértices. Esto tiene el potencial de aumentar el tamaño del archivo, que sé que es un poco diferente de esta charla, pero puede crear un aspecto más consistente que se ejecuta más suavemente en móviles. Como todos estos consejos, se trata de encontrar los compromisos adecuados para los objetivos de tu proyecto. Equilibrar rendimiento, tamaño de archivo, calidad visual, consistencia, jugabilidad y mucho más.

Una sugerencia final para el estilo artístico es sobre las sombras. El método moderno de renderizar sombras es con mapas de sombras. Aunque estos son soluciones efectivas en tiempo real para las sombras, también son bastante pesados en términos de rendimiento, ya que todos tus objetos tienen que ser renderizados varias veces, una vez desde cada luz para las sombras y luego una vez más para la renderización final. Y también pueden requerir algunos ajustes con la resolución, cascadas y otros ajustes para realmente gestionar el compromiso de calidad versus rendimiento para dispositivos como los móviles. Una alternativa es en cambio tomar un nodo de juegos clásicos y simplemente renderizar un objeto de sombra debajo de los objetos de juego relevantes. Esto es mucho más rápido, puede ser personalizado un poco más, como cuán suaves quieres que sean las sombras, y también puede hacer que la jugabilidad sea más clara, permitiendo al usuario ver la posición precisa x e y de los objetos en el aire, especialmente útil para recoger monedas flotantes o apuntar saltos complicados.

Además de los estilos artísticos no realistas que se prestan a tamaños de archivo pequeños, otra acción útil es asegurarte de que estás eligiendo el tipo correcto de formatos de archivo para tu proyecto. La forma en que me gustaría dividir esto es en tres categorías de archivos. Aquellos que contienen los datos de salida sin comprimir, como BMP y muchos archivos wave. Aquellos que almacenan los datos de salida en una forma comprimida, como la mayoría de las imágenes comunes, video, y archivos audio como png o mp3. Y lo que me gustaría llamar formatos procedimentales, aquellos que, en lugar de los datos en sí, almacenan una serie de instrucciones para generar esos datos de salida en tiempo de ejecución, como SVG y MIDI. La primera categoría de formatos sin comprimir no se usa mucho, ya que no es muy eficiente. Así que, en su lugar, vamos a hablar sobre la segunda categoría con la discusión sobre la compresión. Tenemos dos tipos de compresión. Sin pérdida, en la que los datos se conservan de tal manera que descomprimir la imagen te da una copia perfecta. Y con pérdida, en la que se pierden algunos datos, pero para el ojo humano se ve igual, o al menos lo suficientemente cerca. Una cosa clave a tener en cuenta es que nunca debes realizar una compresión con pérdida en imágenes que contienen datos en lugar de colores. Mapas normales, mapas de rugosidad metálica, imágenes de fuentes de campo de distancia firmadas y similares. Por lo general, estos resultarán en artefactos significativos. De hecho, aquí hay un ejemplo de eso. Hacer una compresión con pérdida en un archivo de fuente de campo de distancia firmado a la izquierda cambia severamente el aspecto del texto, de caracteres limpios a lo que parece pintura mojada emborronada. Sí, puede ser un efecto genial, pero no una sorpresa que quieras que te caiga inesperadamente cuando simplemente haces push a producción. Con una comprensión de estos dos tipos de compresión, echemos un vistazo a algunos formatos comunes para la web. GIF, JPEG y PNG son los formatos clásicos, y son compatibles con prácticamente todo.

Sin embargo, los formatos más nuevos pueden ser mucho más pequeños. En particular, WebP está alcanzando un amplio soporte, y no sólo puede combinar la compresión con pérdida con soporte alfa, sino que también comprime mejor que PNG y JPEG. Al cambiar a usar WebP, vimos una reducción del 25% en el tamaño del juego. AVIF es un nuevo formato de archivo que parece prometer una compresión aún mejor que WebP, pero todavía está comenzando en el camino hacia el soporte. Definitivamente algo a tener en cuenta, pero puede que aún no esté listo para migrar completamente a él todavía.

Otra categoría de archivos de imagen son las texturas comprimidas de GPU. Con otros tipos de imágenes, aunque están comprimidas en el disco, el ordenador tiene que expandirlas a 32 bits por pixel antes de que puedan ser utilizadas para dibujar. Esta es la razón por la que puedes haber notado que las imágenes ocupan mucho más memoria de la que podrías haber esperado. Las texturas comprimidas de GPU resuelven este problema al poder ser utilizadas mientras están comprimidas. Sin embargo, su uso puede ser muy complicado, especialmente porque hay una gran variedad de formatos diferentes, y las GPUs móviles y de escritorio tienen poca superposición en los tipos de formato que soportan. Dicho esto, si tu game engine soporta su uso, pueden ser bastante ventajosas.

Hemos hablado un poco sobre la compresión, así que vamos a pasar al último tipo de formatos de archivo - los procedimentales. Así que los formatos procedimentales son lo que llamo métodos de almacenar los procedimientos para generar los data, en lugar de los data en sí mismos. Esto puede tomar la forma de cosas como SVG, MIDI, o incluso JavaScript o code de sombreado. Aunque estos formatos tienen desventajas, a menudo hay un gran costo de performance como resultado de tener que pre-renderizar una imagen, realizar instrucciones adicionales de sombreado, o poner en cola instrumentos MIDI. También son increíblemente pequeños, y pueden ser personalizados, lo que te permite hacer algunas cosas realmente geniales. En mi opinión, estos son algunos de los grandes ejemplos de cómo a veces, cuando optimizas el tamaño del archivo, también obtienes grandes victorias en otras partes de tu proyecto.

Así que, por ejemplo, con SVGs y texturas procedimentales, puedes hacer imágenes que se ven nítidas a cualquier resolución. El número uno son las imágenes 9-patch, que se utilizan un poco en Android. Estos son archivos PNG configurados de tal manera que puedes hacer fácilmente componentes de UI que pueden ser redimensionados eficientemente manteniendo los bordes, márgenes y esquinas correctos. Otro que ya es popular en el mundo de los videojuegos son los mapas de baldosas. En lugar de almacenar una imagen completa y masiva del mundo del juego, puedes en su lugar almacenar un conjunto limitado de arte modular. Esto te permite ahorrar mucho espacio, pero también te permite hacer cosas geniales como tener mapas de daño de batalla o permitir que el jugador entre con un editor de terreno y construya sus propios mapas. En el lado del audio, también hay algunos casos de uso geniales, como los efectos de sonido procedimentales. Es más fácil mutar un efecto de sonido procedimental para que suene menos repetitivo cuando tienes un montón de ellos seguidos. También hay usos para audio más largo, como la music. Con los archivos MIDI, puedes reproducir la misma music en diferentes niveles, pero cambiar los instrumentos para que cada nivel suene único, pero aún tenga un tema cohesivo. Y finalmente, con herramientas 3D como Blender adoptando pipelines procedimentales con cosas como Geometry Nodes, creo que puede haber un montón de casos de uso geniales en el horizonte.

Para concluir todo esto, el mensaje central que quiero que todos se lleven es que hay un montón de formas de reducir el tamaño de tu juego web, y aunque a veces hay compensaciones con desventajas o beneficios adicionales, mantener los juegos pequeños realmente te permite canalizar la facilidad y la accessibility que hacen que los juegos web sean tan geniales. Si estás interesado en hacer juegos en formato masterclass, definitivamente te animaría a unirte a nosotros aquí en Gamesnacks.

Actualmente estamos en una etapa de programa de Acceso Anticipado trabajando con socios selectos, pero esperamos abrirlo más públicamente en un futuro cercano. Aquí hay un enlace si estás interesado en aprender más. Muchas gracias por tu tiempo y que tengas un gran resto de tu día.

Creo que empezaré mirando los resultados de la encuesta aquí. Parece que la elección principal que la gente usa cuando hace juegos en la web es Phaser, lo cual no me sorprende, o Pixie, lo cual tampoco me sorprende mucho, eso es también lo que tiendo a usar. Pero también es interesante que Unity sea la segunda opción porque, sí, Alex, ¿qué piensas?

Sí, creo que lo más destacado de esto, que creo es realmente genial, es simplemente cuán diversa es la gama de motores que la gente usa. Sé que, cuando estaba preparando la charla, no estaba seguro si debería, ya sabes, realmente centrarme en un motor u otro. Y creo que hacerlo de una manera general amplia, estoy realmente contento de haber elegido hacer eso, ya que esto muestra, ya sabes, porque tanta gente está usando tantas cosas diferentes. Y creo que ese tipo de poder para elegir lo que mejor te funciona, ya sabes, ¿quiero algo como un todo en uno como Unity, o quiero entrar más en el code con cosas como Phaser o Pixie? Creo que ese es uno de los poderes geniales que te da la web. Sí, me gusta mucho eso, e incluso puedes ver que hay una porción no insignificante que simplemente no usa un motor o construye su propia cosa, lo cual también añade a la diversidad de tecnologías en la web, pero también creo que al juego se siente o a cómo la gente le gusta crear cosas.

Sí, por supuesto. Creo que una de las cosas que, ya sabes, me he dado cuenta al construir un motor personalizado es que realmente te permite cambiar la forma en que estás construyendo el juego. Y creo que eso te permite crear proyectos más experimentales o irte. Es como recuerdo que un desarrollador decía que las herramientas que usas para hacer algo informan lo que haces. Y así, cuando estás construyendo tus propias herramientas personalizadas, realmente te ayuda a expandir y salir del camino trillado. Sí, estoy totalmente de acuerdo con eso. Y creo que he experimentado eso yo mismo cuando solía hacer juegos flash, como Box 2D era, ya sabes, un motor de física muy común, ese era realmente el único que la gente conocía. Y la mayoría de las veces podía decir que un juego estaba hecho con Box 2D simplemente porque muchas veces si simplemente dejas un montón de la fricción por defecto, un montón del impulso por defecto, etc. Obtienes esa sensación. No hay nada malo en eso porque muchos de esos juegos son realmente divertidos, pero es como dijiste, como tu elección de herramientas a menudo sí que, incluso si no te limita, pero sí te apunta en una dirección diferente. ¿Verdad? Sí, como te pone en el camino por defecto, más o menos. Sí. No hay nada malo en, creo que hay algo que decir para dar al jugador familiaridad, como, Oh, ya sabes, esta física es justo como espero, ya sabes, pero sí. Así que, creo que quieres mantener la seguridad con algunas cosas y ser experimental con otras por supuesto. Tener un poco de flexibilidad, supongo. Sí, sí. Por supuesto. Creo que podemos pasar a algunas de las preguntas de la audiencia aquí. Una pregunta fue ¿debería siempre tratar de optimizar mi juego para el tamaño del archivo? Sí, creo que esta es una gran pregunta. Una cosa que sé en mi charla, era como mucho sobre, ya sabes, puedes optimizar esto y aquello, y ya sabes, todas estas cosas diferentes.

Pero quiero insistir en que, definitivamente hay casos en los que puede que no quieras optimizar, tal vez es un juego de programación, como un juego sobre programación. Entonces, en realidad quieres que los usuarios profundicen en tu code, vean cómo funciona la lógica del enemigo y la utilicen para contrarrestarlos. Entonces, si estás minimizando todo ese code, es como, ya sabes, pobres usuarios, el juego es injugable. Pero quiero decir, en el caso general, creo que, ya sabes, si tomas cada pequeña optimization, generalmente, ya sabes, incluso si es un juego grande, cada pequeña optimization es definitivamente una victoria. Pero realmente se trata de gestionar las prioridades. ¿Estás buscando juegos pequeños o tienes otras prioridades para hacerlo más realista? Creo que esta charla y quería dar esta charla a todos es que creo que el tamaño del archivo es un valor importante si estás planeando lanzar en la web. Si sabes, no valoras poder entrar y salir muy fácilmente y por lo tanto no te importa el tamaño del archivo, tal vez la web no sea la mejor plataforma, ya sabes, si vas para la web, podrías aprovecharla al máximo.

Creo que eso tiene mucho sentido. Y creo que fue algo que quizás mencionaste en tu masterclass sobre cómo. Generalmente, tener un tamaño de archivo mucho más pequeño ayuda en términos de retención o alcance, es decir, es más probable que las personas se queden en el juego. Y para mí, al menos, esa es parte de la motivación de la web si estoy decidiendo si estoy haciendo un proyecto en el escritorio o no.

Muchas veces les diré a mis amigos, oh, podrías hacer esto y publicarlo en el escritorio, pero probablemente tendrás 10 veces más personas mirándolo. Si publicas una versión web y especialmente si es algo que está optimizado y se carga rápido y puedes enviarle a alguien un enlace para jugar.

Sí, seguro. Como sé por nuestras métricas, no puedo compartir la exacta. Definitivamente hemos visto que muchas más personas se unirán no solo cuando sea web versus móvil, sino también cuando sea web pequeña versus web grande o, ya sabes, web que te permite al menos comenzar a jugar versus web que requiere registrarte antes de que puedas, tú sabes, dar inicio. Tiene mucho sentido. Sí. Oh no, sigue adelante. Lo siento. Iba a decir, creo que algunos de los advice que diste en la masterclass, no necesariamente incluso tienen un compromiso. Como uno de ellos era como, quieres que se cargue más rápido, pero incluso si no lo hace, puedes hacer que parezca que se está cargando, como que algo está sucediendo. Entonces ni siquiera necesitas hacerlo, ya sabes, no necesitas desechar los activos de arte, pero solo comunicar eso al jugador, ya sabes, ayuda, ya sabes, visualmente retrasa, reduce el tiempo de carga percibido, que creo que es bastante valioso.

Exactamente. Como, creo que una cosa que creo que fue un profesor quien me lo dijo, pero creo que es realmente valioso, es como la verdad versus la percepción. Es como la percepción es en realidad más importante porque la verdad, es como nadie sabe realmente qué está pasando, pero si el usuario siente como la verdad, lo que el usuario percibe es su verdad. Así que eso es realmente lo que quieres optimizar. Me encanta eso. Siento que es una gran conclusión. Una conclusión muy sucinta y genial. Teníamos otra pregunta sobre cuándo estás desarrollando. ¿Cómo pruebas conexiones a Internet más lentas?

Claro. Esta es una gran pregunta. Tenemos una variedad de ellas. Creo que para la prueba rápida, como, ya sabes, creo que lo importante son los ciclos de retroalimentación, ¿verdad? Quieres mantener el ciclo de retroalimentación en general, ya sabes, si estás haciendo arte o quieres reducir eso lo más rápido posible. Así puedes seguir iterando sobre ello. Entonces, para pruebas rápidas, como las herramientas de navegador de Chrome o, ya sabes, Firefox o lo que sea, donde puedes limitar las velocidades de red, creo que hace un gran trabajo aproximado de eso.

Pero para que sepas, eso te ayuda a estar en la posición correcta cuando realmente quieres hacer ese corte preciso, hay muchas herramientas hoy en día. No quiero patrocinar ninguna en particular, pero donde realmente como proxy tu a través de un servidor para que puedas ver cómo se siente realmente si vives en diferentes ubicaciones o a través de diferentes redes, o diferentes navegadores, dispositivos, lo cual creo que es realmente genial. Eso es increíble. No había pensado en eso, porque mi objetivo siempre ha sido solo las herramientas de desarrollador de Chrome. Pero me gusta eso, sabes, tener estas herramientas extra y tendríamos como, de nuevo, creo que eso te lleva la mayor parte del camino. Y cuando realmente necesitas averiguar con cuál ir, creo que conseguirlo de una manera más física más cercana al metal, creo que se siente más preciso. Eso tiene mucho sentido. Tenemos otra pregunta sobre métricas. Dice ¿qué métricas estás mirando cuando se trata de performance y retención de jugadores? Claro. Sí. Así que esta es una gran pregunta. Así que performance, como hay muchos tipos diferentes de performance, ¿verdad? Cosas que por ejemplo medimos es cuánto tiempo, cuán grande es el juego, como descarga inicial antes de que puedas empezar a jugar, cuánto tiempo tarda en aparecer las primeras pantallas como, sabes, solo una carga como, sabes, spinner o algo así. Así que esos dos son como cuán grande es, cuán rápido puedes saltar. También el promedio de fotogramas por segundo, creo que hicimos como el fondo, hicimos como promedio y también como el fondo, sabes, 5%. Así que como si ocasionalmente se pierde un fotograma, sabes, OK, pero como no debería estar perdiendo fotogramas mucho. Así que eso va a performance en tiempo de ejecución en términos de cuánto como tipo de compromiso del usuario. Creo que algunas de las métricas que miramos fueron como tiempo medio de juego como tasa de equilibrio en los juegos. Y oh, chico, necesito mirar las métricas de nuevo hoy, en realidad, para algunas cosas. Pero sí, promedio eso. Y creo que hay uno de cuánto tiempo como promedio como número porcentaje de usuarios que juegan más tiempo que como X tiempo. Eso tiene mucho sentido. Creo que es la última pregunta que tenemos. ¿Cuáles son tus pensamientos sobre las nuevas tecnologías web como WebAssembly o WebGPU? Claro, sí, creo que sé que hubo algunas charlas más temprano hoy que estaban hablando sobre como WebTransport y WebGPU. Solo quiero hacer eco de eso. Creo que todas esas son realmente emocionantes porque creo que realmente pueden habilitar algunos de los avances que hemos visto últimamente con el escritorio, como mover cosas a shaders de cálculo y así sucesivamente. En términos de WebAssembly, que ya está más o menos fuera y se está volviendo bastante popular, creo que también es realmente emocionante solo porque habla de como accessibility y facilidad de uso. Pero en el lado del desarrollador, y eso, sabes, creo que hay muchos grandes navegadores como frameworks nativos como Pixie y Phaser y, sabes, free JS. Pero creo que la idea de que WebAssembly también puede extenderlo a tipo de C, C++ cosas como Unity o, bueno, solía ser Unreal. De todos modos, en resumen, creo que es realmente emocionante que abre más formas de construir. Genial. Increíble. Bueno, muchas gracias, Alex. Fue genial tenerte aquí. Aprendí mucho, personalmente, y definitivamente voy a revisar el enlace que tenías sobre los juegos a continuación. Así que muchas gracias por estar aquí. Sí, muchas gracias también por tenerme. Es genial estar aquí.