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?
Respuestas:
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.
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.
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:
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.
No. Esta es un área increíblemente difícil que aún no se ha resuelto.
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.