Qual è l'architettura migliore per più server di gioco che devono dialogare?

Question

Il gioco è un gioco strategico a bassa grafica (SVG). Ogni server rappresenta un dominio di gioco con i suoi giocatori. Tutti i server dovrebbero essere in grado di parlare tra loro, poiché i giocatori possono spostarsi (nel gioco) da un dominio all'altro / inviare " messaggeri diplomatici " etc ..

Abbiamo scelto questa idea in quanto ci consente di allargare all'infinito la mappa del mondo, ci consente a seconde parti di collegare i loro server di gioco a noi e quelli allargano il mondo ancora di più. Se un server (e i relativi backup) falliscono, il gioco continuerà comunque a funzionare (un vero ambiente distribuito).

Siamo solo all'inizio. Quali sono le piattaforme là fuori che dovremmo guardare, che ci aiuteranno a sviluppare un mondo del genere?

Answer 1

XMPP, precedentemente noto come Jabber, potrebbe essere un buon punto di partenza.

Answer 2

Molto dipende da quanti dati vuoi condividere tra i server. Volete che ciascun server gestisca il proprio dominio, ma per quanto riguarda il database degli account, i dati su chi possiede quali informazioni, la topografia dei domini, questi dati saranno centrali e / o distribuiti e come li sincronizzerete. Quindi, a parte il funzionamento del gioco, esiste un'altra serie di metadati, di cui i server devono comunicare. Per quanto riguarda i dati di gioco, probabilmente passerai in giro eventi, oggetti dati e informazioni sulla proprietà e il controllo dei dati. Inoltre, ci devono essere alcuni metadati di clock nel gioco per mantenere sincronizzato il tempo dei domini.

Probabilmente userei un sistema di code asincrone con priorità diverse per metadati, richieste e messaggi di risposta. Protocollo come XMPP oltre allo scambio di messaggi può offrire informazioni sulla presenza, autenticazione, crittografia e altri vantaggi. Ma all'inizio, il protocollo di consegna stesso non è importante quanto la struttura dei messaggi e lo scambio di dati. In sostanza i protocolli di consegna sono intercambiabili.

Esempio : Un giocatore invia un'unità di gioco X dal dominio A al dominio B. Il dominio Un server invia un messaggio con un evento al server del dominio B. Durante l'elaborazione della coda di eventi, B riceve un messaggio e invia una richiesta a una coda di richiesta su A per i dati sull'unità X e l'autorizzazione a controllare / modificare i dati dell'unità X. La coda di richieste ha una priorità più alta e verrà gestita prima di altri eventi sul dominio A Il dominio A invia i dati richiesti e controlla il token alla coda di risposta del dominio B con la massima priorità. Nel frattempo il server del dominio B ha già elaborato altri 3 eventi, non in attesa in sessione.

• Nota: A dovrebbe essere obsoleto, versione o rimuovere i dati sull'unità X a questo punto. Se una richiesta arriva per i dati dal dominio C, dovrebbe inoltrare questa richiesta al server B d'ora in poi.
• Nota: L'esempio sopra può essere ottimizzato per inviare dati sull'unità X direttamente con l'evento corrispondente, ma volevo illustrare un semplice esempio.

L'importante è che dovrai progettare il protocollo di incapsulamento dei dati, probabilmente uno schema XML. Il protocollo per la gestione degli eventi. Elenco di eventi, risposte consentite, messaggi di errore, recupero. Sono tutti specifici del gioco.

Answer 3

Vorrei prendere seriamente in considerazione Erlang e CouchDB, o implementarlo con Google AppEngine.

Answer 4

Se è veramente distribuito, suppongo che non ci siano piani per un server centrale. Ciò significa che quello che stai veramente cercando è un meccanismo di comunicazione tra i vari server. REST e XML-RPC sono entrambi meccanismi davvero semplici per consentire ai server di comunicare tra loro per comunicare che un utente deve spostarsi l'uno dall'altro.

Potresti anche usare qualcosa come XMPP come ha detto Daniel, ma ciò significa che devi collegare un altro set di software server nel mix insieme a qualunque cosa tu abbia in esecuzione il gioco stesso (che suppongo sia dalla tua descrizione probabilmente un server di app Web di qualche tipo).

Dal punto di vista dello sviluppo, qualsiasi linguaggio / framework forte per lo sviluppo di app Web dovrebbe funzionare. Ruby on Rails, Python su Django, numerosi framework più Java, o Cake w / PHP (ick) avrebbero funzionato per il lavoro di sviluppo.

Ho considerato qualcosa del genere in passato, ma i problemi di controllo dei vari server (ovvero come gestire un server che è rotto o dannoso e consente a un giocatore di spostare simultaneamente lo stesso pezzo su due o tre altri server ), occuparsi di server abbandonati (cosa succede ai giocatori che sono esistiti l'ultima volta lì), ecc. sembrava molto impegnativo.

Answer 5

Penso che la prima domanda a cui rispondere sia se il gioco è in tempo reale o guidato dagli eventi e se il client è il browser o meno. Sembra che sia guidato dagli eventi, ma ricorda che il server non può inviare i risultati a un semplice client HTML in modo efficace, solo su un'applet Java, un filmato Flash incorporato, ecc. Se hai un client personalizzato, non è necessario utilizzare un HTTP stile sistema sul server, il che significa che la comunicazione server- > server e server- > client può essere fatta allo stesso modo.

Answer 6

Dovresti dare un'occhiata a " Gestione degli interessi " articoli sui giochi p2p, affronterai approcci davvero interessanti. Google Schoolar ti presenterà dei documenti davvero validi.

Ma attenzione, lo sviluppo di applicazioni distribuite è molto più complesso dei semplici approcci a server singolo.