Construyendo Juegos de Pensamiento en Equipo en Synthesis

Hola a todos. Mi nombre es Vivek Vidyasagaran. Y hoy voy a hablar sobre la creación de juegos de pensamiento en equipo en Synthesis. Así que, primero que nada, ¿qué es Synthesis? Y aquí hay un video rápido para explicar el concepto.

Dos. Uno. ¿A dónde vamos chicos? Necesito que todos estén aquí. Esperen chicos, creo que sé lo que está pasando. No se trata de la longitud de la línea, sino de la ruta más rápida para volver al planeta. ¿Cuál es tu idea, Tag? Sí, describiría el púrpura. Tiene el beneficio estratégico más grande para nosotros. Oh sí, sí, sí. Haruun tuvo una idea increíble. Oh Dios mío. Este es el mejor lugar para Tag. Vamos muy rápido. Queríamos correr un riesgo extremo o queríamos jugar seguro. Phoenix bloquea la flecha. Vamos Phoenix. Adelante. La cadena está funcionando. La cadena. Adelante. Adelante. Oh, esto va bien. Sí, sí. Sí. Tristan, Tristan. ¿Qué estás haciendo? Oh Dios mío, eso es suerte. Somos los primeros.

Lo estamos haciendo muy bien en esto. Hola, Rahat. Hola, hola. Hay otros invasores. Otros invasores. ¿Qué? ¡No! No, deberíamos volver todo el camino atrás. Oh sí, cuando lleguemos aquí. Sí. Esto va a ser increíble. Oh sí, esto es genial. Tenemos a este mocoso, chicos. Tenemos esto, chicos. Vamos a ganar esto. Y esto no es una escuela, es mejor que una escuela. Genial.

Entonces, eso es Synthesis. Esencialmente, es un programa de enriquecimiento para niños. Y como viste allí, todos están jugando juntos y aprendiendo sobre trabajo en equipo, colaboración y cosas así. En pocas palabras, lo que estamos tratando de hacer es construir una generación de supercolaboradores. Estas son personas que pueden trabajar juntas en un equipo y lograr resultados realmente buenos.

Estos son algunos de los juegos que tenemos en producción en este momento. Puedes ver que es una amplia variedad de géneros y estilos de juego. Tenemos juegos deportivos, tenemos juegos de construcción de ciudades. Y por lo tanto, necesitamos un marco que pueda construir todo esto rápidamente. Cuando construimos el estudio de juegos de Synthesis y hablamos sobre en qué queremos enfocarnos nos dimos cuenta de que nuestro producto es único y que necesitamos un conjunto específico de restricciones de diseño para poder construir los mejores juegos.

Así que llegamos a estos principios. Asegurarse de que cada jugador tenga un impacto, la colaboración multiplique ese impacto, permitir a los jugadores tomar decisiones complejas y consecuentes, proporcionar oportunidades para reflexionar e iterar, y equilibrar cuidadosamente la mente, la boca y las manos de cada jugador. Puedes ver que estas son principalmente restricciones de design. Y esa fue una idea clave que tuvimos, que lo que realmente nos limita aquí es el design. No estamos tratando de hacer los juegos más gráficamente complejos o agregar una IA muy potente o algo por el estilo.

Simplemente queremos crear juegos que cumplan nuestros objetivos de aprendizaje y sean divertidos. Como ejemplo, este es uno de nuestros primeros juegos con los que lanzamos la compañía. Y puedes ver que es bastante simple. Y luego, una vez que establecimos estos principios y rediseñamos el juego con eso en mente, obtuvimos Proxima v2. Entonces puedes ver, visualmente, obviamente, se ve mucho mejor. Pero realmente, lo que fue realmente diferente entre estos dos juegos son todas las mecánicas y cosas que sucedieron detrás de él. Y hubo períodos de meses en los que cada dos semanas, estábamos como creando nuevos sistemas, probándolos, verificando que funcionen y eliminando otros sistemas. Básicamente, hubo muchas iteraciones en el diseño del juego. Y ese es el enfoque del estudio. Nuestro objetivo principal es optimizar las iteraciones del diseño de juegos.

Y lo hacemos en tres áreas principales: herramientas para desarrolladores, arquitectura de software y creación de contenido. Veamos cada una de ellas con más detalle.

Comencemos con las herramientas para desarrolladores. En primer lugar, sería negligente si no mencionara algunos de los increíbles software de código abierto en los que confiamos. Obviamente, hay cosas regulares que todas las compañías de software usan hoy en día, como Kubernetes y otras cosas. Pero en cuanto al diseño del juego y su aspecto, estas dos herramientas, Corsius y Pixie, nos han sido de gran ayuda. Corsius es una red multijugador y Pixie es una biblioteca gráfica que utilizamos para renderizar nuestros juegos. Dependemos mucho de estas herramientas de terceros, pero también hemos estado desarrollando estratégicamente nuestras propias herramientas donde sentimos que necesitamos más flexibilidad. Por ejemplo, Play es una herramienta para el emparejamiento, los lobbies y también tenemos servicios de amigos. Esto nos brinda mucha flexibilidad para poder juntar a los niños adecuados para que todos se diviertan y nadie se sienta excluido, entre otras cosas. También hemos construido nuestra propia versión de Zoom, básicamente, el sistema de audio y video, que llamamos Synthesis A V, y eso es lo que se muestra aquí a la derecha. Así que puedes ver que mientras juegan, también pueden interactuar con sus amigos y compañeros de equipo y planificar qué deben hacer a continuación, entre otras cosas. Construir estas cosas nosotros mismos le da a los juegos mucha flexibilidad para decidir qué equipos deben ir juntos y cambiar los equipos a mitad del juego, entre otras cosas. Ha sido muy útil contar con equipos de ingeniería que puedan desarrollar todo esto y que los juegos puedan... Y que puedan soportar los juegos.

Esa es la parte de las herramientas para desarrolladores, ahora veamos la arquitectura de software. Básicamente, en cuanto a la arquitectura multijugador, seguimos una arquitectura nativa del servidor, que es bastante común en los juegos. Y para aquellos que no lo sepan, aquí hay una breve introducción, pero básicamente tienes todos estos clientes que están conectados a algún servidor. Y cuando recibes alguna entrada del usuario a través del teclado o el mouse, el cliente... Básicamente, la idea aquí es que el cliente es un cliente muy ligero, por lo que no realiza demasiada lógica. Simplemente toma tu entrada y la envía directamente al servidor. Y luego en el servidor se ejecutan estos sistemas, que explicaré en un momento. Pero básicamente es toda la lógica para actualizar algo. Por ejemplo, supongamos que quieres mover la nave espacial hacia adelante, entonces presionarías la tecla de flecha hacia arriba en tu teclado, y el cliente simplemente lo enviaría al servidor. Y luego el servidor realmente movería la nave espacial y también decidiría si colisionó con algo. Entonces, si la nave espacial estuviera justo al lado de un planeta o algo así, se produciría esa colisión, se decidiría qué le sucede al planeta y a la nave espacial, y luego se resolvería eso. Y luego ese nuevo estado se pasa a todos los clientes para que todos estén sincronizados y podamos seguir adelante. Este ciclo se repite una y otra vez. Y esa es la idea principal de la conexión en red autoritativa del servidor. Pero hay algunos casos en los que no queremos eso, como por ejemplo, el movimiento de la nave espacial.

El problema aquí es que cuando presionas una tecla, necesita llegar hasta el servidor y hacer algo y luego regresar, y solo entonces puedes ver ese cambio en tu pantalla. Así que eso es demasiado lento, especialmente para algo como el movimiento. Por lo tanto, en esos casos, en realidad utilizamos un modelo de autoridad del cliente, donde cuando tienes la entrada, actualizamos el estado local que tiene el cliente y también lo mostramos así. Así que se siente como si se moviera inmediatamente. Y luego enviamos ese nuevo estado al servidor. Y el servidor no es tan pesado aquí, porque todo lo que necesita hacer es tomar ese estado y pasarlo a todos los demás clientes para que todos estén sincronizados. Así que usamos ambos modos. Solo usamos el modo de autoridad del cliente cuando necesitamos que algo responda rápidamente. Por lo tanto, en la medida de lo posible, intentamos mantenerlo con autoridad del servidor. Y eso en realidad nos ayuda a simplificar la complejidad de la architecture. Y te mostraré cómo funciona. Entonces sí, esta es la única sección con un poco de código. Así que ten paciencia. El código es bastante simple. Solo estoy aquí para explicar ese diagrama que te mostré. Así que solo intento mostrar el estado del juego aquí. Lo interesante de esta architecture es que tienes este único estado que captura todo sobre tu juego. Entonces, en este caso, todos los equipos, todos los jugadores, planetas, naves espaciales, todo lo que le importa al juego está en esta gran clase llamada 'state'. Y contiene todo. Y esto solo necesita sincronizarse entre el servidor y los clientes. Dentro de esto, si miras las naves espaciales, por ejemplo, son solo más clases con más data. Entonces, en este caso, son todas las cosas que esperarías que tenga una nave espacial. Así que tenemos posición, velocidad, el equipo al que pertenece, etc. Y los sistemas son como el código de actualización. Entonces aquí tenemos un montón de sistemas. Y en cada fotograma, básicamente ejecutamos estos sistemas para resolver cualquier cambio que haya ocurrido durante el fotograma anterior. Aquí es donde realmente se encuentra toda la lógica en el servidor. Y en el lado del cliente, solo tenemos dos cosas. Como mencioné, tenemos el manejo de entrada y solo puse este código aquí para mostrar lo sencillo que es. Esto es literalmente una declaración de caso de cambio para todas las entradas de tu teclado.

En este caso, los números son el número de teclas 1, 2, 3. Y en cada caso, simplemente enviamos alguna instrucción al servidor. Entonces, si presionan 1, construye un extractor. Si presionan 2, una base. Y si presionan 3, una mina. Entonces, esto es todo lo que el cliente necesita hacer. El resto de su código es como, ¿pueden construir una base? ¿Tienen suficientes recursos para construir una base? Todas esas cosas suceden en el servidor. Y luego, el otro lado del cliente es el renderizado. Básicamente, cuando inicializas el cliente, ejecutamos esta función de renderizado para cada objeto. Y así configuramos todos los sprites, que básicamente son solo imágenes a través de PNG aquí. Y luego también configuramos estos listeners, que es el patrón que sigue Coliseus. Entonces, básicamente, cuando configuramos la nave espacial, estamos escuchando cualquier cambio en los puntos de acción. Y si hay algún cambio, inmediatamente se activaría esta función. Y simplemente cambiaríamos el texto para reflejar ese nuevo cambio. Así que es muy simple, al menos lógicamente, cuando intentas pensarlo.

Entonces, como ejemplo, imaginemos que queremos agregar meteoritos o algo así a este juego, porque no puedes tener un juego espacial sin meteoritos, ¿verdad? ¿Cómo lo haríamos? Realmente solo necesitamos cambiar el código en tres lugares. El primero, queremos agregar la clase de meteorito al estado del juego. Y luego queremos implementar el sistema de meteoritos. Entonces aquí es donde realmente pondrías el código de cómo se mueve el meteorito, y qué sucede cuando golpea un planeta, cosas así. Y luego queremos agregar la función renderMeteor en el código del cliente para renderizar este meteorito. Así que las imágenes y la animación y cosas que van con eso. Entonces puedes ver, es muy simple. Y esto es realmente lo que nos permite poder sacar elementos del juego y luego agregar cosas y cosas muy rápidamente, porque todo es tan modular. Así que eso es la architecture de software. Ahora pasemos a la oferta de contenido. La forma en que se crean los juegos en Synthesis, es casi como una plataforma. Y luego tienes todo este contenido que se puede agregar encima. Y eso es lo que nos da mucha flexibilidad. Así que podemos hacer nuevos mapas, hacer nuevo contenido cada semana.

Y así los niños tienen una experiencia fresca cada semana. Y la forma en que podemos hacer tanto contenido es invirtiendo realmente en las herramientas de la canalización de contenido.

Así que aquí, por ejemplo, esto es en realidad solo Google Sheets. Y esto es lo que usamos para hacer mapas para Proxima. Así que puedes ver que es solo una gran tabla. Y tenemos todos estos fragmentos de código, supongo, que usamos para especificar qué debería haber en el mapa. Y verás, hay mucha flexibilidad aquí. Podemos cambiar muchas cosas sobre el mapa.

Y lo genial aquí es que la persona que diseña estos mapas no necesita saber nada de código. Simplemente trabajan en Google Sheets y luego lo exportan a JSON, que luego se coloca en el juego. Y luego puedes probar el nuevo mapa allí. Así que podemos generar muchos mapas incluso en el transcurso de un solo día.

Y luego el otro lado de eso es el esquema de configuración. Así es como se configuran todas las opciones junto con el mapa que establece un juego. Así que aquí, por ejemplo, esto es para Proxima. Puedes ver que tenemos este campo de mapa personalizado. Básicamente, todo lo que hiciste en esa hoja de cálculo de Google, simplemente copiarías todo ese JSON aquí. Y simplemente instanciaría tu juego con estos nuevos data. Así que es muy rápido de probar. Es muy rápido de instanciar un juego, incluso en producción real también. Y en este lado, tengo el esquema de configuración para otro juego llamado Constellation. Y aquí, ofrecemos mucha más flexibilidad en las cosas que puedes cambiar. Por ejemplo, el tiempo que tienes para colocar las sedes centrales o la profundidad del acero o el número de aceros. Esto realmente cambia el juego significativamente al cambiar estos números. Así que podemos obtener mucho más juego de un solo juego.

Sí, en resumen, todo esto lo hacemos para optimizar las iteraciones de design de juegos. Y la razón por la que queremos hacer eso es porque queremos construir los mejores juegos de pensamiento en equipo del mundo. Y la razón por la que queremos hacer eso es porque queremos construir una generación de super colaboradores. Eso es lo que hacemos aquí en Synthesis. Muchas gracias. Puedes obtener más información visitando Synthesis.com. Mi nombre es Vivek Vidyasagran y puedes encontrarme aquí en Twitter, RX. Sí, gracias. ♪♪ ♪♪