Patrones y Arquitecturas de Desarrollo de Juegos en JavaScript

Hola a todos, muchas gracias por venir a mi charla hoy. Mi nombre es Olayinka Atobele y hoy les guiaré a través del diseño y la arquitectura de juegos. Antes de comenzar, me gustaría darles una breve introducción sobre quién soy. Soy estudiante de ingeniería informática en la Universidad de Lagos. También soy ingeniero de software, escritor técnico y experto en GitHub Campus. Me apasiona mucho la diversidad e inclusión en la tecnología. Básicamente, organizo eventos y programas dirigidos hacia eso. Hoy hablaremos sobre los patrones y arquitecturas de desarrollo de juegos en JavaScript. Básicamente, les presentaré algunos patrones y arquitecturas comunes que pueden ayudarnos a acelerar el desarrollo de juegos en JavaScript. Entonces, ¿qué son exactamente el desarrollo de juegos, los patrones y las arquitecturas? Son soluciones razonables que se pueden utilizar para resolver algunos problemas comunes que enfrentamos en el desarrollo de juegos. El desarrollo de juegos puede volverse fácilmente voluminoso, especialmente a medida que escalas tus juegos, a medida que tus juegos se vuelven más grandes y poderosos, puede volverse más difícil de mantener, más difícil de expandir o extender sus características. Básicamente, lo que hacen los buenos patrones y arquitecturas es ayudarte a hacer tu código más modular, más mantenible, más extensible y, a largo plazo, incluso puedes mejorar el rendimiento de tu juego, qué tan bien funciona, qué tan bien los usuarios pueden interactuar con tus juegos y qué tan escalable es, qué tan fácil es para ti agregar otras características o incluso incorporar nuevos recursos a tus juegos. Entonces, ¿por qué es importante? Como mencioné anteriormente, el desarrollo de juegos es una tarea compleja. Es desafiante. Puede volverse fácilmente complejo. Los patrones y arquitecturas, tener buenos patrones y arquitecturas en su lugar, te ayudará a simplificar el proceso de desarrollo de los juegos y también ayudará a que la gestión del juego sea más manejable. Además, incluso podría ayudarte a prevenir algunos errores comunes, ya sabes, tener algunos errores en tus juegos. Entonces, ¿qué vamos a cubrir en esta charla? Vamos a comenzar... vamos a cubrir algunos patrones comunes e importantes en el desarrollo de juegos. Hablaremos sobre los sistemas de entidad-componente, ECS, luego hablaremos sobre los bucles de juego y luego hablaremos sobre el desacoplamiento, ya sabes, la lógica del juego del renderizado. Entonces, ahora comencemos con el sistema de entidad-componente. Entonces, el sistema de entidad-componente, ECS, es básicamente un patrón popular para el desarrollo de juegos. El sistema de entidad-componente es un patrón arquitectónico de software que representa los juegos como entidades y sus componentes como comportamiento en los datos. Esto tiene palabras grandes, así que solo para simplificarlo, voy a usar una analogía. Así que supongamos que muchos de nosotros estamos familiarizados con los juegos de Lego, los bloques de Lego, así que supongamos que estás construyendo un automóvil con bloques de Lego, ¿verdad?, entonces probablemente tendrás las ruedas, el volante, el cuerpo, todas esas diferentes partes, todos esos diferentes componentes, serán tus componentes. Básicamente, solo representan, ya sabes, el comportamiento, solo representan, como, una parte en particular, como los datos de todo tu juego, ¿verdad?, así que todo tu juego y, básicamente, las entidades son solo una colección de los componentes. Entonces, cuando, digamos, terminas de ensamblar todos tus diferentes bloques de Lego y tienes un automóvil. Entonces, en esa situación, como tu automóvil, que es básicamente, como, una colección de los diferentes componentes, es básicamente, en este caso, tu entidad, porque es solo, como, estás ensamblando diferentes componentes juntos, ¿verdad? Entonces, tus diferentes componentes que, básicamente, representan un comportamiento, como un dato en particular de tus componentes, ¿verdad? Básicamente, solo representan, ya sabes, una sola, ya sabes, pieza, como un solo dato, un solo comportamiento, y luego tu entidad es básicamente, ya sabes, una colección de diferentes componentes que, ya sabes, tal vez representen, como, una entidad en particular, un objeto en tu juego. Así que ahora, volviendo al desarrollo de juegos en el mundo de JavaScript, supongamos que estás construyendo,

digamos, un juego de video, ¿verdad? En tu juego de video, tal vez tengas un automóvil que se está moviendo o algo así. En ese caso, digamos que tu automóvil va a tener, ya sabes, velocidad, ¿verdad?, vas a tener una velocidad, vas a tener una posición, como, donde se encuentra actualmente tu automóvil. Todas esas dos cosas son un poco tus componentes, ¿verdad?, tu velocidad y tu posición, son componentes. Pero el automóvil en sí, que va a ser, ya sabes, como, ya sabes, un cierto automóvil va a tener una velocidad, va a tener una posición, va a tener un color, el automóvil en sí va a ser una entidad, porque básicamente es solo, ya sabes, una colección de diferentes componentes reunidos. Entonces, básicamente, ese es el concepto principal detrás de ECS. Básicamente queremos separar, ya sabes, diferentes, quieres separar el diferente[56] comportamiento y data en tus juegos en componentes. Y de esa manera, es fácil para ti, es básicamente fácil para ti, ya sabes, elegir cualquier componente que necesites. Ya sabes, al construir una entidad o para crear un objeto en tu juego, es fácil para ti, ya sabes, simplemente elegir diferentes componentes, ya sabes, como parte de las entidades. Y básicamente como, ya sabes, construir un nuevo, ya sabes, un nuevo objeto para tu juego, como directamente de la caja. Entonces, y básicamente, las entidades son identificadores únicos, como mencioné, y los componentes son solo data que se adjuntan a las entidades. Ahora, hablando de los sistemas, los sistemas son, por otro lado, básicamente solo una colección de entidades y componentes que realizan una tarea específica. Entonces, solo para, nuevamente, usando esa analogía. Supongamos que en una situación en la que tienes, tal vez, quieres realizar una tarea, digamos, en el caso de un juego de video, ¿verdad?, donde tienes, como, un automóvil, tu juego de video y quieres, básicamente, digamos, mover el automóvil. En esa situación, el único componente que realmente necesitas para realizar esa tarea es, digamos, posición y velocidad, ¿verdad? En este caso, probablemente no tienes ningún interés en, ya sabes, tal vez el color del automóvil o qué tan grande es el automóvil porque no afectan la tarea particular que deseas realizar en ese momento específico, ¿verdad? Entonces, básicamente, lo que hace el sistema es, básicamente, como, funciones que te ayudan a, como, separar, como, tareas específicas y los componentes específicos que están relacionados para que realmente puedas realizar la tarea. Y, básicamente, a largo plazo, lo que hace es que facilita, ya sabes, gestionar tu código, hace que tu código sea más manejable. Entonces, ¿cómo funciona ECS? Las entidades se crean y destruyen en tiempo de ejecución por tu motor de juego. Las entidades son básicamente solo objetos en tus juegos. Agregas componentes, tu motor de juego agrega, ya sabes, o elimina componentes de ellas en tiempo de ejecución. Eso es de tus entidades, ¿verdad? Y luego tus sistemas se actualizan regularmente, ya sabes, según las operaciones que realizas o que el usuario realiza dentro de los juegos. Entonces, ¿por qué ECS es tan popular, ya sabes, es una arquitectura de desarrollo de juegos muy popular, ¿verdad? ¿Y por qué es así? Es una buena elección para el desarrollo de juegos porque, en primer lugar, promueve la reutilización de código, ¿verdad? Como explicamos anteriormente, tienes, ya sabes, componentes específicamente definidos, lo que significa que puedes agarrar fácilmente un componente y adjuntarlo a diferentes entidades, no solo a un tipo de entidad. Puedes puedes crear fácilmente un objeto de juego modificado. Básicamente, todo lo que tienes que hacer es, ya sabes, definir una entidad de juego y simplemente crear una nueva, adjuntar algunos componentes a ella. Y también puede ayudar a admitir un acceso eficiente a los data, como, ya sabes, separación de, como, todos tus data en componentes bien definidos. Y se puede escalar fácilmente, ya sabes, a medida que tu juego se vuelve más grande, puedes escalarlo fácilmente. Entonces, solo para agregar, como, un pequeño ejemplo de código, solo para darle sentido a lo que he estado hablando hasta ahora. Entonces, en este ejemplo aquí, puedes ver que tienes, tienes un componente de posición, tienes un componente de velocidad. Y tu componente de posición, puedes ver, básicamente, solo tienes tu eje X y eje Y, ¿verdad? Y tu componente de velocidad, también tienes tu eje X y Y. Y luego tienes tu sistema de movimiento. Y esos, okay, volviendo atrás. Los componentes, como,

verás, básicamente, no estoy haciendo nada más que representar un componente. Un dato particular en tu juego, y si observas tu sistema de movimiento, eso es básicamente mover una entidad. Entonces, básicamente, solo está llamando a los componentes que necesita para realizar la tarea específica, que es moverse. Entonces, básicamente, solo está llamando a la posición y velocidad. Así que, básicamente, este es solo un pequeño ejemplo de ECS en código. Pasando a otro patrón muy interesante en el desarrollo de juegos, que son los bucles de juego, el arte de cada juego. Se le llama el arte de cada juego porque, básicamente, se utiliza en casi todos los juegos que desarrollarías, ¿verdad? Y, básicamente, ¿qué es un bucle de juego? Imagina que estás jugando, digamos, un juego de persecución, donde básicamente repites algunas secuencias una y otra vez. Eso es básicamente un bucle de juego. Es una secuencia repetitiva de instrucciones que controla el flujo del juego. Y, literalmente, en casi todos los juegos que juegas, eso es lo que haces. Haces algo, ya sabes, algo sucede en tu pantalla. Luego, en algún momento, ya sea inmediatamente o más adelante en el juego, vuelves a hacer lo mismo. Eso es literalmente lo que es un bucle de juego. Y es responsable de actualizar el estado de tu juego, volver a renderizar tu juego y manejar las entradas del jugador del juego. Entonces, básicamente, ¿cómo funciona? Un bucle de juego básicamente consta de diferentes pasos. El primer paso son las entradas. Por ejemplo, supongamos que estoy jugando un juego de video. Nuevamente, donde, digamos, tengo un automóvil que se mueve en la pantalla, y para mover el automóvil, tengo que presionar una tecla en mi teclado. Digamos, tal vez, M para mover. Presiono M. En esa situación, eso es una entrada, ¿verdad? El juego básicamente recibe una entrada de mi parte. Y el siguiente paso es las actualizaciones. Dependiendo de lo que haya presionado, estoy presionando en esta analogía que estamos usando actualmente del juego de video. Estoy presionando M. El juego recibe la tecla M de mí. Y tan pronto como recibe las entradas de mi parte, sabe que tiene que, ya sabes, actualizar el estado del juego. En este caso, probablemente sea la posición, ¿verdad? Ese es el siguiente paso que ocurre, las actualizaciones. El siguiente paso que ocurre es el renderizado. Entonces, he, ya sabes, actualizado algo en mi juego. He actualizado el estado del juego. Entonces, lo siguiente es que el juego mismo renderice, ya sabes, cambie lo que estoy viendo en la pantalla o mueva el automóvil desde la posición actual hasta

la nueva posición actualizada. ¿Y luego esperas, verdad? Básicamente, esperas un tiempo, ya sabes, para que el bucle comience de nuevo una y otra vez, ¿verdad? Entonces, esa es básicamente toda la idea de un bucle de juego. Y luego, al construir un juego que involucra el uso de bucles de juego, tienes diferentes arquitecturas que puedes utilizar. Una de las arquitecturas es la de paso de tiempo fijo. Esto básicamente significa que si volvemos a lo que hablamos antes, ya sabes, esperar y el número, y la cantidad de tiempo que esperas antes de la siguiente iteración del bucle. En el paso de tiempo fijo, la arquitectura utiliza básicamente una cantidad fija de tiempo para cada iteración. Eso significa que espera, ya sabes, un tiempo especificado, un tiempo fijo antes de comenzar la siguiente iteración cada vez para todas las iteraciones. Y el paso de tiempo variable significa que permite que el tiempo cambie en cada iteración. Y eso puede variar. Puede variar dependiendo de tal vez lo que el usuario escriba. Puede variar dependiendo de tal vez la posición de los objetos dentro del juego y varios otros factores. Y la tercera arquitectura, que en mi opinión es probablemente la más utilizada, básicamente combina ambas de las dos arquitecturas que mencionamos anteriormente. Entonces, dependiendo de la situación del juego y el tipo de lógica detrás del juego, básicamente, el tiempo entre cada iteración puede ser fijo o puede variar. Así que sí, solo un pequeño ejemplo de código. En este ejemplo, estás obteniendo, básicamente siguiendo los pasos que mencionamos, ¿verdad? Estás obteniendo las entradas del jugador. Estás actualizando el estado del juego en función de las entradas. Luego estás

renderizado del juego. Luego duermes, luego, ya sabes, comienzas de nuevo. Entonces, ahora, a continuación, otra arquitectura, otro patrón de diseño del que vamos a hablar es desacoplar la lógica del juego del renderizado, que es un patrón que básicamente te ayuda a lograr un mejorperformance y flexibilidad en tu juego. Vale. Entonces, ¿por qué es importante desacoplar la lógica del juego del renderizado? Básicamente, la lógica del juego y el renderizado son dos cosas diferentes, ¿verdad? Entonces hay algún código detrás de escena que representa lo que ves en la pantalla. Entonces detrás de la pantalla tienes cierta información específica que estás cambiando según la acción del usuario, ¿verdad? Usando el ejemplo del juego de video del que hemos estado hablando, entonces podrías tener tu posición, tienes tu velocidad y en este sentido, cuando el usuario realiza una acción, estás actualizando esto según la acción del usuario, ¿verdad? Esa es la lógica del juego, pero por otro lado, básicamente lo que el usuario ve en su pantalla es solo el coche moviéndose, el coche en una posición particular, eso es el renderizado. Y esas son dos cosas, ya sabes, dos cosas diferentes, ¿verdad? Porque la lógica del juego está básicamente relacionada con las reglas del juego, el comportamiento del juego, cómo cambias, cómo se actualiza ladata dentro del juego, mientras que el renderizado es, ya sabes, principalmente sobre cómo mostrar o representar estos juegos en la pantalla, y luego, cuando desacoplas eso, ¿verdad?, cuando separas estas dos preocupaciones, lo que haces es mejorar elperformance y la flexibilidad de tu juego. Entonces, básicamente, ¿cómo se puede lograr, verdad? Entonces, una forma de lograr esto es, antes de hablar de cómo se puede lograr, solo para dar más contexto, solo para dar más contexto sobre cómo puede ser útil desacoplar los dos juegos, ¿verdad? Así que supongamos, nuevamente una analogía, oh, usemos una analogía nuevamente, así que supongamos que estás jugando un juego donde, digamos que estás corriendo en un bosque, ¿verdad? Entonces, en ese tipo de situación, lo que ves es, el bosque con las hojas, el color de las hojas y todo, ¿verdad? Y luego, por otro lado, que es el renderizado, ¿verdad? Que es el renderizado del juego. Y por otro lado, tienes la lógica, que básicamente es alguna información detrás de escena sobre cómo te mueves dentro del bosque y todo. Y básicamente lo que eso hace, lo que, ya sabes, separar estas dos cosas hace es que podrías cambiar fácilmente, digamos, cómo se ve tu juego sin necesariamente cambiar, afectar cómo funciona tu juego, si tiene sentido, ¿verdad? Entonces, supongamos que quiero cambiar, tal vez inicialmente estaba construyendo mi bosque con la suposición de que es verano, ¿verdad? O tal vez más adelante en el juego, digo, quiero cambiar el color de las hojas en el bosque. Quiero que parezca que están cayendo. Quiero que parezca que es otoño, por ejemplo. Entonces, en esa situación, estás cambiando básicamente la apariencia de tu juego, pero no necesariamente estás cambiando la lógica detrás del juego o las reglas detrás del juego. Entonces, en ese tipo de situación, tener, ya sabes, una separación clara de tu renderizado y una separación clara de tu renderizado y tu lógica va a ser útil porque eso significa que en esa situación, todo lo que necesitas hacer es ir a la parte particular de tu código que se enfoca en el renderizado, ¿verdad? No necesitas cambiar nada que tenga que ver con la lógica. Y esto va a facilitar mucho el desarrollo para ti, mucho más mantenible. ¿Cómo se puede lograr? La forma en que se puede lograr es que tienes un hilo separado para la lógica del juego, tienes un hilo separado para el renderizado del juego, y básicamente incluso esto en sí mismo, tener un hilo separado incluso va a mejorar la eficiencia, elperformance de tu juego, porque eso significa que ninguno de ellos necesita esperar al otro para realizar la tarea. Puedes estar actualizando la lógica de tu juego independientemente de lo que se esté representando actualmente en tu pantalla o lo que el usuario vea en tu juego. Entonces, básicamente, usar un hilo separado para tu lógica y tu renderizado es una forma en que puedes lograr este mecanismo de desacoplamiento. Otra forma en que podrías hacerlo es que podrías tener tal vez un sistema que pase mensajes entre la lógica del juego y el motor de renderizado. Entonces podrías tener alguna forma de pasar información entre estas dos partes separadas del juego. Pero incluso aunque estén separados, aún necesitas que trabajen juntos. Aún necesitas que tu motor de renderizado obtenga información sobre el estado particular del juego, que es la lógica del juego. Entonces, básicamente eso es lo que se entiende por tener un sistema entre ellos que básicamente pasa información entre las dos partes de tu juego. Y también podrías tener un enfoque basado en componentes para representar el objeto del juego. Y esto es de alguna manera, esto es similar al ECS del que hablamos anteriormente, donde tenemos un componente para representar los diferentes detalles de un juego, y luego juntamos diferentes componentes para representar objetos dentro de tu juego. Y esto es como, ya sabes, decirte cómo cada uno de estospatterns de juego no son, ya sabes, necesariamente separados. Todos ellos, ya sabes, van de la mano entre sí para, ya sabes, darte un código más mantenible, una forma más mantenible de trabajar dentro de tu proceso de desarrollo degame development.

Entonces, ¿cuáles son los beneficios de desacoplar la lógica del juego del renderizado? Entonces, hemos tocado brevemente algunos de los beneficios anteriormente. Entonces, el mejor, el primer, lo siento, el primer beneficio es que mejora elperformance de tu juego. Como mencioné antes, ya sabes, tener diferentes hilos para tu lógica, para tu renderizado, desacoplar estas dos cosas esencialmente te ayudará a mejorar elperformance porque cada uno de ellos puede, ya sabes, ejecutarse de forma independiente de los demás. Entonces, podrías, ya sabes, estar, o podrías estar actualizando la lógica de tu juego, ya sabes, el estado de tu juego, ya sabes, sin tener que preocuparte por, ya sabes, cómo se ve el juego para el usuario, ¿verdad? Y por otro lado también, podrías, ya sabes, podrías estar cambiando, como, la posición o la apariencia de tu juego sin necesariamente, ya sabes, tener que preocuparte, como, tener que preocuparte por, ya sabes, la lógica,

como, qué está sucediendo detrás de escena. Entonces, tener, como, esta clara separación de responsabilidades va a mejorar el rendimiento del juego. Lo siguiente es que va a aumentar la flexibilidad, por lo que te ayudará a hacer tu juego más flexible porque básicamente puedes, tal vez, ya sabes, agregar una nueva característica, agregar un nuevo estado a tu juego sin preocuparte mucho por, ya sabes, cambiar el rendimiento, cambiar la apariencia del juego. Como mencioné antes usando la, ya sabes, analogía del bosque, podrías fácilmente, ya sabes, agregar un nuevo, no sé, tal vez un nuevo árbol a tu bosque sin pensar mucho en, oh, cómo va a cambiar esto cómo se mueve mi jugador dentro del bosque. Porque en esa situación, esas dos cosas están, ya sabes, separadas entre sí, ¿verdad? Y también te va a ayudar a depurar fácilmente tu juego, ¿verdad? Entonces, ya sabes, si te encuentras en una situación donde, ya sabes, tal vez el jugador no está..tal vez el juego no está..la lógica no está, ya sabes, cambiando como quieres que lo haga, ¿verdad? Entonces, podrías.. podrías, ya sabes, enfocarte en una cosa, ¿verdad? Puedes simplemente enfocarte en, ya sabes, solo la parte de la lógica del juego sin necesariamente tocar..sin necesariamente tocar la parte de representación. Y lo que eso va a hacer es que va a facilitar la depuración de tus juegos. Así que, solo otro truco. Otro ejemplo de código de eso. Entonces, puedes ver en este ejemplo, tienes, ya sabes, diferentes funciones. Tienes una función para actualizar tu juego. Tienes una diferente para representar el juego, ¿verdad? Y luego..entonces, cada una de ellas está básicamente separada de las demás. Y, ya sabes, volviendo a nuestra explicación anterior del bucle del juego. Puedes ver que el bucle del juego recibe la entrada. Luego actualizas la lógica del juego. Luego representas el juego. Entonces, esto separa, como, cada una de las responsabilidades. Entonces, tienes una función que básicamente se preocupa solo por, ya sabes, cómo se ve el juego en la pantalla. Y tienes una que, básicamente, solo se preocupa de cómo se mueve tu jugador dentro del juego. Entonces, sí. Ahora, pasando a la conclusión, ya sabes, resumiendo todo lo que hemos hablado hoy. Entonces, ¿cuáles son los beneficios de usar estos patrones y arquitecturas? Como mencioné antes, esto va a mejorar el rendimiento de los juegos. Usar patrones bien diseñados dentro de tus juegos, usar arquitecturas bien definidas va a ayudar a los usuarios, ya sabes, a jugar tus juegos de una manera mucho más fácil, de una manera más rápida y escalable. Esto va a aumentar la flexibilidad de tus juegos. Entonces, eso significa que tus juegos se vuelven más versátiles. Puedes agregar nuevas cosas fácilmente a tu juego. Puedes mantener tu juego fácilmente. Y también va a mejorar tu proceso de desarrollo. Porque al usar patrones y arquitecturas bien diseñados, ¿verdad?, es más fácil incluso entender qué está sucediendo dentro de tu juego, y a largo plazo, te facilitará agregar más cosas a tu juego, extender fácilmente tu juego como desees. Entonces, ¿qué hemos aprendido? Hemos aprendido sobre los diferentes patrones y arquitecturas de desarrollo de juegos. Hemos hablado sobre cómo utilizar estas arquitecturas para crear mejores juegos. Y también hemos hablado sobre la importancia de separar la lógica del juego del renderizado del juego. Entonces, muchas gracias por escuchar esta charla. Si quieres conectarte conmigo, básicamente discutir más sobre la charla, cualquier opinión que tengas, puedes encontrarme en cualquiera de las plataformas de redes sociales. Sí, muchas gracias por escuchar.