Juego Multijugador en Tiempo Real con React Native: Un Estudio de Caso de un Juego de Reflejos

Hola a todos. Gracias por sintonizar mi charla, Real-Time Multiplayer Game with React Native. Esta charla es principalmente un estudio de caso de mi experiencia construyendo un juego llamado Quickflex. Si no has oído hablar del juego, te animaría mucho a que vayas y lo descargues de la tienda de aplicaciones. Es un juego divertido, y déjame mostrarte. Ahora, este juego se puede jugar con un amigo o puedes jugarlo solo. En este video, te voy a mostrar cómo se juega cuando quieres jugarlo con un amigo.

Entonces, cuando comienzas el juego, tienes la opción de crear una sala. Puedes crear una sala y compartir ese código con un amigo. Usando ese código, un amigo puede unirse a la misma sala de juego. Una vez que ambos están en esa sala, se inicia un temporizador o una cuenta regresiva, y luego se carga el juego. Así es como realmente funciona el juego. La persona que es más rápida en hacer clic en ese ícono o el botón verde obtiene la puntuación, y la posición de este botón cambia tan pronto como alguien hace clic en él para ambos jugadores, y esto es lo que hace que el juego sea divertido.

Bueno, eso fue sobre el juego, pero déjame presentarme. Mi nombre es Harshal Agarwal, y vivo en Berlín, Alemania. Trabajo como educador de desarrolladores en CloudFlare. Si estás construyendo algo en CloudFlare, me encantaría saber sobre eso. Aparte de mi trabajo diario, también me encanta construir proyectos realmente geniales en mi tiempo libre, y QuickFlags fue uno de esos proyectos. Sigamos adelante con la charla, y déjame hablar sobre la agenda de esta charla. En esta charla, voy a hablar sobre los problemas que enfrenté cuando estaba construyendo esta aplicación. También compartiré las soluciones que implementé. Ahora, por favor nota, estas soluciones no son las mejores soluciones. No son las soluciones más eficientes, y por esa razón, voy a cubrir las soluciones eficientes en la siguiente sección de pasos.

Ahora, vamos a echar un vistazo al flujo del juego o la arquitectura del juego nuevamente. Entonces, una vez que instalas la aplicación y la abres por primera vez, obtienes esta pantalla de cómo jugar. Esta pantalla tiene un carrusel donde puedes desplazarte y aprender cómo funciona el juego. Si omites, si haces clic en el botón de omitir para cerrar esto, te lleva a nuestra pantalla de inicio. Ahora, esta es la pantalla donde el usuario puede seleccionar en qué modo quiere jugar el juego. Si seleccionan el modo dual, son llevados a otra pantalla donde pueden crear una nueva sala o unirse a una sala existente. Pero si hacen clic en el modo solo, el temporizador de cuenta regresiva comienza para el juego y pueden comenzar a jugar. Y si el usuario nuevamente quiere ver cómo jugar el juego, pueden hacer clic en el botón de cómo jugar y los lleva a las instrucciones nuevamente.

Ahora, si notas aquí, hay un montón de enrutamiento sucediendo aquí. Y eso me lleva a mi primer problema al construir la aplicación, que fue el enrutamiento. Ahora, el desarrollo de esta aplicación comenzó hace casi un año. En ese momento, Expo Router todavía estaba en beta. No había muchos recursos disponibles que me ayudaran con algunos de los problemas que estaba enfrentando. Ahora, estos problemas no eran realmente problemas mayores, pero era más la falta de recursos educativos que no estaban disponibles en ese momento. Pero no te preocupes, si estás construyendo una aplicación usando Expo Router hoy, hay toneladas de recursos disponibles ahora.

El equipo de Expo ha hecho un trabajo increíble asegurándose de que tengan la mejor documentación para esto, o no solo la documentación, incluso tutoriales en video para ese asunto. Entonces, el primer problema con el enrutamiento comenzó cuando inicialicé o arranqué un proyecto de Expo. Y si inicializas un proyecto de Expo, tiene una especie de navegación basada en pestañas. Entonces, la navegación se configura por las pestañas, lo que significa que necesitas tener pestañas para las opciones en tu pantalla para que esas cosas funcionen. El grupo de pestañas tenía un archivo de diseño, que contenía esto para ti. Entonces, si haces clic en el título de inicio o el ícono de inicio en la pestaña, te llevaría a la siguiente ruta, y similar para el botón Explorar.

Pero si volvemos a mirar las pantallas de mi aplicación, no hay pestaña. El usuario debería poder navegar a diferentes rutas ya sea haciendo clic o basado en alguna lógica del juego. Este fue uno de los primeros obstáculos que tuve. Debido a la falta de documentación adecuada en ese momento, realmente luché para hacer que esto funcionara. Afortunadamente, mi exploración en Expo Router me enseñó que Expo Router utiliza React Navigation en su núcleo. Así que navegué a través de la documentación de React Navigation y pude encontrar una solución.

Entonces, en lugar de tener un enrutamiento basado en pestañas, ahora puedo tener un enrutamiento basado en pilas. Así que ya no necesito pestañas. Podría simplemente tener el componente de pila allí, un componente allí, y las cosas comenzaron a encajar. El otro aprendizaje importante que tuve con Expo Router fue la estructura de archivos. La estructura de archivos en el proyecto Expo importa mucho si estás usando Expo Router porque cada archivo dentro de tu directorio de aplicaciones es una ruta. Y si no quieres una ruta, asegúrate de que ese archivo en particular se mantenga fuera de tu aplicación. Así que, así es como se ve ahora la estructura de mi aplicación.

Hay un directorio de aplicaciones que contiene solo las rutas que necesito y el archivo layout.tsx básicamente contiene el diseño de mi aplicación. Los componentes y los hooks se mantienen fuera del directorio de aplicaciones. Ahora, no voy a profundizar más en Expo Router, pero te permite también tener grupos para tus rutas. También puedes tener rutas protegidas y todas esas cosas. Te animaría mucho a que vayas y revises la documentación para entender mejor cómo puedes usar esas cosas en particular. Ahora que tenía el enrutamiento más o menos resuelto, el siguiente gran problema que tuve con mi aplicación fue gestionar el estado.

Ahora, porque esto es un juego, había muchas cosas. ¿Qué debería hacer mi juego cuando comienza o cuando termina? ¿Cómo gestiono el temporizador de cuenta regresiva? ¿Qué pasa con el temporizador de cuenta regresiva del juego? Ahora, estos son dos temporizadores diferentes. El temporizador de inicio es el temporizador cuando ambos jugadores se unen a la sala, que es un temporizador de cinco segundos. Mientras que el temporizador de cuenta regresiva del juego es básicamente todo el período de tiempo para ese juego, que es aproximadamente de 20 a 30 segundos. También necesitaba mantener el estado de dónde estaba posicionado ese botón verde y asegurarme de que se actualizara rápidamente. Si un jugador está jugando solo o está jugando en modo multijugador, también debe haber un estado para eso.

También necesitaba tener un estado para la puntuación, porque ningún juego es divertido sin puntuaciones. No importa realmente si estás jugando solo o si estás jugando con un amigo. Una cosa que también implementé que, en retrospectiva, no fue una solución realmente buena fue básicamente tener estados para gestionar mi UI. Para darte un ejemplo, no tenía rutas adecuadas o rutas separadas para la pantalla de cómo jugar o incluso el formulario de juego multijugador. Estos fueron básicamente manejados por los estados de la UI, así que cada vez que un usuario hacía clic en el botón de cómo jugar, básicamente actualizaba un estado y basado en los cambios de estado, mostraba la pantalla. Nuevamente, no es una solución eficiente, pero esto es lo que tenía en ese entonces.

¿Cómo se traduce esto en código? La primera versión donde era solo para un jugador con una lógica de juego simple tenía esta cantidad de estados. Esto en sí mismo es mucho. Cuando agregué la funcionalidad multijugador sin tener salas separadas, sino solo una sala única para que diferentes jugadores se unieran y jugaran el juego, el estado que tenía que gestionar aumentó. Ahora, cuando había un código de sala o salas separadas para cada uno de esos juegos, esto se volvió masivo. No, no escribí este código. También estaba probando diferentes herramientas de IA para ayudarme a construir este juego, básicamente aprendiendo a escribir código. Cuando le pedí a la IA que hiciera esto por mí, esto fue lo que salió. A primera vista, no me pareció correcto y también tenía miedo de estropear este código porque un pequeño cambio rompería toda la lógica de mi juego y cuando le pedí a la IA que lo arreglara, realmente no pudo hacerlo.

Esto me llevó a mi primera lección sobre gestión de estado: nunca tener tantos estados en tu aplicación. Comencé a investigar cuáles serían las mejores formas de resolver esto. Una de las soluciones que implementé fue usar rutas para la gestión de estado. Ahora, esto no manejó todos los estados porque obviamente no tenía sentido, pero lo que me ayudó a hacer fue separar mi lógica. Así que ahora tenía una pantalla de índice que básicamente mostraría los botones para que el jugador seleccionara el modo, pero ahora también había una pantalla de juego que manejaría la lógica del juego. Así que simplemente separar las pantallas me dio una mejor experiencia al construir esta aplicación y la cantidad de problemas que encontré disminuyó mucho.

Lo siguiente que implementé fue combinar los estados similares en hooks y usar esos hooks para una interfaz más simple. Así que comencé a usar hooks para tener el estado del juego e incluso para manejar la posición del elemento. Estas dos soluciones por sí solas ayudaron mucho a mejorar la gestión del estado para el juego, pero todavía era un poco desordenado, especialmente cuando se trataba de la parte multijugador. Aquí es donde comencé a usar WebSocket como gestión de estado. No estoy realmente familiarizado con el concepto de usar WebSocket para gestionar estados, pero para mi caso de uso esto funcionó realmente bien. Cada mensaje que se enviaba o se recibía a través del WebSocket tenía un tipo de dato y basado en el tipo de dato que el componente recibía, realizaría una acción particular. Así que, por ejemplo, si el mensaje que llegaba era una actualización de puntuación, actualizaría la posición del botón verde y también actualizaría las puntuaciones de ambos jugadores.

Ahora hablando de WebSockets, ese fue el tercer problema con el que me encontré. Quiero decir, realmente no me encontré con ese problema, pero pensemos en cómo construiríamos un servidor WebSocket. Primero tendrías que tal vez aprender un nuevo lenguaje si quieres hacerlo a escala, o simplemente puedes usar algo como Socket.io para construirlo con JavaScript o TypeScript. Una vez que tienes eso, lo segundo era averiguar cómo tener la lógica de las salas, porque quería que solo dos jugadores estuvieran en una sala particular y no todos los jugadores en una sola sala. Eso simplemente habría arruinado la experiencia del juego. Así que tener salas fue otro desafío con eso. El tercero fue dónde desplegarlo y cómo manejar la escalabilidad. Ahora soy muy optimista cuando construyo tales proyectos. Siempre pienso en que lo usen millones de personas, lo cual en teoría aún no ha sucedido, pero siempre quise asegurarme de tener ese tipo de optimización o ese tipo de prueba para mi servidor WebSocket.

Ahora afortunadamente, trabajando en Cloudflare me introdujo a este primitivo llamado Durable Objects. Durable Objects te permiten construir aplicaciones sin servidor con estado. Ahora, sé que suena un poco extraño cuando digo aplicaciones sin servidor con estado, pero no te preocupes, no voy a entrar en detalles y explicártelo ahora mismo. Lo que quiero que sepas es que debido a que Durable Objects te ayudan a construir aplicaciones sin servidor con estado, son el mejor lugar para construir cualquier tipo de aplicación multijugador, agentes de IA, o cualquier aplicación coordinada. Y debido a que son sin servidor, realmente no tengo que preocuparme también por el costo de la infraestructura. Solo pagaré por la cantidad que se está utilizando, así que eso también me dio una especie de tranquilidad.

Hablando de tranquilidad, la experiencia del desarrollador con Durable Objects es aún mejor porque solo tuve que escribir una clase y con eso tendría un servidor WebSocket en funcionamiento. Ahora hay diferentes maneras de hacer servidores WebSocket en Durable Objects, y mi forma favorita es usar el paquete llamado PartyServer. PartyServer es un paquete npm creado por Sunil Pai. Este paquete básicamente abstrae todas las complejidades de Durable Objects y en unas pocas líneas de código, como puedes ver en la pantalla, puedes tener un servidor WebSocket en funcionamiento. Así que técnicamente, esto es todo lo que necesitaba para tener un servidor WebSocket en mis Durable Objects. Una vez que tuve esto en marcha y desplegado, solo tuve que implementarlo en mi lado del cliente, que era mi aplicación y creé nuevamente un hook para esto, que era useWebSocket, y estaba usando una biblioteca llamada react-useWebSocket.

En esto, simplemente lo conectaría a mi servidor WebSocket y tendría un código de sala, que nuevamente era único para cada juego. Y eso es todo. Esa fue la implementación para el servidor WebSocket así como para el cliente. Bueno, de lo que hablé y lo que mostré no eran soluciones muy eficientes, pero eran las mejores soluciones para mí en ese momento. Al revisar el código nuevamente para la aplicación y pensar en la optimización, noté algunas cosas que quiero compartir con todos ustedes en esta sección de la charla. Ahora, si hay algo que quiero que te lleves de esta charla, es todo lo que está en esta diapositiva en particular. Si tienes una aplicación que va a manejar muchos estados, especialmente si estás construyendo un juego, comienza con máquinas de estado, y Xstate es la mejor manera de hacerlo.