Quali tecniche consentono ai giochi basati sul Web di aggiornare frequentemente le risorse del giocatore?


8

Molto tempo fa c'era questo gioco basato sul web chiamato Utopia (e sono sicuro che sia ancora in circolazione), i turni sono all'ora. Ottieni solo nuovo oro / legname o cosa non ogni ora.

Alcuni nuovi giochi basati sul web hanno risorse che aumentano con una risoluzione più fine, come al minuto. Quindi supponiamo che un giocatore abbia un tasso di produzione di cibo di 5 al minuto: il giocatore aumenterà la sua quantità di cibo ogni minuto. Non sono sicuro se sia saggio impostare costantemente un lavoro CRON per aggiornare il database SQL, che presumo sia quello che stanno usando, poiché è basato sul web. Forse mi sbaglio, ogni minuto.

Quali tecniche usano quei giochi basati sul web? Aggiunto su Modifica: e il database può davvero gestire il carico?

Risposte:


7

Mi sembra che potresti semplicemente memorizzare i tassi di produzione, il livello di risorse di base e un timestamp aggiornato per ultimo. Quindi, ogni volta che è necessario conoscere il livello effettivo delle risorse, è possibile semplicemente moltiplicare il tasso di produzione per il tempo trascorso.

Ogni volta che il livello effettivo delle risorse cambia: è sufficiente aggiornare il livello base. Ogni volta che la velocità di produzione cambia, aggiorna il livello base al livello effettivo e il timestamp all'ora corrente.

In questo modo, invece di aggiornare ogni giocatore (presumibilmente compresi quelli non attualmente registrati) ogni minuto, stai aggiornando solo le righe che vengono effettivamente utilizzate attivamente dai giocatori.

(Se il tuo gioco "spunta" una volta al minuto, immagino che un "numero di svolta" di qualche tipo potrebbe essere migliore di un vero e proprio timestamp.)

Un vantaggio di questo sistema è che puoi usare la stessa logica usata per aggiornare il database e prevedere i valori senza modificarli - per inviare solo le informazioni necessarie al client (piuttosto che aggiornare una volta al minuto) e per prevedere valori sul client.


3
Questo in realtà richiede una certa comprensione della matematica complessa in alcuni casi. Prendi in considerazione la possibilità di guadagnare interessi in denaro: aggiungere un interesse dell'1% una volta al mese non equivale ad aggiungere un interesse del 12% una volta all'anno. Secondo esempio, se la probabilità che un evento si verifichi in un determinato minuto è del 10%, la probabilità che si verifichi dopo 10 minuti non è del 100%. È interessante notare che questa è solo una dimostrazione molto lenta dei problemi di fisica che le persone vedono in altri giochi, e lo stesso metodo può essere usato per affrontarli, ad es. utilizzare un timestep fisso ed eseguirlo tutte le volte che è necessario per "recuperare".
Kylotan,

7
Kylotan, non classificherei l'interesse composto e le molteplici probabilità di probabilità come matematica complessa. : P
L'anatra comunista,

1
È un punto valido. Ma spero che chiunque implementi la produzione di risorse non lineari nei propri giochi capisca come funziona;)
Andrew Russell,

2
Ma non è necessario, se utilizzano il vecchio aggiornamento periodico. Questo è l'intero problema che sto riscontrando: l'utilizzo di questo metodo introduce un nuovo potenziale errore che prima non era possibile.
Kylotan,

2
Non potresti utilizzare un processo iterativo per assicurarti che tutto venga applicato correttamente? Quando un giocatore accede, "attiva" ciascuna delle risorse che poi si innescano in un ciclo fino a quando l'ora successiva non è successiva all'ora corrente del sistema. Forse un po 'più dispendioso in termini di risorse, ma dovrebbe occuparsi della maggior parte dei sistemi non lineari.
Lunin,

5

I moderni database SQL comunemente utilizzati (MySQL, Postgres, Oracle, MSSQL, ecc.) Consentono di pianificare l'esecuzione di procedure memorizzate con intervalli di tempo arbitrari. È un metodo molto leggero per eseguire aggiornamenti come questo e rimuove la necessità di invocare script o programmi esterni per farlo per te.

Ciò consente inoltre al database di ottimizzare la query eseguita una sola volta, invece di farlo ogni volta che lo script esterno lo richiama, quindi è molto utile dal punto di vista delle prestazioni. Ovviamente questo vale solo se gli aggiornamenti sono abbastanza banali da essere programmati nel proprio linguaggio di scripting del database. Aggiornamenti delle risorse, disconnessioni automatiche degli intervalli di tempo, eliminazione dei record e simili sono candidati eccellenti per queste stored procedure programmate.

Molto probabilmente il carico che sta riscontrando il tuo database proviene dal 99,9% da caricamenti di pagine, aggiornamenti del motore di gioco e simili, poiché un gioco popolare può facilmente avere centinaia di migliaia di query al secondo. Rispetto al carico che deriva dall'esecuzione di alcune query (sebbene quelle che toccano gran parte di una tabella) una volta al minuto, il carico non dovrebbe essere un problema. Cioè, a meno che non si aggiornino i valori indicizzati dal database. Dovresti evitare di aggiornare le colonne indicizzate a tutti i costi se ti preoccupi delle prestazioni.


2

Per quanto riguarda gli aggiornamenti:

Alcuni usano lavori CRON che colpiscono una determinata pagina PHP ogni tanto.

Alcuni usano lavori CRON, questa volta eseguendo un certo processo.

Un altro approccio è quello di fare aggiornamenti "just in time" - ogni volta che viene caricata una pagina, eseguire tutti gli aggiornamenti in sospeso ed eseguirli a quel punto. Questo è generalmente ciò che devi fare se non riesci a eseguire lavori CRON o processi di lunga durata.

Infine, altri stanno eseguendo l'intera applicazione Web come un processo, in modo che possano aggiornare ogni volta che vedono che è il momento.

Il sistema finale è il migliore se hai quell'opzione disponibile in quanto puoi archiviare i dati in memoria. L'aggiornamento di alcune migliaia di giocatori una volta al minuto è banale se stai semplicemente modificando i dati nella RAM piuttosto che dover scrivere su un database SQL tradizionale.

Ma se non hai quel lusso, puoi usare una sorta di cache. Qualcosa come memcached può essere un'opzione (dipende dal tuo hosting) che è un punto a metà strada tra la memoria e un database. È possibile memorizzare valori transitori in memcache e salvarli nel DB solo quando assolutamente necessario.

Tra memcache e un database SQL tradizionale ci sono altre opzioni, ad es. i vari negozi chiave / valore o negozi di documenti: cose come MongoDB , CouchDB , le offerte Amazon o Google, ecc ... vale a dire. tutti i sistemi con il termine NoSQL . Questi in genere non offrono il potere di interrogazione generico né sempre le stesse garanzie di sicurezza di un database tradizionale ma spesso sono molto più veloci nel funzionamento. (Il che non è così sorprendente, perché stanno facendo di meno per te.)

Ma tutto ciò presuppone che un normale database non sia in grado di gestire il carico. In effetti, nella maggior parte dei casi probabilmente può. Se devo inviare 10.000 chiamate UPDATE al minuto per aumentare i livelli di risorse, non è molto scalabile una volta che inizi ad aggiungere tutto il resto. Ma se lo cambi per aggiornare la risorsa per tutti con 1 chiamata SQL, improvvisamente le cose sembrano molto più positive. Quindi non sopravvalutare il costo di una determinata funzionalità, poiché spesso può essere implementata in una forma più efficiente.


0

Sono a favore di KISS : "Keep It Simple, Stupid!"

Non vedo alcun motivo per cui un lavoro cron non funzioni, e il lato positivo è che le opzioni di web hosting a basso costo spesso non ti consentono di eseguire direttamente i comandi, ma ti consentono di eseguire comandi cron. Quindi non è necessario un server dedicato costoso.

Puoi anche fare il tuo codice di aggiornamento in PHP o nella tua lingua preferita, usando il comando cron o usando il browser di testo. Le istruzioni in Configurazione dei lavori cron hanno diversi comandi di esempio che è possibile utilizzare per eseguire il ping della propria pagina a intervalli.wget --spider http://yoursite.com/secretphppage.phplynx


Immagino di essere più preoccupato per un lavoro CRON che viene eseguito ogni minuto aggiornando i dati di alcune centinaia di utenti contemporaneamente.
Extrakun,

1
Un aggiornamento a diverse centinaia di set di dati una volta al minuto non è un problema per un database moderno. Non so come siano le tue query, ma una singola chiamata "AGGIORNA" dovrebbe comunque funzionare bene anche con migliaia di righe interessate.
Bummzack,

E in quale mondo un lavoro cron è considerato "semplice"? Se non sei un amministratore di sistema probabilmente ti arrabbierai solo guardando il suo file di configurazione ...
o0 '.

Il mondo dei webhost, in cui non (di solito) ti danno l'accesso SSH, quindi devono fornire un'interfaccia semplice a Cron. Il mio webhost (Lunarpages) usa Cpanel e lo trovo abbastanza facile da usare: img822.imageshack.us/img822/7022/easycron.png
Ricket,

0

Ricordo di aver dato un'occhiata al codice di un clone di Planetarion. Tutto è in PHP, ma il codice ticker è in C grezzo, con i collegamenti C MySQL. Poiché il modello di dati era molto semplice, gli aggiornamenti avvengono molto velocemente.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.