¿Cuál es la mejor arquitectura para múltiples servidores de juegos que necesitan comunicarse entre sí?

Question

El juego es un juego estratégico de bajo gráfico (SVG). Cada servidor representa un dominio de juego con sus jugadores. Todos los servidores deben poder comunicarse entre sí, ya que los jugadores pueden moverse (en el juego) del dominio al dominio / enviar " mensajeros diplomáticos " etc.

Hemos elegido esta idea, ya que nos permite ampliar el mapa del mundo de forma interminable, permite a otras personas conectar sus servidores de juegos a nosotros y los que amplían el mundo aún más. Si un servidor (y sus copias de seguridad) falla, el juego seguirá ejecutándose (un entorno distribuido real).

Estamos solo al principio. ¿Cuáles son las plataformas que debemos ver, que nos ayudarán a desarrollar ese mundo?

Answer 1

XMPP, anteriormente conocido como Jabber, podría ser un buen lugar para comenzar.

Answer 2

Mucho de esto depende de la cantidad de datos que desee compartir entre servidores. Usted quiere que cada servidor maneje su propio dominio, pero ¿qué pasa con la base de datos de cuentas, los datos sobre quién posee qué información, la topografía de los dominios, estos datos serán centrales y / o distribuidos y cómo los mantiene sincronizados? Entonces, aparte del funcionamiento del juego, hay otro conjunto de metadatos, sobre los cuales los servidores necesitan comunicarse. En cuanto a los datos del juego, probablemente pasarás eventos, objetos de datos e información sobre la propiedad y el control de los datos. Además de esto, debe haber algunos metadatos de reloj en el juego para mantener los dominios sincronizados.

Probablemente usaría un sistema de colas asíncronas con diferentes prioridades para metadatos, solicitudes y mensajes de respuesta. Un protocolo como XMPP además de intercambiar mensajes puede brindarle información de presencia, autenticación, cifrado y otras ventajas. Pero al comienzo, el protocolo de entrega en sí no es tan importante como la estructura de los mensajes y el intercambio de datos. En esencia, los protocolos de entrega son intercambiables.

Ejemplo : Un jugador envía una unidad de juego X del dominio A al dominio B. El servidor del dominio A envía un mensaje con el evento al servidor del dominio B. Mientras se procesa la cola de eventos, B recibe un mensaje y envía una solicitud a una cola de solicitudes en A para obtener datos sobre la unidad X y el permiso para controlar / modificar los datos de la unidad X. La cola de solicitudes tiene mayor prioridad y se manejará antes que otros eventos en el dominio A El dominio A envía los datos solicitados y el token de control a la cola de respuesta del dominio B con la mayor prioridad. Mientras tanto, el servidor del dominio B ya procesó otros 3 eventos, sin esperar en sesión.

• Nota: A debe quedar obsoleto, versión o eliminar datos sobre la unidad X en este punto. Si llega una solicitud de datos del dominio C, debe enviar esta solicitud al servidor B a partir de ahora.
• Nota: El ejemplo anterior se puede optimizar para enviar datos sobre la unidad X directamente con el evento correspondiente, pero quería un ejemplo simple para ilustrar.

Lo importante es que tendrá que diseñar el protocolo de encapsulación de datos, probablemente algún esquema XML. El protocolo para el manejo de eventos. Lista de eventos, respuestas permitidas, mensajes de error, recuperación. Esos son todos juegos específicos.

Answer 3

Consideraría seriamente Erlang y CouchDB, o implementarlo en el motor de aplicaciones de Google.

Answer 4

Si está realmente distribuido, supongo que no hay planes para un servidor central. Eso significa que lo que realmente está buscando es un mecanismo de comunicación entre los distintos servidores. REST y XML-RPC son mecanismos realmente simples para que los servidores puedan comunicarse entre sí para comunicar que un usuario necesita pasar de uno a otro.

También puedes usar algo como XMPP como dijo Daniel, pero eso significa que tienes que conectar otro conjunto de software de servidor a la mezcla junto con cualquier cosa que tengas que esté ejecutando el juego (lo que supongo de tu descripción es probablemente un servidor de aplicaciones web de algún tipo).

Desde un punto de vista de desarrollo, cualquier lenguaje / marco que sea fuerte para desarrollar aplicaciones web debería funcionar. Ruby on Rails, Python en Django, numerosos frameworks más Java, o incluso Cake w / PHP (ick) funcionarían para el trabajo de desarrollo.

En el pasado, he considerado algo como esto, pero los problemas de examinar los distintos servidores (es decir, cómo maneja un servidor que está roto o malicioso y permite que un jugador mueva simultáneamente la misma pieza a otros dos o tres servidores). ), tratar con servidores abandonados (lo que les sucede a los jugadores que existieron por última vez allí), etc. parecía muy difícil.

Answer 5

Creo que la primera pregunta a responder es si el juego es en tiempo real o por eventos, y si el cliente es el navegador o no. Parece que está impulsado por eventos, pero recuerde que el servidor no puede enviar los resultados a un cliente HTML simple de manera efectiva, solo a un applet de Java, a una película Flash incrustada, etc. Si tiene un cliente personalizado, no hay necesidad de usar un HTTP Sistema de estilo en el servidor, lo que significa que la comunicación entre servidor y servidor y servidor se puede realizar de la misma manera.

Answer 6

Debes echar un vistazo a " Gestión de intereses " documentos sobre juegos p2p, te enfrentarás a enfoques realmente interesantes. Google Schoolar te presentará muy buenos artículos.

Pero tenga cuidado, desarrollar aplicaciones distribuidas es mucho más complejo que los enfoques simples de servidor único.