Servidor de juegos C ++ distribuido que usa una base de datos

11

Mi servidor de juegos por turnos C ++ (que usa una base de datos) no se compara con la cantidad promedio actual de clientes (jugadores), por lo que quiero expandirlo a múltiples (más de una) cantidad de computadoras y bases de datos donde todos los clientes permanecerán dentro mundo de juego único (los servidores deben comunicarse entre sí y usar múltiples bases de datos).

¿Hay algunos tutoriales / libros / estándares comunes que explican cómo hacerlo de la mejor manera?

server databases eslavo
fuente

Respuestas:

8

La terminología MMO para "permanecer dentro de un mundo de juego único" es un fragmento individual . EVE en línea es el único MMO importante que intenta meter a cada jugador en un solo fragmento.

Por suerte para ti, publicaron un artículo muy informativo sobre cómo lo hacen.


(fuente: gamasutra.com )

Las malas noticias. No puede aplicar las técnicas de EVE en línea en general. Sus soluciones se adaptan absolutamente a su género e implementación particulares.
NOTA : Para toda la red de fragmentos únicos súper elegante de EVE en línea, usan una base de datos. No pudieron diseñar una solución escalable, consistente y moderadamente en tiempo real para bases de datos distribuidas.

De cualquier manera, leer cómo lo hicieron debería ayudarlo a diseñar su propia solución. Sin embargo, tenga cuidado, está intentando resolver un problema muy difícil.

En lugar de distribuir su servidor de juegos, sugeriría explorar primero sus otras vías.

  • Perfila tu servidor de juegos.
    • Optimice el código de su servidor para mantener baja la carga de la CPU si eso es un problema.
    • Optimice el protocolo de comunicación entre los clientes y el servidor para reducir la conversación en la red.
  • Optimice el servidor de jugador para las comunicaciones de la base de datos.
    • ejecute un optimizador de consultas y luego realice los cambios según corresponda.
    • reducir la interacción de DB a un mínimo
  • Mueva la base de datos a una máquina separada.
    Esto a menudo ayuda mucho. Si es posible, mantenga la base de datos en la misma red local, pero eso debería ayudar a que su servidor de juegos sea mucho más dinámico cuando es lo único que se ejecuta en el hardware del servidor.
código_deft
fuente
¿Cómo estás definiendo "mayor"? Kingdom of Loathing usa un solo fragmento. Todos comparten el mismo fragmento de Farmville. Star Trek Online y Champions Online usan un modelo de fragmento único, pero zonas instantaneas.
En lugar de usar una base de datos SQL, también podría usar una solución noSQL que fue diseñada para la agrupación y el fragmentación, como MongoDB.
Philipp
1
Los juegos web de @JoeWreschnig no son juegos en tiempo real, mucho más fáciles ... No estoy seguro de cuántos jugadores tienen Star Trek Online y Champions Online ...
o0 '.
4

Su primer movimiento debería ser desacoplar el acceso directo a la base de datos del servidor del juego y usar un middleware de uso específico para preparar los datos para su servidor (es decir, XML, JSON). Estos podrían manejar cualquier cantidad de bases de datos y, lo que es más importante, ofrecerle opciones de almacenamiento en caché específicas de la aplicación. Guarde en caché todo lo que pueda y fastidie la base de datos solo cuando sea necesario. Realice grandes recuperaciones y rara vez en lugar de muchas consultas pequeñas para lograr el mejor rendimiento posible en su escenario.

La base de datos de su elección también podría permitirle operar clústeres que faciliten la expansión de los recursos de la base de datos disponibles y brinden sus resultados más rápido, pero este es un tema que necesita mucha experiencia y un administrador de base de datos dedicado para configurar y mantener, y no del todo para el presupuesto independiente tampoco.

Konrad K.
fuente
1
Todo esto suena bien hasta que consideres que espera tener múltiples servidores accediendo a un conjunto de datos; esto significa que sin una mayor coordinación, los cachés del lado de la aplicación se desincronizarán, lo que provocará errores en el juego en el mejor de los casos y pérdida de datos en el peor. No estoy en desacuerdo con nada de lo que ha dicho, pero el póster original también deberá considerar el problema de coherencia entre servidores antes de continuar.
Kylotan
El middleware es un túnel de datos que, por un lado, es responsable del almacenamiento en caché de los datos y también de proporcionarlos. Sin embargo, solo proporciona datos al servidor (nunca al cliente) y el servidor almacena en caché todos los datos maestros relacionados con el juego al inicio. Por lo tanto, puede haber muchas fuentes de datos y muchos solicitantes de datos conectados en cualquier momento. El MMO en el que trabajo utiliza este esquema de manera bastante eficiente.
Konrad K.
Eso no explica cómo resolvió en absoluto los problemas de consistencia entre servidores. En algún momento los servidores de datos que tenga que sincronizar entre sí, o si tiene condiciones de carrera, que se manifiesta como desconexiones al azar, los jugadores duplicados, artículos engañados, misiones que faltan, etc.
Los datos nunca se duplican: en todo momento solo hay un servidor a cargo de un determinado objeto y, cuando es necesario, lo transfiere a otro servidor. Los objetos son conexiones de cliente que también incluyen el objeto de control del jugador. Sin embargo, esto se realiza a través de un servidor maestro y se debate entre servidores. Por lo tanto, estamos tratando con dos tipos de datos: información de la base de datos (a la que se refiere mi publicación original) y objetos del juego que se crean en tiempo de ejecución y se transmiten en un mmo de varios servidores. Ninguno de estos debe caer en una condición de carrera o duplicarse en el nivel de aplicación.
Konrad K.
3

Con respecto al servidor del juego: Una estrategia común es usar múltiples servidores donde cada servidor gestiona una parte del mundo del juego. Por lo general, cada usuario solo necesita saber qué sucede a su alrededor, por lo que tiene sentido dividir el mundo por localidad. Desafortunadamente, esto se vuelve mucho más complicado cuando tienes un mundo abierto sin fronteras en lugar de un mundo que consiste en zonas cerradas y jugadores que se teletransportan entre ellos. Cuando tienes un mundo abierto, necesitas una forma de transferir jugadores entre zonas de una manera fluida y una forma de sincronizar las áreas cercanas a las fronteras entre los servidores. Ese es un problema complicado.

Con respecto a la base de datos: las bases de datos SQL generalmente escalan mal. No están diseñados para ser distribuidos. Pero actualmente hay una tendencia bastante nueva de bases de datos NoSQL como MongoDB o Cassandra que fueron diseñadas para distribuirse en múltiples servidores. Hacen que sea mucho más fácil agregar capacidad simplemente agregando más servidores. Entonces, ¿por qué no todos los juegos grandes cambian a ellos? Porque:

  1. Las bases de datos SQL existen por más de 40 años, esas bases de datos NoSQL solo por unos pocos años. Todavía no hay mucho conocimiento sobre cómo usarlos de manera más eficiente y su desarrollo avanza rápidamente. Hay muchos productos competidores y completamente incompatibles en el mercado, y no hay señales de cuáles sobrevivirán y cuáles quedarán obsoletos y descontinuados en unos pocos años. La mayoría de los grandes jugadores prefieren las deficiencias conocidas de SQL sobre los riesgos desconocidos de las bases de datos NoSQL.
  2. Funcionan de manera muy diferente a las bases de datos SQL y requieren repensar toda su estrategia de persistencia. Esto podría generar cambios drásticos en toda la arquitectura de software.

Entonces, cuando su proyecto ya está muy avanzado, cambiar a otra solución de base de datos puede ser un gran riesgo y una gran inversión de tiempo y energía.

Philipp
fuente
0

No. Esta es un área increíblemente difícil que aún no se ha resuelto.

Kylotan
fuente
Puede haber algo de "plantilla" (no como "patrones de diseño C ++) Solución de ella Hay un montón de MMORPGs?.
eslavos
2
La mayoría de los MMO están respaldados por desastres absolutos para bases de datos.
En particular, los MMO a menudo tienen enfoques muy diferentes para su persistencia de datos, que a menudo funcionan de manera aceptable para su propio diseño de juego, pero no para otros diseños de juegos. Dado que el diseño del juego es la parte más importante, no puedes especificar adecuadamente una estrategia de distribución y persistencia de datos sin una. (Lo que podría interpretarse como: "Haga una pregunta más específica, diciéndonos qué tipo de datos tiene, con qué frecuencia cambian y por qué cree que desea distribuir un solo mundo en varios servidores")
Kylotan
0

Sé que esto es viejo pero ...

En realidad, hay dos áreas en las que centrarse con esto.

Necesita distribuir su aplicación en varios servidores. Necesita distribuir su base de datos en varios servidores.

Y necesitas tener redundancia para ambos.

Hay algunas soluciones de código abierto para esto. Farmville es un buen ejemplo con MemSQL / Couchbase.

KermEd
fuente
1
La distribución de la base de datos a través de múltiples servidores es ciertamente un problema resuelto. Desafortunadamente, generalmente no es un requisito importante para los juegos en línea que mantienen sus accesos de base de datos al mínimo. Por el contrario, distribuir el juego real a través de múltiples servidores todavía no es un problema resuelto.
Kylotan