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 voy a guiarles 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, experto del campus de GitHub. Soy muy apasionado por la diversidad e inclusión en tecnología. Básicamente, organizo eventos y programas dirigidos a eso.

Hoy, vamos a hablar sobre patrones de desarrollo de juegos y arquitectura en JavaScript. Básicamente, voy a introducirles a algunos patrones y arquitecturas comunes que pueden ayudarnos a acelerar el desarrollo de juegos en JavaScript.

Entonces, ¿qué son exactamente los desarrollos de juegos, patrones y arquitecturas? Básicamente, son soluciones razonables que puedes usar para resolver algunos problemas comunes que enfrentamos en el desarrollo de juegos. El desarrollo de juegos puede volverse fácilmente voluminoso, y especialmente a medida que amplías tus juegos, a medida que tus juegos se vuelven más grandes y más poderosos, puede volverse muy fácil que se vuelva más difícil de mantener, más difícil de expandir o extender sus características. Básicamente, lo que tener buenos patrones y arquitecturas hace es que te ayuda a hacer tu código más modular, más mantenible, más extensible y a largo plazo, incluso podrías 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é antes, 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 desarrollar los juegos y también ayudará a hacer 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 con... básicamente vamos a cubrir algunos patrones comunes e importantes en el desarrollo de juegos. Entonces, vamos a hablar sobre sistemas de componentes de entidad, ECS, luego vamos a hablar sobre bucles de juego, luego vamos a hablar sobre desacoplar, ya sabes, la lógica del juego del renderizado. Entonces, ahora comencemos con el sistema de componentes de entidad.

Entonces, el sistema de componentes de entidad, ECS, es básicamente un patrón popular para el desarrollo de juegos. Entonces, el sistema de componentes de entidad es un patrón arquitectónico de software que representa el juego como entidades y sus componentes como comportamiento sobre datos. Así que, estas son solo palabras grandes, así que solo para desglosarlo, voy a usar una analogía. Así que, asumamos que, ya sabes, muchos de nosotros probablemente estamos familiarizados con los juegos de Lego, los bloques de Lego, así que asumamos que estás construyendo un coche con un bloque de Lego, ¿verdad?, así que probablemente vas a tener las ruedas, las ruedas, el volante, el cuerpo, todas esas diferentes partes, todos esos diferentes componentes, van a ser tus componentes. Básicamente, solo representan, ya sabes, el comportamiento, solo representa, como, una parte particular, como tus datos de todo el juego, ¿verdad? , así que todo tu juego y, básicamente, las entidades son solo una colección de los componentes. Así que, cuando, digamos, terminas, ya sabes, ensamblando todos tus diferentes bloques de Lego y tienes un coche. Entonces, en esa situación, como, donde tu coche, que es básicamente, como, ya sabes, una colección de los diferentes componentes es básicamente, como, en este caso, tu entidad, así que, porque es solo, como, ya sabes, estás ensamblando diferentes componentes juntos, ¿verdad?. Así que, tus diferentes componentes que, básicamente, como, representan un comportamiento, como un dato particular de tus componentes, ¿verdad?.

En tu videojuego, tal vez tengas un coche que se está moviendo o algo así. En ese caso, digamos, tu coche va a tener, ya sabes, velocidad, la rapidez, ¿verdad?, vas a tener una rapidez, vas a tener una posición, como, donde tu coche actualmente está. Todas esas dos cosas son como tus componentes, ¿verdad?, tu velocidad y tu posición, son componentes.

Pero el coche en sí, que es, ya sabes, va a ser como, ya sabes, un cierto coche va a tener una velocidad, va a tener una posición, va a tener un color, el coche en sí va a ser una entidad, porque es básicamente solo, ya sabes, una colección de diferentes componentes reunidos. Así que básicamente, ese es el concepto principal detrás de ECS. Básicamente queremos separar, ya sabes, diferentes, quieres separar los diferentes comportamientos y datos 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. Sabes, al construir como una entidad o para desglosar 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, construiste 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 datos que están adjuntos a las entidades. Entonces, ahora hablando de sistemas, los sistemas son, por otro lado, básicamente solo una colección de entidades y componentes que realizan una tarea específica. Así que, solo para, de nuevo, usando esa analogía. Así que, supongamos que en una situación donde tienes tal vez, quieres realizar una tarea, digamos en el caso de un videojuego, ¿verdad?, donde tienes como un coche, tu videojuego y quieres básicamente, digamos, mover el coche. Entonces, en esa situación, el único componente que realmente necesitas para realizar esa tarea es, digamos, posición y velocidad, ¿verdad?

Entonces, en este caso, probablemente no tengas interés en, ya sabes, tal vez el color del coche o qué tan grande es el coche porque no afectan la tarea particular que quieres realizar en ese momento particular, ¿verdad? Entonces, básicamente, lo que hacen los sistemas es que son básicamente solo como, una especie de, funciones que te ayudan, como, a separar, como, tareas específicas y los ciertos componentes que están relacionados para que realmente realices la tarea. Y, básicamente, a largo plazo, lo que hace es que hace que sea más fácil para ti, ya sabes, gestionar tu código, hace que tu código sea, como, más manejable. Entonces, y cómo, básicamente, cómo funciona ECS? Entonces, las entidades se crean y destruyen en tiempo de ejecución por tu motor de juego. Entonces, las entidades son básicamente solo objetos en tus juegos. Agregas componentes, tu motor de juego agrega, ya sabes, o elimina componentes de él en tiempo de ejecución. Eso es de tus entidades, ¿verdad? Y luego tus sistemas se actualizan a intervalos regulares, ya sabes, dependiendo de las operaciones que realices o que el usuario realice dentro de los juegos. Entonces, ¿por qué es ECS una arquitectura de desarrollo de juegos 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 uno, promueve la reutilización de código, ¿verdad? Quiero decir, como explicamos antes, tienes, ya sabes, componentes específicamente definidos, lo que significa, como, que puedes fácilmente tomar un componente y adjuntarlo a diferentes entidades, en realidad, no solo a un tipo de entidades. Puedes puedes fácilmente crear un objeto de juego modificado.

Como, básicamente, todo lo que tienes que hacer es simplemente, ya sabes, defines la entidad del juego y simplemente creas una nueva, adjuntas algunos componentes a ella. Y también puede ayudar a soportar el acceso eficiente a datos, al igual que, ya sabes, la separación de, como, todos tus datos en componentes bien definidos. Y puede ser fácilmente escalado, ya sabes, a medida que tu juego se hace más grande, puedes escalarlo fácilmente. Así que, solo para añadir, como, un pequeño ejemplo de código, solo para dar sentido a lo que he estado hablando hasta ahora. Así que, 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, como, básicamente, solo tienes tu eje X y Y, ¿verdad? Y tu componente de velocidad, también, tienes tu eje X y Y.

Un dato particular en tu juego, y si miras tu sistema de movimiento, entonces, básicamente, eso es básicamente solo mover una entidad. Entonces, es básicamente solo, y todo lo que está haciendo es llamar a los componentes que necesita para realizar la tarea específica, que es mover. Entonces, es básicamente solo llamando a posición y velocidad. Entonces, básicamente, este es solo un pequeño ejemplo de ECX en código.

Entonces, pasando a otro patrón muy interesante en el desarrollo de juegos, que es Game Loops, el arte de cada juego. Entonces, se llama el arte de cada juego porque, básicamente, se utiliza literalmente en casi todos los juegos que desarrollarías, ¿verdad? Y entonces, básicamente, ¿qué es Game Loop? Entonces, imagina que estás jugando, digamos, un juego de etiqueta, donde básicamente repites algunas secuencias una y otra vez. Eso es básicamente Game Loop. Entonces, es básicamente 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, sabes, algo sucede en tu pantalla. Luego, en algún momento, ya sea inmediatamente o más tarde en el juego, haces lo mismo otra vez. Entonces, eso es literalmente lo que es Game Loop. Y es responsable de actualizar el estado de tu juego, de volver a renderizar tu juego y de manejar las entradas del jugador del juego.

Entonces, básicamente, ¿cómo funciona? Entonces, Game Loop básicamente consiste en diferentes pasos. Entonces, el primer paso son las entradas. Entonces, por ejemplo, supongamos que estoy jugando un videojuego. Nuevamente, donde, digamos, tengo un coche que se mueve en la pantalla, y para mover el coche, 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 está recibiendo una entrada de mí. Y el siguiente paso es actualizaciones. Entonces, dependiendo de lo que he presionado, estoy presionando en esta analogía que estamos actualmente usando del videojuego. Entonces, estoy presionando M. El juego recibe la tecla M de mí. Y tan pronto como recibe las entradas de mí, sabe que tiene que, ya sabes, actualizar el estado del juego. En este caso, eso es probablemente la posición, ¿verdad? Entonces, ese es el siguiente paso que sucede, actualizaciones. El siguiente paso que sucede es renderizar. Entonces, he, ya sabes, actualizado algo en mi juego. Entonces, he actualizado el estado del juego.

Y luego dormir, ¿verdad? Básicamente, esperas un tiempo para que, ya sabes, el loop comience una y otra vez, ¿verdad? Entonces, esa es básicamente toda la idea de un game loop. Y luego, al construir un juego que involucra el uso de game loops, tienes algunas diferentes arquitecturas que usas. Entonces, una de las arquitecturas, fixed time step architecture. Entonces, eso básicamente significa que si volvemos a esto donde hablamos sobre, ya sabes, dormir y el número, y la cantidad de tiempo que esperas antes de la siguiente iteración de un loop. Entonces, en fixed time step, la arquitectura básicamente utiliza una cantidad fija de tiempo para cada iteración. Entonces, eso significa que duerme bien. Ya sabes, es un tiempo especificado, un tiempo fijo antes de que comience la siguiente iteración cada vez para todas las iteraciones. Y variable time step significa que permite que el tiempo cambie para cada iteración. Y eso podría variar. Podría variar dependiendo de um tal vez lo que tu usuario escriba. Podría 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, probablemente sea la más utilizada, es básicamente, entonces esto básicamente solo combina ambas de las dos arquitecturas de las que hablamos 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 sería fijo o podría variar. Así que sí, solo un pequeño ejemplo de código. Entonces, podrías en este ejemplo, estás obteniendo, básicamente sigue los pasos que hemos mencionado, ¿verdad? Estás obteniendo las entradas de un jugador. Estás actualizando el estado del juego basado en las entradas. Luego estás renderizando el juego. Luego duermes, luego, ya sabes, comienzas de nuevo.

Entonces, ahora, otra arquitectura, otro patrón de diseño del que vamos a hablar es separar la lógica del juego de la renderización, que es un patrón que básicamente te ayuda a lograr un mejor rendimiento y flexibilidad en tu juego.

Bien. Entonces, ¿por qué es importante separar la lógica del juego de la renderización? Básicamente, la lógica del juego y la renderización son dos cosas diferentes, ¿verdad? Así que hay algún código detrás de escena que representa lo que ves en la pantalla. Así que detrás de la pantalla tienes alguna información particular que estás cambiando en función de la acción del usuario, ¿verdad? Usando el ejemplo del videojuego del que hemos estado hablando, podrías tener tu posición, tienes tu velocidad, y en este sentido, cuando el usuario realiza una acción, estás actualizando esto en función de la acción del usuario, ¿verdad? Así que esa es la lógica del juego, pero por otro lado, básicamente lo que el usuario solo ve en su pantalla es solo el coche moviéndose en una posición particular, así que eso es renderización. Y esas son dos, ya sabes, dos cosas diferentes, ¿verdad? Porque la lógica del juego básicamente se ocupa de las reglas del juego, el comportamiento del juego, cómo cambias, cómo se actualizan los datos dentro del juego, mientras que la renderización es, ya sabes, principalmente sobre, ya sabes, cómo realmente muestras o renderizas estos juegos en la pantalla, y luego cuando separas esos, ¿verdad?

, cuando de alguna manera, haces que estas dos preocupaciones sean separadas lo que haces es mejorar el rendimiento y la flexibilidad de tu juego. Entonces, básicamente, ¿cómo se puede lograr, verdad? Entonces, una forma en que esto se puede lograr es que, antes de siquiera hablar sobre cómo se puede lograr, solo para dar más contexto sobre, solo para dar más contexto sobre lo útil que puede ser separar los dos juegos, ¿verdad? Así que asumamos, analogía de nuevo, oh, usemos una analogía de nuevo, así que asumamos que estás jugando un juego donde, digamos que estás corriendo en un bosque, ¿verdad? Así que 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 la renderización, ¿verdad? Que es la renderización del juego. Y por otro lado, tienes la lógica, que es básicamente, alguna información detrás de escena sobre tal vez cómo te mueves dentro del bosque y todo. Y básicamente lo que hace eso, 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 opera tu juego, si eso tiene sentido, ¿verdad? Así que, asumamos 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, estoy como, oh, quiero cambiar el color de mis hojas en el bosque. Quiero hacer que parezca que están cayendo. Quiero hacer que parezca que es otoño, por ejemplo. Así que, en esa situación, estás básicamente cambiando el aspecto de tu juego, pero no estás necesariamente cambiando la lógica detrás del juego o las reglas detrás del juego. Así que, en ese tipo de situación, tener, ya sabes, una separación clara de tu renderización y una separación clara de tu renderización 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 centra en los derechos de renderización. No necesitas cambiar nada que tenga que ver con la lógica. Y esto va a hacer que el desarrollo sea mucho más fácil 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 la renderización del juego, y básicamente incluso esto en sí mismo, tener un hilo separado va a incluso mejorar la eficiencia, el rendimiento de tu juego, porque eso significa que ninguno de ellos necesita esperar a que el otro realice la tarea. Puedes estar actualizando la lógica de tu juego independientemente de lo que se esté renderizando actualmente en tu pantalla o para que el usuario lo vea en tu juego. Así que básicamente, usar un hilo separado para tu lógica y tu renderización es una forma en que puedes lograr este mecanismo de separación. Así que 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 renderización. Así que podrías tener alguna forma de pasar información entre estas dos partes separadas del juego. Pero incluso aunque están separadas, todavía necesitas que trabajen juntas. Todavía necesitas que tu motor de renderización obtenga alguna información sobre el estado particular del juego, que es la lógica del juego. Así que básicamente eso es lo que quieres decir al tener un sistema entre ellos que básicamente pasa información entre las dos partes de tu juego. Y luego 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 juntas diferentes componentes para realmente representar objetos dentro de tu juego. Y esto es como, ya sabes, diciéndote cómo cada uno de estos patrones de juego no son, ya sabes, necesariamente como separados.

Todos ellos de alguna manera, como, trabajan de la mano entre sí para, ya sabes, darte un código más mantenible, una forma más mantenible de realmente trabajar dentro de tu proceso de desarrollo de juegos. Entonces, ¿cuáles son los beneficios de separar la lógica del juego de la renderización? Así que, hemos tocado brevemente algunos de los beneficios anteriormente. Así que, el mejor, el primer, perdón, el primer beneficio es que mejora el rendimiento de tu juego. Así que, como mencioné anteriormente, ya sabes, tener, como, diferentes hilos para tu lógica, para tu renderización, separar estas dos cosas esencialmente te va a ayudar a mejorar el rendimiento porque cada uno de ellos puede, ya sabes, ejecutarse independientemente de cada uno. Así que, podrías, ya sabes, estar, o podrías estar actualizando la lógica de tu juego, ya sabes, eso es como el estado de tu juego, ya sabes, sin tener que preocuparte por, ya sabes, cómo se ve el juego para el usuario, ¿verdad?

Entonces, tener, como, esta clara separación de preocupaciones va a, como, mejorar el rendimiento del juego. Lo siguiente es, va a aumentar la flexibilidad, por lo que te ayudaría 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 siquiera preocuparte mucho por, ya sabes, cambiar el rendimiento, cambiar la apariencia del juego. Como mencioné anteriormente usando la analogía del bosque, podrías fácilmente, ya sabes, tal vez agregar un nuevo, no sé, tal vez un nuevo árbol a tu bosque sin pensar mucho en, oh, ¿cómo va esto a cambiar 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 enfrentas a 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, ¿verdad? Entonces, podrías..podrías, ya sabes, simplemente enfocarte en una cosa, ¿verdad? Puedes simplemente enfocarte en, ya sabes, solo la parte de la lógica del juego sin necesariamente tocar la..sin necesariamente tocar la parte de la ocurrencia. Y lo que eso va a hacer es que va a facilitarte la depuración de tus juegos. Así que, solo otro truco. Otro ejemplo de código de eso. Entonces, podrías ver en este ejemplo, tienes, ya sabes, diferentes funciones. Tienes una función para actualizar tu juego. Tienes una diferente para renderizar el juego, ¿verdad? Y luego..así que, cada una de ellas está básicamente separada de la otra. Y, ya sabes, solo para volver a nuestra explicación anterior del bucle del juego. Entonces, puedes ver que el bucle del juego está obteniendo la entrada. Luego estás actualizando la lógica del juego. Luego estás renderizando el juego. Así que esto de alguna manera separa, como, cada una de las preocupaciones. Así que tienes una función que básicamente solo se preocupa por, ya sabes, cómo se ve el juego en la pantalla. Y tienes una que, todo lo que básicamente le preocupa es cómo se mueve tu jugador dentro del juego. Así que, sí.