Creación de juegos web "Bite-Sized" con GameSnacks

Rate this content
Bookmark

Una de las grandes fortalezas de los juegos en la web es lo fácilmente accesibles que pueden ser. Sin embargo, esta ventaja clave a menudo se ve negada por activos grandes y tiempos de carga largos, especialmente en conexiones móviles lentas. En esta charla, Alex Hawker de GameSnacks de Google ilustrará cómo están abordando este problema y algunos aprendizajes clave que el equipo encontró al optimizar juegos de terceros y diseñar su propio motor de juegos ultraligero.

33 min
07 Apr, 2022

Video Summary and Transcription

Bienvenido a la creación de juegos "Bite-Sized" con GameSnacks, una plataforma que se enfoca en optimizar el tamaño de los juegos para facilitar su accesibilidad en la web. Técnicas como la carga diferida, la ubicación de scripts y la optimización de código y arte pueden mejorar en gran medida el rendimiento del juego. Elegir los formatos de archivo correctos, reducir el tamaño del juego y utilizar motores de juegos o herramientas personalizadas son consideraciones importantes. Priorizar el tamaño del archivo, probar las conexiones a Internet y utilizar herramientas de prueba para una simulación precisa pueden ayudar a atraer a más usuarios y mejorar la retención y el alcance del juego.

Available in English

1. Introducción a GameSnacks y Optimización de Juegos

Short description:

Bienvenidos a la creación de juegos pequeños con GameSnacks. La web tiene la ventaja de ser fácilmente accesible para los juegos, pero los tamaños de archivo grandes dificultan esto. GameSnacks está trabajando en la optimización de los tamaños de los juegos. El uso de la compresión gzip y la visualización rápida de elementos mejoran la experiencia del usuario.

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

Ahora, es posible que estén pensando, ¿por qué juegos pequeños? ¿No son suficientemente buenas las velocidades de internet en estos días? Bueno, una de las principales ventajas de la web como plataforma para juegos es su capacidad para la viralidad, perfectamente expresada en ejemplos desde los juegos io hasta el éxito reciente, Wordle. Pero esta ventaja de fácil accessibility se ve gravemente afectada cuando los tamaños de los archivos se disparan demasiado alto. A pesar de los avances como el 5G, gran parte del mundo todavía experimenta conexiones más lentas con frecuencia, desde Australia, hasta India, hasta aquí mismo en los Estados Unidos. Sé que muchas veces he experimentado en lugares donde la velocidad de internet de mi teléfono de repente se vuelve muy lenta. Y en momentos como estos, cuando incluso un juego de 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 web para ayudar a que los juegos sean universalmente accesibles y útiles. Como parte de este esfuerzo, hemos experimentado mucho con la optimización de juegos y sus archivos tamaños. Incluso llegando tan lejos como construir un game engine experimental para ver hasta dónde se pueden llevar estas optimizaciones, y qué tan valiosos pueden ser los diferentes tipos. Hoy estoy aquí 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 profundizaremos en las optimizaciones específicas para diferentes tipos de archivos.

En primer lugar, el uso de la compresió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 admiten que los servidores les envíen estos archivos comprimidos con gzip, lo que permite reducir la cantidad de bytes que necesitamos enviar. Sin embargo, debido a la forma en que funciona gzip, no funciona bien en todos los archivos. En su lugar, solo debes usarlo en archivos sin comprimir como código, configuraciones y formatos específicos como svg o midi. A diferencia de otros tips, el uso de gzip no es un cambio realizado en el proyecto del juego en sí, sino que debe habilitarse en el servidor. Afortunadamente, esto suele ser bastante sencillo. Por ejemplo, en Google Cloud Storage, solo tienes que agregar esta bandera Zed con la lista de extensiones que deseas comprimir con gzip.

A continuación, tenemos bueno, esto es un poco incómodo. No es realmente agradable, por eso es tan importante mostrar algún tipo de visualización a los usuarios rápidamente. Esto es fundamental, porque las investigaciones muestran que simplemente tener un tiempo de carga de la página de 1 segundo a 5 segundos aumenta la tasa de rebote de la página en un 90%. Por lo tanto, mostrar al usuario alguna visualización idealmente animada, ya sea una pantalla de presentación o una pantalla de carga les asegura que las cosas no están rotas y les da algo en qué enfocarse para que la carga se sienta más rápida para el usuario. Entonces, aunque esto no mejorará los tiempos de carga totales, o incluso podría empeorarlos ligeramente es en general una gran victoria, ya que al final del día, la percepción del usuario es lo que importa, no las métricas en bruto. De manera similar, la carga lenta de contenido puede ser una gran victoria.

2. Lazy Loading y Tamaño de JavaScript

Short description:

La carga lenta es una técnica en la que solo se carga el contenido que se necesita en el momento actual. Esto se puede hacer a nivel detallado, cargando los activos sobre la marcha y utilizando marcadores de posición. Ayuda a que el usuario entre al juego más rápido y reduce la descarga promedio requerida. JavaScript es relativamente pequeño en comparación con los gráficos y el audio en términos de tamaño de archivo, pero puede ser más pesado de lo que parece.

Esto es cuando, en lugar de cargar todo de manera anticipada, 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 los mecanismos básicos del juego y los activos del nivel de la nave espacial primero, y pospondríamos el resto para cargarlo más tarde cuando el jugador llegue a eso. También se puede hacer esto a nivel más detallado, donde los activos individuales se cargan sobre la marcha y se representan con marcadores de posición mientras tanto.

Esta es una técnica popular en Unreal Engine que consiste en renderizar versiones de baja resolución de texturas como marcadores de posición para acelerar 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 al 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 código para dividir el juego en segmentos autocontenidos, lo cual es más fácil para algunos tipos de juegos y algunos motores de juegos que para otros. Además, si planeas incrustar este juego en el dispositivo del usuario, por ejemplo, con algo como Cordova o Electron, la carga lenta no te dará muchas ventajas importantes ya que el usuario necesita el juego completo de todos modos.

Ahora que hemos cubierto algunos consejos generales, profundicemos 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 GZIP y podemos ver claramente tres categorías principales: JavaScript, Gráficos, y Audio. Comencemos con JavaScript. Entonces, JavaScript es relativamente pequeño en comparación con los gráficos y el audio. Nuestro juego representativo, gracias en parte a GZIP, tenía JavaScript que solo componía el 20% del tamaño total, en comparación con el 43% de los gráficos y el audio. Sin embargo, aunque su tamaño de archivo en bruto es más pequeño, JavaScript puede ser mucho más pesado de lo que parece al principio.

3. Carga de JavaScript y Colocación de Scripts

Short description:

JavaScript es el recurso más costoso que enviamos a los teléfonos móviles, ya que puede retrasar la interactividad. Cargar JavaScript requiere descargar, analizar y ejecutar el script, lo que puede bloquear el navegador y la representación inicial. Colocar JavaScript correctamente y usar etiquetas de script asíncronas puede mejorar el rendimiento. Mover las etiquetas de script regulares al final del cuerpo permite que se descarguen en paralelo y se ejecuten en orden. La minificación reduce el tamaño del script eliminando caracteres innecesarios.

Como lo explica Adi Osmani 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, ya que puede retrasar la interactividad de gran manera. De hecho, cargar JavaScript puede tener muchos efectos secundarios. A diferencia de recursos como imágenes, cargar JavaScript no solo requiere descargarlo, sino también analizarlo y ejecutarlo. Y si no tienes cuidado, durante todo este tiempo a menudo puede bloquear el navegador para descargar más elementos en paralelo e incluso la representación inicial de la página.

Pero retrocedamos un momento y repasemos cómo maneja el navegador el HTML. Cuando visitas 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 una representación en memoria de la página. Cuando encuentra CSS, comenzará a descargarlo y bloqueará la representación hasta que se cargue por completo, pero seguirá analizando el HTML. JavaScript es donde se vuelve un poco complicado. Debido a que JavaScript no solo puede cambiar, sino también leer del DOM de la página, técnicamente necesita ejecutarse de inmediato o el DOM estará en un estado desconocido de una ejecución a otra. Como resultado, el JavaScript no solo evitará la representación, sino también cualquier análisis adicional hasta que se haya descargado, analizado y ejecutado por completo.

Puedes notar el asterisco en la diapositiva. Aquí hay algunos casos especiales. Las etiquetas de script marcadas con async, generalmente para cosas como análisis, no bloquearán la representación y el análisis. Y los navegadores modernos al menos pueden comenzar a cargar scripts y recursos que están todos agrupados en HTML sin otros elementos del DOM en el medio. Entonces, aquí tienes un ejemplo de un escenario potencialmente peor. Si tu JavaScript se carga dinámicamente por JavaScript, puedes terminar en esta desafortunada situación donde todo tu JavaScript se carga y se ejecuta en serie. Esto tomará mucho más tiempo total que si pudieran cargarse en paralelo como las imágenes en la mitad inferior. Todo esto es para decir que definitivamente hay cosas a tener en cuenta. Y si colocas incorrectamente tu JavaScript en tu página, definitivamente puede ralentizar el tiempo de carga. Pero afortunadamente, la solución general es bastante simple. Básicamente, 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, se descargarán en paralelo. Como todavía son etiquetas de script normales y no están marcadas como asíncronas, se ejecutarán en orden, lo cual es excelente para inicializar el código de tu juego. Y como todo esto está al final de la etiqueta del cuerpo, todos los elementos DOM anteriores aún tendrán la oportunidad de cargarse y representarse, por lo que puedes brindar algo rápido a tus usuarios.

Ahora que todos nuestros scripts están en el lugar correcto, hablemos de los propios scripts. Un atributo clave para reducir el tamaño del script es utilizar la minificación. Este es un proceso en el que se eliminan caracteres innecesarios de tu código, de modo que seguirá funcionando de la misma manera después. Hay una variedad de herramientas para hacer esto.

4. Optimización de Código y Arte

Short description:

Ejecutar herramientas de minificación con la configuración predeterminada solo te lleva hasta cierto punto. Habilitar la mezcla de nombres de variables puede reducir el tamaño del código, pero ten cuidado al mezclar diferentes formas de acceder a las propiedades del objeto. Ten en cuenta las bibliotecas de terceros y considera importar subsecciones más pequeñas. En cuanto al arte, los gráficos realistas tienen compensaciones en rendimiento y tamaño de archivo. Los juegos estilizados pueden utilizar texturas y materiales más simples para optimizar para dispositivos móviles.

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, ejecutarlo con la configuración predeterminada solo te lleva hasta cierto punto.

Una de las cosas clave que está deshabilitada de forma predeterminada en la mayoría de las herramientas es la mezcla de nombres de variables. El nombre exacto difiere según la herramienta, pero cuando lo activas, automáticamente se renombrarán las variables para que sean más pequeñas. Bastante útil.

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

Si solo estás minificando tu propio código, esto todavía es bastante factible, pero puede volverse realmente complicado cuando mezclas bibliotecas de terceros. En ese sentido, ten cuidado de no exagerar con las bibliotecas de terceros. Si bien son muy útiles, a menudo están escritas para manejar una amplia gama de casos de uso, lo que puede hacer que sean más grandes de lo necesario. Como ejemplo, recuerdo una biblioteca de carga de archivos .obj que ocupaba 400 kilobytes de código minificado. Escribir un código suficientemente bueno para cargar OBJ en su lugar requiere alrededor de 100 líneas. Esto no significa que debas escribir todo tú mismo, solo debes auditar lo que uses y asegurarte de que sea 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 visual de arte de un juego. Hoy en día es mucho más fácil 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 flujos de trabajo requieren mucha más información de textura, tamaños más grandes y muchos más tipos de texturas, además de datos grandes para cálculos relacionados con la iluminación, como sondas de reflexión o iluminación indirecta precalculada.

En contraste, para un juego estilizado, es posible que puedas salirte solo con una colección de texturas o incluso un solo atlas pequeño de 512 píxeles de gradientes. De hecho, si solo estás utilizando materiales sin iluminación, es posible que incluso puedas prescindir de las normales en tus archivos de modelo. Dicho esto, si estás buscando un aspecto estilizado, asegúrate de no seguir utilizando innecesariamente los materiales y flujos de trabajo de renderizado basados en física de los motores de juegos. Especialmente si estás apuntando a dispositivos 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 o textura, no juegues con texturas de emisión en el material de renderizado basado en física estándar. Simplemente utiliza un material sin iluminación. Es probable que también se renderice más rápido de esta manera.

5. Efectos de Postprocesamiento, Sombras y Formatos de Archivo

Short description:

SSAO es un efecto de postprocesamiento que oscurece las grietas en modelos 3D para simular sombras. Hornear sombras en texturas o colores de vértices puede crear una apariencia más consistente. Renderizar un objeto de sombra debajo de los objetos del juego es una alternativa a los mapas de sombras en tiempo real pesados. Elije los formatos de archivo adecuados: sin comprimir, comprimidos y procedurales. No se debe utilizar compresión con pérdida en imágenes con datos. GIF, JPEG y PNG son formatos web comunes.

Occlusion en Espacio de Pantalla, que oscurece las grietas en modelos 3D para simular sombras a partir de la 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 puede aumentar el tamaño del archivo, lo cual sé que es un tema diferente en esta charla, pero puede crear una apariencia más consistente que se ejecuta de manera más fluida en dispositivos móviles. Como todos estos consejos, se trata de encontrar los compromisos adecuados para los objetivos de tu proyecto. Equilibrar el rendimiento, el tamaño del archivo, la calidad visual, la consistencia, la jugabilidad y mucho más.

Una sugerencia final para el estilo artístico se refiere a las sombras. El método moderno para renderizar sombras es con mapas de sombras. Si bien son soluciones en tiempo real efectivas para sombras, también son bastante pesadas en términos de rendimiento, ya que todos tus objetos deben renderizarse varias veces, una vez desde cada luz para las sombras y luego nuevamente para la renderización final. También pueden requerir ajustes de resolución, cascadas y otras configuraciones para gestionar realmente el equilibrio entre calidad y rendimiento en dispositivos como los móviles. Una alternativa es tomar una idea de los juegos clásicos y simplemente renderizar un objeto de sombra debajo de los objetos relevantes del juego. Esto es mucho más rápido, se puede personalizar un poco más, como la suavidad que deseas que tengan las sombras, y también puede hacer que la jugabilidad sea más clara, al permitir al usuario ver la posición precisa en el eje x e y de los objetos en el aire, especialmente útil para recolectar 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 asegurarse de elegir 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 de audio. Aquellos que almacenan los datos de salida en forma comprimida, como la mayoría de los formatos comunes de imagen, video y audio como png o mp3. Y lo que me gustaría llamar formatos procedurales, 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 utiliza tanto, ya que no es muy eficiente. Entonces, en lugar de eso, pasemos a hablar sobre la segunda categoría al discutir la compresión. Tenemos dos tipos de compresión. Sin pérdida, en la que los datos se conservan de manera que descomprimir la imagen te da una copia perfecta. Y con pérdida, en la que se pierden algunos datos, pero a simple vista se ve igual, o al menos lo suficientemente similar. Una cosa clave a tener en cuenta es que nunca debes realizar compresión con pérdida en imágenes que contengan datos en lugar de colores. Mapas normales, mapas de rugosidad metálica, imágenes de fuentes de campo de distancia firmadas, y cosas por el estilo. Por lo general, esto resultará en artefactos significativos. De hecho, aquí tienes un ejemplo de eso. Hacer compresión con pérdida en un archivo de fuente de campo de distancia firmada a la izquierda cambia drásticamente la apariencia del texto, de caracteres limpios a lo que parece pintura húmeda manchada. Sí, puede ser un efecto interesante, pero no es una sorpresa que quieras tener cuando lo implementes. 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 casi todo.

6. Optimización de formatos de archivo y reducción del tamaño del juego

Short description:

Los nuevos formatos de imagen como WebP y AVIF ofrecen una mejor compresión y soporte para alfa. Las texturas comprimidas por GPU se pueden utilizar mientras están comprimidas, pero la compatibilidad puede ser un desafío. Los formatos procedurales como SVG y MIDI son pequeños y personalizables, pero tienen compromisos de rendimiento. Las imágenes de 9-patch y los mapas de mosaicos ahorran espacio y ofrecen posibilidades creativas. Los efectos de sonido procedurales y los archivos MIDI permiten variación y temas cohesivos. Los flujos de trabajo procedurales en herramientas 3D abren nuevos casos de uso. Reducir el tamaño del juego permite una fácil accesibilidad. Únete a GameSnacks para el desarrollo de juegos en formato reducido.

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

Otra categoría de archivos de imagen son las texturas comprimidas por GPU. Con otros tipos de imágenes, aunque están comprimidas en el disco, la computadora debe expandirlas a 32 bits por píxel antes de poder usarlas para dibujar. Esta es la razón por la cual es posible que hayas notado que las imágenes ocupan mucha más memoria de la que esperabas. Las texturas comprimidas por GPU resuelven este problema al poder utilizarse mientras están comprimidas. Sin embargo, usarlas puede ser muy complicado, especialmente porque hay una gran variedad de formatos diferentes y las GPU de dispositivos móviles y de escritorio tienen poca superposición en los tipos de formato que admiten. Dicho esto, si tu motor de juegos admite su uso, pueden ser bastante ventajosas.

Hemos hablado un poco sobre la compresión, así que pasemos al último tipo de formatos de archivo: los formatos procedurales. Los formatos procedurales son métodos de almacenamiento de los procedimientos para generar los datos, en lugar de los propios datos. Esto puede tomar la forma de cosas como SVG, MIDI o incluso código JavaScript o de sombreado. Si bien estos formatos tienen desventajas, a menudo hay un gran costo de rendimiento como resultado de tener que pre-renderizar una imagen, realizar instrucciones de sombreado adicionales o encolar instrumentos MIDI. También son increíblemente pequeños y se pueden personalizar, lo que te permite hacer cosas realmente geniales. En mi opinión, estos son algunos ejemplos excelentes de cómo a veces, cuando optimizas el tamaño del archivo, también obtienes grandes beneficios en otros aspectos de tu proyecto.

Por ejemplo, con SVG y texturas procedurales, puedes crear imágenes que se vean nítidas a cualquier resolución. El número uno son las imágenes de 9-patch, que se utilizan un poco en Android. Estos son archivos PNG configurados de tal manera que puedes crear fácilmente componentes de interfaz de usuario que se pueden redimensionar de manera eficiente mientras mantienen los bordes, márgenes y esquinas correctos. Otro que ya es popular en el mundo de los juegos son los mapas de mosaicos. En lugar de almacenar una imagen completa y masiva de todo el mundo del juego, puedes almacenar un conjunto limitado de arte modular. Esto te permite ahorrar mucho espacio, pero también te permite hacer cosas geniales como tener mapas con daños de batalla o permitir que el jugador use un editor de terrenos para construir sus propios mapas. En el lado del audio, también hay algunos casos de uso interesantes, como los efectos de sonido procedurales. Es más fácil modificar un efecto de sonido procedural para que suene menos repetitivo cuando tienes un montón de ellos seguidos. También hay usos para audios más largos, como la música. Con archivos MIDI, puedes reproducir la misma música 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 que adoptan flujos de trabajo procedurales con cosas como Geometry Nodes, creo que puede haber muchos casos de uso geniales en el horizonte.

Para resumir todo esto, el mensaje principal que quiero que todos se lleven es que hay muchas formas de reducir el tamaño de tu juego web, y aunque a veces hay compromisos con desventajas o beneficios adicionales, mantener los juegos pequeños realmente te permite aprovechar la facilidad y accesibilidad que hacen que los juegos web sean tan geniales. Si estás interesado en crear juegos en formato reducido, definitivamente te animo a que te unas a nosotros aquí en GameSnacks.

QnA

Motores de Juego y Herramientas Personalizadas

Short description:

Actualmente estamos en una etapa de acceso anticipado trabajando con socios seleccionados. Las principales opciones para crear juegos en la web son Phaser y Pixie. Unity también es una opción popular. La diversidad de motores utilizados por las personas es impresionante. El poder de elegir lo que mejor funcione para ti es uno de los aspectos geniales que ofrece la web. Construir un motor personalizado te permite cambiar la forma en que construyes el juego y crear proyectos experimentales. La elección de tus herramientas a menudo te lleva en una dirección diferente. Darle familiaridad al jugador puede ser beneficioso, pero también experimental. Una pregunta de la audiencia fue: ¿Siempre debo intentar optimizar mi juego en cuanto al tamaño del archivo?

Actualmente estamos en una etapa de acceso anticipado trabajando con socios seleccionados, pero esperamos abrirlo de manera más pública en un futuro cercano. Aquí tienes un enlace si estás interesado en obtener más información. Muchas gracias por tu tiempo y que tengas un excelente resto de día.

Creo que comenzaré por analizar los resultados de la encuesta aquí. Parece que la opción principal que la gente utiliza al crear juegos en la web es Phaser, lo cual no me sorprende, o Pixie, lo cual tampoco me sorprende, ya que también es lo que suelo usar. Pero también es interesante que Unity esté en segundo lugar porque, sí, Alex, ¿qué opinas al respecto?

Sí, creo que lo que más me llama la atención de esto, y que me parece realmente genial, es la diversidad de motores que la gente utiliza. Cuando estaba preparando la charla, no estaba seguro si debería centrarme en un motor en particular. Y creo que hacerlo de manera general y amplia, como se muestra aquí, es una buena elección, ya que muchas personas utilizan diferentes cosas. Creo que ese poder de elegir lo que mejor funcione para ti, ya sea un enfoque todo en uno como Unity o adentrarte más en el código con cosas como Phaser o Pixie, es uno de los aspectos geniales que ofrece la web. Me gusta mucho eso, e incluso se puede ver que hay una parte no insignificante que no utiliza un motor o que crea su propia herramienta, lo cual también contribuye a la diversidad de tecnologías en la web y a la forma en que a la gente le gusta crear cosas.

Sí, definitivamente. Creo que una de las cosas que me he dado cuenta al construir un motor personalizado es que realmente te permite cambiar la forma en que construyes el juego. Y creo que eso te permite crear proyectos más experimentales o salirte del camino trillado. Recuerdo que un desarrollador decía que las herramientas que utilizas para crear algo influyen en lo que creas. Por lo tanto, cuando construyes tus propias herramientas personalizadas, realmente te ayuda a expandirte y a explorar nuevos caminos. Estoy totalmente de acuerdo con eso. También lo he experimentado cuando solía crear juegos en Flash, por ejemplo, Box2D era un motor de física muy común, era prácticamente el único que la gente conocía. La mayoría de las veces podía decir que un juego estaba hecho con Box2D simplemente porque muchas veces se dejaban los valores predeterminados de fricción y momento, etc. No hay nada de malo en eso, porque muchos de esos juegos son realmente divertidos, pero como dijiste, la elección de tus herramientas a menudo te lleva en una dirección diferente, ¿verdad? Sí, te pone en el camino predeterminado, por así decirlo. Sí, no hay nada de malo en eso. Creo que hay algo que decir acerca de darle familiaridad al jugador, como `Oh, esta física es justo como esperaba`, ya sabes, pero sí. Creo que debes mantener algunas cosas seguras y experimentar con otras, así que definitivamente. Es bueno tener un poco de flexibilidad, supongo. Sí, exactamente. Claro, creo que podemos pasar a algunas preguntas de la audiencia. Una pregunta fue: ¿Siempre debo intentar optimizar mi juego en cuanto al tamaño del archivo? Sí, creo que esta es una excelente pregunta. Una cosa que mencioné en mi charla es que puedes optimizar esto y aquello, y todas estas cosas diferentes.

Optimización y Prioridades

Short description:

Existen casos en los que la optimización puede no ser necesaria, como en los juegos de programación en los que los usuarios necesitan analizar el código. Sin embargo, en general, optimizar cada aspecto del juego es beneficioso. Priorizar el tamaño del archivo es importante para los lanzamientos web.

Pero quiero enfatizar que existen casos en los que es posible que no desees optimizar, como en un juego de programación, un juego sobre programar. En realidad, quieres que los usuarios profundicen en tu código, vean cómo funciona la lógica del enemigo y lo utilicen para contrarrestarlos. Si estás minimizando todo ese código, es como, ya sabes, malo para los usuarios, el juego no se puede jugar. Pero en general, creo que, ya sabes, si tomas cada pequeña optimización, generalmente puedes obtener una ventaja, incluso si es un juego grande. 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 porque creo que el tamaño del archivo es un valor importante si planeas lanzarlo en la web. Si no valoras la capacidad de entrar y salir 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 a la web, más vale aprovecharla al máximo.

Retention, Reach, and Testing Internet Connections

Short description:

Tener un tamaño de archivo más pequeño ayuda con la retención y el alcance. Publicar una versión web, especialmente si está optimizada y se carga rápidamente, puede atraer a más usuarios. Incluso si el juego no se carga más rápido, hacer que parezca que se está cargando puede reducir el tiempo de carga percibido. La percepción es más importante que la verdad. Se pueden realizar pruebas de conexiones a Internet más lentas utilizando herramientas del navegador que limitan la velocidad de la red.

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

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

Sí, seguro. Sé que en nuestras métricas, no puedo compartir las exactas. Definitivamente hemos visto que muchas más personas se unirán no solo cuando es una web versus móvil, sino también cuando es una web pequeña versus una web grande o, ya sabes, una web que te permite al menos comenzar a jugar versus una web que requiere registro antes de poder siquiera comenzar. Tiene mucho sentido. Sí. Oh no, sigue adelante. Lo siento. Iba a decir que creo que algunos de los consejos que mencionaste en la charla no tienen necesariamente un intercambio. Como uno de ellos era que quieres que se cargue más rápido, pero incluso si no lo hace, puedes hacer que parezca que se está cargando, como si algo estuviera sucediendo. Entonces, ni siquiera necesitas descartar los activos de arte, sino simplemente comunicar eso al jugador, ya sabes, ayuda, ya sabes, retrasar visualmente, reducir el tiempo de carga percibido, lo cual creo que es bastante valioso.

Exactamente. Como, creo que una cosa que me dijo un profesor, pero creo que es realmente valioso, es la verdad versus la percepción. Es como que la percepción es en realidad más importante porque, como la verdad, nadie sabe realmente qué está sucediendo, pero si el usuario siente que la verdad, lo que el usuario percibe es su verdad. Entonces, eso es realmente en lo que quieres optimizar. Me encanta eso. Creo que es una gran lección. Una lección muy concisa y genial. Teníamos otra pregunta sobre cómo probar conexiones a Internet más lentas durante el desarrollo.

Claro. Esta es una gran pregunta. Tenemos varias opciones. Creo que para las pruebas rápidas, lo importante son los bucles de retroalimentación, ¿verdad? Quieres mantener el bucle de retroalimentación en general, ya sea que estés haciendo arte o quieres reducirlo lo más rápido posible. Entonces, para las pruebas rápidas, como las herramientas del navegador Chrome o Firefox, donde puedes limitar la velocidad de la red, creo que eso hace un buen trabajo aproximado.

Testing Tools and Accurate Simulation

Short description:

Existen herramientas disponibles que pueden simular diferentes ubicaciones, redes, navegadores y dispositivos para ayudarte a probar con precisión tu juego. Estas herramientas brindan una experiencia física y precisa que complementa las herramientas de desarrollo de Chrome.

Pero para, ya sabes, eso te ayuda a posicionarte correctamente cuando realmente quieres hacer ese corte preciso, hay muchas herramientas en estos días. No quiero promocionar ninguna en particular, pero hay algunas que realmente te permiten simular tu conexión a través de un servidor para que puedas ver cómo se siente si vives en diferentes ubicaciones o usas diferentes redes, navegadores o dispositivos, lo cual creo que es genial. ¡Eso es increíble! No se me había ocurrido, porque siempre he utilizado las herramientas de desarrollo de Chrome. Pero me gusta eso, tener estas herramientas adicionales y creo que eso te lleva casi hasta el final. Y cuando realmente necesitas decidir cuál usar, creo que obtener una experiencia más física y precisa es más exacto. Eso tiene mucho sentido. Tenemos otra pregunta sobre métricas. Dice: ¿Qué métricas consideras cuando se trata del performance y la retención de los jugadores? Claro. Sí. Esta es una gran pregunta. En cuanto al performance, hay muchos tipos diferentes de performance, ¿verdad? Algunas de las cosas que medimos, por ejemplo, son el tamaño del juego y el tiempo de descarga inicial antes de poder comenzar a jugar, y cuánto tiempo tardan en aparecer las primeras pantallas, ya sabes, solo una pantalla de carga o algo así. Estas dos métricas son importantes para saber qué tan grande es el juego y qué tan rápido puedes comenzar a jugar. También medimos los fotogramas por segundo promedio, tanto el promedio general como el 5% más bajo. Es decir, si ocasionalmente se pierde un fotograma, está bien, pero no debería perder muchos fotogramas. Eso se relaciona con el performance en tiempo de ejecución y cómo afecta la participación del usuario. Algunas de las métricas que observamos son el tiempo de juego promedio y la tasa de retención en los juegos. Y, oh, vaya, hoy mismo tengo que volver a revisar las métricas para algunas cosas. Pero sí, el promedio de eso. Y creo que hay una métrica que se refiere al porcentaje de usuarios que juegan más tiempo que X. Eso tiene mucho sentido. Creo que es la última pregunta que tenemos. ¿Qué opinas sobre las nuevas tecnologías web como WebAssembly o WebGPU? Claro, sí, creo que sé que hubo algunas charlas hoy que hablaban sobre WebTransport y WebGPU. Solo quiero reiterar eso. Creo que todas esas son realmente emocionantes porque creo que realmente pueden permitir algunos de los avances que hemos visto últimamente en el escritorio, como mover cosas a los sombreadores de cálculo y cosas así. En cuanto a WebAssembly, que ya está disponible y se está volviendo bastante popular, también creo que es muy emocionante porque habla de accesibilidad y facilidad de uso. Pero desde el punto de vista del desarrollador, creo que hay muchos excelentes frameworks de navegador como Pixie, Phaser y FreeJS, entre otros. Pero creo que la idea de que WebAssembly también pueda extenderse a cosas más tradicionales como Unity o, bueno, solía ser Unreal. En fin, en resumen, creo que eso es realmente emocionante porque abre más formas de construir. Genial. Estupendo. Muchas gracias, Alex. Fue genial tenerte aquí. Personalmente, aprendí mucho y definitivamente voy a revisar el enlace que mencionaste sobre los juegos próximos. Así que muchas gracias por estar aquí. Sí, muchas gracias también por invitarme. Es genial estar aquí.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Building Fun Experiments with WebXR & Babylon.js
Top Content
During this session, we’ll see a couple of demos of what you can do using WebXR, with Babylon.js. From VR audio experiments, to casual gaming in VR on an arcade machine up to more serious usage to create new ways of collaboration using either AR or VR, you should have a pretty good understanding of what you can do today.
Check the article as well to see the full content including code samples: article. 
React Summit 2023React Summit 2023
32 min
How Not to Build a Video Game
In this talk we'll delve into the art of creating something meaningful and fulfilling. Through the lens of my own journey of rediscovering my passion for coding and building a video game from the ground up with JavaScript and React, we will explore the trade-offs between easy solutions and fast performance. You will gain valuable insights into rapid prototyping, test infrastructure, and a range of CSS tricks that can be applied to both game development and your day-to-day work.

Workshops on related topic

JSNation 2023JSNation 2023
116 min
Make a Game With PlayCanvas in 2 Hours
Featured WorkshopFree
In this workshop, we’ll build a game using the PlayCanvas WebGL engine from start to finish. From development to publishing, we’ll cover the most crucial features such as scripting, UI creation and much more.
Table of the content:- Introduction- Intro to PlayCanvas- What we will be building- Adding a character model and animation- Making the character move with scripts- 'Fake' running- Adding obstacles- Detecting collisions- Adding a score counter- Game over and restarting- Wrap up!- Questions
Workshop levelFamiliarity with game engines and game development aspects is recommended, but not required.
JS GameDev Summit 2022JS GameDev Summit 2022
121 min
PlayCanvas End-to-End : the quick version
Top Content
WorkshopFree
In this workshop, we’ll build a complete game using the PlayCanvas engine while learning the best practices for project management. From development to publishing, we’ll cover the most crucial features such as asset management, scripting, audio, debugging, and much more.
JS GameDev Summit 2022JS GameDev Summit 2022
86 min
Introduction to WebXR with Babylon.js
Workshop
In this workshop, we'll introduce you to the core concepts of building Mixed Reality experiences with WebXR and Balon.js.
You'll learn the following:- How to add 3D mesh objects and buttons to a scene- How to use procedural textures- How to add actions to objects- How to take advantage of the default Cross Reality (XR) experience- How to add physics to a scene
For the first project in this workshop, you'll create an interactive Mixed Reality experience that'll display basketball player stats to fans and coaches. For the second project in this workshop, you'll create a voice activated WebXR app using Balon.js and Azure Speech-to-Text. You'll then deploy the web app using Static Website Hosting provided Azure Blob Storage.