Allora, dato che sono passati solo 4 anni dall'idea e dalle 100 versioni create, disfatte e ricreate, apro questo thread nella speranza che qualcuno abbia tempo e voglia di collaborare.
Non al mio progetto nello specifico, ma nel cercare la migliore soluzione possibile per la creazione di un'accoppiata client (b4a, per il momento) - server (websocket b4j) per giochi multiplayer online a turni.
Per questo tipo di giochi esiste un "framework" (@udg, non mi viene il termine in italiano
) di Google che, "all'epoca", non dico che studiai ma lessi con non molta concentrazione ed interesse.
Non ho intenzione di sfruttare quel servizio di Google per vari motivi:
1) mi renderei dipendente da quel servizio, il quale potrebbe cambiare nel tempo, e dalla libreria di @Informatix, il quale ha criticato Google stessa per le frequenti modifiche a questo framework (costringendolo, quindi, ad aggiornare continuamente la sua non certo semplice libreria);
2) perché "credo" che non sia adatto del tutto al mio scopo. Se non ho capito male, questa soluzione consiste nell'inviare al giocatore di turno lo stato del gioco; il giocatore esegue la propria "mossa", aggiornando quindi questo "stato", ed il tutto passa poi al giocatore successivo.
Il motivo per cui non mi sembra del tutto adatto al mio scopo sta nel fatto che, durante una partita, i giocatori non di turno devono avere la possibilità di effettuare altre azioni, come scrivere un testo che comparirà accanto ad essi sotto forma di fumetto, oppure di inviare oggetti-regalo, piccole immagini divertenti, affettuose oppure offensive (una birra, una rosa, un asino), oppure ancora una richiesta di amicizia.
Tutto questo viene fatto tramite animazioni (una birra parte dal giocatore A per arrivare al giocatore B e verrà piazzata accanto ad esso).
Queste azioni non fanno parte del gioco vero e proprio e quindi certamente non vanno inviate con lo "stato", ad esempio sotto forma di comando tipo "ID Mittente - ID Oggetto - ID Destinatario", per il semplice fatto che lo stato è ricevuto solo dal giocatore di turno e quindi solo lui potrebbe eseguire sul proprio client l'animazione in questione, gli altri non la vedrebbero.
Quindi (riesco sempre ad essere molto sintentico), direi di abbandonare questo servizio di Google e realizzare appunto una soluzione client-server come detto all'inizio di questo lungo post.
Se non esistessero le possibilità di rallentamenti di connessioni e quindi di non sincronizzazione tra i client, il tutto sarebbe relativamente semplice; questo è uno dei punti principali da risolvere nella maniera migliore possibile.
Il secondo punto riguarda la "distribuzione dell'elaborazione" tra i vari client.
Il nostro amico @LordZenzo giustamente ritiene che affidare completamente il lavoro al server possa sovraccaricare questo, mentre inserire nel client la logica di gioco ed utilizzare il server solo per scambiare vari tipi di messaggi tra i client, ne alleggerirebbe il carico.
Chiaramente concordo ma esiste il problema hacker (come già dimostrato NON da @Star-Dust ma da qualche suo conoscente).
E' anche vero che, perlomeno per quanto riguarda l'invio di messaggi da client a server, criptare-cifrare questi "potrebbe" risolvere in parte la questione sicurezza, ma se un hacker decidesse e riuscisse invece a risalire al codice sorgente, modificarlo e quindi rovinare le partite, i giocatori onesti abbandonerebbero presto l'app.
Ci sto pensando meglio mentre scrivo; penso che sia molto difficile che un hacker, a meno che non sia un super-esperto, nel qual caso avrebbe altro da fare, piuttosto che occuparsi di stupidi giochi, possa riuscire sia a risalire al sorgente e modificarlo a suo favore, sia a decodificare i messaggi cifrati.
Quindi probabilmente seguire la strada della "distribuzione del lavoro sui client" possa essere fattibile senza rischi.
L'idea (non certo originale) era invece di creare oggetti vari sul server, ovvero stanze di gioco, in queste oggetti "giocatore", oggetti facenti parte il gioco stesso, come ad esempio mazzo di carte, pezzi degli scacchi, che so, una roulette, etc. Avere magari una classe di gestione del tipo di gioco (quindi le regole, le mosse previste-consentite, etc).
Un ultimo punto che mi ha creato problemi: decidere se creare anche giocatori-bot.
Avendo impostato la faccenda come appena detto, un insieme di oggetti sul server, in cui uno dei principali è l'oggetto "Player", inizialmente pensavo di creare anche bot player, poi ci ho ripensato e deciso di non farlo e poi di nuovo pensato che siano indispensabili, in quanto potrebbero non esserci giocatori umani disponibili, soprattutto all'inizio, con poche installazioni, e quindi un umano si stuferebbe di attendere avversari, distinstallando l'app.
Esiste anche il problema che, per come è fatto adesso il server, un giocatore umano è rappresentato da un'istanza di una classe di tipo websocket, istanza creata automaticamente da B4J nel momento in cui un client si connette al server. Questa classe contiene appunto un oggetto websocket che serve per le comunicazioni client-server. Se dovessi creare un bot, questo non disporrebbe di un oggetto websocket; dovrei creare un'istanza della stessa classe usata per i giocatori umani? Senza oggetto websocket?
E poi tutto questo riguardava la "decisione" di far gestire tutto, completamente al server, mentre, viste le considerazioni fatte sopra, tutto andrebbe rianalizzato ripartendo dall'idea di far gestire il gioco sui client.
Solo chi abbia molta pazienza, tempo sufficiente e grande capacità di interpretazione potrà aver seguito e capito quali e quanti siano i miei dubbi.
Vedremo se qualcuno risponderà; vi pregherei soltanto di non scrivere brevi sentenze semplicistiche, perché la questione non è semplice come forse a qualcuno potrebbe sembrare e perché per me questo progetto è veramente importante.
Grazie.
P.S. guardando questo post dopo averlo inviato, direi che è spaventoso, in quanto a lunghezza; penso che abbia superato qualunque record (negativo?).
Non al mio progetto nello specifico, ma nel cercare la migliore soluzione possibile per la creazione di un'accoppiata client (b4a, per il momento) - server (websocket b4j) per giochi multiplayer online a turni.
Per questo tipo di giochi esiste un "framework" (@udg, non mi viene il termine in italiano
) di Google che, "all'epoca", non dico che studiai ma lessi con non molta concentrazione ed interesse.Non ho intenzione di sfruttare quel servizio di Google per vari motivi:
1) mi renderei dipendente da quel servizio, il quale potrebbe cambiare nel tempo, e dalla libreria di @Informatix, il quale ha criticato Google stessa per le frequenti modifiche a questo framework (costringendolo, quindi, ad aggiornare continuamente la sua non certo semplice libreria);
2) perché "credo" che non sia adatto del tutto al mio scopo. Se non ho capito male, questa soluzione consiste nell'inviare al giocatore di turno lo stato del gioco; il giocatore esegue la propria "mossa", aggiornando quindi questo "stato", ed il tutto passa poi al giocatore successivo.
Il motivo per cui non mi sembra del tutto adatto al mio scopo sta nel fatto che, durante una partita, i giocatori non di turno devono avere la possibilità di effettuare altre azioni, come scrivere un testo che comparirà accanto ad essi sotto forma di fumetto, oppure di inviare oggetti-regalo, piccole immagini divertenti, affettuose oppure offensive (una birra, una rosa, un asino), oppure ancora una richiesta di amicizia.
Tutto questo viene fatto tramite animazioni (una birra parte dal giocatore A per arrivare al giocatore B e verrà piazzata accanto ad esso).
Queste azioni non fanno parte del gioco vero e proprio e quindi certamente non vanno inviate con lo "stato", ad esempio sotto forma di comando tipo "ID Mittente - ID Oggetto - ID Destinatario", per il semplice fatto che lo stato è ricevuto solo dal giocatore di turno e quindi solo lui potrebbe eseguire sul proprio client l'animazione in questione, gli altri non la vedrebbero.
Quindi (riesco sempre ad essere molto sintentico
), direi di abbandonare questo servizio di Google e realizzare appunto una soluzione client-server come detto all'inizio di questo lungo post.Se non esistessero le possibilità di rallentamenti di connessioni e quindi di non sincronizzazione tra i client, il tutto sarebbe relativamente semplice; questo è uno dei punti principali da risolvere nella maniera migliore possibile.
Il secondo punto riguarda la "distribuzione dell'elaborazione" tra i vari client.
Il nostro amico @LordZenzo giustamente ritiene che affidare completamente il lavoro al server possa sovraccaricare questo, mentre inserire nel client la logica di gioco ed utilizzare il server solo per scambiare vari tipi di messaggi tra i client, ne alleggerirebbe il carico.
Chiaramente concordo ma esiste il problema hacker (come già dimostrato NON da @Star-Dust ma da qualche suo conoscente
).E' anche vero che, perlomeno per quanto riguarda l'invio di messaggi da client a server, criptare-cifrare questi "potrebbe" risolvere in parte la questione sicurezza, ma se un hacker decidesse e riuscisse invece a risalire al codice sorgente, modificarlo e quindi rovinare le partite, i giocatori onesti abbandonerebbero presto l'app.
Ci sto pensando meglio mentre scrivo; penso che sia molto difficile che un hacker, a meno che non sia un super-esperto, nel qual caso avrebbe altro da fare, piuttosto che occuparsi di stupidi giochi, possa riuscire sia a risalire al sorgente e modificarlo a suo favore, sia a decodificare i messaggi cifrati.
Quindi probabilmente seguire la strada della "distribuzione del lavoro sui client" possa essere fattibile senza rischi.
L'idea (non certo originale) era invece di creare oggetti vari sul server, ovvero stanze di gioco, in queste oggetti "giocatore", oggetti facenti parte il gioco stesso, come ad esempio mazzo di carte, pezzi degli scacchi, che so, una roulette, etc. Avere magari una classe di gestione del tipo di gioco (quindi le regole, le mosse previste-consentite, etc).
Un ultimo punto che mi ha creato problemi: decidere se creare anche giocatori-bot.
Avendo impostato la faccenda come appena detto, un insieme di oggetti sul server, in cui uno dei principali è l'oggetto "Player", inizialmente pensavo di creare anche bot player, poi ci ho ripensato e deciso di non farlo e poi di nuovo pensato che siano indispensabili, in quanto potrebbero non esserci giocatori umani disponibili, soprattutto all'inizio, con poche installazioni, e quindi un umano si stuferebbe di attendere avversari, distinstallando l'app.
Esiste anche il problema che, per come è fatto adesso il server, un giocatore umano è rappresentato da un'istanza di una classe di tipo websocket, istanza creata automaticamente da B4J nel momento in cui un client si connette al server. Questa classe contiene appunto un oggetto websocket che serve per le comunicazioni client-server. Se dovessi creare un bot, questo non disporrebbe di un oggetto websocket; dovrei creare un'istanza della stessa classe usata per i giocatori umani? Senza oggetto websocket?
E poi tutto questo riguardava la "decisione" di far gestire tutto, completamente al server, mentre, viste le considerazioni fatte sopra, tutto andrebbe rianalizzato ripartendo dall'idea di far gestire il gioco sui client.
Solo chi abbia molta pazienza, tempo sufficiente e grande capacità di interpretazione potrà aver seguito e capito quali e quanti siano i miei dubbi
.Vedremo se qualcuno risponderà; vi pregherei soltanto di non scrivere brevi sentenze semplicistiche, perché la questione non è semplice come forse a qualcuno potrebbe sembrare e perché per me questo progetto è veramente importante.
Grazie.
P.S. guardando questo post dopo averlo inviato, direi che è spaventoso, in quanto a lunghezza; penso che abbia superato qualunque record (negativo?).
Last edited:
