La clave para diseñar la arquitectura de un juego es considerar la eficiencia desde el principio. Centrarse en las métricas, el registro, la telemetría y la monetización demasiado pronto puede provocar una sobrecarga excesiva en la arquitectura del juego. Incluir todo eso en su servidor de juegos en tiempo de ejecución puede reducir el retorno de la inversión (ROI) y aumentar el costo total de propiedad.

En su lugar, comience con un producto mínimo viable (MVP) lo antes posible. Haga que el servidor funcione, el cliente funcione, su código de red y su sistema de emparejamiento estén bloqueados y luego construya desde allí. También debería considerar contratar a su proveedor de alojamiento desde el principio; puede proporcionarle soluciones e infraestructura prediseñadas que pueden ahorrarle tiempo de desarrollo.

Cuando se trata del diseño de tu juego, ¿cómo se ve lo simple? La imagen de arriba muestra un diseño complejo no solo con una instancia de servidor de juegos, sino también con muchos procesos auxiliares en la misma máquina, incluidos ejecutables de emparejamiento, registro y métricas.

Esta complejidad no necesariamente se vuelve evidente hasta que comienzas a realizar pruebas a escala, que es cuando puedes comenzar a darte cuenta de que estas cosas no funcionan bien juntas cuando hay miles de jugadores. Además, es posible que los servicios auxiliares no tengan ningún límite de recursos, por lo que pueden comenzar a canibalizar recursos en la máquina y afectar el rendimiento del jugador. Mantener las cosas simples puede ayudar a mitigar estos problemas.

En términos de diseño de servidor de juegos, lo simple es empaquetar cosas en una única instancia de servidor, como un único ejecutable y un emparejador resistente (tal vez alojado en un servicio backend en lugar de en una máquina). De esta forma, cuando uno de los servidores del juego se pierde, no se lleva consigo a otros jugadores y el área afectada sigue siendo pequeña. A escala, si tienes un servidor de juegos con este diseño que no funciona correctamente, no afectará tu experiencia de jugador.

Para ayudar a minimizar el riesgo de costos, no mantenga procesos auxiliares como depuración, observadores y emparejamiento en la misma máquina. Si te encuentras en una situación en la que un servidor de juegos muere y tienes máquinas en la nube a las que se escala, estás dejando los procesos auxiliares "zombis". Todavía están consumiendo recursos, lo que le cuesta dinero a tu estudio y no tienes forma de cerrarlos.

En su lugar, considere hacer que los procesos auxiliares, como el emparejamiento y la depuración, sean subprocesos del servidor del juego; manténgalo simple. Luego, si pierdes el servidor del juego, este se lleva consigo los subprocesos, en lugar de dejarlos ejecutándose en segundo plano. En este caso, si el servidor deja de funcionar, puede activar otro sin los recursos y costos adicionales asociados con los procesos "zombis".

En juegos multijugador con sesiones de larga duración, puede haber problemas como pérdidas de memoria, aumento del uso de RAM y más, que pueden no aparecer hasta que ejecutes el juego a escala.

A continuación se detallan algunos riesgos asociados con sesiones de juego de larga duración:

• Ataques DDoS: Dado que la IP de la instancia del juego no cambia con un modelo de sesión de juego persistente, existe la posibilidad de que se produzcan ataques DDos.
• Altos costos de la nube: Se necesitan muchos recursos costosos para mantener un juego que esté siempre, o casi siempre, activo, incluso si los jugadores no están jugando.
• Interrupciones por parches: La aplicación de parches puede ser difícil de gestionar, porque puede haber partidas activas que deban finalizar para poder parchear el juego, lo que resulta en una mala experiencia para el jugador.

Todavía existen riesgos y consideraciones sobre la experiencia del jugador para sesiones de juego cortas. Incluso si tu partida de dos jugadores dura sólo dos minutos, facilitar cientos de miles (o más) de esas partidas simultáneas puede ser costoso y presentar riesgos.

Aquí hay algunas consideraciones para sesiones de juego cortas:

• Alta carga de backend: Las llamadas API constantes a su backend para facilitar sesiones de juego cortas pueden suponer una carga enorme, por lo que debe ser resistente.
• Duro con la infraestructura: Cuando el servidor se reinicia entre sesiones cortas, es posible que vea un aumento en la CPU y la RAM al comienzo de la carga de los procesos, lo que puede resultar costoso.
• Requiere un casamentero robusto: Con sesiones cortas, necesitas un emparejador eficaz que se encargue de los tickets de emparejamiento para nuevas sesiones, reconexiones y más.
• Calidad de Servicio (QOS): Necesitará un proveedor que le permita enviar a su cliente de juego una lista de direcciones IP en tiempo real para determinar cuál debe ser esa región del servidor en función de la telemetría y los datos reales, en lugar de la ubicación física.
• Necesita métricas y datos de telemetría: Si algo sale mal, es más probable que un jugador abandone e inicie otra sesión en lugar de informar un error. Si no obtienes métricas y telemetría de esas sesiones cortas, es posible que te pierdas cosas que van mal en el juego.

Estos son los pros y los contras de los juegos de sesiones cortas:

Ventajas:

• No es necesario estabilizar durante tiempos de ejecución prolongados
• Permite aplicar parches más rápido
• Facilidad de reducción
• Sin estado inactivo
• Los archivos de registro para cada sesión permiten una solución de problemas más sencilla

Contras:

• Más devoluciones de llamadas, lo que significa más carga a escala
• El costo de la computación en la nube para los reinicios no es trivial a escala
• Condiciones de carrera
• MEM/CPU aumenta al inicio
• Más complejidades para el emparejamiento
• Los problemas de rendimiento de la máquina se pueden ocultar

En los juegos multijugador persistentes (como los MMO), puede haber ciertos problemas y riesgos. Por ejemplo, soportar situaciones como migraciones de jugadores entre servidores significa que necesita un sistema backend más sólido, que incluya servidores costosos y discos duros potentes.

A continuación se presentan algunas consideraciones para los diseños de sesiones de juego persistentes:

• El presupuesto puede ser una preocupación: Se requieren sistemas backend más sólidos para que las sesiones persistentes funcionen, por lo que deberá calcular cuánto se basarán los costos de mantenimiento en función de los usuarios para comprender si este es el diseño de sesión adecuado para usted.
• Es posible que la nube no sea factible: Debido a las altas exigencias de una sesión de juego persistente, la nube puede resultar demasiado costosa para su proyecto.
• La calidad de la red es extremadamente importante: La latencia y la gestión de la latencia mejorarán o arruinarán la sesión de juego persistente para los jugadores, por lo que probar su red de manera temprana y rigurosa es esencial para una buena experiencia de jugador.
• Parchar es difícil y arriesgado: El tiempo de inactividad relacionado con el mantenimiento nunca es una buena experiencia para los jugadores, incluso si es necesario para mejorar la experiencia general. Comunicarse con su comunidad sobre el tiempo de mantenimiento es clave. También es posible que desees considerar la posibilidad de ejecutar varias versiones del juego al mismo tiempo y eliminar parches con el tiempo.

Estos son los pros y los contras de los juegos persistentes basados ​​en sesiones:

Ventajas:

• Los servidores están siempre en funcionamiento
• Es posible un bucle de juego más corto
• Menos carga en su backend

Contras:

• Más difícil de diseñar
• Inestabilidad en el tiempo
• Limpieza de sesiones
• Es necesario un diseño en estado inactivo
• Necesita ser consciente del casamentero
• La aplicación de parches A/B puede tardar más

Es una buena idea prepararse para posibles problemas en la experiencia del jugador a gran escala. Iniciar, ejecutar y actualizar un juego multijugador puede ser caótico, por lo que es importante realizar pruebas situacionales de "resiliencia al caos" y asegurarse de que el backend de su juego esté configurado para manejar ese caos.

Por ejemplo, ¿qué sucede si todos salen del juego e intentan volver al emparejamiento al mismo tiempo? Averiguar la respuesta del backend a esa situación y configurarlo para manejar ese problema puede ahorrarle dolores de cabeza (y ayudar a proteger su reputación) a largo plazo.

Es probable que tengas que parchear tu juego durante el lanzamiento. Por eso es importante construir su infraestructura con la capacidad de aplicar parches durante la producción y el lanzamiento. Esto puede ayudar a que el caos del día del lanzamiento y la aplicación de parches sobre la marcha sean mucho más rápidos y fluidos, y el impacto en los jugadores puede ser limitado.

Una forma de abordar esto es ejecutar varias versiones de tu juego simultáneamente. Sin embargo, también deberá asegurarse de que su infraestructura pueda manejar múltiples versiones. Además, necesitarás tener un sandbox con todas las diferentes versiones.

Si ya ha incorporado la capacidad de ejecutar varias versiones simultáneamente, no habrá tiempo de inactividad ni interrupciones para los jugadores cuando aplique el parche.

Las pruebas de escala frecuentes son fundamentales, por lo que encontrar un proveedor que pueda ayudarlo debe ser una consideración importante al seleccionar sus servicios.

Una cosa importante para escalar la prueba es la teselación y desfragmentación del servidor. La teselación de servidores es una consideración de costos importante. Básicamente, primero desea utilizar máquinas metálicas económicas para el alojamiento. A medida que su base de jugadores fluctúa, también querrá eliminar rápidamente las máquinas en la nube más caras, lo cual es más rentable.

Game Server Hosting (Multiplay) evita la asignación a máquinas que son más costosas, lo que nos permite eliminarlas más rápidamente cuando el número de jugadores disminuye.

La capacidad de nuestro sistema para hacer esto depende de la vida útil de su partido. Las duraciones más cortas de las partidas nos permiten finalizar más rápidamente las asignaciones en máquinas costosas. Los partidos más largos significan que no podemos apagar las máquinas hasta que termine el partido.