Trantorian: arquitectura del juego

Por qué no puedes construir algo grandioso, sin tener algo robusto. Desarrollar un videojuego no es una tarea sencilla. Y, como todo desarrollo de software, involucra a un equipo de especialistas interdisciplinarios. El diseño de su arquitectura es muy importante para el desempeño del videojuego.

Áreas involucradas en el desarrollo

Áreas como arte, contenido creativo, UX, UI, diseño de juegos, equilibrio, control de calidad, entre otras, son tan importantes como la programación en sí. Los motores para el desarrollo de videojuegos como Unity o Unreal, han recorrido un largo camino y han facilitado muchas cosas. A veces, haciéndolo demasiado fácil.

En Unity, por ejemplo, es muy fácil desarrollar sin una base arquitectónica sólida. Y al igual que con un edificio, la arquitectura y su implementación son extremadamente importantes.

Este artículo es el primero de una serie de artículos que describirán la arquitectura de Trantorian. Este es un resumen. Nos adentraremos más en la madriguera del conejo en los siguientes. ¡No te los pierdas!

Ten en cuenta que este artículo será un poco técnico. Así que siéntete libre de preguntar si tienes alguna duda. Y estaremos más que felices de editar y aclarar cualquier cosa.

Aclaremos algunas cosas generales antes de comenzar, ¿de acuerdo?

¿Por qué es importante la arquitectura?

Depende del juego. Para un solo jugador, un juego simple como tic-tac-toe, probablemente podría salirse con la suya con una arquitectura muy simple o incluso sin arquitectura.

Pero con un proyecto más grande (y cualquier juego en línea multijugador masivo como Trantorian es un proyecto grande), una arquitectura sólida es primordial.

La arquitectura de un videojuego asegura:

  • Escalabilidad: cuando tienes capas independientes, puedes duplicar cualquier capa y obtener, por ejemplo, el doble de potencia de procesamiento (tener varios servidores de inicio de sesión con un equilibrador de carga que puede tomar la carga de inicio/cierre de sesión de los servidores de juego reales) o el doble del ancho de banda de la red. Todo sin tener que modificar nada.
  • Sostenibilidad: el código escrito con una arquitectura sólida es más fácil de mantener y ampliar por los futuros desarrolladores, lo que garantiza el éxito a largo plazo del proyecto. El código debe ser consistente, desacoplado y funcional. Y una buena arquitectura lo impone.
  • Estabilidad: el manejo de errores y las pruebas automatizadas son algunos ejemplos de lo que te permite reducir en gran medida la cantidad de errores; una buena arquitectura (junto con el uso de patrones y principios de programación como SOLID y SoC) te permite escribir código comprobable (cubierto por pruebas automatizadas). En Trantorian esperamos una cobertura de código del 100% por parte de las pruebas (permitiendo algunas excepciones cuando corresponda).
  • Seguridad: todo lo anterior se suma a la seguridad general del proyecto. Cuando tienes un código que está cubierto por pruebas automatizadas, con capas independientes, obtienes menos vulnerabilidades. Porque es más fácil detectar errores de tiempo de ejecución y detectar rápidamente el código que no cumple con la arquitectura. El resultado es un código que es más fácil de leer, escribir, ampliar y refactorizar para los desarrolladores nuevos y actuales, etc.

¿Qué pasa cuando no tienes una arquitectura sólida?

Es muy poco probable que un gran proyecto llegue a buen término sin algún tipo de arquitectura. Pero hemos visto lo que una arquitectura no tan buena puede hacerle a un juego.

Estoy seguro de que puede relacionarse con algunos de los siguientes problemas en los juegos multijugador, que seguramente has notado:

  • Cuellos de botella: los servidores fallan constantemente por tener muchos jugadores. Esto sucede durante mucho tiempo porque es difícil de escalar (o extremadamente costoso e ineficiente).
  • Hacks: desde exploits de errores o problemas en el código, hasta problemas de seguridad completos por falta de procedimientos y pruebas.
  • Bloqueos: desde problemas constantemente molestos hasta bloqueos.
  • Costos operativos más altos: los proyectos con errores e inseguros necesitan un equipo de desarrollo más grande y con más experiencia. Además, los servidores son más costosos, ya que es más difícil hacer que el código de red sea eficiente.

Como puedes ver, cualquier juego necesita una arquitectura sólida. Más aún si es online. Y es de suma importancia cuando el juego maneja el dinero del jugador (desde la compra del juego hasta el pago de una suscripción o un juego blockchain).

Arquitectura de Trantorian

En Indelve sabemos todo esto. Así que nos tomamos nuestro tiempo antes de comenzar a codificar para hacer las cosas bien. Nuestro equipo veterano trabajó incansablemente para asegurarse de que Trantorian tenga una arquitectura sólida para que sea escalable, sostenible y seguro.

Aquí hay una descripción general de cómo estamos estructurando todo en Trantorian:

El diagrama anterior muestra las capas que tenemos y cómo se realiza la comunicación.

Sigamos con más detalles al respecto.

No hables con extraños

Como puedes ver, cada capa está muy claramente definida y modularizada. No solo eso, sino que todas las comunicaciones son limitadas.

Puedes ver que la capa N° 1, la «Capa visual», solo interactúa con la capa N° 2, la «Capa lógica». Esto significa que la capa N° 1, el juego real que el jugador inicia y juega, no tiene contacto directo con el servidor de socket, la base de datos o la red blockchain.

Esto garantiza que, en caso de que haya un error en la capa N° 1, sin importar cuán crítico pueda ser, nunca podrá afectar la base de datos o la información en la blockchain.

Esto es extremadamente importante. Blockchain agrega seguridad y descentralización, pero si no se toman medidas, un exploit puede acuñar (¡o quemar!) cientos de tokens o NFTs en la cadena de bloques, corrompiendo por completo la economía del juego. Con este tipo de arquitectura y modularización, esto es casi imposible.

Además, contamos con intermediarios externos que validan todos los mensajes antes de que se les permita pasar. Puedes verlo en dos lugares: entre la capa Nº 2 y la Nº 3 (primer punto de entrada a la nube). Y entre la capa #3 y #4 (primer punto de entrada para las API).

Esto nos brinda un paso de seguridad adicional que, garantiza que los mensajes entrantes realmente provengan de los clientes, que estén firmados y formateados correctamente.

Alejando los fósforos uno del otro

Para que un exploit o un error afecte el código de la red blockchain, debe haber:

  • Un error en Unity (capa #1).
  • Otro error en la capa #2 (la capa lógica) que se ve afectada y puede ser aprovechada por el error anterior. Esto se debe a que son proyectos y códigos completamente diferentes e independientes.
  • Otro error más en la capa 3, el servidor de conexión (donde el jugador no tiene control directo ya que está en la nube) que, nuevamente, se ve afectado por los errores anteriores.
  • Y otro error más en la API REST de la cadena de bloques (capa 4) que, al igual que antes, está fuera del acceso directo del usuario.

Es como poner un juego de fósforos en línea y encender el primero. Todos se quemarán. Pero si los separas lo suficiente, evitas la reacción en cadena.

Cada capa en Trantorian es independiente (diferentes proyectos, código y acceso) y está cubierta con pruebas automatizadas.

Doblando fácilmente

Para volver a la escalabilidad, ahora puedes ver claramente que descubrimos que la capa n. ° 3 (el servidor de socket) se está quedando sin recursos, podemos agregar fácilmente otro servidor con un equilibrador de carga frontal. Esto será completamente transparente para la capa lógica (capa n. ° 2) y duplica la potencia de procesamiento.

En realidad, la arquitectura completa es incluso más granular que esta descripción general. Cada capa también está modularizada por sí sola. Por ejemplo, la capa n.º 1, «Capa visual», creada con el motor de juegos Unity, está modularizada con Vistas, Componentes y Modelos, además de la filosofía ECS de Unity.

Llegaremos a más detalles sobre todo esto en futuros artículos.

Conclusión

Al igual que cuando se construye un edificio, el desarrollo de un videojuego necesita un buen conjunto de planos (la arquitectura), una base sólida (implementación de la arquitectura siguiendo patrones de programación de juegos, principios SOLID, SoC, etc.), código bien escrito (código limpio, mejores prácticas), pruebas automatizadas (unidad, integración, regresión y humo) y control de calidad (¡realmente jugar el juego y buscar errores!).

Y, por supuesto, un buen diseño de juego, buenos gráficos, mecánicas profundas, una tradición convincente y, sobre todo, ¡diversión!

Hacer un videojuego no es tarea fácil. Pero no estamos aquí para que sea fácil. Estamos aquí para el desafío.

Visiten Trantorian en https://trantorian.com y estén atentos para seguir artículos más detallados sobre la arquitectura de Trantorian.

Nicolas Varchavsky (twitter: @NicoVarcha)

CEO of Indelve, Inc.


Este artículo ha sido escrito originalmente por Nicolas Varchavsky, publicado en https://medium.com y traducido por AlgoLatam.

Original Article: https://medium.com/@Indelve/trantorians-architecture-38c80bf6bb81

Aviso de responsabilidad:

Este artículo no contiene consejos financieros, ni recomendaciones de inversión de ningún tipo. La información brindada se ofrece sólo con fines educativos y didácticos en cuanto a tecnología Web3 y análisis sobre sus casos de uso.

Las inversiones con criptomonedas, NFTs, tokens u otros activos digitales conllevan riesgos y no se encuentran regulados, por lo que los lectores deben realizar su propia investigación antes de tomar cualquier tipo de decisión bajo su entera responsabilidad, así como adaptarse y observar las diferentes regulaciones legales según su país de residencia.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *