HTML5 Game Optimization Guide

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

El motor de juegos de código abierto PlayCanvas está construido específicamente para el navegador, incorporando 10 años de aprendizaje sobre optimización. En esta charla, descubrirás la salsa secreta que permite a PlayCanvas generar juegos con tiempos de carga increíblemente rápidos y tasas de fotogramas sólidas como una roca.

This talk has been presented at JS GameDev Summit 2022, check out the latest edition of this JavaScript Conference.

FAQ

PlayCanvas es un motor de juegos de código abierto escrito en JavaScript y basado en WebGL. Ofrece un editor visual basado en navegador que permite la colaboración en tiempo real y está construido en la nube.

PlayCanvas es utilizado por desarrolladores de juegos en todo el mundo para crear diversos tipos de juegos, desde juegos casuales hasta juegos .io y FPS. Además, alimenta Snap Games, la plataforma de juegos de Snapchat, con más de 200 millones de jugadores.

La optimización sigue siendo crucial debido a que mejora los tiempos de carga y la tasa de fotogramas, lo que afecta directamente la experiencia del usuario. Los tiempos de carga lentos pueden hacer que los usuarios abandonen un juego, mientras que una tasa de fotogramas optimizada asegura un juego fluido y agradable.

Chrome DevTools incluye pestañas como la de Red, que muestra los recursos que está cargando un juego, y la de Performance, que muestra cómo se están cargando estos recursos, facilitando la identificación de áreas para la optimización.

La compresión de texturas reduce el tamaño de los archivos de texturas, lo que disminuye el tiempo de carga y el uso de memoria en los dispositivos. Formatos como Basis y herramientas en PlayCanvas permiten la compresión eficiente de texturas para mejorar el rendimiento del juego.

GLTF es un formato abierto diseñado para ser el 'JPEG del 3D', que almacena datos en un formato listo para GPU, lo que permite una carga y renderización más rápidas. Es ampliamente utilizado en PlayCanvas para optimizar el rendimiento de los juegos 3D.

Elegir la resolución correcta es crucial porque renderizar a la resolución completa puede ser innecesariamente demandante para el hardware, especialmente en dispositivos más antiguos o menos potentes. Ofrecer opciones de resolución ajustables o detectar la GPU puede ayudar a optimizar el rendimiento.

Will Eastcott
Will Eastcott
33 min
08 Apr, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
PlayCanvas es un motor de juegos de código abierto utilizado por desarrolladores de juegos en todo el mundo. La optimización es crucial para los juegos HTML5, centrándose en los tiempos de carga y la tasa de fotogramas. La optimización de texturas y mallas puede reducir significativamente los tamaños de descarga. Los formatos GLTF y GLB ofrecen tamaños de archivo más pequeños y tiempos de análisis más rápidos. Comprimir los recursos del juego y utilizar formatos de archivo eficientes puede mejorar los tiempos de carga. La optimización de la tasa de fotogramas y el escalado de resolución son importantes para un mejor rendimiento. La gestión de las llamadas de dibujo y el uso de técnicas de agrupación pueden optimizar el rendimiento. Las herramientas de desarrollo del navegador, como Chrome y Firefox, son útiles para la depuración y el perfilado. Detectar el rendimiento del dispositivo y optimizar en función de dispositivos específicos puede mejorar el rendimiento del juego. Apple está avanzando con la implementación de WebGPU. Los juegos HTML5 pueden ser enviados a la App Store utilizando Cordova.

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

Short description:

Hola, mi nombre es Will Eastcott. Soy el creador de PlayCanvas. Hoy, hablaré sobre la optimización de juegos HTML5 basada en 10 años de experiencia con el motor de juegos PlayCanvas. PlayCanvas es un motor de juegos de código abierto escrito en JavaScript y basado en WebGL. Incluye un editor visual basado en el navegador para el desarrollo de juegos colaborativo en tiempo real. Alimenta Snap Games en Snapchat y es utilizado por desarrolladores de juegos en todo el mundo para varios tipos de juegos. Mi viaje en la optimización de juegos comenzó con Renderware, un motor de juegos utilizado en la generación de PlayStation 2. Los desarrolladores de juegos HTML5 ahora tienen hardware potente y herramientas incorporadas, pero la optimización sigue siendo crucial, centrándose en los tiempos de carga y la optimización de la tasa de fotogramas.

♪ Hola, mi nombre es Will Eastcott. Soy el creador de PlayCanvas. Y voy a hablarles hoy sobre la optimización de juegos HTML5 basada en 10 años de aprendizaje trabajando en el motor de juegos PlayCanvas.

Así que para empezar, quiero comenzar explicando un poco sobre qué es PlayCanvas. Es un motor de juegos de código abierto. Está escrito en JavaScript. Está basado en WebGL. Y también obtienes este editor visual que es como basado en el navegador. Es colaborativo en tiempo real. Está construido en la nube. Así que sí, puedes construir visualmente tus juegos en este editor.

Así que PlayCanvas en realidad alimenta Snap Games, que es la plataforma de juegos en Snapchat. Ha tenido más de 200 millones de jugadores. Hay un gran número de juegos que puedes revisar de casi cualquier género, así que te animo a que los revises. Pero PlayCanvas no solo es utilizado por los desarrolladores de juegos basados en Snapchat. Es utilizado por desarrolladores de juegos en todo el mundo para hacer todo tipo de juegos diferentes, desde juegos casuales hasta juegos .io. Es bastante popular entre los desarrolladores de juegos FPS, y puedes ver varios de esos representados allí.

Ahora, mi viaje personal trabajando en la optimización de juegos comenzó a principios de los años 2000 trabajando para una empresa llamada Criterion Software en un motor de juegos llamado Renderware. Ahora, Renderware se utilizó para alimentar alrededor de un tercio de los juegos en la generación de PlayStation 2, y día a día estaría trabajando en este tipo de hardware. Así que estamos hablando de un kit de desarrollo de PlayStation 2 T-10,000. Y sí, si querías hacer un análisis de rendimiento en ese tipo de hardware, te costaría. Y a menudo necesitarías ir a la sede de Sony y trabajar en hardware especial que fue desarrollado por entonces, hardware muy caro. Era increíblemente inconveniente.

Avanzamos rápidamente hasta 2022, y los desarrolladores de juegos HTML5 están viviendo el sueño, ¿verdad? Quiero decir, tenemos hardware increíblemente potente en la palma de nuestras manos. Y tenemos grandes herramientas que están integradas directamente en nuestros navegadores web. Entonces, ¿sigue siendo importante la optimización? Bueno, alerta de spoiler, sí lo es. Ahora, la optimización del rendimiento, en mi opinión, se divide en dos áreas principales. Los tiempos de carga, y también la optimización de la tasa de fotogramas. Y comencemos a hablar de los tiempos de carga. Ahora, esto es algo que no queremos que nuestros usuarios finales vean, barras de carga.

2. Investigando los tiempos de carga y la optimización de texturas

Short description:

¿Por qué importa si presentamos a nuestros usuarios barras de carga? Después de 6 segundos de espera, tendemos a perder el 40% de nuestra audiencia. Para investigar los tiempos de carga, podemos usar herramientas avanzadas incorporadas en el navegador, como Chrome DevTools. Al ordenar los recursos según su tamaño, podemos identificar oportunidades de optimización. En los juegos HTML5, la mayoría de los datos son de textura, y las imágenes grandes pueden causar fallos y largos tiempos de carga. Sin embargo, la compresión de texturas de hardware puede ayudar reduciendo el uso de memoria de la GPU y eliminando los costos de decodificación.

Entonces, ¿por qué importa si presentamos a nuestros usuarios con barras de carga? Bueno, resulta que después de 6 segundos de espera, tendemos a perder algo así como el 40% de nuestra audiencia que simplemente se va, no está dispuesta a esperar a que se cargue la página.

Entonces, cuando comenzamos una investigación sobre el tiempo de carga, ¿qué tipo de herramientas tenemos disponibles que pueden ayudarnos a investigar la optimización de los tiempos de carga? Bueno, como dije, incorporado directamente en el navegador, tienes algunas herramientas bastante avanzadas. En Chrome DevTools, tienes un par de pestañas. Tienes la pestaña de Red, que te muestra qué recursos está cargando Mi Juego, y luego tienes la pestaña de Performance que muestra cómo Mi Juego está cargando esos recursos. Entonces, cuando comienzas tu investigación, normalmente buscas las frutas más bajas. Si miras en la parte inferior izquierda de la pestaña del navegador, verás el número de solicitudes realizadas por el navegador. Verás la cantidad de data que se transfiere, y verás el tiempo que tarda en cargar tu juego. Ahora, lo primero que querrás hacer es ordenar la lista de recursos según su tamaño, porque, obviamente, cuanto más grande sea el recurso, mayores serán las oportunidades de optimización. Puedes buscar duplicados o recursos redundantes que tu juego realmente no debería estar cargando en primer lugar. Y si miramos el archivo más grande que se está cargando aquí en nuestro juego, es un jpeg de 2.2 megabytes. Entonces podemos preguntarnos, oye, ¿podemos reducir el tamaño de estos recursos? ¿Podemos optimizarlos de alguna manera?

Ahora, resulta que en los juegos HTML5, normalmente la mayoría de los data tienden a ser data basada en texturas. Y en nuestro ejemplo en la diapositiva anterior, teníamos un jpeg de 2.2 megabytes. Ahora, si el navegador descarga este archivo, necesitamos descomprimirlo en memoria. Y eso son 48 megabytes de data. Luego tenemos que pasarlo a WebGL para ser utilizado como textura. Y se hace una copia de él, además, tenemos que generar mitmaps, que son otros 64 megabytes de data. Así que juntos, eso son como 112 megabytes de data solo para un único jpeg. Ahora, si intentas cargar unos 10 de estos en una pestaña del navegador en móvil, te garantizo que harás que la pestaña se bloquee. Así que necesitamos algún tipo de solución para esto. Además, cada vez que recargamos un jpeg, tenemos que pagar, como, un costo de decodificación. Lleva tiempo descomprimir realmente los data del jpeg a un formato sin comprimir. Y en este caso, esta textura de 2 megabytes tarda 160 milisegundos, lo cual es simplemente excesivo. Porque va a hacer que el marco principal se bloquee, y va a causar largos tiempos de carga. Afortunadamente, tenemos compresión de texturas de hardware que podemos usar para cargar data de textura más optimizada. Entonces, si tomamos nuestro jpeg original de 2.2 megabytes y lo reducimos a algunos formatos de textura de hardware nativamente soportados como DXT, PVR y ETC, encontramos que los tamaños son en realidad más grandes que el jpeg original. Entonces, como el formato de esta compresión de textura de hardware data es nativo para la GPU, podemos simplemente suministrarlo a la GPU sin costo de decodificación, lo cual es genial. Además, la cantidad de memoria de la GPU utilizada por los formatos de data comprimidos de textura de hardware está entre 1 5th y 1 10th del jpeg original. Así que al menos estamos seguros de que no vamos a hacer que la pestaña del navegador se bloquee. Pero estamos pagando los costos por tener que descargar imágenes grandes. Y eso es un problema.

3. Optimización de Textura y Malla

Short description:

Afortunadamente, existe otro formato de textura llamado basis, que comprime el jpeg original a un tamaño más pequeño mientras mantiene los beneficios de los formatos nativos. Comprimir texturas a basis en el Editor de Play Canvas es un proceso sencillo. Los datos de malla son otro contribuyente significativo al tamaño de descarga, especialmente en juegos 3D. JSON es un formato comúnmente utilizado para cargar datos de malla, pero puede resultar en tamaños de archivo grandes y tiempos de análisis lentos. GLTF, un estándar abierto propiedad del Grupo Kronos, ofrece una solución a este problema y tiene un ecosistema próspero.

Entonces, ¿qué podemos hacer? Bueno, afortunadamente, hay otro formato de textura llamado basis, que es esencialmente un formato de compresión abstracto que se supone que se transcodifica a cualquiera de los formatos soportados nativamente en tiempo de ejecución, en el momento de carga de tu juego. Así que si tomamos ese jpeg original y lo convertimos a una textura basis, pasa de 2.2 meg a 1.7, lo cual es genial. Pero también, obtenemos todos los beneficios de estos formatos nativos, así que de nuevo, entre 1 5th y 1 10th de la memoria GPU original que ocupaba el jpeg.

Entonces, ¿cómo se ve la compresión de texturas a basis en el Editor de Play Canvas? Bueno, es una operación muy sencilla. Simplemente seleccionas las texturas que estás buscando comprimir. Puedes ver que tenemos cuatro texturas 2K aquí, que son como 5 megabytes de PNG data. Simplemente dices, hey, quiero que estas sean comprimidas a basis. Importas el transcodificador. Y pulsas el botón de comprimir. Y ahí lo tienes. Es muy sencillo.

Entonces, después de los datos de textura, el siguiente contribuyente más grande al tamaño de descarga en un juego HTML5 suele ser los datos de malla, al menos para los juegos 3D. Así que hablemos un poco sobre la optimización de malla. Aquí tenemos algo llamado el Dragón de Stanford. Es una malla que se utiliza a menudo en experimentos de renderizado. Y vamos a usarla en algunas pruebas aquí. Ahora puedes ver que es una malla muy densa. Tiene cientos de miles de vértices y triángulos. Probablemente no sea un activo de juego típico, pero debería hacer algunos, subrayar algunos puntos de construcción.

Entonces, si fueras a empezar a pensar en un formato para cargar estos datos, bueno, creo que es razonable empezar a pensar en JSON porque JSON funciona genial con el navegador. Es muy fácil de trabajar en JavaScript. Puedes simplemente pasar los datos a un objeto JavaScript. Así que increíblemente conveniente. Resulta que esta Malla de Dragón se serializará a 43 megabytes de JSON. Eso es bastante grande, pero lo reducirá de manera relativamente agresiva a 12.8 meg. El gran problema que tenemos aquí sin embargo es que analizar tanto JSON lleva 1.25 segundos. Y también porque estamos teniendo que mover un archivo JSON bastante grande hay un uso de memoria pico bastante alto de la aplicación.

Entonces, ¿qué podemos hacer? Bueno, el Grupo Kronos posee un estándar abierto llamado GLTF, que está diseñado esencialmente para ser el JPEG del 3D. Un gran ecosistema ha crecido alrededor de GLTF. Hay empresas que proporcionan herramientas como Play Canvas.

4. Optimización de GLTF y GLB

Short description:

Ahora usamos GLTF como el formato principal para el motor. GLB, el formato binario de GLTF, es significativamente más pequeño que JSON y tiene un tiempo de análisis de solo 50 milisegundos. El formato glTF almacena los datos en un formato listo para la GPU, permitiendo un análisis directo a WebGL sin procesamiento. Comprimir el archivo glb utilizando la tecnología Draco de Google reduce su tamaño a 1.84 megabytes, con un tiempo de descompresión de 0.4 segundos. La descompresión de offloading a un hilo WebWorker puede optimizar aún más el rendimiento.

Y ahora usamos GLTF como los formatos principales para el motor. Así que vamos a examinar cómo se comporta GLTF, con estos data en particular. Así que GLB es el formato binario de GLTF. Así que si decimos que un archivo GLB que contiene esta malla encontramos que es menos de la mitad del tamaño del archivo JSON original. Y cuando lo usamos, es solo marginalmente más pequeño que los data JSON. Eso es porque JSON es texto y se comprime muy bien. Lo importante a notar es que el tiempo de análisis para la malla, el archivo GLB, es solo de 50 milisegundos, una fracción minúscula del tiempo que lleva analizar el JSON, lo cual es bastante increíble pero la razón de esto es que el formato glTF almacena data en un formato listo para la GPU. Así que una vez que se copia del archivo, puedes analizarlo directamente a WebGL sin procesamiento. Así que esto es una gran victoria para los motores de juegos y los juegos HTML5 para asegurarse de que están usando glTF. Además, el uso máximo de memoria es menor porque, como digo, no estamos manejando grandes conjuntos de datos JSON. Pero podemos hacerlo aún mejor que esto. Podemos comprimir el archivo glb utilizando una tecnología de Google llamada Draco. Esta es una extensión de la especificación glTF y te permite comprimir los data del vértice. Así que aquí podemos ver que el glb de 21meg se puede comprimir hasta 1.84 megabytes. E incluso puedes reducirlo un poco más hasta 1.79 meg. El único pequeño problema del que debes estar consciente es que estos data necesitan ser descomprimidos en el momento de la carga. Así que ejecutar el descompresor Draco para esta malla toma 0.4 segundos. Pero como hicimos con las texturas basis, podemos descargar eso a un hilo WebWorker y entonces no almacenamos el hilo principal y esencialmente ocultamos ese proceso.

5. Compresión de Recursos del Juego

Short description:

Es importante comprimir los recursos del juego para mejorar los tiempos de carga. Verifique que su servidor sirva recursos comprimidos comprobando el encabezado de codificación de contenido. La técnica de compresión variará dependiendo de su proveedor de servicios de back end. Por ejemplo, con Google Cloud, puedes usar util para especificar qué tipos de archivos deben ser gzipped.

Entonces, he mencionado algunas veces que es importante usar gzip o compresión como parte de su proceso para publicar sus juegos. Es muy crítico que su infraestructura, su servidor sirva sus recursos de juego comprimidos. Así que para verificar eso deberías poder seleccionar cualquier recurso y mirar el encabezado de codificación de contenido. Y comprobar que está configurado para gzip o brotli. Ahora, cómo comprimes tus data para ponerlo en tu infraestructura dependerá de tu proveedor de servicios de back end. La técnica será diferente por proveedor, pero aquí hay un ejemplo de cómo lo harías con Google Cloud. Usarías simplemente util y especificarías qué tipos de archivos quieres que sean gzipped.

6. Optimización de los Tiempos de Carga y Diseño de Juegos

Short description:

Apliquemos estas técnicas al juego Swoop. Al convertir los JPEGs a basis y usar GLB en lugar de JSON, podemos reducir el tiempo de carga en un segundo. Descargar y cargar áreas de forma asíncrona puede crear un entorno sin interrupciones sin barras de carga. Bitmoji Party utiliza esta técnica para cargar activos mientras el usuario selecciona una opción de juego.

Así que apliquemos algunas de estas técnicas al juego HTML5 Swoop. Podemos ver que el juego original utilizaba JPEGs y JSON para el modelo data y el tiempo de carga original era de 4.5 segundos en total. Así que solo con convertir, comprimiendo todos estos JPEGs a basis y reimportando todo el arte como GLB en lugar de JSON, podemos reducir un segundo entero del tiempo de carga. Y eso representa un porcentaje de tu audiencia que has logrado retener reduciendo ese tiempo de carga.

Hay otras técnicas para mejorar tus tiempos de carga, una de las cuales es realmente pensar en tu diseño de juego. Así que uno de mis juegos favoritos de todos los tiempos es Metroid Prime y tenían una técnica interesante donde podías moverte de una gran área abierta a otra gran área abierta a través de un túnel. Y cuando te estás moviendo a través del túnel, descargan el área anterior y comienzan a cargar de forma asíncrona la siguiente área. Cuando llegas al final del túnel, disparas a la puerta. Y tan pronto como la siguiente área ha terminado de cargar, la puerta se abrirá. Y significa que en todo el juego, no ves barras de carga y todo el entorno parece completamente sin interrupciones. Esta técnica se utiliza en muchos juegos de PlayCanvas. Así que aquí tenemos Bitmoji Party, que carga un conjunto muy mínimo de activos para mostrar ese menú inicial. Tal vez toma dos segundos para que ese primer menú inicial se cargue y se muestre y sea interactivo. Y mientras el usuario está pasando esos dos o tres segundos simplemente decidiendo qué quiere seleccionar en términos de una opción de juego inicial, podemos estar transmitiendo el primer conjunto de activos en ese mini-juego a la derecha. Y significa que en ese juego en particular, no ves barras de carga.

7. Optimización de Framerate y Resolución

Short description:

Hablemos de la optimización de framerate y por qué es importante escalar tu juego desde dispositivos de alta gama hasta dispositivos económicos. Investiga el framerate utilizando la pestaña de rendimiento y el perfilador jerárquico. Enfócate en los puntos calientes en la función de renderizado para obtener ganancias de rendimiento. Utiliza herramientas como Spectre.js para capturar y analizar fotogramas de renderizado. Elige la resolución correcta en función de las capacidades del dispositivo y limita la complejidad gráfica para un mejor rendimiento.

Pasemos a hablar de la optimización del framerate. ¿Por qué nos importa el framerate en estos días? Seguramente los smartphones son bastante potentes hoy en día, ¿verdad? Bueno, es interesante si vas y miras algunos de los números de benchmarking para los teléfonos que están en el mercado hoy en día. Así que tomé el iPhone 13 y el Samsung Galaxy A21s, y el iPhone 13, en términos de benchmarks de CPU, supera al A21s en un orden de magnitud. Esta es una gran diferencia. Por lo tanto, es importante que tu juego pueda escalar desde el extremo superior, hasta algunos de estos dispositivos más económicos, así como considerar algunos de los dispositivos heredados que ni siquiera están en el mercado todavía.

¿Qué herramientas tenemos en nuestro arsenal para poder investigar el framerate? Bueno, durante la investigación del tiempo de carga, miramos la pestaña de rendimiento. La pestaña de rendimiento es muy poderosa. También puedes usarla para ejecutar un perfilador jerárquico para tu código. Así que puedes capturar un rastro, digamos durante 10 segundos, y luego puedes profundizar en la pila central de tu juego, e identificar los puntos calientes que ocupan el mayor porcentaje de CPU, y luego enfocar tus esfuerzos allí. Y también tenemos la vista de línea de tiempo en la pestaña de Rendimiento, que te permite acercarte a un fotograma individual, y tener una representación visual de dónde se gasta el tiempo en ese fotograma individual. Así que aquí puedo ver que mi bucle de juego consta de una actualización y un renderizado. Ahora, en este caso, la función de renderizado tarda casi tres veces más en ejecutarse que la función de actualización. Así que claramente voy a querer enfocar mis esfuerzos allí porque la mayoría de las ganancias de rendimiento se pueden encontrar allí. Así que para investigar el rendimiento del renderizado, hay muchas herramientas disponibles que se encuentran en las extensiones del navegador. Una realmente buena que recomiendo es Spectre.js. Te permite capturar un solo fotograma de renderizado, y muestra cómo se está manejando WebGL. Así que puedes ver las llamadas de dibujo individuales que se están enviando, e incluso puedes profundizar y ver el código del shader que se está ejecutando.

Quizás el mayor error que veo que cometen los desarrolladores de juegos hoy en día es elegir la resolución incorrecta para su juego. Ahora, elegí un par de dispositivos aquí para hacer un punto. El iPhone 13 Pro Max en realidad tiene un 20% menos de píxeles físicos que el Samsung Galaxy S6, que es un dispositivo de hace siete años, mientras que el S6 en realidad tiene, obviamente, una GPU mucho más débil en términos de procesamiento de fragmentos. Así que no tendría sentido que simplemente, como, renderices tu juego libremente a la resolución completa del dispositivo en cualquier dispositivo. Lo que puedes hacer es darle al usuario una opción para renderizar a diferentes resoluciones, o mejor aún, puedes detectar la GPU. Puedes hacer eso en Android, y puedes tomar una decisión sobre la resolución de renderizado basada en la familia de GPU que has detectado. Algo más que deberías considerar es limitar la complejidad gráfica de tu juego. Así que, a la izquierda, hay un juego llamado Bitmoji Tennis, que es muy simplista. Utiliza un solo mapa emisivo para el entorno. No hay sombras dinámicas. Todo está horneado. Hay una sola luz direccional para las sombras, bueno, para iluminar a los personajes. Y luego, a la derecha, puedes ver que hay una demo mucho más compleja.

8. Optimizando las Llamadas de Dibujo y el Rendimiento

Short description:

La complejidad de los shaders afecta la tensión de la GPU y las tasas de fotogramas. Gestiona cuidadosamente las llamadas de dibujo para minimizar los costos de CPU y GPU. Técnicas como Atlasine Textures y el batching pueden optimizar las llamadas de dibujo y reducir la sobrecarga de procesamiento. Tres consejos clave: optimiza temprano, diseña para el rendimiento y prueba en tu dispositivo base.

Hablando gráficamente, es una demostración técnica que el equipo de PlayCanvas construyó, que utiliza sombreado físico, mapeo de sombras, iluminación basada en imágenes y otros efectos también. Y la complejidad de los shaders del juego a la izquierda es mucho más simple. Y por lo tanto, pone menos tensión en la GPU y puedes renderizar a altas tasas de fotogramas.

También recomiendo que seas muy cuidadoso con el número de llamadas de dibujo que hace tu juego. Ahora, una llamada de dibujo es esencialmente enviar un primitivo gráfico a la GPU con algún estado de renderizado. Cada llamada de dibujo tendrá un costo en términos de CPU y GPU. Y un juego HTML5 típico podría renderizar entre, digamos, 100 y 200 llamadas de dibujo si quieres apuntar a algunos de estos dispositivos de gama baja.

Entonces, una técnica para optimizar las llamadas de dibujo es Atlasine Textures. Así que para este entorno que ves renderizado allí, había varios materiales. Hay tablones de madera en el suelo, hay papel tapiz en las paredes, etc. Ahora, estas texturas están atlasadas en un conjunto de texturas, y esto significa que las llamadas de dibujo pueden combinarse. Otra técnica es el batching, donde tenemos un entorno que se renderiza usando siete modelos distintos, y algunos de estos modelos se renderizan varias veces. Puedes ver, por ejemplo, que algunos de los edificios están duplicados, los neumáticos de gato están duplicados. Y, cuando renderizamos esta escena normalmente, esta es la forma en que se construye la escena. Puedes ver que hay una llamada de dibujo individual por objeto. Pero, si usamos batching, podemos combinar modelos similares en llamadas de dibujo combinadas, si quieres. Y, esto significa que podemos renderizar toda la escena en solo seis llamadas de dibujo, en lugar de las 50 originales. Entonces, casi una reducción de un orden de magnitud, que se traduce prácticamente en un orden de magnitud menor procesamiento en la CPU y GPU en términos de, bueno, quiero decir, en la CPU y en la GPU, es una sobrecarga menor, porque hay menos llamadas de dibujo. Entonces, voy a dejarte con tres piezas clave de advice aquí. No dejes las consideraciones de optimization hasta el final de tu proceso de desarrollo. Además, design tu juego con performance en mente, desde el principio. Y por último, selecciona cuál es tu dispositivo base y prueba en ese dispositivo temprano y a lo largo de tu ciclo de desarrollo. Eso es todo por esta masterclass. Gracias por escuchar.

9. Uso del Navegador y DevTools

Short description:

Comencemos echando un vistazo a los resultados de la encuesta. Hay una abrumadora mayoría de usuarios de Chrome, lo cual no es sorprendente. Yo uso principalmente Chrome, pero también pruebo el motor en otros navegadores. Las DevTools de Firefox han avanzado en los últimos años y vale la pena echarles un vistazo. El perfilador de CPU es particularmente útil. Opera comparte las DevTools de Chrome, pero no estoy seguro si tienen su propio motor. Las DevTools de Safari son geniales para la depuración en iOS, permitiendo la depuración remota en un teléfono conectado. Sin embargo, hay limitaciones al conectar con aplicaciones firmadas y de producción. La experiencia de conexión con Chrome en Android también es fluida.

Entonces, comencemos echando un vistazo a los resultados de la encuesta aquí. Parece que hay una abrumadora mayoría de usuarios de Chrome aquí. Sí, supongo que esto es más o menos lo que esperaba. Quiero decir, no sé tú, Omar, pero yo uso principalmente Chrome. Pero tengo que probar todos los diferentes navegadores porque, obviamente, es importante que pruebe el motor en todos los lugares donde se va a ejecutar. Y sí, no es raro que pase un poco de tiempo en Safari y Firefox y así sucesivamente, pero... Sí, y especialmente, iba a decir la forma en que se formula la pregunta, ya sabes, ¿qué navegador usas para optimizar tus juegos? Porque también usaré principalmente Chrome DevTools, pero me sorprendió gratamente la última vez que probé Firefox que sus DevTools han avanzado al menos desde, ya sabes, hace cinco años cuando lo usé por última vez. Así que tal vez no es, quiero decir, no sé si es comparable, pero creo que vale la pena echarle un vistazo. Creo que el perfilador de CPU es realmente impresionante. Lo uso bastante. También noté que hay algunas personas que optaron por Opera aquí y quiero decir, presumiblemente Opera comparte Chrome DevTools con... Iba a preguntar eso, no sé si tienen su propio motor. Nunca he usado Opera. Quiero decir, lo he usado antes. Sí. Y Safari, porque no he hecho mucha depuración de iOS, ¿tiene Safari... Porque sé que puedes hacer la cosa donde conectas el teléfono y luego puedes hacer esta depuración remota. ¿Tiene Safari agradablemente... Bueno, DevTools? Bueno, sí, las DevTools son bastante geniales. Sí, quiero decir, como mencionaste, la principal razón por la que las vas a usar es porque estás conectando a un dispositivo iOS y luego puedes depurar ya sea un WebView o un navegador Safari. Y esa experiencia es bastante buena. Creo que el único problema que hemos tenido es porque PlayCanvas se usa para construir bastantes aplicaciones híbridas donde WebView está incrustado en la aplicación para que pueda ser enviada a una tienda de aplicaciones y no puedes conectar realmente a una aplicación que ha sido firmada y de producción. Lo cual es un poco frustrante, pero sí, generalmente funciona bastante bien. ¿Y Chrome es lo mismo con Android, verdad? Me refiero a la experiencia cuando te conectas, normalmente hago registro por USB, pero toda esa experiencia es bastante fluida estos días.

QnA

Detección del rendimiento del dispositivo y optimizaciones

Short description:

Dan pregunta sobre las herramientas para detectar el rendimiento del dispositivo. Play Canvas tiene un mini perfilador de estadísticas que muestra la utilización de la CPU y la GPU, así como las llamadas de dibujo. El perfilado de la GPU es difícil en los móviles, pero una extensión de WebGL llamada Disk Joined Timer puede proporcionar tiempos precisos. Mark pregunta sobre la optimización de los juegos en función de dispositivos específicos. La detección del dispositivo en el navegador puede ser limitada, pero el sniffing del agente de usuario y las propiedades de la ventana pueden proporcionar pistas. En Android, Chrome informa de la familia de la GPU, lo que permite optimizaciones específicas. Muchos desarrolladores de juegos utilizan declaraciones if para dirigirse a las GPUs más antiguas y limitar la complejidad de la representación.

Genial, eso tiene sentido. Ahora, tenemos un par de preguntas llegando desde la audiencia. Entonces, Dan dice, gran charla, ¿hay alguna herramienta para detectar el rendimiento del dispositivo? Así que hay muchas herramientas. No estoy muy seguro si Dan se refiere a algo como, el rendimiento teórico o si simplemente quiere obtener estadísticas de rendimiento de una aplicación en ejecución. Quiero decir, en Play Canvas, tenemos algo que llamamos el mini perfilador de estadísticas. Y es como un panel que automáticamente obtienes como parte de nuestra página de lanzamiento cuando ejecutas tu aplicación. Y te mostrará la utilización de la CPU, la utilización de la GPU, y el número de llamadas de dibujo y cosas así. Así que tienes como un pequeño centro en tiempo real allí abajo que te muestra las estadísticas de rendimiento del dispositivo en el que estás ejecutando. Y es realmente importante que, ya sabes, eso sea fácil de hacer, especialmente en móviles, ¿verdad? Porque la mayoría de nosotros estamos apuntando a los móviles estos días. Así que tener formas fáciles de averiguar qué rendimiento estás obteniendo en un dispositivo móvil es realmente, realmente importante. Y el único, como un pequeño problema que tienes en los móviles estos días es que si quieres hacer como un perfilado de la GPU, es bastante difícil en el navegador. Hay una extensión de WebGL llamada Disk Joined Timer, que te permite esencialmente hacer, ya sabes, tiempos precisos en la GPU. Así que eso es lo que utiliza nuestro mini perfilador de estadísticas. Pero desafortunadamente no está bien soportado en los móviles. No creo que esté soportado en iOS, por ejemplo. Eso tiene sentido. Creo que es en realidad una buena transición a la siguiente pregunta donde Mark pregunta, si alguna vez encuentras útil hacer un perfilado en tiempo real del hardware en el que se está ejecutando un juego y luego hacer, como, en base a eso modificaciones de, vale, para este dispositivo, tendremos LODs más altos o LODs más bajos o algo así. ¿Alguna vez haces estas micro-optimizaciones basadas en dispositivos específicos? Sí, esa es una muy buena pregunta. Quiero decir, había una diapositiva en mi charla donde mencioné la enorme disparidad en la potencia del hardware móvil de hoy que puedes comprar en una tienda. Y entonces, ya sabes, es una pena si tuvieras que escribir un juego que sólo estuviera dirigido al hardware de menor denominador común. Así que si vas a dar a tus usuarios, a tus jugadores una mejor experiencia, querrás encontrar una forma de permitir que tu juego escale dependiendo del rendimiento del dispositivo, ¿verdad? Eso puede ser complicado porque en el navegador estás limitado en poder detectar el dispositivo en el que estás ejecutando. Así que por ejemplo, en iOS, no sabes qué GPU se está utilizando. Puedes hacer cosas como el sniffing del agente de usuario para darte pistas sobre el dispositivo. Incluso puedes hacer cosas como hacer suposiciones basadas en cosas como el ancho y la altura de la ventana reportados o como, ya sabes, ¿cómo se llama? La relación de píxeles del dispositivo de la ventana, lo que sea. Como esas propiedades pueden darte una pista sobre la edad y la potencia del dispositivo. Y luego en Android, las cosas son un poco más fáciles porque Chrome informará de la familia real de la GPU en la que estás ejecutando. Así que en realidad conozco a muchos desarrolladores de juegos que escriben sus juegos donde tienen alguna declaración en su código que dice si Android, y luego tienen una declaración de cambio con ciertas GPUs para las que quieren hacer algo específico para, normalmente son familias de GPUs de hace siete, ocho, nueve años como la Armali 400 o la familia Adreno 300, ¿verdad? Porque en esos dispositivos más antiguos, probablemente querrás limitar la complejidad de lo que estás representando. Así que tal vez, no sé, vas a apagar las partículas o vas a, no sé, usar LEDs más bajos como dices, que lo normal. Así que sí, hay técnicas que puedes usar para detectar características del hardware y habilitar y deshabilitar ciertos aspectos del juego. Eso es genial.

Micro-optimización y progreso de Apple

Short description:

Es triste que tengamos que hacer micro-optimización para juegos web basados en diferencias de dispositivo. Apple ha avanzado con la implementación de WebGPU, apoyando WebGL 2 y WebXR. Están alcanzando rápidamente, y las cosas serán emocionantes con WebGPU. Los juegos HTML5 pueden ser enviados a la App Store usando Cordova, lo cual es fácil y rápido.

Quiero decir, es realmente triste que tengamos que hacer esto como micro-optimización basada en ello. Porque en mi mente, la razón por la que me gusta la web es que es esta publicación única y es lo mismo en todas partes. Pero también, supongo, es agradable que podamos, al menos cuando necesitas hacer estos cambios según sea necesario en función del dispositivo.

Tenemos una pregunta más, es un poco picante. ¿Crees que Apple está retrasando a propósito, esto es Daniel preguntando, ¿crees que Apple está retrasando a propósito porque Fioria en iOS no está en peligro de sus ganancias de la App Store? ¿O crees que hay otras razones por las que están tan atrasados en las aplicaciones web progresivas y las API modernas en general?

Sí, eso es interesante, quiero decir, probablemente hay algunas consideraciones sobre el negocio de la App Store. Creo que tenemos que darle crédito a Apple aquí porque realmente han avanzado con su implementación de WebGPU. Así que WebGL 2 ya está en producción en iOS y macOS. Y además de eso, también estamos viendo un compromiso de Apple para implementar WebXR en WebKit. Así que creo que estamos en un mundo ligeramente diferente al que estábamos hace dos o tres años cuando había bastante frustración de que todavía estábamos en WebGL 1. Pero sí, creo que, demosles crédito y digamos que están alcanzando muy rápidamente. Y creo que las cosas van a ser realmente emocionantes una vez que WebGPU aterrice. Creo que está disponible en un, ¿es como un ajuste si vas a la configuración del navegador en iOS? Así que sí, quiero decir, las cosas se ven bastante bien ahora. Lo otro que hay que decir es que, sabes, puedes hacer, puedes enviar juegos, juegos HTML5 a la App Store utilizando tecnologías como Cordova. Como tenemos una guía en la documentación para desarrolladores de Play Canvas que explica ese proceso, ¿verdad? Así que si simplemente buscas en Google como Play Canvas Cordova o algo así, te llevará a esa página y te sorprenderá lo fácil que es el proceso, ¿verdad? Como puedes hacerlo en cinco minutos, construir un ejecutable IPA, que luego puedes probar en tu dispositivo iOS y es sí, super fácil. Eso es impresionante. Tiene mucho sentido. Muchas gracias, Will. Fue genial tenerte aquí. Realmente lo apreciamos. Es súper genial escuchar todas tus ideas. Muchas gracias. Mi placer. Adiós.

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

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Acelerando tu aplicación React con menos JavaScript
React Summit 2023React Summit 2023
32 min
Acelerando tu aplicación React con menos JavaScript
Top Content
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Concurrencia en React, Explicada
React Summit 2023React Summit 2023
23 min
Concurrencia en React, Explicada
Top Content
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.
How React Compiler Performs on Real Code
React Advanced 2024React Advanced 2024
31 min
How React Compiler Performs on Real Code
Top Content
I'm Nadia, a developer experienced in performance, re-renders, and React. The React team released the React compiler, which eliminates the need for memoization. The compiler optimizes code by automatically memoizing components, props, and hook dependencies. It shows promise in managing changing references and improving performance. Real app testing and synthetic examples have been used to evaluate its effectiveness. The impact on initial load performance is minimal, but further investigation is needed for interactions performance. The React query library simplifies data fetching and caching. The compiler has limitations and may not catch every re-render, especially with external libraries. Enabling the compiler can improve performance but manual memorization is still necessary for optimal results. There are risks of overreliance and messy code, but the compiler can be used file by file or folder by folder with thorough testing. Practice makes incredible cats. Thank you, Nadia!
El Futuro de las Herramientas de Rendimiento
JSNation 2022JSNation 2022
21 min
El Futuro de las Herramientas de Rendimiento
Top Content
Today's Talk discusses the future of performance tooling, focusing on user-centric, actionable, and contextual approaches. The introduction highlights Adi Osmani's expertise in performance tools and his passion for DevTools features. The Talk explores the integration of user flows into DevTools and Lighthouse, enabling performance measurement and optimization. It also showcases the import/export feature for user flows and the collaboration potential with Lighthouse. The Talk further delves into the use of flows with other tools like web page test and Cypress, offering cross-browser testing capabilities. The actionable aspect emphasizes the importance of metrics like Interaction to Next Paint and Total Blocking Time, as well as the improvements in Lighthouse and performance debugging tools. Lastly, the Talk emphasizes the iterative nature of performance improvement and the user-centric, actionable, and contextual future of performance tooling.
Construyendo Experimentos Divertidos con WebXR & Babylon.js
JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Construyendo Experimentos Divertidos con WebXR & Babylon.js
Top Content
This Talk explores the use of Babylon.js and WebXR to create immersive VR and AR experiences on the web. It showcases various demos, including transforming a 2D game into a 3D and VR experience, VR music composition, AR demos, and exploring a virtual museum. The speaker emphasizes the potential of web development in the metaverse and mentions the use of WebXR in Microsoft products. The limitations of WebXR on Safari iOS are discussed, along with the simplicity and features of Babylon.js. Contact information is provided for further inquiries.

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Crea un Juego Con PlayCanvas en 2 Horas
JSNation 2023JSNation 2023
116 min
Crea un Juego Con PlayCanvas en 2 Horas
Top Content
Featured WorkshopFree
Steven Yau
Steven Yau
En esta masterclass, construiremos un juego utilizando el motor WebGL de PlayCanvas desde el principio hasta el final. Desde el desarrollo hasta la publicación, cubriremos las características más cruciales como la escritura de scripts, la creación de UI y mucho más.
Tabla de contenido:- Introducción- Introducción a PlayCanvas- Lo que vamos a construir- Agregando un modelo de personaje y animación- Haciendo que el personaje se mueva con scripts- 'Falsa' carrera- Agregando obstáculos- Detectando colisiones- Agregando un contador de puntuación- Fin del juego y reinicio- ¡Resumen!- Preguntas
Nivel de la masterclassSe recomienda familiaridad con los motores de juegos y los aspectos del desarrollo de juegos, pero no es obligatorio.
Next.js 13: Estrategias de Obtención de Datos
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Estrategias de Obtención de Datos
Top Content
Workshop
Alice De Mauro
Alice De Mauro
- Introducción- Prerrequisitos para la masterclass- Estrategias de obtención: fundamentos- Estrategias de obtención – práctica: API de obtención, caché (estática VS dinámica), revalidar, suspense (obtención de datos en paralelo)- Prueba tu construcción y sírvela en Vercel- Futuro: Componentes de servidor VS Componentes de cliente- Huevo de pascua de la masterclass (no relacionado con el tema, destacando la accesibilidad)- Conclusión
PlayCanvas de principio a fin: la versión rápida
JS GameDev Summit 2022JS GameDev Summit 2022
121 min
PlayCanvas de principio a fin: la versión rápida
Top Content
Workshop
João Ruschel
João Ruschel
En esta masterclass, construiremos un juego completo utilizando el motor PlayCanvas mientras aprendemos las mejores prácticas para la gestión de proyectos. Desde el desarrollo hasta la publicación, cubriremos las características más cruciales como la gestión de activos, scripting, audio, depuración, y mucho más.
Depuración del Rendimiento de React
React Advanced 2023React Advanced 2023
148 min
Depuración del Rendimiento de React
Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Veía una interacción lenta, probaba una optimización aleatoria, veía que no ayudaba, y seguía probando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Hacía una grabación en Chrome DevTools o React Profiler, la examinaba, intentaba hacer clic en cosas al azar, y luego la cerraba frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos cómo analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, cubriremos el rendimiento de interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Construyendo aplicaciones web que iluminan Internet con QwikCity
JSNation 2023JSNation 2023
170 min
Construyendo aplicaciones web que iluminan Internet con QwikCity
WorkshopFree
Miško Hevery
Miško Hevery
Construir aplicaciones web instantáneas a gran escala ha sido elusivo. Los sitios del mundo real necesitan seguimiento, análisis y interfaces y interacciones de usuario complejas. Siempre comenzamos con las mejores intenciones pero terminamos con un sitio menos que ideal.
QwikCity es un nuevo meta-framework que te permite construir aplicaciones a gran escala con un rendimiento de inicio constante. Veremos cómo construir una aplicación QwikCity y qué la hace única. El masterclass te mostrará cómo configurar un proyecto QwikCity. Cómo funciona el enrutamiento con el diseño. La aplicación de demostración obtendrá datos y los presentará al usuario en un formulario editable. Y finalmente, cómo se puede utilizar la autenticación. Todas las partes básicas para cualquier aplicación a gran escala.
En el camino, también veremos qué hace que Qwik sea único y cómo la capacidad de reanudación permite un rendimiento de inicio constante sin importar la complejidad de la aplicación.