Spiegazione su algoritmo alla base di un browser game

[lyllo]

Ciao gente.
Volevo chiedervi di togliermi una curiosità: vorrei capire come funzionano alcuni aspetti dei browser games.
Come si fa a visualizzare la lista di utenti online e farli interagire in tempo reale senza, ad esempio sovraccaricare troppo il server ed il db mysql?
Voglio dire, ammesso che ci sia un'area di "incontro", in teoria basta inserire l'ID del giocatore in una tabella temporanea quando clicca sul link x entrare nell'area. Ma così si avrebbe il problema che se si disconnette, magari chiudendo il browser, il dato rimane nel db anche se è falso.. Senza poi contare la mole di query che deve sostenere il server...
Oppure, se due giocatori interagiscono, c'è un modo x far visualizzare a tutti gli altri in tempo reale eventuali cambiamenti? Che so, se uno dei due muore si potrebbe far apparire un teschietto nella pagina che riporta la lista dei giocatori, sulla sua foto, in tempo reale?
È giusto l'approccio secondo cui tutti gli eventi di una durata elevata, tipo le famose miniere in oGame, devono essere inserite nel database come calcolo del tempo di completamento e quindi come confronto dei dati al momento del ritorno online del giocatore?

Grazie!
Sono curioso di capire delle cosette
ciao ciao

[lyllo]

Tutto tace ?

[Ocerusico]

Premetto che partecipo pur non essendo molto ferrato sull'argomento, ma la cosa incuriosisce molto anche me.

Originariamente inviato da lyllo
Voglio dire, ammesso che ci sia un'area di "incontro", in teoria basta inserire l'ID del giocatore in una tabella temporanea quando clicca sul link x entrare nell'area. Ma così si avrebbe il problema che se si disconnette, magari chiudendo il browser, il dato rimane nel db anche se è falso..

Se gestisci le sessioni con il db dopo un tot di inattività l'ID viene comunque eliminato dall'eventuale tabella giocatori_on_line .

Originariamente inviato da lyllo
Oppure, se due giocatori interagiscono, c'è un modo x far visualizzare a tutti gli altri in tempo reale eventuali cambiamenti? Che so, se uno dei due muore si potrebbe far apparire un teschietto nella pagina che riporta la lista dei giocatori, sulla sua foto, in tempo reale?

Con ajax credo.

[lyllo]

resto allora in attesa di un qualche feedback più esaustivo

grazie cmq per l'interessamento

in merito alla gestione delle sessioni col DB, non ho idea di come si possa fare.
o meglio, posso capire che al login scrivo nel db dei giocatori online, inserendogli un temporaneo campo per l'id della sessione, ma
1) a parte che ad ogni caricamento dovrei fare una query al db per prelevarmi l'id,
2) se pure la sessione dopo un pò scade, non c'è alcun trigger per aggiornare il db facendogli rimuovere il pg "Inattivo"...

il punto di ajax è solo in parte giusto, perchè ajax cambia in "tempo reale" la pagina all'utente che vi sta interagendo, facendo però una sorta di chiamata all'handler ajax.
se io semplicemente sto con una pagina aperta e non attivo alcun evento, mi sa che non funge...

[cigiri18]

premetto che pure io non mi sono mai applicato seriamente all'argomento, però ci avevo ragionato di mio tempo fa, quindi bene o male mi ero capito(avevo provato a creare una versione tutta mia di ogame partendo da zero ).

ogame è estremamente banale come gioco online: per sapere se un giocatore è online basta memorizzare l'ora dell'ultima azione eseguita, e infatti è quello che fa, inoltre interagisce col server solo quando l'utente apre una nuova finestra, per il resto è tutto gestito in javascript.

per giochi più complicati, che comunque non sono realizzati tramite browser, ma come normalissimi programmi, il problema di base è l'elevato numero di query: se per esempio il gioco si svolge su mappe(vedi i mmorpg), e su una mappa ci sono due tizi connessi, bisognerà aggiornare il database ad ogni mossa di questi tizi, e i programmi di questi due tizi dovranno leggere dal database ogni unità di tempo, per verificare eventuali cambiamenti del contesto.

quindi il problema è il numero di query inumano, ma li l'unica soluzione che mi viene in mente è avere un buon server e una buona connessione

tornando ai browser game credo tu possa comunque sfruttare l'ajax: col javascript puoi creare un timer, quindi ad ogni aggiornamento di questo connetti al db e scarichi quel che ti serve.

[daniele_dll]

Originariamente inviato da cigiri18
premetto che pure io non mi sono mai applicato seriamente all'argomento, però ci avevo ragionato di mio tempo fa, quindi bene o male mi ero capito(avevo provato a creare una versione tutta mia di ogame partendo da zero ).

ogame è estremamente banale come gioco online: per sapere se un giocatore è online basta memorizzare l'ora dell'ultima azione eseguita, e infatti è quello che fa, inoltre interagisce col server solo quando l'utente apre una nuova finestra, per il resto è tutto gestito in javascript.

Beh, è un browser game: o aggiorni lo stato ricaricando la pagina oppure usi ajax/ahah/json per interfacciarti con le pagine del gioco per effettuare le operazioni e nel contempo ricevere le informazioni aggiornate sulla pagina

per giochi più complicati, che comunque non sono realizzati tramite browser, ma come normalissimi programmi, il problema di base è l'elevato numero di query: se per esempio il gioco si svolge su mappe(vedi i mmorpg), e su una mappa ci sono due tizi connessi, bisognerà aggiornare il database ad ogni mossa di questi tizi, e i programmi di questi due tizi dovranno leggere dal database ogni unità di tempo, per verificare eventuali cambiamenti del contesto.

quindi il problema è il numero di query inumano, ma li l'unica soluzione che mi viene in mente è avere un buon server e una buona connessione

non si usa un database per come lo intendi tu, esploderebbe tutto: di solito uno dei componenti del server fa da storage, ovvero ricevere le informazioni da aggiornare e restituisce le informazioni, il tutto in memoria ... ovviamente ogni TOT di tempo (mezz'ora, un'ora, 2 volte al giorno e via dicendo) serializza tutti i dati presenti in memoria sul disco

Inoltre, in quel tipo di gioco, è molto importante il discorso "visuale": non serve far sapere ad un giocatore che non può vederti che ti sei spostato!

tornando ai browser game credo tu possa comunque sfruttare l'ajax: col javascript puoi creare un timer, quindi ad ogni aggiornamento di questo connetti al db e scarichi quel che ti serve.

non è conveniente nemmeno questo, o meglio, si, ma con le pinze! Un'aggiornamento con un timer è MOLTO più pesante del semplice caricamento di una pagina perché vuol dire che ogni n secondi ci sarà una richeista che comporterà delle operazioni.

La cosa va scomposta in due sotto problemi: tenere aggiornato il client sulle risorse e sulla loro produzione e tenere aggiornato il client sugli eventi (eventi come messaggi, attacchi, difese, costruzioni completate e via dicendo).
Visualizzare lo stato delle risorse non richiede, di per sé, fare continue richieste si può benissimo incrementare il totale delle risorse possedute tramite il client stesso sapendo quanto viene prodotto ogni ora: se produco 3600 all'ora, vuol dire che ogni secondo produco 1 e quindi ogni secondo incremento il contatore di quella data risorsa ... ovviamente è solo un fatto "visuale", il server comunque gestisce tutto per i fatti suoi. Il discorso cambia per gli eventi: questi devono essere comunicati dal server.
Usare un timer ogni minuto, ogni 5 minuti o simili può essere una buona idea: si richiede solo un'aggiornamento dello stato, nulla di nuovo. E' normale che non c'è motivo che il timer scatti se l'utente svolge qualche operazione perché in quel caso il server può mandare gli aggiornamenti che avrebbe richiesto con il timer

In realtà un browser game non è più semplice perché è un browser game, ma perché, in genere, non vi sono giochini online che ad esempio tengono conto al 100% dello stato di ogni singola unità (esperienza, energia e via dicendo) a cui associato un consumo di risorse per viaggiare o essere riparate, cosi come non vi sono giochini online che ad esempio nei paesaggi tengono in considerazione i dislivelli del terreno o che tengano conto dei fiumi e via dicendo ... cosi continuando tutti i giochi online di questo tipo non permettono di costruire il proprio villaggio sulla mappa, lo fanno costruire all'interno di una cella che "aperta" mostra il villaggio ... e cosi via ^^ tutte queste cose rendono un browser game moltooo più semplice di quello che sembra

[cigiri18]

non è conveniente nemmeno questo, o meglio, si, ma con le pinze! Un'aggiornamento con un timer è MOLTO più pesante del semplice caricamento di una pagina perché vuol dire che ogni n secondi ci sarà una richeista che comporterà delle operazioni.

La cosa va scomposta in due sotto problemi: tenere aggiornato il client sulle risorse e sulla loro produzione e tenere aggiornato il client sugli eventi (eventi come messaggi, attacchi, difese, costruzioni completate e via dicendo).
Visualizzare lo stato delle risorse non richiede, di per sé, fare continue richieste si può benissimo incrementare il totale delle risorse possedute tramite il client stesso sapendo quanto viene prodotto ogni ora: se produco 3600 all'ora, vuol dire che ogni secondo produco 1 e quindi ogni secondo incremento il contatore di quella data risorsa ... ovviamente è solo un fatto "visuale", il server comunque gestisce tutto per i fatti suoi. Il discorso cambia per gli eventi: questi devono essere comunicati dal server.
Usare un timer ogni minuto, ogni 5 minuti o simili può essere una buona idea: si richiede solo un'aggiornamento dello stato, nulla di nuovo. E' normale che non c'è motivo che il timer scatti se l'utente svolge qualche operazione perché in quel caso il server può mandare gli aggiornamenti che avrebbe richiesto con il timer
In realtà un browser game non è più semplice perché è un browser game, ma perché, in genere, non vi sono giochini online che ad esempio tengono conto al 100% dello stato di ogni singola unità (esperienza, energia e via dicendo) a cui associato un consumo di risorse per viaggiare o essere riparate, cosi come non vi sono giochini online che ad esempio nei paesaggi tengono in considerazione i dislivelli del terreno o che tengano conto dei fiumi e via dicendo ... cosi continuando tutti i giochi online di questo tipo non permettono di costruire il proprio villaggio sulla mappa, lo fanno costruire all'interno di una cella che "aperta" mostra il villaggio ... e cosi via ^^ tutte queste cose rendono un browser game moltooo più semplice di quello che sembra

si ok, ma io il discorso l'avevo fatto pensando ad un browser game che avesse bisogno di aggiornamenti periodici(tipo la mappa in cui vedi gli eserciti di non ricordo più che gioco[quello in cui si possono avere città realmente esistenti]), ovvio che per le risorse di ogame usi strumenti lato client.

per tutto il resto riconfermo la mia ignoranza in merito, io un programma simile l'avevo solo pensato a suo tempo, non avendo mai trovato articoli né nulla al riguardo mi sono dovuto arrangiare ^^ (è anche per questo che non l'ho mai messo in atto: richiedeva un numero improponibile di query)

[daniele_dll]

Originariamente inviato da cigiri18
si ok, ma io il discorso l'avevo fatto pensando ad un browser game che avesse bisogno di aggiornamenti periodici(tipo la mappa in cui vedi gli eserciti di non ricordo più che gioco[quello in cui si possono avere città realmente esistenti]), ovvio che per le risorse di ogame usi strumenti lato client.

anche in questo caso, si fa come ti ho detto prima

immagina tu quante richieste arriverebbero ogni secondo: scoppierebbe tutto! Siccome si tratta solo di un problema di "visualizzazione" e non di funzionalità lato server, queste informazioni si fanno calcolare direttamente al client (ripeto, solo esclusivamente visive e non influiscono su nulla anche se il gioco viene modificato per fare strane robe!) e quindi tu gli passi di nuovo il punto di partenza, il punto di arrivo e l'orario di arrivo ... a ogni "aggiornamento" di stato gli passi di nuovo il punto di partenza, il punto di arrivo e l'orario di arrivo ... in questo modo ci pensa direttamente il client a visualizzare tutto



ovviamente una richiesta ogni tanto è importante farla sia per via delle sessioni sia per via del fatto che qualche aggiornamento ogni tanto gli deve arrivare all'utente, ma già facendole con una scadenza di 5 minuti, secondo me, siamo assolutamente apposto

il problema, al massimo, e far si che non siano 5 minuti esatti ma dai 4 minuti e 30 ai 5 minuti e 30 cosi che il server non si veda recapitare, ogni tot, una massa di richieste tutt'insieme (certo, arrivano lo stesso, ma in quel modo, statisticamente, ne arrivano di più in dati momenti)