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

♪ 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.