Optimización de juegos HTML5: 10 años de aprendizaje

Rate this content
Bookmark

El motor de juegos de código abierto PlayCanvas está diseñado específicamente para el navegador, incorporando 10 años de aprendizaje sobre optimización. En esta charla, descubrirás el ingrediente secreto que permite a PlayCanvas generar juegos con tiempos de carga ultrarrápidos y una tasa de fotogramas sólida.

33 min
08 Apr, 2022

Video Summary and Transcription

PlayCanvas es un motor de juegos de código abierto utilizado por desarrolladores de juegos de 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 el tamaño 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. Gestionar las llamadas de dibujo y utilizar técnicas de agrupación puede optimizar el rendimiento. Las herramientas de desarrollo del navegador, como Chrome y Firefox, son útiles para depurar y perfilar. 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 se pueden enviar a la App Store utilizando Cordova.

Available in English

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 navegador para el desarrollo colaborativo en tiempo real de juegos. Impulsa Snap Games en Snapchat y es utilizado por desarrolladores de juegos de todo el mundo para diversos 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 velocidad de fotogramas.

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

Para comenzar, quiero explicar 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 basado en navegador. Es colaborativo en tiempo real. Está construido en la nube. Sí, puedes construir visualmente tus juegos en este editor.

PlayCanvas en realidad impulsa Snap Games, que es la plataforma de juegos en Snapchat. Ha tenido más de 200 millones de jugadores. Hay una gran cantidad de juegos que puedes probar de casi cualquier género, así que te animo a que los pruebes. Pero PlayCanvas no solo es utilizado por desarrolladores de juegos basados en Snapchat. Es utilizado por desarrolladores de juegos de todo el mundo para crear todo tipo de juegos diferentes, desde juegos casuales hasta juegos .io. En realidad, es bastante popular entre los desarrolladores de juegos de disparos en primera persona, y puedes ver varios de ellos 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 utilizaba para impulsar aproximadamente un tercio de los juegos en la generación de PlayStation 2, y día a día trabajaba en este tipo de hardware. Estamos hablando de un kit de desarrollo de PlayStation 2 T-10,000. Y sí, si querías hacer análisis de rendimiento en ese tipo de hardware, te costaría. Y a menudo tenías que ir a la sede de Sony y trabajar en hardware especial que fue desarrollado por entonces, hardware muy caro. Era increíblemente incómodo.

Avancemos rápido 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 nuestra mano. Y tenemos excelentes herramientas integradas en nuestros navegadores web. Entonces, ¿la optimización sigue siendo importante? Bueno, spoiler alerta, sí lo es. Ahora, la optimización del rendimiento, en mi opinión, se divide en dos áreas principales. Hay tiempos de carga, y también hay optimización de la velocidad de fotogramas. Y comencemos hablando de los tiempos de carga. Ahora, esto es algo que no queremos que vean nuestros usuarios finales, barras de carga.

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

Short description:

Entonces, ¿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 utilizar herramientas avanzadas integradas 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 se basan en texturas, y las imágenes grandes pueden causar bloqueos y tiempos de carga prolongados. Sin embargo, la compresión de texturas de hardware puede ayudar al reducir el uso de memoria de la GPU y eliminar los costos de decodificación.

Entonces, ¿por qué importa si presentamos a nuestros usuarios barras de carga? Bueno, resulta que después de 6 segundos de espera, tendemos a perder aproximadamente el 40% de nuestra audiencia que simplemente se va, sin estar dispuestos 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, integradas directamente en el navegador, tienes algunas herramientas bastante avanzadas. En Chrome DevTools, tienes un par de pestañas. Tienes la pestaña de Networking, que muestra los recursos que está cargando Mi Juego, y luego tienes la pestaña de Performance que muestra cómo Mi Juego está cargando esos recursos. Así que cuando comienzas tu investigación, generalmente buscas los frutos más fáciles de alcanzar. 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 datos que se transfieren 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 nos preguntamos, ¿podemos reducir el tamaño de estos recursos? ¿Podemos optimizarlos de alguna manera?

Ahora bien, resulta que en los juegos HTML5, típicamente la mayoría de los datos tienden a basarse 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 la memoria. Y eso son 48 megabytes de datos. Luego tenemos que pasarlo a WebGL para que se use como una textura. Y se hace una copia de él, además, tenemos que generar mipmaps, que son otros 64 megabytes de datos. Entonces, en total, son como 112 megabytes de datos solo para un solo jpeg. Ahora, si intentas cargar alrededor de 10 de estos en una pestaña del navegador en un dispositivo móvil, te garantizo que harás que la pestaña se bloquee. Así que necesitamos alguna solución para esto. Además, cada vez que se vuelve a cargar el jpeg, tenemos que pagar un costo de decodificación. Se tarda tiempo en descomprimir los datos del jpeg a un formato sin comprimir. Y en este caso, esta textura de 2 megabytes tarda 160 milisegundos, lo cual es excesivo. Porque hará que el marco principal se bloquee y causará tiempos de carga prolongados. Afortunadamente, tenemos compresión de texturas de hardware que podemos usar para cargar datos de texturas más optimizados. Entonces, si tomamos nuestro jpeg original de 2.2 megabytes y lo reducimos a formatos de textura de hardware nativamente compatibles como DXT, PVR y ETC, encontramos que los tamaños son en realidad más grandes que el jpeg original. Pero debido a que el formato de estos datos de compresión de texturas de hardware es nativo de la GPU, podemos suministrárselos 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 datos de compresión de texturas de hardware es entre 1/5 y 1/10 del jpeg original. Así que al menos estamos seguros de que ya no haremos que la pestaña del navegador se bloquee. Pero aún estamos pagando los costos de tener que descargar imágenes grandes. Y eso es un problema.

3. Optimización de texturas y mallas

Short description:

Afortunadamente, existe otro formato de textura llamado basis, que comprime el jpeg original a un tamaño más pequeño manteniendo los beneficios de los formatos nativos. Comprimir texturas a basis en el Editor de Play Canvas es un proceso sencillo. Los datos de malla también contribuyen significativamente 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, existe otro formato de textura llamado basis, que es básicamente un formato de compresión abstracto que se supone que se transcodifica a cualquiera de los formatos nativamente compatibles en tiempo de ejecución, en el momento de carga de tu juego. Entonces, si tomamos ese jpeg original y lo convertimos en una textura basis, pasa de 2.2 megabytes a 1.7, lo cual es genial. Pero también obtenemos todos los beneficios de estos formatos nativos, por lo que nuevamente, entre 1/5 y 1/10 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 deseas comprimir. Puedes ver que aquí tenemos cuatro texturas de 2K, que son alrededor de 5 megabytes de datos PNG. Simplemente dices: `Oye, quiero que estas sean comprimidas a basis`. Importas el transcodificador y presionas el botón de compresión. Y eso es todo, es muy sencillo.

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

Entonces, si estuvieras pensando en un formato para cargar estos datos, creo que es razonable considerar JSON porque JSON funciona muy bien con el navegador. Es muy fácil de trabajar con él en JavaScript. Simplemente puedes pasar los datos a un objeto JavaScript. Increíblemente conveniente. Ahora resulta que esta malla de dragón se serializará a 43 megabytes de JSON. Eso es bastante grande, pero se reducirá relativamente agresivamente a 12.8 megabytes. El gran problema que tenemos aquí, sin embargo, es que analizar tanto JSON lleva 1.25 segundos. Y también, debido a que tenemos que manejar 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 es propietario de un estándar abierto llamado GLTF, que está diseñado para ser el JPEG del 3D. Se ha desarrollado un gran ecosistema en torno a GLTF. Hay empresas que ofrecen herramientas como Play Canvas.

4. Optimización de GLTF y GLB

Short description:

Ahora utilizamos 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, lo que permite el 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 en un hilo de WebWorker puede optimizar aún más el rendimiento.

Y ahora utilizamos GLTF como los formatos principales para el motor. Entonces examinemos qué es GLTF, cómo funciona con estos datos específicos. GLB es el formato binario de GLTF. Entonces, 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 datos JSON. Eso se debe a que JSON es texto y se comprime muy bien. Lo importante a tener en cuenta es que el tiempo de análisis para la malla, el archivo GLB, es de solo 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 los datos en un formato listo para la GPU. Entonces, una vez que se copia del archivo, puedes analizarlo directamente en WebGL sin procesamiento. Esto es una gran ventaja para los motores de juegos y los juegos HTML5 para asegurarse de que estén utilizando glTF. Además, el uso máximo de memoria es menor porque, como dije, no estamos manipulando grandes conjuntos de datos JSON. Pero podemos hacerlo aún mejor. 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 datos de vértices. Aquí podemos ver que el glb de 21 megabytes se puede comprimir a 1.84 megabytes. E incluso se puede reducir un poco más a 1.79 megabytes. El único problema pequeño del que debes ser consciente es que estos datos deben descomprimirse al cargar. Entonces, ejecutar el descompresor Draco para esta malla lleva 0.4 segundos. Pero al igual que hicimos con las texturas basis, podemos descargar eso a un hilo de WebWorker y luego no almacenar el proceso en el hilo principal y esencialmente ocultar ese proceso.

5. Compresión de Recursos del Juego

Short description:

Es importante comprimir los recursos del juego para mejorar los tiempos de carga. Verifica que tu servidor sirva recursos comprimidos mediante la comprobación de la cabecera de codificación de contenido. La técnica de compresión variará según el proveedor de servicios de tu backend. Por ejemplo, con Google Cloud, puedes utilizar util para especificar qué tipos de archivos deben ser comprimidos con gzip.

Entonces, he mencionado varias veces que es importante utilizar gzip o compresión como parte de tu proceso para publicar tus juegos. Es muy importante que tu infraestructura, tu servidor sirva tus recursos de juego comprimidos. Para verificar esto, debes poder seleccionar cualquier recurso y verificar la cabecera de codificación de contenido. Y asegurarte de que esté configurada en gzip o brotli. Ahora, cómo comprimes tus data para ponerlo en tu infraestructura dependerá del proveedor de servicios de tu backend. La técnica será diferente según el proveedor, pero aquí hay un ejemplo de cómo hacerlo con Google Cloud. Solo usarías util y especificarías qué tipos de archivos deseas que se compriman con gzip.

6. Optimización de Tiempos de Carga y Diseño del Juego

Short description:

Apliquemos estas técnicas al juego Swoop. Al convertir las imágenes JPEG 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 problemas y sin barras de carga. Bitmoji Party utiliza esta técnica para cargar activos mientras el usuario selecciona una opción de juego.

Entonces, apliquemos algunas de estas técnicas al juego HTML5 Swoop. Podemos ver que el juego original utilizaba imágenes JPEG y JSON para los datos del modelo y el tiempo de carga original fue de 4.5 segundos en total. Así que solo con convertir, comprimir todas estas imágenes JPEG a basis y volver a importar todas las ilustraciones como GLB en lugar de JSON, podemos reducir un segundo completo del tiempo de carga. Y eso representa un pequeño porcentaje de tu audiencia que has logrado retener al reducir ese tiempo de carga.

Existen otras técnicas para mejorar los tiempos de carga, una de las cuales es pensar en el diseño de tu juego. 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 a través de un túnel. Y cuando te mueves por el túnel, descargan el área anterior y comienzan a cargar de forma asíncrona el área siguiente. Cuando llegas al final del túnel, disparas a la puerta. Y tan pronto como el área siguiente haya terminado de cargar, la puerta se abrirá. Y esto significa que en todo el juego, no ves barras de carga y todo el entorno parece completamente fluido. Esta técnica se utiliza en muchos juegos de PlayCanvas. Aquí tenemos Bitmoji Party, que carga un conjunto muy mínimo de activos para mostrar ese menú inicial. Tal vez se tarda dos segundos en cargar y mostrarse ese primer menú inicial y ser interactivo. Mientras el usuario pasa esos dos o tres segundos 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 esto significa que en ese juego en particular, no ves barras de carga.

7. Optimización de Framerate y Resolución

Short description:

Hablemos sobre la optimización de framerate y por qué es importante ajustar tu juego desde dispositivos de gama alta hasta dispositivos de presupuesto. Investiga el framerate utilizando la pestaña de rendimiento y el perfilador jerárquico. Enfócate en los puntos críticos de la función de renderizado para obtener mejoras en el rendimiento. Utiliza herramientas como Spectre.js para capturar y analizar los cuadros de renderizado. Elige la resolución adecuada en función de las capacidades del dispositivo y limita la complejidad gráfica para obtener un mejor rendimiento.

Avancemos y hablemos sobre la optimización de framerate. ¿Por qué nos importa el framerate en estos días? Seguramente, los teléfonos inteligentes son bastante potentes en la actualidad, ¿verdad? Bueno, es interesante si observas algunos de los números de referencia para los teléfonos que están en el mercado hoy en día. Tomé el iPhone 13 y el Samsung Galaxy A21s, y en términos de referencia de la CPU, el iPhone 13 supera al A21s en un orden de magnitud. Esta es una gran diferencia. Por lo tanto, es importante que tu juego pueda ajustarse desde dispositivos de gama alta hasta algunos de estos dispositivos más económicos, considerando también algunos de los dispositivos antiguos que aún no están en el mercado.

¿Qué herramientas tenemos a nuestra disposición para investigar el framerate? Bueno, durante la investigación del tiempo de carga, analizamos la pestaña de rendimiento. La pestaña de rendimiento es muy poderosa. También puedes utilizarla para ejecutar un perfilador jerárquico para tu código. Así puedes capturar un rastreo durante unos 10 segundos y luego profundizar en la pila principal de tu juego para identificar los puntos críticos que consumen más porcentaje de CPU y enfocar tus esfuerzos allí. También tenemos la vista de línea de tiempo en la pestaña de rendimiento, que te permite acercarte a un cuadro individual y tener una representación visual de cómo se gasta el tiempo en ese cuadro individual. Aquí puedo ver que mi bucle de juego consta de una actualización y un renderizado. En este caso, la función de renderizado tarda casi tres veces más en ejecutarse que la función de actualización. Por lo tanto, claramente quiero enfocar mis esfuerzos allí, ya que la mayoría de las mejoras de rendimiento se pueden encontrar allí. Para investigar el rendimiento de renderizado, existen muchas herramientas disponibles en extensiones del navegador. Una muy buena que recomiendo es Spectre.js. Te permite capturar un solo cuadro de renderizado y muestra cómo se está utilizando WebGL. Puedes ver las llamadas de dibujo individuales que se están enviando e incluso profundizar y ver el código de sombreado 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 tiene, obviamente, una GPU mucho más débil en términos de procesamiento de fragmentos. Por lo tanto, no tendría sentido renderizar tu juego libremente a la resolución completa del dispositivo en cualquier dispositivo. Lo que puedes hacer es darle al usuario la opción de renderizar a diferentes resoluciones o, mejor aún, puedes detectar la GPU. Puedes hacerlo en Android y tomar una decisión sobre la resolución de renderizado en función de la familia de GPU que hayas detectado. Algo más que debes considerar es limitar la complejidad gráfica de tu juego. A la izquierda, hay un juego llamado Bitmoji Tennis, que es muy simplista. Utiliza un solo mapa de emisión para el entorno. No hay sombras dinámicas. Todo está precalculado. Hay una sola luz direccional para las sombras, bueno, para iluminar a los personajes. Y luego, a la derecha, puedes ver una demostración mucho más compleja.

8. Optimización de Llamadas de Dibujo y Rendimiento

Short description:

La complejidad de los sombreadores afecta la carga de la GPU y las tasas de fotogramas. Gestiona cuidadosamente las llamadas de dibujo para minimizar los costos de la CPU y la GPU. Técnicas como las texturas Atlasine y el agrupamiento pueden optimizar las llamadas de dibujo y reducir la sobrecarga de procesamiento. Tres consejos clave: optimiza desde el principio, diseña para el rendimiento y prueba en tu dispositivo base.

Hablando gráficamente, es una demostración técnica que el equipo de Play Canvas 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 sombreadores del juego de la izquierda es mucho más simple. Y por lo tanto, ejerce menos presión sobre la GPU y puedes renderizar altas tasas de fotogramas.

También recomiendo que tengas mucho cuidado con la cantidad de llamadas de dibujo que realiza 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á una sobrecarga en términos de costos de la CPU y la GPU. Y un juego típico de HTML5 podría renderizar entre, digamos, 100 y 200 llamadas de dibujo si deseas apuntar a algunos de estos dispositivos de gama baja.

Entonces, una técnica para optimizar las llamadas de dibujo son las texturas Atlasine. 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 se agrupan en un conjunto de texturas, y esto significa que las llamadas de dibujo se pueden combinar. Otra técnica es el agrupamiento, donde tenemos un entorno que se renderiza utilizando siete modelos distintos, y algunos de estos modelos se renderizan varias veces. Puedes ver, por ejemplo, algunos de los edificios se duplican, los neumáticos de los gatos se duplican. Y, cuando renderizamos esta escena normalmente, así es como se construye la escena. Puedes ver que hay una llamada de dibujo individual por objeto. Pero, si usamos el agrupamiento, podemos combinar modelos similares en llamadas de dibujo combinadas, por así decirlo. 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, lo que se traduce en una reducción de un orden de magnitud en el procesamiento en la CPU y la GPU en términos de, bueno, quiero decir, en la CPU y en la GPU, hay una menor sobrecarga, porque hay menos llamadas de dibujo. Así que te voy a dejar con tres consejos clave aquí. No dejes las consideraciones de optimización hasta el final de tu proceso de desarrollo. Además, diseña tu juego teniendo en cuenta el rendimiento, desde el principio. Y por último, selecciona cuál es tu dispositivo base y prueba en ese dispositivo desde el principio y durante todo el ciclo de desarrollo. Eso es todo por esta charla. Gracias por escuchar.

9. Uso del Navegador y Herramientas de Desarrollo

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 principalmente uso Chrome, pero también pruebo el motor en otros navegadores. Las herramientas de desarrollo 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 herramientas de desarrollo de Chrome, pero no estoy seguro si tienen su propio motor. Las herramientas de desarrollo de Safari son excelentes para la depuración en iOS, permitiendo la depuración remota en un teléfono conectado. Sin embargo, hay limitaciones al conectarse a aplicaciones firmadas y de producción. La experiencia de conectarse a 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 también tengo que probar en todos los diferentes navegadores porque, obviamente, es importante que pruebe el motor en todos los lugares donde se 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 plantea la pregunta, como, ya sabes, ¿qué navegador usas para optimizar tus juegos? Porque yo también principalmente usaré las DevTools de Chrome, pero me sorprendió gratamente la última vez que probé Firefox, ya que sus DevTools han alcanzado al menos desde hace cinco años cuando las usé por última vez. Así que tal vez no sea, quiero decir, no sé si es comparable, pero creo que vale la pena echarles un vistazo. Creo que el perfilador de CPU es realmente impresionante. Lo uso bastante. También noté que hay algunas personas que eligieron Opera aquí y, quiero decir, supongo que Opera comparte las DevTools de Chrome 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 en iOS, ¿las DevTools de Safari tienen... Porque sé que puedes hacer esa cosa donde conectas el teléfono y luego puedes hacer esta depuración remota. ¿Las DevTools de Safari son agradables... Bueno, ¿DevTools? Sí, bueno, las DevTools son bastante buenas. Sí, quiero decir, como mencionaste, la razón principal por la que las usarás es porque te estás conectando a un dispositivo iOS y luego puedes debug una WebView o el navegador Safari. Y esa experiencia es bastante buena. Creo que el único problema que hemos tenido es porque Play Canvas se utiliza para construir bastantes aplicaciones híbridas donde la WebView está incrustada en la aplicación para que se pueda enviar a una tienda de aplicaciones y en realidad no puedes conectarte a una aplicación que ha sido firmada y está en producción. Lo cual es un poco frustrante, pero sí, en general funciona bastante bien. Y Chrome es lo mismo con Android, ¿verdad? Como la experiencia cuando te conectas, quiero decir, normalmente hago el registro USB, pero toda esa experiencia es bastante fluida en estos días.

QnA

Detectando el Rendimiento del Dispositivo y Optimizaciones

Short description:

Dan pregunta sobre herramientas para detectar el rendimiento del dispositivo. Play Canvas tiene un perfilador de estadísticas mini 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 dispositivos móviles, pero una extensión de WebGL llamada Disk Joined Timer puede proporcionar tiempos precisos. Mark pregunta sobre la optimización de juegos basada en dispositivos específicos. La detección del dispositivo en el navegador puede ser limitada, pero el análisis del agente de usuario y las propiedades de la ventana pueden proporcionar pistas. En Android, Chrome informa sobre la familia de la GPU, lo que permite optimizaciones específicas. Muchos desarrolladores de juegos utilizan declaraciones condicionales para dirigirse a GPUs más antiguas y limitar la complejidad de renderizado.

Genial, eso tiene sentido. Ahora tenemos un par de preguntas que llegan del público. Entonces Dan dice, gran charla, ¿hay alguna herramienta para detectar el rendimiento del dispositivo? Hay muchas herramientas. No estoy seguro si Dan se refiere a un rendimiento teórico o si simplemente quiere obtener estadísticas de rendimiento de una aplicación en ejecución. En Play Canvas, tenemos algo que llamamos el perfilador de estadísticas mini. Es como un panel que obtienes automáticamente como parte de nuestra página de lanzamiento cuando ejecutas tu aplicación. Y 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 que muestra estadísticas de rendimiento del dispositivo en el que estás ejecutando. Y es realmente importante, ya sabes, es fácil de hacer, especialmente en dispositivos móviles, ¿verdad? Porque la mayoría de nosotros nos enfocamos en dispositivos móviles en 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 problema, un pequeño problema que tienes en dispositivos móviles en estos días es que si quieres hacer 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 hacer, ya sabes, mediciones precisas en la GPU. Eso es lo que usa nuestro perfilador de estadísticas mini. Pero desafortunadamente no es muy compatible con dispositivos móviles. No creo que sea compatible con iOS, por ejemplo. Eso tiene sentido. Creo que es una buena transición hacia la siguiente pregunta, donde Mark pregunta, si alguna vez encuentras útil hacer un perfilado en tiempo real del hardware en el que se ejecuta un juego y luego hacer modificaciones basadas en eso, como, por ejemplo, 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. En mi charla había una diapositiva donde mencioné la gran disparidad en la potencia del hardware móvil hoy en día que puedes comprar en una tienda. Y, ya sabes, sería una gran lástima si tuvieras que escribir un juego que solo esté dirigido al hardware de menor denominador común. Entonces, si de alguna manera quieres darles a tus usuarios, a tus jugadores, una mejor experiencia, querrás encontrar una forma de permitir que tu juego se adapte según el rendimiento del dispositivo, ¿verdad? Eso puede ser complicado porque en el navegador estás limitado para detectar el dispositivo en el que se está ejecutando. Por ejemplo, en iOS, no sabes qué GPU se está utilizando. Puedes hacer cosas como analizar el agente de usuario para obtener pistas sobre el dispositivo. Incluso puedes hacer cosas como hacer suposiciones basadas en cosas como el ancho y alto de la ventana informados o, ya sabes, lo que se llama la relación de píxeles del dispositivo de la ventana, lo que sea. Esas propiedades pueden darte una pista sobre la antigüedad y potencia del dispositivo. Y luego en Android, las cosas son un poco más fáciles porque Chrome informará sobre la familia real de la GPU en la que se está ejecutando. De hecho, conozco a muchos desarrolladores de juegos que escriben sus juegos donde tienen algún tipo de declaración en su código que dice si es Android, y luego tienen un switch con ciertas GPUs para hacer algo específico, normalmente son GPUs más antiguas de siete, ocho, nueve años, como la Armali 400 o la familia Adreno 300, ¿verdad? Porque en esos dispositivos más antiguos, probablemente quieras limitar la complejidad de lo que estás renderizando. Entonces, tal vez, no sé, desactivar partículas o usar LODs más bajos, como dices, son normales. Sí, hay técnicas que puedes usar para analizar las 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 basada en las diferencias de dispositivos. Apple ha avanzado con la implementación de WebGPU, soportando WebGL 2 y WebXR. Se están poniendo al día rápidamente y las cosas serán emocionantes con WebGPU. Los juegos HTML5 se pueden enviar a la App Store utilizando 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 quiero decir, en mi opinión, la razón por la que me gusta la web es porque es como publicar una vez y es lo mismo en todas partes. Pero también es, supongo, agradable que podamos, al menos cuando necesitamos hacer estos cambios según sea necesario basado en el dispositivo.

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

Sí, eso es interesante, quiero decir, creo que probablemente haya algunas consideraciones sobre el negocio de la App Store. Creo que tenemos que darle crédito a Apple aquí porque realmente han mejorado 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 porque todavía estábamos estancados en WebGL 1. Pero sí, creo que, démosles algo de crédito y digamos que se están poniendo al día muy rápidamente. Y creo que las cosas serán realmente emocionantes una vez que WebGPU se implemente. Creo que está disponible en una, ¿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, ya sabes, puedes enviar juegos, juegos HTML5 a la App Store utilizando tecnologías como Cordova. Como tenemos una guía en la documentación del desarrollador de Play Canvas que explica ese proceso, ¿verdad? Así que si simplemente buscas 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 sí, es súper fácil. Eso es genial. Tiene mucho sentido. Muchas gracias, Will. Fue genial tenerte aquí. Realmente lo aprecio. Es súper genial escuchar todos tus conocimientos. Muchas gracias. Un 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

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
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. 

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
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.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
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.
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)