Server di gioco C ++ distribuito che utilizza database

11

Il mio server di gioco a turni C ++ (che utilizza il database) non regge la quantità media corrente di client (giocatori), quindi voglio espanderlo a più (più di una) quantità di computer e database in cui rimarranno tutti i client mondo di gioco singolo (i server dovranno comunicare tra loro e utilizzare più database).

Esistono tutorial / libri / standard comuni che spiegano come farlo nel migliore dei modi?

server databases

— slavo
fonte

8

La terminologia MMO per "rimanere all'interno di un singolo mondo di gioco" è un singolo frammento . EVE online è l'unico MMO principale che tenta di inserire tutti i giocatori in un singolo frammento.

Per fortuna hanno pubblicato un articolo molto informativo su come lo fanno.

_{(fonte: gamasutra.com )}

Le cattive notizie Non è possibile applicare le tecniche di EVE online in generale. Le loro soluzioni sono assolutamente su misura per il loro particolare genere e implementazione.
NOTA : per tutta la superba rete single shard di EVE online usano un database. Non sono stati in grado di progettare una soluzione scalabile, coerente, moderatamente in tempo reale per database distribuiti.

In ogni caso, leggere come hanno fatto dovrebbe aiutarti a progettare la tua soluzione. Tuttavia, stai tentando di risolvere un problema molto difficile.

Invece di distribuire il tuo server di gioco, suggerirei prima di esplorare le tue altre strade.

Crea il profilo del tuo server di gioco.
- Ottimizza il codice del tuo server per ridurre l'onere della CPU se questo è un problema.
- Ottimizza il protocollo di comunicazione tra i client e il server per ridurre le chat di rete.
Ottimizza il server gamer per le comunicazioni del database.
- eseguire un Query Optimizer quindi apportare le modifiche appropriate.
- ridurre al minimo l'interazione tra DB
Spostare il DB su una macchina separata.
Questo spesso aiuta un sacco. Mantieni il DB sulla stessa rete locale, se possibile, ma ciò dovrebbe aiutare il tuo server di gioco a essere molto più instabile quando è l'unica cosa in esecuzione sull'hardware del server.

— deft_code
fonte

Come definisci "maggiore"? Kingdom of Loathing usa un singolo frammento. Tutti condividono lo stesso frammento di Farmville. Star Trek Online e Champions Online utilizzano entrambi un modello a frammento singolo, ma zone istanziate.

Invece di utilizzare un database SQL, è possibile utilizzare anche una soluzione noSQL progettata per il clustering e lo sharding, come MongoDB.

— Philipp

1

I web game di @JoeWreschnig non sono giochi in tempo reale, molto più facili ... Non sono sicuro di quanti giocatori hanno Star Trek Online e Champions Online ...

— o0 '.

4

La tua prima mossa dovrebbe essere il disaccoppiamento dell'accesso diretto al database dal server di gioco e l'utilizzo di un middleware specifico per l'utilizzo per preparare i dati per il tuo server (es. XML, JSON). Questi sarebbero in grado di gestire un numero qualsiasi di database e, soprattutto, di fornire opzioni di memorizzazione nella cache specifiche dell'applicazione. Metti in cache tutto ciò che puoi e infastidisci il db solo quando è necessario. Effettua grandi recuperi e raramente invece di molte piccole query per ottenere le migliori prestazioni possibili nel tuo scenario.

Il database di tua scelta potrebbe anche permetterti di gestire cluster che facilitano l'espansione delle risorse di database disponibili e forniscono i risultati più velocemente, ma questo è un argomento che richiede molta esperienza e un amministratore di database dedicato da configurare e mantenere - e neanche per il budget indipendente.

— Konrad K.
fonte

1

Tutto questo suona bene fino a quando non si considera che spera di avere più server che accedono a un set di dati - questo significa che senza ulteriore coordinamento, le cache sul lato dell'applicazione non saranno sincronizzate, portando nel migliore dei casi errori di gioco e perdita di dati nel peggiore dei casi. Non sono in disaccordo con qualsiasi cosa tu abbia detto, ma il poster originale dovrà considerare anche il problema della coerenza tra server prima di procedere.

— Kylotan,

Il middleware è un tunnel di dati che è da un lato responsabile della memorizzazione nella cache dei dati e anche della fornitura dei dati. Tuttavia, fornisce solo dati al server (mai al client) e il server memorizza nella cache tutti i dati anagrafici relativi al gioco all'avvio. Quindi ci possono essere molte fonti di dati e molti richiedenti di dati collegati in qualsiasi momento. L'MMO su cui lavoro utilizza questo schema in modo piuttosto efficiente.

— Konrad K.

Questo non spiega come hai risolto i problemi di coerenza tra server. Ad un certo punto i server devono sincronizzare i dati tra loro o si hanno condizioni di gara, che si manifestano come disconnessioni casuali, giocatori duplicati, oggetti ingannati, missioni mancanti, ecc.

I dati non vengono mai duplicati: in ogni momento esiste un solo server responsabile di un determinato oggetto e, quando richiesto, passa l'oggetto su un altro server. Gli oggetti sono connessioni client che includono anche l'oggetto di controllo del lettore. Tuttavia, questo viene fatto tramite un server master e viene discusso tra i server. Quindi abbiamo a che fare con due tipi di dati: informazioni sul database (a cui si riferisce il mio post originale) e oggetti di gioco che vengono creati in fase di esecuzione e passati in un mmo multi-server. Nessuno di questi dovrebbe mai cadere in una condizione di competizione o essere duplicato a livello di applicazione.

— Konrad K.

3

Per quanto riguarda il server di gioco: una strategia comune è quella di utilizzare più server in cui ciascun server gestisce una parte del mondo di gioco. Ogni utente di solito ha solo bisogno di sapere cosa succede intorno ad esso, quindi ha senso dividere il mondo per località. Questo purtroppo diventa molto più complicato quando hai un mondo aperto senza confini invece di un mondo che consiste in zone chiuse e giocatori si teletrasportano tra di loro. Quando hai un mondo aperto, hai bisogno di un modo per trasferire i giocatori tra le zone in modo continuo e un modo per sincronizzare le aree vicino ai confini tra i server. Questo è un problema difficile.

Per quanto riguarda il database: i database SQL di solito si adattano male. Non sono progettati per essere distribuiti. Ma attualmente esiste una tendenza piuttosto nuova dei database NoSQL come MongoDB o Cassandra, progettati per essere distribuiti su più server. Rendono molto più facile aggiungere capacità semplicemente aggiungendo più server. Quindi perché non tutti i grandi giochi passano a loro? Perché:

I database SQL esistono da oltre 40 anni, quei database NoSQL solo da pochi anni. Non c'è ancora molto know-how su come usarli in modo più efficiente e il loro sviluppo sta avanzando rapidamente. Ci sono molti prodotti concorrenti e completamente incompatibili sul mercato, e non vi è alcun segno di chi sopravviverà e quale sarà obsoleto e interrotto tra qualche anno. La maggior parte dei grandi giocatori preferisce le note carenze di SQL rispetto ai rischi sconosciuti dei database NoSQL.
Funzionano in modo molto diverso dai database SQL e richiedono di ripensare l'intera strategia di persistenza. Ciò potrebbe comportare cambiamenti drastici nell'intera architettura del software.

Quindi, quando il tuo progetto è già molto avanzato, il passaggio a un'altra soluzione di database potrebbe essere un grande rischio e un investimento molto grande di tempo ed energia.

— Philipp
fonte

0

No. Questa è un'area incredibilmente difficile che non è stata ancora risolta.

— Kylotan
fonte

Potrebbe esserci una soluzione "modello" (non come "modelli di progettazione C ++)? Ci sono molti MMORPG.

— Slav

2

La maggior parte degli MMO è supportata da catastrofi assolute per i database.

In particolare, gli MMO hanno spesso approcci molto diversi alla persistenza dei dati, che spesso funzionano in modo accettabile per il proprio design di gioco ma non per altri design di gioco. Poiché la progettazione del gioco è la parte più importante, non è possibile specificare adeguatamente una persistenza dei dati e una strategia di distribuzione senza una. (Che potrebbe essere interpretato come: "Poni una domanda più specifica, dicendoci che tipo di dati hai, con che frequenza cambia e perché pensi di voler distribuire un singolo mondo su più server.")

— Kylotan

0

So che questo è vecchio ma ...

In realtà ci sono due aree su cui concentrarsi.

È necessario distribuire l'applicazione su più server. È necessario distribuire il database su più server.

E devi avere ridondanza per entrambi.

Ci sono alcune soluzioni open source per questo. Farmville è un buon esempio usando MemSQL / Couchbase.

— KermEd
fonte

1

La distribuzione del database su più server è sicuramente un problema risolto. Sfortunatamente non è di solito un requisito importante per i giochi online che mantengono al minimo gli accessi ai loro DB. Al contrario, distribuire il gameplay effettivo su più server non è ancora un problema risolto.

— Kylotan,