Formato del registro di gioco per server MMO

Un registro degli eventi di gioco (al contrario dei registri errori / debug) per un intero cluster / frammento è molto utile per un MMO commerciale che si trova in un ambiente di produzione dal vivo, fornendo un supporto vitale per il servizio clienti e i mezzi per l'analisi storica.

Il progetto a cui sto attualmente lavorando utilizza un database relazionale per archiviare tutti i registri degli eventi di gioco e, sebbene quel metodo funzioni bene, mi sembra che la natura cronologica di sola lettura dei registri consentirebbe un formato di archiviazione più efficiente .

Tuttavia, non sono sicuro da dove iniziare a conoscere la creazione di formati di log binari personalizzati. Quali sono le tue esperienze con la creazione di formati di registro personalizzati o articoli / articoli consigliati sull'argomento?

In Stendhal abbiamo risolto il problema delle prestazioni aggiungendo eventi di gioco a una coda e quindi elaborandoli in modo asincrono in background .

Nel nostro caso gli eventi non sono solo record ma oggetti che hanno un po 'di logica perché in alcuni casi dobbiamo fare due inserti con un collegamento tra loro. Ad esempio, la prima volta che un oggetto viene gestito nel gioco, deve essere inserito nella tabella degli oggetti prima di poter registrare un evento-oggetto.

Ma scrivere il registro è solo un lato del problema:

A quali domande vuoi rispondere con i registri?

È facile leggere il registro completo in ordine cronologico; o per filtrarlo per un giocatore.

Ma potrebbero esserci domande come:

• Quali oggetti ha messo Anton sul terreno che sono stati ritirati ieri da Beth? Quale giocatore li possiede ora? (Anton si è lamentato del furto del suo oggetto)
• Di quanto tempo ha bisogno un giocatore medio per raggiungere il livello 100? Quali giocatori sono stati significativamente più veloci? solo per i primi personaggi?
• Ci sono giocatori che gestiscono enormi quantità di denaro per il gioco? A quali giocatori è passato? Senza nulla di prezioso in cambio?
• I giocatori deboli sono in grado di uccidere creature forti che non dovrebbero essere in grado di uccidere legalmente?
• ...

In Stendhal utilizziamo un database relazionale per i registri dei giochi perché è il modo più semplice per consentire query ad hoc performanti. Se si utilizza un formato di registro personalizzato, in pratica è necessario codificare tutte quelle query in caso di necessità. E farlo con prestazioni sufficienti diventa piuttosto difficile.

La nostra tabella gameEvents ha 51.429.139 righe (l'anno scorso) e abbiamo una tabella di itemlog dedicata che ha 60.360.657 righe (sempre) per 15.893.831 articoli.

Cosa intendi per efficienza? Che si tratti di dimensioni su disco o velocità di query, un database relazionale sarà quasi sicuramente in grado di battere o eguagliare il formato binario proprietario ed essere molto più semplice e flessibile da usare.

Ogni tabella che usi in un DB relazionale ti consente di specificare esattamente al byte lo spazio per riga che intendi consentire. Se non stai registrando testo normale - e "registro degli eventi di gioco (al contrario dei registri errori / debug)" implica che non stai, o almeno non è necessario, l'approccio di campo a larghezza fissa di un il database relazionale è piuttosto vicino all'ottimale in termini di spazio, il che li rende piuttosto veloci in primo luogo. Inoltre, i database relazionali sono molto utili per creare indici per un accesso molto veloce e ottimizzare le query per sfruttarli al meglio.

Quindi consiglierei di attenermi a quello che hai.

È vero che probabilmente potresti salvare qualche byte con un formato personalizzato, o mai solo il testo compresso, lo spazio di archiviazione è economico, quindi non vale più la pena ottimizzarlo. Ciò che è più importante è occuparsi di cose come il buffering e l'interrogazione degli I / O, entrambi i quali un server SQL standard probabilmente fa abbastanza bene. Se funziona per te su quei fronti, correrei con esso. Abbiamo scritto il nostro server di log di buffering che scrive su file personalizzati e quindi ha un programma parser separato per leggerlo in un database per le query, non lo consiglierei.

I database relazionali in questi giorni vengono eliminati per essere inefficienti, ma quando si memorizza il tipo di log di cui si sta parlando, non è davvero necessaria efficienza perché non saranno costantemente accessibili dal gioco o dai suoi utenti - solo il tuo team avrà bisogno per leggere i dati.

Quindi "l'efficienza" non ha molta importanza. Ciò che conta di più è ordinare i dati in modo da rendere semplice la storia di ciò che gli utenti stanno facendo nel gioco. I tuoi sviluppatori dovranno generalmente consumare questi dati e visualizzarli in un'interfaccia che è facile da leggere per gli analisti e gli analisti a volte dovranno interrogare i dati per approfondire il comportamento degli utenti. Ad esempio, se i giocatori acquistano un determinato articolo prima di un aggiornamento, ma smettono di acquistarlo dopo un aggiornamento, un analista trarrà vantaggio scrivendo alcune query che espongono determinati numeri sul comportamento che circonda quell'acquisto per determinare perché gli utenti non lo acquistano più. È meglio se hanno un linguaggio di query standard con cui lavorare è ben documentato. Se devono trasformare queste query in un formato binario personalizzato, i loro lavori diventeranno MOLTO più difficili,

Generalmente gli eventi di gioco sembrano simili a questo (questo è il formato di DeltaDNA in particolare)

{
 "eventName":"specific event code – eg. gameStarted",
 "userID":"ABCD1-4321a879b185fcb9c6ca27abc5387e914",
 "sessionID":"4879bf37-8566-46ce-9f3b-bd18d6ac614e",
 "eventTimestamp":"yyyy-mm-dd hh:mm:ss.SSS",
 "eventParams":
  {
   "platform":"WEB",
   "param1":"stringParam",
   "param2":true,
   "param3":1234,
   "param4":["a","b","c"]
  },
}

L'evento di solito include un nome di evento, un ID utente, un ID di sessione, data e ora e parametri che consentono di registrare tutti i dati che ritieni utili per registrare intorno a quell'evento. E nella mia esperienza, i formati di database relazionali sono i migliori per la registrazione di una tale struttura.