È evidente come questo approccio creerebbe un cortocircuito di parecchie letture dalla Tabella 4.

Si potrebbe pensare che sia necessario semplicemente archiviare i dati appena calcolati dopo aver archiviato una nuova voce del registro. E sulla carta potrebbe anche sembrare una buona soluzione, ma potrebbe portare a un'incoerenza dei dati e a un degrado della performance. Un esempio di un possibile degrado della performance è che il sistema sarebbe impegnato a ricalcolare e archiviare i dati, spesso per la necessità di leggerli e quindi scriverli. Ma noi dobbiamo bilanciare i calcoli, dovendo al contempo fornire prestazioni adeguate per il gioco a tutti i giocatori e le giocatrici.

Un esempio di incoerenza dei dati riguarderebbe i conti di fine partita. La nostra infrastruttura server e la nostra piattaforma supportano i messaggi "in ritardo". Un esempio potrebbe essere un problema temporaneo tra due centri di dati (A e B) che fa sì che il messaggio che fornisce a giocatori e giocatrici l'esperienza per il suo Mini venga inviato da A ma non venga immediatamente consegnato a B. Immagina questo scenario: stai giocando una partita subito prima di mezzanotte. Giochi e vinci. È mercoledì e sono le 23:59. Il processore di rollup è stato configurato per essere eseguito quotidianamente per tutti i dati fino al giorno corrente. Quindi, il processo dovrebbe iniziare a mezzanotte e calcolare i valori totali dell'esperienza fino a giovedì alle 00:00. Questi dati verrebbero archiviati nella seconda tabella e le nuove letture sull'esperienza cercherebbero l'ultimo valore memorizzato, riassumendo tutto dopo giovedì alle 00:00. Quello che succede con un messaggio "in ritardo" è che noi lo riceveremmo, ma noteremmo che la partita è finita mercoledì alle 23:59 e quindi scriveremmo la voce dell'esperienza con quell'ora. La tabella di rollup non includerebbe questa voce e anche la query per i dati successivi non mostrerebbe questa voce. Questi dati incompleti sarebbero un problema. E che dire dei messaggi che arrivano con giorni di ritardo? Be', abbiamo messo in atto un sistema di monitoraggio e avvisi in atto che garantisce quasi sempre che queste nuove informazioni vengano elaborate in tempo per il successivo rollup.

Calcolare i livelli dei Mini

Tornando a guardare la tabella dell'esperienza totale, noterai che non vengono calcolati i livelli, lì. C'è solo il totale della quantità di esperienza acquisita. Separatamente, c'è una tabella statica impostata dal team di progettazione che assomiglia a quella che segue. Un Mini inizia al livello 1 e quando ottiene 1 punto d'esperienza diventa di livello 2. Poi, servono 3 punti d'esperienza per raggiungere il livello 3.

La combinazione dei due elenchi di dati ci consente di calcolare quale sia il livello effettivo di un Mini facendo un totale parziale e ottenendo questo set di dati finale:

Il team di progettazione ha un certo margine di manovra, quando si tratta di modificare la quantità di esperienza necessaria per salire di livello. Può decidere che è troppo difficile salire di livello ai livelli bassi e diminuire quindi l'esperienza necessaria per salire al livello successivo. Quindi, senza apportare modifiche ai dati di giocatori e giocatrici salvati nel database, i Mini otterrebbero tutti un leggero aumento del livello attuale e avrebbero bisogno di accumulare meno esperienza per passare al livello successivo. Il processo funziona anche nell'altro senso. Se un giorno il team di progettazione valuta che i livelli salgono troppo rapidamente, può decidere di aumentare i relativi valori e non fornire più alcuna esperienza aggiuntiva, ripristinando i Mini ai livelli precedenti al cambiamento. Il che non significa che non potrebbe concedere un po' di esperienza aggiuntiva ai Mini per alleviare i momenti più difficili.

Approcci alternativi

Prima di utilizzare la soluzione attuale, abbiamo esaminato diversi approcci per archiviare l'esperienza ottenuta e calcolare il risultante livello dei Mini. Alcuni portavano a tempi di inattività aggiuntivi che avrebbero potuto alterare l'esperienza di giocatori e giocatrici, mentre altri erano migliori perché fornivano una buona esperienza di gioco e tenevano il passo con la progressione di giocatori e giocatrici.

"Archiviare sempre il livello del Mini, l'ESP e i punti mancanti al livello successivo"

E se avessimo utilizzato un semplice modello SQL standard e degli aggiornamenti transazionali? Gli aggiornamenti transazionali consentono di aggiornare un insieme di dati nella loro interezza, come tutti o nessuno. Se non si riesce a scrivere un dato, vengono ripristinati tutti i dati al valore originale. Per questo si usa spesso l'acronimo A.C.I.D. (atomicity, consistency, isolation, durability), che evidenzia le caratteristiche di atomicità, consistenza, isolamento e resistenza.

Questo sistema utilizzerebbe una singola riga per mantenere l'esperienza e il livello totale di ogni Mini, rendendo le letture molto leggere.

Man mano che ogni Mini ottiene esperienza, il sistema aggiorna il Mini a 2 punti d'esperienza con 8 punti mancanti e il suo livello a 3. Una modifica di questo tipo impone una lettura dei dati, un ricalcolo e quindi una scrittura nel database. Uno schema che non funziona bene con Cassandra e i suoi punti di forza. Un altro problema con questo approccio è che la modifica delle quantità di esperienza necessaria per salire di livello richiederebbe di mettere il gioco offline per poter modificare i dati per tutti i Mini e per tutti i giocatori e le giocatrici.

"Archiviarlo come percentuale"

Abbiamo anche pensato di archiviare una percentuale per il livello successivo, per esempio:

Quindi, dopo una partita, dovremmo fare dei rapidi calcoli. Per esempio, se il Bruto Gnoll ottiene +3 ESP, la percentuale è +3/10. Quindi, al Bruto Gnoll daremmo il 30% di un livello, e questi sarebbero i risultati:

Avremmo la flessibilità necessaria per cambiare la curva di livello dei Mini, senza comportare alcun cambiamento di livello per quel Mini. Questo sistema ci fornirebbe anche una visualizzazione più semplici nell'interfaccia utente del gioco, poiché dovremmo semplicemente riempire il 30% di una barra, senza bisogno di calcoli matematici aggiuntivi. Tuttavia, questo tipo di modello comporterebbe percentuali molto piccole ai livelli più alti. Se un Mini ottiene 10 ESP per partita e occorrono 100.000 ESP per salire di livello, quel valore sarebbe uno 0,01%. Le CPU (Central Processing Units) possono gestire queste fluttuazioni, ma la precisione e l'accuratezza possono produrre diversi errori, se non si tiene conto della natura dei calcoli matematici con virgola mobile.

Alla prossima...

Sono state prese in considerazione diverse opzioni per la tecnologia dei database, quali strumenti potessero essere forniti e, infine, come archiviare e calcolare i dati. Come per qualsiasi cosa ancora in fase di sviluppo, potremmo dover cambiare tutto in seguito, se dovessimo trovare qualcosa che funziona ancora meglio, ma tutto questo ci è sembrato un buon punto di partenza per questo gioco.

Grazie per aver partecipato a questo aggiornamento sulla programmazione!

~ Andy Lim