¿Cómo son las ‘estructuras de back-end’ de los juegos más grandes con alrededor de mil millones de jugadores, como los juegos de Supercell?

Esta pregunta parece un poco ambigua ya que hay muchas partes móviles, y no estoy seguro de qué es exactamente lo que quieres saber. Voy a responder esto asumiendo que quieres una visión general.

Filosofía de diseño

Las empresas dejan que sus el diseño del juego impulsa su infraestructura, o deja que las limitaciones de infraestructura existentes limiten el diseño. A veces eligen una vía intermedia. Cada uno tiene compensaciones y esto puede cambiar con el tiempo.

Cuando apareció World of Warcraft por primera vez, usó la configuración del servidor MMO estándar para ese momento, con algunos ajustes interesantes. Con el tiempo, lo mejoraron para permitir que los jugadores se unieran dentro de un clúster de servidores físicos / centro de datos (grupos de batalla etiquetados), y ahora lo mejoraron aún más para permitir el juego regional cruzado. Esto ahora se considera estándar, pero sigue siendo técnicamente un desafío. Debajo del capó, estoy seguro de que se parece bastante al modelo de servidor individual, pero simplemente unieron las cosas para permitir que los jugadores se transfieran temporalmente a voluntad.

Compare esto con Game of War, donde el objetivo inicial era todos los jugadores en un solo servidor. MZ construyó la infraestructura para hacer esto desde cero. es costoso y difícil, pero lograron hacerlo funcionar. También convirtieron ese trabajo en una plataforma ahora disponible públicamente llamada Satori.

En su lugar, Supercell utilizó la mayor cantidad de infraestructura disponible, aprovechando Amazon AWS.

Vea este caso de estudio: Estudio de caso de Supercell – Amazon Web Services (AWS)

Conectando mil millones de jugadores

Si eres MZ o Supercell, no comienzas a conectar a mil millones de personas simultáneamente, y desde la perspectiva del back-end no los pones a todos en el mismo servidor.

No hay ningún servidor en el mundo que pueda contener a todos estos jugadores. Entonces, dividimos el problema en las piezas más pequeñas posibles hasta que tengamos una unidad de jugadores que un servidor pueda admitir, luego las unimos. Fragmentar o dividir un recurso en muchos servidores paralelos idénticos se usa mucho.

La pregunta que realmente impulsa los desafíos de infraestructura es la siguiente: ¿cuántos jugadores necesitan jugar juntos al mismo tiempo?

Si dice 100, incluso mil millones de jugadores simultáneos en línea (lo cual no es realista) es un problema de costo de 1 billón / 100 grupos de servidores concurrentes. Si puedes resolver 100 jugando juntos y 100 es tu concurrencia local máxima, efectivamente has resuelto cualquier número de jugadores si tienes la infraestructura física.

Si 5,000 necesitan jugar juntos (como el mundo abierto), entonces encontramos una manera de dividir esto progresivamente en grupos de servidores más pequeños que luego se comunican entre sí para que estén conectados.

Esta filosofía se usa para todo lo demás también.

Los recursos estáticos son mucho más fáciles de fragmentar que los datos en vivo. Si me dice que 1 millón de personas necesitarán descargar algunos recursos simultáneamente, seguimos el modelo descrito anteriormente.

  1. El reproductor se conecta al recurso para iniciar la descarga.
  2. el jugador realmente alcanza el clúster de equilibrio de carga (o round robin dns, etc.).
  3. el equilibrador de carga dirige al jugador a uno de los muchos servidores de recursos idénticos que atenderán la solicitud.

Algunas compañías tienen cientos o miles de dichos servidores para atender solicitudes. Dependiendo del contenido, algunos usan servicios como AWS para acelerar y cerrar dinámicamente fragmentos de recursos a medida que cambia la demanda. Esto ahorra mucho dinero y puede reaccionar extremadamente rápido (minutos). No usar AWS o similar significa construir esta infraestructura usted mismo.

Jerarquía del servidor

Cuando el modelo fragmentado tradicional no funciona (porque cada servidor es idéntico), podemos trabajar en paralelo. Si me dices que necesitamos un sistema de emparejamiento que todo Estados Unidos usará simultáneamente, no puedo compartirlo, pero puedo paralelizarlo. Si los jugadores pueden segmentarse en grupos basados ​​en alguna característica, entonces este problema podría paralelizarse fácilmente.

Funciona de manera similar a los recursos estáticos explicados anteriormente, pero es más dinámico.

En lugar de equilibrador de carga -> fragmento estático, podemos hacer:

emparejador (asignar grupo a usuario) -> gestor de colas para grupo -> servidor de colas.

Entonces, ¿qué está pasando en este ejemplo?

  1. Matchmaker segmentará a los usuarios en grupos en función de algunos atributos, como ping o nivel de habilidad. Esto divide el total de n jugadores en k grupos. Aunque los tamaños de grupo no son necesariamente de tamaño uniforme.
  2. un gestor de colas para el grupo actuaría como un equilibrador de carga, llevando a los usuarios asignados a ese grupo y descubriendo dónde colocarlos. Una cola de grupo sería esencialmente un clúster donde los jugadores en cola se dividen equitativamente entre cada cola (servidor).
  3. Cada servidor, cuando se le solicite, responderá con el siguiente jugador en línea. Como ya hemos estructurado la cola de antemano, esto debería ser rápido.

¿Qué hizo esta infraestructura? Se hizo un gran problema muy manejable.

ejemplo: 24,000 están en línea esperando en el emparejamiento. Digamos que son una distribución uniforme de 3 niveles de habilidad, bronce, plata, oro. Esto significa que están esperando unos 8,000 jugadores por nivel de habilidad.

Si cada cola de grupo tiene 40 instancias de cola que sirven, entonces cada cola tiene alrededor de 200 jugadores. Cuando el servidor de emparejamiento dice “oye, dame 5 jugadores de bronce”, entonces el administrador de colas del grupo de bronce puede seleccionar inmediatamente 5 instancias de colas, hacer que el jugador siga en la fila para cada uno y devolverlos como grupo. Entonces, si se trata de un juego como Choque real o supervisión, solo necesitas una pequeña instancia de partido para los jugadores involucrados en ese partido. Los servidores de instancias pueden seleccionarse utilizando cualquier método descrito anteriormente.

El emparejamiento real es más complicado, pero la idea general es casi la misma. Se escala bien porque simplemente puede agregar más servidores a cada cola de grupo y seguirá escalando.

Realmente hay mucho más sobre estos temas, pero estos fueron algunos ejemplos de cómo podría configurar servidores en ciertos escenarios.

Muy, muy indulgente.

Primero apagado, latencia. Para un juego como Choque de clanes o Choque real, el juego debe adaptarse a la latencia de conexión de todo el mundo, por lo que intencionalmente tienen un contador de latencia incorporado de 10 segundos . Si la conexión dura más de 10 segundos, en lugar de abandonar el juego, el juego usará automáticamente una IA para cubrir al jugador mientras el juego lucha por obtener paquetes del otro usuario.

Para la contabilidad, los juegos utilizan un método de grabación y guardado muy complejo para guardar los datos del juego. De hecho, externalizan sus recursos de ahorro a Amazon y Google.

Para la representación, todos los juegos de Supercell realmente usan un método de capas en lugar de representar objetos 3D en la pantalla. Esto permite que sus juegos sean fluidos, independientemente del hardware en el que se esté ejecutando.