Ragionamento script

[damy11]

Ciao a tutti devo realizzare uno script per il mio sito simile a quello presente nei browser game o nei giochi online...
Praticamente in molti browser game tu puoi ad esempio mettere a lavoro il tuo personaggio e dopo 8 ore viene aumentato il denaro a disposizione,ma come viene strutturato uno script del genere?
Io ad esempio ho pensato che un utente clicca sul bottone per avviare l'azione e viene registrata nel database la data nel momento in cui ha cliccato + un tot. di ore,ma come faccio poi alla fine delle ore passate ad aumentare ad esempio il denaro di un personaggio?

Spero di essere riuscito a spiegare quello che voglio fare e che qualcuno mi sappia aiutare

[eiyen]

Si può gestire con dei temporizzatori, ma per un gioco la cosa più semplice è che ALLA PRIMA OCCASIONE gestisci la cosa, in pratica ad ogni azione entri in un ciclo di controllo degli eventi temporizzati e se è passato almeno il tempo minimo previsto esegui l'azione COME SE FOSSE AVVENUTA NEL MOMENTO ESATTO, anche se in realtà potrebbe essere avvenuta successivamente.

Per es.: azione che dopo 8 ore deve provocare un evento
uno gioca per 4 ore e poi smette
il giorno dopo ricomincia
come inizia il gioco risulta in sospeso un evento (che doveva essere già accaduto) e tu lo gestisci in questo momento

[Virus_101]

lo gestisci con script lanciati da cron tab che controllano ogni x tempo lo stato di un giocatore e quindi eventualmnete re-impostano alcuni valori

[_debo]

Che database stai usando? MySQL? Versione?

[Dascos]

La soluzione di eyen è la più corretta ma è incompleta.
Il modo giusto per effettuare un trig, ovvero scatenare un evento in certe condizioni, senza appesantire (troppo) l'elaborazione, è effettuare in ogni pagina (del browser...cioè a ogni cambio pagina o ogni evento ajax) una chiamata con register_shutdown_function.
A questa funzione devi solo passare la funzione da eseguire o, meglio, un array composto dalla classe instanziata e dalla funzione da chiamare. Per esempio

$functions =  new func_taskmanager();
register_shutdown_function( array( &$functions, 'run_task') ); 

In questo modo, al termine del normale flusso di elaborazione, ovvero DOPO aver "buttato fuori" l'output, header compresi, php continua ad eseguire qualcosa ma in modalità, diciamo, "background".

Nella tua funzione run_task dovrai poi fare tutti i controlli del caso per evitare doppie triple quadruple ecc esecuzioni dello stesso task (un flag boolean 1-0 nella tabella dei task dovrebbe essere sufficiente) ed eseguire le operazioni che ti servono, come appunto controllare se qualche operazione di aggiornamento deve essere eseguita eccetera.

Se queste register_shutdown le inserisci in una unica classe che instanzi sempre è ancora meglio, così le gestisci tutte da un'unica classe e in modo più semplice.

Il modo che ti suggerisce invece virus, per quanto non scorretto in toto, è preferibile non usarlo perchè non è detto che sul server che ti ospita tu possa usare i cron (soprattutto se il sistema è windows).

[_debo]

In realtà ove possibile per quanto non proprio ortodossa, la soluzione di Virus_101 attualmente è la più corretta.

register_function_shutdown registra un funzione comune a qualsiasi script da eseguire per l'appunto durante l'evento di shutdown cioè un attimo prima della fine dell'esecuzione della chiamata. In altri termini tale funzione NON viene eseguita in background ma per ultima. In un contesto MMO è l'equivalente di un disastro di dimensioni epocali.

Consiglio o cron (che non mi piace) o in alternativa l'utilizzo di timer MySQL (assunto che si stia usando tale database) oppure per i più audaci la soluzione più adatta che è l'utilizzo di un job server tipo gearman.

[Dascos]

Originariamente inviato da _debo
In altri termini tale funzione NON viene eseguita in background ma per ultima. In un contesto MMO è l'equivalente di un disastro di dimensioni epocali.

Assolutamente no.

Quella di virus ha un "buco" tra una esecuzione di cron e l'altra e non è controllabile...è il server che decide quando eseguire il cron, non più il gioco (a meno di fare un sacco di bruttissime cose che dal punto di vista della sicurezza sono una boiata assoluta, come concedere una shell all'utente del webserver....)

La soluzione register_shutdown invece, per l'utente è come fosse in background perchè ha già ricevuto tutto l'output a browser, inoltre non è influenzata dall'interruzione utente (click su STOP o disconnessione, che puoi controllare con connection_aborted() e connection_status()) e anzi ne trae vantaggio potendo essere eseguita successivamente.

Se i controlli di esecuzione sono fatti bene, cioè subito all'inizio della funzione, alla fine si tratta probabilmente di una massimo due query aggiuntive quando non si deve eseguire la funzione e se gli algoritmi da eseguire sono fatti bene il carico è davvero minimo.

Ho un forum con 2000 utenti contemporanei al minuto e una serie di pseudo-cron (invio email di notifica di risposte a una discussione, invio di mail per messaggi privati, funzioni che elaborano gli RSS, un browser game eccetera) e non si è mai verificato un singolo ritardo o timeout o carico eccessivo del sistema.

Resta inteso che è impensabile fare per esempio dei download con questo metodo o delle elaborazioni grafiche piuttosto che delle elaborazioni SOAP complesse, ma se le funzioni, le query e tutto il resto è ben programmato, le register_shutdown sono l'ideale.

[_debo]

Assolutamente si, spero tu sappia la differenza tra un processo di background ed un event shutdown. If not, back to php.net.

Se quello che dici tu fosse vero sarebbe un paradiso, ajax non servirebbe e nemmeno i job servers.

Concordo un cron non è controllabile ecco perché ho suggerito di usare i timer mysql o un job server.

Ho un forum con 2000 utenti contemporanei al minuto e una serie di pseudo-cron (invio email di notifica di risposte a una discussione, invio di mail per messaggi privati, funzioni che elaborano gli RSS, un browser game eccetera) e non si è mai verificato un singolo ritardo o timeout o carico eccessivo del sistema.

Engine fatto da te? Posso avere il link per cortesia anche in privato, sono curioso. Grazie.

[eiyen]

Tutte le soluzioni sono applicabili e hanno pro e contro. In generale e soprattutto in casi non critici la mia reputo sia la migliore (perchè sarebbe incompleta?) perchè è la più semplice e meno esigente in termini di risorse. Molto importante è però stabilire l'esigenza esatta: se infatti occorre che un certo evento si verifichi al tempo "X" è necessaria una temporizzazione EFFETTIVA (NON la mia soluzione), ma se - come spesso accadde - questa è un'esigenza apparente e quella reale è che occorre che l'evento si verifichi "come se fosse" accaduto al tempo "X" (e posso in effetti fare un aggiornamento successivo) è opportuno l'accumulo delle azioni (*) che si risolve spesso in un'unica chiamata sql.
L'uso delle funzioni in background secondo me è molto penalizzante IN QUESTO CASO (NON IN ALTRI) perchè devo "aspettare" un determinato momento e quindi c'è il rischio di un intasamento del sistema.

Come sempre... dipende, secondo me! Ma nel caso proposto MI SEMBRA che in realtà l'esigenza reale sia quella che dicevo e quindi una gestione al primo accesso sarebbe efficace (ripeto: mi pare).


(*) in caso di moli immense si possono fare delle pianificazioni

[_debo]

Non trovo nemmeno io la tua soluzione incompleta o meglio come tu stesso dici, pensando ad un wbg, si può applicare solo ad un contesto che è quello della creazione di risorse statiche. Con il tuo metodo sempre come tu stesso dici, tutte le azioni di transizione o spostamento di risorse o unità non possono essere gestite.

Mi pare comunque di notare che c'è dell'incomprensione su quello che è un azione di background. Un azione di background è azione che viene eseguita parallelamente al processo iniziale di conseguenza vive di vita propria e non attende ne intasa nulla.