3+ Usos de React en un Estudio de Juegos

♪♪ ♪♪ Maravilloso. Muchas gracias, Kathleen. Bienvenidos a todos. Gracias por unirse aquí. Va a ser un día interesante, sin duda, así que comenzaré con una breve introducción, de nuevo.

Soy Hendrik. Vivo aquí en esta ciudad, así que es un placer dar una charla aquí. Hago principalmente juegos para móviles, y lo hago en C++ o C Sharp utilizando Unity, pero como dije, siempre he tenido mucha curiosidad por la web desde los primeros tiempos en los que empecé a trabajar. Y he trabajado para algunas compañías muy geniales en proyectos emocionantes con personas realmente inteligentes. Así que, buenos tiempos, pero hoy en día trabajo en Playpack Games, que es un nuevo estudio aquí en Berlín. Bueno, estamos basados aquí, pero en realidad trabajamos desde cualquier lugar, y aquí puedes ver a mi maravilloso equipo de todo el mundo. Nuestra declaración de misión es crear juegos multiplataforma con un fuerte y significativo elemento social.

Muy bien. Así que, tal vez un breve descargo de responsabilidad. Soy bastante nuevo en React. Si estás buscando una inmersión profunda o cosas técnicas, hay charlas mucho mejores para eso en esta conferencia, estoy seguro de ello. Voy a presentar tres casos de estudio, y todos estos son reales, pero cambié algunos de los nombres y los gráficos, porque eso es de tiempos de freelance, y también para hacerlo más ilustrativo.

Muy bien, ¿puedo empezar con una rápida muestra de manos? ¿Quién de ustedes ha hecho algún tipo de juego? Maravilloso. ¿Quién ha usado Unity para hacerlo? Todavía hay bastantes. Impresionante. Muy, muy genial. Quiero decir, esta es la pista de juegos, así que no debería sorprenderme tanto, pero es genial verlo. Así que, hagamos un juego. Hagámoslo para un solo jugador. ¿Por qué? El multijugador es realmente, realmente, realmente difícil. Así que, el modo de un solo jugador es mucho más fácil. Vamos a lanzarlo en móviles y hagámoslo casual y gratuito, porque eso es lo que hace mi estudio.

El desarrollo de juegos, como resultó, no ha cambiado mucho desde los años 90, si somos honestos. Así que te sientas frente a una computadora, tienes algo de código fuente, tienes algunos activos, tienes herramientas y editores para trabajar con ellos. Los viertes en una gran caja, y luego sale un paquete, que es como un ejecutable, y eso se ejecuta en la computadora de otra persona.

Aún es prácticamente lo mismo. Si construyes actualmente para un dispositivo Android o un dispositivo iOS, al final, sigues construyendo un paquete, ¿verdad? Y como puedes ver, en ningún momento entra en juego la cloud o alguna forma de servidores aquí.

Los desarrolladores de juegos son realmente especializados, ¿verdad? Son personas de front-end que son realmente buenas en hacer que las cosas se vean geniales, se sientan geniales, performance, hacer que los juegos sean divertidos. Pero muchos de ellos en realidad no conocen mucho sobre el mundo web más amplio que existe.

Muy bien, vamos a hacer un juego, lleva un tiempo, y luego después de tres a seis meses, tienes un juego. Maravilloso, tal vez lo hiciste en Unity, lo envías a plataformas móviles, está allí, está en el dispositivo, ¿verdad?, es para un solo jugador, todo se ve genial. Pero ya no estamos en 1999 y la gente tiene expectativas. Por ejemplo, cuando un jugador cambia de teléfono, como la gente hace, como cada año, algunos de ellos, esperan poder guardar sus juegos guardados y no ponerlos en un disquete. Así que tenemos que almacenarlos en algún lugar de la cloud. ¿Verdad? Otra cosa, la gente espera soporte al cliente, ¿verdad? El soporte al cliente debería poder, dentro del juego, dar retroalimentación o recompensas a los jugadores. Bien. ¿Cómo empezamos con eso? Empecemos poniendo el progreso del jugador dentro de una database, ¿verdad? ¿Qué tan difícil puede ser eso? El progreso es un solo documento JSON, vive en el dispositivo. Así que en lugar de tenerlo solo en el dispositivo, lo ponemos en una tienda de clave-valor, algo como Firebase funciona muy bien. Las grandes compañías tienen sus propias soluciones, ¿verdad? Hay un SDK para eso. Así que en realidad no tenemos que hacer nada de cosas backend.

Bien. Cuando el juego se carga, lo cargamos, ¿verdad? Cada vez que hacemos cambios, lo escribimos de vuelta en la database. Funciona bastante bien. Genial. Notas algo aquí. Ahora podemos cambiar el progreso del jugador de forma remota, ¿verdad? Porque podemos jugar con el estado del juego en la database. Así que hagámoslo y resolvamos el problema del servicio al cliente, ¿verdad? OK, el caso aquí es que el jugador nos contacta, el juego se comportó de alguna manera incorrecta, ya sabes, algo salió mal, y queremos recompensarlos con alguna moneda o algunos objetos o algo así, ¿verdad? Y queremos escribir un pequeño mensaje allí. Ahora, las personas del servicio al cliente no deberían hacer entradas manuales en la database. Así que deberíamos tener una herramienta para esto. ¿Qué herramientas deberíamos construir? ¿En qué lenguaje? Debería ser utilizable por no desarrolladores. Hmm, es hora de aprender un poco de React, ¿verdad?

Caso uno, una herramienta de servicio al cliente. Construyes una pequeña aplicación React, se comunica con la database, ¿verdad? Nuevamente, como Firebase, hay un SDK, no tienes que aprender algo realmente difícil, ¿verdad? Como un buen patrón aquí, probablemente para cosas como esta, no escribas directamente en la database y cambies el estado, haz que el jugador lo confirme, porque se siente mucho, mucho mejor, ¿verdad?, como parte de la conversación de servicio al cliente. Puedes ver aquí, la herramienta a la izquierda programa un comando en la database. El dispositivo lee el comando, lo aplica, y lo escribe de vuelta cuando se consume. ¿Verdad, y esto es cómo se ve esta herramienta, ¿verdad? Todo esto debería resultarte muy familiar, un poco de material UI con algunas cajas de texto y tal vez algunos editores personalizados, porque quieres tener estos elementos allí y tener algunos selectores y cosas así.

Y en la parte inferior, hay un gran botón que lo escribe todo en la base de datos, y eso es genial. Así que hospedas eso en algún lugar, lo proteges con OAuth o algo así, ya sabes, lo proteges, y luego se lo entregas al servicio al cliente y listo. No se necesitan más desarrolladores.

Bueno, ¿cómo sabe la herramienta de React qué elementos están en el juego o qué recursos? Además, ¿podemos visualizar el progreso de un jugador en la herramienta de alguna manera para que lo vean las personas del servicio al cliente que la usan? ¿Y quién se encarga de actualizar estos datos cuando el juego obtiene nuevo contenido?

Así que retrocedamos un paso. Volvamos al desarrollo de juegos, ¿de acuerdo? En producción, estamos haciendo nuestro juego y los juegos son simulaciones, más o menos, ¿verdad? Y eso generalmente significa un sistema más o menos complejo, ¿verdad? Y los sistemas complejos son difíciles de comprender. Y acertar con la dificultad es realmente crucial. Quiero decir, ese es el trabajo de los diseñadores de juegos asegurarse de que el juego sea divertido porque tiene la cantidad correcta de dificultad.

Entonces, ¿cuál es la herramienta principal que utilizan los diseñadores de juegos? Sí, es Microsoft Excel, porque ya sabes, es una gran herramienta, en realidad, para visualizar grandes cantidades de datos numéricos. Tienes fórmulas allí, pero cuando se trata de ejecutar simulaciones, es muy limitado, ¿verdad? ¿Qué pasa si quieres introducir aleatoriedad o cosas a lo largo del tiempo, o tienes bucles de retroalimentación?

Entonces, ¿por qué no escribir una pequeña aplicación React, ¿verdad? Aísla esta lógica central compleja. Básicamente, hazlo un mini juego. Tienes algunos controles deslizantes y todo eso, ¿verdad? Y construyes eso junto con tu diseñador. Es muy rápido iterar porque lo haces de forma independiente, completamente independiente del resto del juego. Cuando estés satisfecho con eso, transfiere todo eso de vuelta al juego.

Pero tienes el mismo problema aquí. ¿Dónde se administra todo ese contenido, ¿verdad? ¿Dónde vive eso? Hmm. Entonces, ¿por qué no ir a lo grande y construir un sistema de gestión de contenido? Quiero decir, después de todo, si miro a los patrocinadores, esto es algo con lo que React parece ser bastante popular, ¿verdad? Así que tomemos todas estas hojas de cálculo, todo este contenido y muévelo a alguna forma de sistema de gestión de contenido. ¿De acuerdo? ¿Qué deberíamos usar? Bueno, pregunta número uno, ¿qué base de datos deberíamos usar? Personalmente, me gusta mucho un flujo de trabajo similar a Git. Esto es algo a lo que estamos muy acostumbrados en los estudios de juegos, tener alguna forma de control de versiones allí. Como ramas, versiones etiquetadas. Debería ser fácil de configurar localmente, tal vez utilizable sin conexión. No sé. Me gusta trabajar en el tren. Git para datos es un problema realmente interesante. Si sabes más sobre esto, como bases de datos que tienen un flujo de trabajo similar a Git, háblame, porque tengo mucha curiosidad al respecto. Pero al final, lo que hicimos fue tener cada entrada de la base de datos como un solo archivo JSON. ¿De acuerdo? Por lo tanto, esto es muy fácil de leer por herramientas externas, tu motor o tus herramientas de React. Es muy fácil de diferenciar en Git. Las personas están muy acostumbradas a eso. Y admite referencias bastante bien, ¿verdad? Si lo piensas un poco.

Y luego, además, si tienes un esquema de base de datos, puedes generar editores personalizados basados en ese esquema. ¿Verdad? Así que sabes que cierta entrada dentro del esquema es una cadena con ciertas validaciones. Luego, renderizas un campo de texto y aplicas esas validaciones a eso. ¿Verdad? Esto está muy inspirado en Rails. Sé que ha pasado un tiempo, pero eso fue una de las primeras cosas con las que me expuse en la web y me pareció muy fascinante. ¿Verdad? Además, si quieres profundizar realmente, puedes escribir editores personalizados. Es divertido en React, en mi opinión. ¿Verdad? Y tienes cosas como campos desplegables listas para usar. Puedes decirle al escritor que escribe estos diálogos que su texto se está alargando un poco. Y tal vez tienes corrección ortográfica en línea y todo eso. Y eso me lleva a un punto muy importante, porque ustedes dan por sentado muchas cosas. Cosas que realmente no tenemos en el mundo del desarrollo de juegos. ¿Verdad?

Piensa en lo que tus usuarios dan por sentado. Y los usuarios, en mi caso, son el resto de mi equipo que tiene que trabajar con este CMS, ¿verdad? Navegación basada en enlaces. No tienes eso en Unity. No tienes eso en Excel. ¿Verdad? Validaciones, difícil de realmente, ya sabes, tienes que poner algo de trabajo, deshacer y rehacer, corrección ortográfica, eso está a solo un complemento del navegador de distancia. Y además, las pestañas del navegador son increíbles. ¿Verdad? Puedes tener múltiples vistas de los mismos datos. Y hacer eso en Unity, por ejemplo, se vuelve realmente complicado.

Además, las cosas que das por sentado como ingenieros, y supongo que aquí hay algunos ingenieros, ¿verdad? Los monorepos son un cambio de juego. En el desarrollo de juegos, por lo general tienes que lidiar con, en el mejor de los casos, submódulos, tal vez repositorios distribuidos, tal vez alguien haya creado un Administrador de Paquetes casero. ¿Verdad? Todo es mucho más complicado. No estamos acostumbrados a tener acceso al código fuente para todo. Unity es de código cerrado. Muchas cosas son de código opaco. Así que puedes adivinar o tal vez encontrar una versión antigua. Y además, si lo tienes en algún monorepo, puedes hacer clic para navegar a cualquier parte del código fuente.

Eso es increíble. No estamos acostumbrados a eso. Los tiempos de iteración. Si alguna vez has trabajado con Unity, sabes que lleva unos segundos. En C++, podrías hablar de minutos hasta que obtienes tu compilación en el dispositivo. Mientras que con cosas como ES build y recargas del navegador, puedes reducirlo a menos de un segundo. Eso es simplemente increíble.

La recarga de módulos en caliente es un cambio de juego absoluto. Poder hacer cambios en el código mientras el juego se está ejecutando y ver los cambios reflejados de inmediato, incluso en el dispositivo, es absolutamente increíble. Normalmente no tenemos eso en el mundo de los juegos.

Además, sé que los navegadores reciben muchas críticas por no ser compatibles con los estándares. Pero en general, son sorprendentemente confiables como herramientas de implementación multiplataforma. Tienes web sockets. Son una herramienta realmente poderosa para comunicarse desde el cliente hasta el servidor y configurar las cosas como quieras. Y en general, diría que las herramientas son muy, muy maduras. Realmente puedes ver que muchas grandes empresas de tecnología han invertido mucho tiempo y dinero para asegurarse de que los depuradores y los perfiles sean realmente buenos.

Bueno, ¿por qué hablo de todo esto en pasado? Bueno, en realidad, recuerda este juego del que mencioné al principio, ¿verdad? Aquí está, ejecutándose dentro del sistema de gestión de contenido en el navegador. Y los casos uno y dos son como este enlace de administrador aquí y la herramienta de juego de los clientes allí a la derecha. Nuevamente, esto sucedió en otras empresas, pero es un caso de uso tan común que esto sucedió nuevamente en este proyecto.

Sí, construimos un juego completo en TypeScript y React, ¿verdad? El tiempo de ejecución está en TypeScript. El editor está construido con React sobre el sistema de gestión de contenido. Hay un pequeño mundo 3D. Hay horas de juego. Esperamos que pronto haya multijugador, ¿verdad?, impulsado por Node.js y WebSockets, y todo esto se implementa en dispositivos iOS y Android, ¿verdad? Porque hay más React, ¿verdad? Simplemente puedes usar React Native y enviar cosas a iOS y Android, ¿verdad? El código abierto es increíble. Obtienes canalizaciones de CI como un problema resuelto, ¿verdad? No tienes que configurar tu propio Jenkins para hacer compilaciones y lidiar con la firma y todo eso. Muchas personas han resuelto estos problemas. Y el soporte de SDK de terceros es bastante bueno, ¿verdad?

Además, y encuentro eso realmente fascinante, usamos React Pixie para renderizar la interfaz de usuario del juego. Es, creo, la parte más experimental de esta pila tecnológica, pero también una que tuvo beneficios increíbles cuando se trataba de poder iterar y hacer cambios en la interfaz de usuario en un juego en ejecución, mover cosas y trabajar con el resto del equipo allí. Nuevamente, la recarga de módulos en caliente es increíble.

Correcto. Sería una mala charla si dijera que todo es increíble, ¿verdad? Y esto es lo que deberías hacer. Algunas advertencias aquí. Si quieres construir un shooter en primera persona AAA, no estoy seguro de que esta sea la forma en la que deberías ir, ¿verdad? Los motores nativos tienen un rendimiento muy, muy bueno, tienen pilas gráficas que no podrás igualar fácilmente por tu cuenta. Además, muchas de las cosas que viste allí requieren herramientas personalizadas. Esto no es algo que puedas obtener fácilmente de la estantería.

Quiero señalar la curva de aprendizaje aquí. Nuevamente, soy bastante nuevo en React, ¿verdad? Entonces, viniendo del desarrollo de juegos, esto es realmente un cambio. Como React con hooks, realmente tienes que entenderlo para asegurarte de que te acostumbras a esa forma de trabajar. Tal vez todo esto te parezca muy normal en este momento. Solo digo que la integración y también la contratación son problemas bastante interesantes cuando estás un poco fuera de lo común. Y esa es la pregunta aquí, ¿verdad? ¿Qué tan grande es la superposición entre el mundo web y el mundo de los juegos? No solo en el sentido técnico, sino también en el sentido de las personas. Y, quiero decir, esta pista me da mucha esperanza, pero es un poco una pregunta abierta. En resumen, absolutamente puedes lanzar un juego hecho con tecnología web en dispositivos. Incluso si solo construyes herramientas, puedes aprender mucho y eso puede ayudar a mejorar tus juegos. El código abierto es absolutamente increíble, ¿verdad? Las cosas que están disponibles y que puedes unir fácilmente. Quiero decir, Pixie.js merece un gran reconocimiento. Es un motor increíble. Es muy rápido. La comunidad es genial. El código base es muy, muy legible. Creo que el desarrollo de juegos puede aprender mucho de la web. En última instancia, la esperanza es que esto conduzca a hacer juegos más rápidos, y creo que un desarrollo de juegos más rápido al final resulta en mejores juegos, y eso es lo que, ya sabes, nuestra industria es, en última instancia, todo acerca de eso.

Y eso es todo. Muchas gracias a todos. Gracias.

Gracias. Muchas gracias, Hendrik. Qué buena presentación. Me gustaría invitarte aquí en la silla porque tenemos algunas preguntas de la audiencia.

Maravilloso. Sí. Así que vamos con la primera. También me preguntaba por qué no usar Git en lugar de Adibi para las entidades y propiedades del juego, y la cantidad de datos seguramente no es abrumadora. ¿Verdad? Así que en realidad es Git, ¿verdad? Todos estos archivos están en control de origen exactamente por esa razón. Pero, ya sabes, eso todavía significa que las cosas están a nivel de archivo. No es una base de datos basada en transacciones, por ejemplo, ¿verdad? Pero sí, al final, la pregunta está absolutamente justificada. Y sí, es Git para la base de datos, sí.

Genial. Hay otra pregunta de un usuario anónimo. ¿Has considerado Go para ver las grandes... Por supuesto, he considerado Go. Es un motor muy bueno, y han hecho muchos cambios en él. Lo miramos al final para lo que estábamos tratando de lograr. Tenía sentido usar nuestra propia tecnología allí. Y me preguntaba sobre la curva de aprendizaje allí, porque es un lenguaje diferente, ¿verdad? Según lo que... Go definitivamente tiene una curva de aprendizaje. Una cosa que no mencioné es que, viniendo de un fondo en C#, cambiar a TypeScript en realidad me resultó bastante fácil. Es el mismo equipo de Microsoft que construyó estos dos motores, y se puede ver que transfirieron muchas ideas. Así que encontré muy fluida la transición a TypeScript. Dame un segundo, porque hay muchas... Mientras reviso las preguntas, también tengo una pregunta propia. Y me preguntaba más sobre la, mencionaste la validación de formularios.

Y me preguntaba, ¿qué has usado para eso? Bueno, lo escribimos nosotros mismos. Estaba mirando el esquema JSON, y hay muchas cosas en ese sentido. Al final, nada encajaba realmente en el caso de uso, así que lo escribimos nosotros mismos. Entonces, las cadenas con expresiones regulares y referencias luego tienen que buscar si ciertos archivos, como las entradas de la database, existen.

De acuerdo. Hay otra pregunta. ¿De qué sería una simulación SCAD? No estoy seguro de qué es SCAD. No lo sé. ¿Alguien de la audiencia? Bueno, está bien. Quiero decir, eso fue... De acuerdo, bastante justo. No todos los juegos son simulaciones hardcore, pero muchos juegos de computadora son simulaciones, en particular juegos para un solo jugador. Debería haberlo dejado más claro.

De acuerdo. Hay otro aspecto interesante, como los aprendizajes sobre la gestión del state del servidor. Si tienes alguno, como núcleos de transmisión de eventos, pequeña F o CRUD abierto. Sí, aplicaciones grandes. ¿Tienes algún aprendizaje desde esta perspectiva, como solución de gestión del state del servidor? ¿Puedes especificarlo? No soy un experto en web, así que no conozco todos los términos. Como usar, por ejemplo, event sourcing, CQRC y nest.js. Tal vez si alguien está en la audiencia aquí, puedes hablar con Patrick después. Sí, habla conmigo después. Eso es lo bueno. El ecosistema web es tan grande, que es imposible tener una visión general de todas las cosas geniales que hay. Así que al final, nos quedamos con las cosas que funcionaron cuando las juntamos.

Hay otra pregunta, ¿has intentado conectar algún código nativo que ya tenías al navegador utilizando WebAssembly? WebAssembly, lo he usado principalmente como usuario. Sorprendentemente, es bueno para nuestra implementación. En realidad, no es necesario, y no me importa escribir el código de mi juego en TypeScript. Así que tengo todo en una base de código. Es muy fácil interoperar. Gracias.

Y hay otra pregunta, ¿tienes herramientas para crear la interfaz de usuario dentro del juego en React, o herramientas integradas? Eso es en realidad un tema muy abierto. Hablo mucho con nuestro diseñador de UI y UX sobre esto, y es algo que queremos abordar porque estas herramientas no existen. Entonces estamos considerando tomar una herramienta de UI existente y escribir un exportador que exporte a ReactPixie o tal vez hacer algunas herramientas nosotros mismos allí. Pero es una pregunta muy interesante.

Sí, solo una pregunta de seguimiento, porque también me preguntaba porque mencionaste que creaste tus propias herramientas internamente. ¿Alguna vez has pensado en hacerlas de código abierto, o hay algo de código abierto en absoluto o cuál es el futuro? Quiero decir, deseo y espero que podamos hacer de código abierto muchas de estas cosas. Como puedes ver, el desarrollo de juegos no es muy afín al código abierto. Creo que es principalmente histórico, pero también es el ritmo del desarrollo de juegos que a menudo no tienes el tiempo y los recursos para poder mantener un proyecto de código abierto al margen.

Hay otra pregunta, ¿cómo manejas el backend para juegos en línea de alto rendimiento como shooters o MOBA? Esa es una pregunta realmente difícil. Nuevamente, tal vez esta no sea la pila de tecnología adecuada para eso. Si quieres un shooter pesado, si lo ejecutas a través de web sockets, puedes tener problemas, tal vez quieras algo que pueda ejecutarse nativamente en tu dispositivo y luego aprovechar UDP. Hay soluciones para eso, pero tal vez esa no sea la tecnología adecuada para eso. ¿Existe alguna posibilidad de estimar algunas partes en el lado del cliente? ¿Qué quieres decir con estimar? Como, ver el futuro en el lado del cliente antes de obtener... Oh sí, sí, no, definitivamente tienes que hacer eso, ¿verdad? Con web sockets, estás hablando de latencias de decenas a cientos de milisegundos, así que necesitas trabajar un poco para ocultar la latencia. Ok, por eso decías próximamente, la parte multijugador, ¿verdad? Quiero decir, también hacer juegos multijugador es realmente difícil. Ok... Hay otra pregunta. ¿Puedes usar compras de activos de Unity Asset Store en tus juegos basados en web? Sí, puedes, sí. Quiero decir, tienes que trabajar un poco, pero hay cosas que pueden, como, tomar archivos OBJ tal vez, o archivos FBX y convertirlos en datos de malla que puedes cargar como búferes de vértices. Quiero decir, eso suena un poco extraño, pero para los desarrolladores de juegos, eso es muy, muy común. Eso es algo que hacemos todos los días, así que está bien. Tengo otra pregunta propia, y también mencionas React Native. Soy un gran fan de React Native, y estás hablando de React Pixie, o ¿cuál fue el proceso para pasar de React a React Native, o qué tuviste que hacer para que esto sucediera? Bien. ¿Quieres decir, al final, lanzar todo el proyecto? Sí. Bien. Entonces, el proceso de implementación actual es tener el juego funcionando como un juego web, y luego envolverlo dentro de una vista web, dentro de una aplicación React Native. Entendido. Y luego hacer puentes hacia las llamadas nativas. Ok, como una aplicación híbrida. Es una aplicación híbrida.

De acuerdo. Hay otra pregunta como seguimiento a React Native. ¿Estás utilizando otras herramientas aparte de React Native para la gestión del estado o las conexiones API? Sé que ustedes saben mucho más sobre esto, pero estoy bien con hacer llamadas HTTP con Axios, eso es prácticamente mi límite. Quería investigar más sobre GraphQL y la forma en que se pueden hacer API modernas, pero eso está un poco fuera de mi alcance. Por el momento, no, en realidad solo utilizamos React y hacemos llamadas.

Sí, realmente depende porque hoy en día la gente no apuesta por GraphQL de todos modos. Así que creo que elegiste la pila adecuada. Tal vez también puedas probar React Query, inténtalo con Axios y también con Prisma. Ellos también nos patrocinan. Y tenemos tiempo para una pregunta más, creo.

Y esta pregunta es ¿Funciona PIXI en React Native? Esa era en realidad mi pregunta también. Correcto. Y si es así, ¿qué tan eficiente es? Correcto. La antigua versión de PIXI, creo que la versión cuatro o algo así, era compatible con React Native. Los chicos de Expo. Sí, ellos lo hicieron y Evan Bacon dio una charla sobre cómo implementar toneladas de juegos. Y se veía increíble. Lo intenté. Pero con PIXI 5 o 6, simplemente dejó de funcionar correctamente. Así que quería echarle un vistazo. Pero al final, tienes el WebView del navegador como una capa de compatibilidad. Y para mí, eso parece mucho más confiable que simular algunas llamadas de OpenGL en una pila nativa que no controlo tan bien. De acuerdo. Sí. Sí, creo que según tengo entendido, también construyó algunos juegos utilizando Expo 3js. Sí, y portó bastantes paquetes web a React Native, lo cual es realmente... Es realmente increíble. Pero en nuestro caso, eso no funcionó realmente. Además, queremos poder hacer una implementación completamente independiente de la plataforma. Correcto.

Entonces, si queremos hacer un juego web, también debería funcionar como un juego web. De acuerdo. Y creo que es la última pregunta. Solo para resumir todo, ¿qué crees que son las lecciones desde la perspectiva de un desarrollador web si están entrando o si les gustaría ir al game development, ¿qué crees que son sus... Correcto. O lo que hay que aprender, básicamente. Correcto. Quiero decir, definitivamente hay mucho que aprender. Creo que el ritmo y la mentalidad en los juegos son bastante diferentes. Pero aún así, quiero decir, es muy divertido. Ambos, creo, son comunidades muy divertidas para estar. Quiero decir, ves una conferencia como esta y luego ves conferencias de juegos. Y hay una vibra muy similar de personas que solo quieren construir cosas geniales. Así que diría que si estás buscando eso, atrévete, ¿verdad?, entra, haz juegos.

Sí, muchas gracias. Con eso creo que, sí, las personas pueden encontrarte en la sesión de preguntas y respuestas, salas de discusión para la audiencia remota, sí, muchas gracias, Hendrik. Y fue un placer tenerte aquí en el escenario. Maravilloso, muchas gracias, chicos. Te aplaudo fuertemente, Hendrik. Sí.