-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Italian Chiacchiericci
- Thread starter LucaMs
- Start date
- Similar Threads Similar Threads
La struttura pensata prevede classi (oggetti) stanze e classi (oggetti) giocatore sul server.
Quando il server invia il "comando" "tocca a te" ad un client, dovrà partire un countdown (devo ancora decidere se, come e dove, pur avendo fatto prove), mettiamo di 10 secondi, come è su Zynga.
Mettiamo che il client subisca un rallentamento di ben 11 secondi (può capitare); riceverà il comando dal server a tempo scaduto.
Il server, non ricevendo un comando dal giocatore, gli farà passare il turno o eseguirà una giocata al posto del giocatore e proseguirà, eseguendo qualcosa o passando il turno ad un altro giocatore.
Passati gli 11 secondi di ritardo, il client riceve il comando "tocca a te" e consente al giocatore di compiere la sua mossa, cosa che invece è già stata fatta dal server ed il giocatore non lo sa, penserà di essere in tempo ed i comandi successivi che riceverà saranno un casino.
E, come al solito, per non pensare troppo alla bella Penny, mi sono messo a fare altro, del tutto inutile (Superenalotto), avendo lasciato in sospeso anche un'altra cosa: la realizzazione dello scontro diretto in A9.
Come al solito, da 4 anni sospendo Penny, unica app che potrebbe farmi guadagnare davvero bene.
Che demente!
Come al solito, da 4 anni sospendo Penny, unica app che potrebbe farmi guadagnare davvero bene.
Che demente!
Quando il client invia la sua risposta ma con 11 secondi di ritardo il server Invia una contro risposta dicendo che fuori tempo.
In un altro gioco simile che ho visto molti anni fa se per qualche ragione il client inviava la risposta in ritardo riceveva dal server il messaggio di fuorigioco e veniva escluso dalla partita. Oppure su alcuni server di battaglia navale, il server se non riceve la risposta entro i tempi stabiliti sceglie lui una mossa in attesa di ricollegarsi col Client.
Ultima soluzione ogni mossa inviata dal cliente deve ricevere conferma dal server di ricezione altrimenti non risulta valida. Quindi il client invia la mossa ma compare un orologino di attesa se questo orologino di attesa dura più di 11 secondi potrebbe concludersi con mossa non accettata connessione persa
Eh, ok, ma bisogna strutturare bene la cosa, in quanto a tipi di dati (comandi), timer (se necessari), generalizzare il più possibile le situazioni di ritardo (non solo mossa del giocatore) etc.
Prima o poi avrò sia un momento di lucidità che uno di voglia di sviluppare... contemporaneamente (cosa rara
).
Intanto, grazie per i suggerimenti; non solo cercherò di tenerli a mente, di valutarli, ma ci metto pure un bel bookmark del browser.
Prima o poi avrò sia un momento di lucidità che uno di voglia di sviluppare... contemporaneamente (cosa rara
).Intanto, grazie per i suggerimenti; non solo cercherò di tenerli a mente, di valutarli, ma ci metto pure un bel bookmark del browser.
Un'altra cosa importante, è che tu numeri messaggi, come succede per il protocollo tcp ip.
Il client invierà i messaggi con un intestazione numerata 1, 2, 3, 4 eccetera punto il server risponderà a ciascun messaggio con la risposta numerata Quindi ogni messaggio sarà riconducibile a una sua risposta, questo serve a limitare l'uso illegittimo del protocollo
Il server comprenderà così se la mossa inviata dal client È quella relativa al turno di gioco o al turno precedente ed è arrivato in ritardo
Il client invierà i messaggi con un intestazione numerata 1, 2, 3, 4 eccetera punto il server risponderà a ciascun messaggio con la risposta numerata Quindi ogni messaggio sarà riconducibile a una sua risposta, questo serve a limitare l'uso illegittimo del protocollo
Il server comprenderà così se la mossa inviata dal client È quella relativa al turno di gioco o al turno precedente ed è arrivato in ritardo
Leggi solo il type - rappresenta un comando e, come hai suggerito, prevede un id comandoTroppo lungo, di mattina mi fai sfruttare il cervello
Nel frattempo mi sono inguaiato da solo.
Salvo una data in formato AAAAMMGG, quindi un testo che però è anche un numero.
Ora vorrei confrontare due date con quel formato e sapere quanti giorni di differenza ci siano.
Sarebbe stato molto più facile usando i "tick".
Me tocca studia'
P.S. non fa parte di Penny, eh.
Salvo una data in formato AAAAMMGG, quindi un testo che però è anche un numero.
Ora vorrei confrontare due date con quel formato e sapere quanti giorni di differenza ci siano.
Sarebbe stato molto più facile usando i "tick".
Me tocca studia'
P.S. non fa parte di Penny, eh.
Bene, parte del nuovo (inutilissimo) sw Superenalotto è fatta.
B4j con db SQLite; per ora fa un'unica cosa: preleva l'ultima estrazione dal sito ufficiale ed aggiorna il db.
Prossimamente sarà un'app Android, con statistiche e generazione serie... sicuramente vincente
N.B. per "vincente" si intende due numeri indovinati, non il 6
B4j con db SQLite; per ora fa un'unica cosa: preleva l'ultima estrazione dal sito ufficiale ed aggiorna il db.
Prossimamente sarà un'app Android, con statistiche e generazione serie... sicuramente vincente
N.B. per "vincente" si intende due numeri indovinati, non il 6
Buongiorno a tutti.
Ho letto il post #1786 di @Star-Dust e concordo con lui. Ma mi è venuto anche un dubbio riguardo all'intera architettura della "nostra" Penny: sicuri che sia basata su continui scambi di messaggi tra server e giocatori? In tutte le sue parti?
E se fosse semplicemente una webview (diciamo una "finestra") su una webapp e quindi tutto il gioco e le animazioni siano gestite dal server con il client che "guarda" e può interagire solo quando abilitato (il server distinguerebbe i giocatori tramite IP)? Certo, ogni x giocatori bisognerebbe attivare un nuovo server per evitare che "affondi", ma questa è operazione semplice e di routine (ad es. Openshift lo fa in automatico).
Per rimanere sul classico, invece, giunto al termine dello slot temporale concesso ad un giocatore per il suo turno, al server non basterebbe chiudere il websocket di quel giocatore che quindi riceverebbe un evento del tipo "connessione chiusa, riapri e ricarica nuova situazione" ?
I entrambi i casi, chat, doni e contorni vari (ovvero attività non legate al gioco) potrebbero utilizzare MQTT o simili perché in fondo si tratta di messaggi poco rilevanti in relazione al gioco in essere.
Forza Penny!
Ho letto il post #1786 di @Star-Dust e concordo con lui. Ma mi è venuto anche un dubbio riguardo all'intera architettura della "nostra" Penny: sicuri che sia basata su continui scambi di messaggi tra server e giocatori? In tutte le sue parti?
E se fosse semplicemente una webview (diciamo una "finestra") su una webapp e quindi tutto il gioco e le animazioni siano gestite dal server con il client che "guarda" e può interagire solo quando abilitato (il server distinguerebbe i giocatori tramite IP)? Certo, ogni x giocatori bisognerebbe attivare un nuovo server per evitare che "affondi", ma questa è operazione semplice e di routine (ad es. Openshift lo fa in automatico).
Per rimanere sul classico, invece, giunto al termine dello slot temporale concesso ad un giocatore per il suo turno, al server non basterebbe chiudere il websocket di quel giocatore che quindi riceverebbe un evento del tipo "connessione chiusa, riapri e ricarica nuova situazione" ?
I entrambi i casi, chat, doni e contorni vari (ovvero attività non legate al gioco) potrebbero utilizzare MQTT o simili perché in fondo si tratta di messaggi poco rilevanti in relazione al gioco in essere.
Forza Penny!
Last edited:
Spero che sia solo perché sto trafficando col Superenalotto ma... praticamente non ho capito quasi niente di quanto hai scritto, @udg
La prima parte, zero assoluto; non capisco cosa intendi, in che modo il tutto non dovrebbe essere uno scambio continuo tra i client ed il server.
Ma il punto è che i comandi sono consecutivi, accodati, quindi il client potrebbe elaborare quest'ultimo (ricarica - ed anche riceve la nuova situazione) dopo aver elaborato altri comandi "non leciti", per "timeout".
Insomma, è complesso, serve un'analisi piuttosto lunga, non penso che due minuti siano sufficienti (oppure sono io che voglio complicarla, per qualche recondito motivo).
1) dovrei studiarlo bene
2) sarebbe un server aggiuntivo
3) bisognerebbe studiare la scelta migliore per il broker
Se hai smanettato con i websocket, sai che è tutto molto semplice, non servono indirizzi IP, basta avere una map di oggetti di tipo websocket handler e puoi eseguire qualunque comunicazione (tranne quella da client a client direttamente, ma ritengo che anche questo sia impossibile usando MQTT).
La prima parte, zero assoluto; non capisco cosa intendi, in che modo il tutto non dovrebbe essere uno scambio continuo tra i client ed il server.
Per questo si può fare qualcosa di simile, senza dover chiudere la connessione, ovvero valutare il comando che il client invia al server (magari solo l'ID del comando, è da studiare) ed il server, anziché chiudere la connessione, potrebbe inviare un comando tipo "ricarica la situazione".
Ma il punto è che i comandi sono consecutivi, accodati, quindi il client potrebbe elaborare quest'ultimo (ricarica - ed anche riceve la nuova situazione) dopo aver elaborato altri comandi "non leciti", per "timeout".
Insomma, è complesso, serve un'analisi piuttosto lunga, non penso che due minuti siano sufficienti (oppure sono io che voglio complicarla, per qualche recondito motivo).
E' una complicazione, in quanto:
1) dovrei studiarlo bene
2) sarebbe un server aggiuntivo
3) bisognerebbe studiare la scelta migliore per il broker
Se hai smanettato con i websocket, sai che è tutto molto semplice, non servono indirizzi IP, basta avere una map di oggetti di tipo websocket handler e puoi eseguire qualunque comunicazione (tranne quella da client a client direttamente, ma ritengo che anche questo sia impossibile usando MQTT).
Ottimo, così sono costretto spiegarmi meglio..eheh
L'idea è che esista una webapp (per rimanere in B4x immagina ABMaterial+B4J) che giri su un server e gestisca interamente il gioco. All'inizio la webapp ha collezionato gli IP dei giocatori presenti ad uno specifico tavolo. Poi avvia il gioco, concedendo al primo giocatore il suo slot di 10 secondi per decidere cosa fare. In questo lasso di tempo eventuali "Click" degli altri giocatori vengono ignorati. Se il giocatore1 effettua la sua mossa nei 10s , il server aggiorna la situazione e passa al prossimo.
Nei 10s, il server aggiorna continuamente la pagina del tavolo creando di fatto le animazioni (es. il countdown per il giocatore di turno).
Intanto, localmente, ogni giocatore vede il tavolo e le sue animazioni come se avesse aperta una finestra sul server (in pratica una webview aggiornata ogni x secondi).
Sarebbe come richiedere ad un webserver la stessa pagina (aggiornata ad esempio ogni paio di secondi) da parte dei 4/5 giocatori.
Se la connessione è lenta, ogni richiesta del giocatore mostrerà la pagina comune del tavolo nello stato in cui si trova al tempo della richiesta (e quindi andrà per salti), mentre se cade del tutto allora il server prenderà nota del nuovo IP in fase di login e anche in quel caso riprenderà trasmettendo la visualizzazione corrente della pagina-tavolo.
Tutto questo per avere la gestione del tempo esclusivamente sul server e quindi evitare ogni necessità di sincronizzazione.
Per questo suggerivo la possibilità di chiudere e riaprire. Ciò scatenerebbe un evento che esula dalla "coda dei comandi" e permetterebbe di ripartire puliti.
Al contrario. Con MQTT (e i messaging in genere) puoi inviare messaggi "privati" tra due client; il messaggio passerebbe comunque tramite broker, ma sarebbe ricevuto solo dal destinatario prescelto.
Se capisco bene, intendi una pagina web continuamente aggiornata da un server. Sarebbe una buona soluzione alla sincronizzazione (forse, dubbi ne ho sempre, finché non provo
) ma non saprei proprio da che parte cominciare. Come minimo bisognerebbe conoscere HTML5 e quasi certamente robaccia java, come javascript, javabean, javayoursister, etc. Suggerisci ABMaterial ma non so se sarebbe sufficiente e non conosco nemmeno questo.Ma il punto è che nel momento in cui il server chiudesse la connessione oppure inviasse un comando di stop-ricarica potrebbe, probabilmente sarebbe, troppo tardi, l'utente vedrebbe tutto normale e tenterebbe di agire normalmente.
Appunto, passerebbe comunque per il broker, che altro non è che un server; anche con i websocket puoi inviare qualcosa solo ad un determinato client, sia un'informazione dal server al determinato client, sia una comunicazione da un client ad un altro, passando per il server.
Il websocket server è davvero molto semplice:
un client si connette? Viene creata AUTOMATICAMENTE un'istanza di una classe di tipo websocket handler. Tu passi questa istanza (oggetto) ad una map, come chiave della map userai un identificativo utente e fine.
In una stanza avrai un'altra map i cui elementi puntano alla map di tutti i client connessi (es. mapUtenti = tutti - mapGiocatori = mappa nella stanza, che è a sua volta un oggetto). Se un utente vuole inviare un messaggio di testo ad un altro utente, è facilissimo.
Ieri sono andato a giocare.
Di solito gioco solo al Lotto, cinquina secca 1€, per 3 estrazioni consecutive (così evito di andarci 3 volte a settimana). Eventuale vincita = 5.280.000€.
Attualmente faccio lo stesso anche al Superenalotto, visto che il Jackpot vale 115 milioni! (appena "azzerato", mollo).
Beh, spesa 3+3 euro, in realtà ho incassato 2,xx+2,xx, avendo vinto ad entrambi i giochi poco più di 5€.
Non male! Hai potuto giocare a ben due giochi e ti è costato solo un euro
Vedrebbe la situazione aggiornata e quindi potrebbe essere ancora in gioco (ha ancora x secondi a disposizione) oppure aver saltato il turno (e quindi vedrebbe la mossa giocata dal server per lui). Ovviamente la ricarica dovrebbe avere l'effetto di settare qualcosa che permetta di ignorare eventuali vecchi comandi che dovessero arrivare in seguito.
Immagina una sequenza tipo: Tocca a te - Hai ancora 5s - Tempo scaduto.
In caso di forte rallentamento o caduta linea prima del msg "hai 5s", alla ripresa dovresti ricevere la situazione corrente del tavolo (quindi il sever ha giocato al posto tuo) e settare qualcosa che dica "ignora comandi fino al prossimo <Tocca a te>"; quindi anche se intanto dovessero arrivare (fuori sync) "hai 5 s" e "tempo scaduto", li ignori.
MQTT
Io faccio riferimento a questo strumento perché l'ho messo su e quindi è già pronto e disponibile. Mi è utile in contesti diversi, non solo chat.
Come dici giustamente tu, non è una stretta necessità nel contesto di Penny visto che hai attivi i ws.
