Italian B4J - Websocket server + client b4a - chiaritemi le idee !!!

[LucaMs]

Faccio e disfo una volta al mese; devo cambiare "nick": Penelopo!

Come diavolo si fa a progettare qualcosa in maniera decente? Non so nemmeno COME farvi domande; il tutto è piuttosto complicato e non posso certo pretendere che vi scervelliate come sto già facendo io da tempo (a periodi alterni, ma da un SAAACCO di tempo).

Va beh, ci provo ugualmente; vorrà dire che magari col tempo questo thread porterà a qualcosa.
-------------------------------------------------------------------------------------------------

L'idea è buona, penso, e può essere ancor più generalizzata.
Vorrei ("me piacesse", direbbero a Napoli) realizzare una specie di "framework" (non so se usare altri termini, magari modello o template, ma sono più adatti a singoli oggetti) composto da un websocket server scritto in B4J e un client B4A; più precisamente dovrebbe essere una base per sviluppare giochi multiplayer online A TURNI. Una volta sviluppata questa base, DOVREBBE essere RELATIVAMENTE semplice e rapido lo sviluppo di vari giochi dello stesso genere: Poker, Briscola, Gioco dell'oca, Risiko... qualunque gioco a turni.

Dicevo che potrebbe essere ancora più generalizzata ma nel senso che ognuno di noi dovrebbe avere qualche "template"-"modello" ma che sia la base di un'app, non di una Classe o Activity o altri "piccoli" oggetti.

Tornando al mio "framework", sono arrivato più volte molto vicino a considerarlo pronto e quindi a mettermi a sviluppare il singolo gioco vero e proprio (supponiamo che io voglia creare, come gioco a turni, un classico poker con 5 carte, benché non sia così) e poi, ogni volta, mi sono reso conto di qualche intoppo oppure ho deciso di "migliorare" il tutto (per poi trovarmi con il tutto talmente migliorato che mi ha fatto trovare altri intoppi ).

Servirebbe qualcuno esperto sia di websocket server B4J, sia di progettazione software, con strumenti adeguati e capace di usarli, questi strumenti. Io non lo sono; ogni volta che ho provato ad usarli, mi sono rotto le scatoline ed ho mollato.

Dal prossimo post tenterò di "analizzare" (parolona della quale non sono all'altezza) tutti gli "oggetti" che concorrono (e che mi incasinano), tutte le condizioni, situazioni. xxxzioni necessarie e da tenere in considerazione (è già questa un'impresa ardua, per me, che non ho il dono della sintesi, come vedete!)

 

[LucaMs]

Anzi, prima di elencare quanto dicevo nel finale del post precedente, vi dico che:

tempo fa pensavo di essere finalmente giunto alla "conclusione" (della base, del framework); poi, nel momento in cui ho ricordato che avrei voluto aggiungere anche giocatori fittizi (bot - il motivo per cui li voglio creare... è lungo da spiegare) ho pensato "bene" di rivoluzionare un po' le cose.

Dato che per gestire le comunicazioni tra server B4J e client B4A ci si serve di un oggetto websocket MA IN PARTICOLARE di una classe speciale chiamata "websocket handler class", classe di cui esiste un template in B4J e che RICEVE DA DIETRO LE QUINTE un oggetto websocket, avevo pensato di utilizzare questa classe (che da adesso chiamerò WHC, Websocket Handler Class per abbreviare) per rappresentare un Player. Nel momento in cui ho pensato ai bot, che non necessitano del proprio websocket in quanto esistono sul server (e per comunicare con gli altri client useranno i websocket delle varie WHC) e pensando di non poter istanziare queste classi senza il famigerato websocket... via... rivoluzione! Creazione di classi Player contenenti una variabile che distingua tra player umano (nel qual caso a questa passerei un oggetto WHC) e bot (oltretutto, dal punto di vista formale, sarebbe più giusto avere una classe che rappresenti un generico User - Utente, che potrebbe essere la classe WHC, una classe Player, che rappresenti un giocatore e una classe Chatter, che rappresenti un utente che voglia solo chattare, anziché giocare. Avevo dimenticato di dirvi questa cosetta: il "framework" dovrebbe prevedere stanze da gioco (GameRoom) e stanze per chattate (ChatRoom)).

Sembra tutto più logico; avrei:

clsGameRoom - stanza gioco;
clsChatRoom - stanza chiacchiere;
whcUser - utente generico;
clsPlayer - utente giocatore;
clsBot - utente fasullo - (dichiarato esplicitamente, ovvero riconoscibile dai giocatori umani);
clsChatter - utente chiacchierone;
poi varie classi rappresentanti vari oggetti "reali", come il piatto del poker, ad esempio.

Potendo programmare in OOP si potrebbero creare interfacce o classi da cui derivare e questo aiuterebbe; invece, sviluppata un bel po' di roba, mi sono ritrovato davanti al fatto che... sia necessario duplicare parecchio codice tra il generico utente whcUser e gli specifici utenti clsPlayer, clsBot e clsChatter (proprio in questo una vera OOP aiuterebbe, ad evitare duplicazioni di routine).

E rieccomi a pensare che forse sia meglio che una classe WHC rappresente tutti quei tipi (Player, Bot, Chatter) e che al suo interno, in base al tipo indicato da una variabile, venga eseguito il codice relativo (dimenticavo che vorrei anche un utente speciale Admin, capace di entrare, invisibile, in ogni stanza per controlli vari).

Quindi, significa tornare indietro (ma naturalmente non posso utilizzare vecchi progetti B4J, avendo nel frattempo apportato migliorie ad altre parti del progetto).

PERO'... è vero che una variabile-oggetto può essere anche soltanto un riferimento ad un altro oggetto, quindi occupare solo lo spazio del riferimento stesso, ma tot oggetti whcUser, che contengano il codice per comportarsi sia da utente che da giocatore che da chatter che da admin, ritengo che occupino parecchio spazio inutile, o no?

----------

Non bastasse tutto questo, tutti questi dubbi, altri sono come comunicare. Finora ho usato un mucchio di routine, sul client chiamate dal server e, viceversa, sul server chiamate dal client. Ma si potrebbe creare una o due routine, con una sorta di schema comando che... etc.

E mo... che ve chiedo? Boh, tanto mi avrete già messo in "ignore" o vi sarete addormentati

 

[LucaMs]

Eh, scrivendo tutta la robaccia sopra, mi rendo conto che... la soluzione sarebbe molto meno complicata se davvero B4J (e B4A) fossero dotati di supporto OOP!

 

[LucaMs]

Va beh, prima che pensiate che sono solo un gran rompiballe e basta...

Vaaaaai Italiaaaaa! (non scrivo "forza Italia" perché qualche nanetto malefico ci ha tolto pure 'sta possibilità!)

 

[sirjo66]

.... un framework per fare giochi ???

.... ma prima di scrivere sul forum, perché non aspetti che la marijuana finisca il suo effetto ??

 

[LucaMs]

.... un framework per fare giochi ???

.... ma prima di scrivere sul forum, perché non aspetti che la marijuana finisca il suo effetto ??

Prova a guardare il numero di download di Zynga Poker versione Android (malgrado esista da anni la versione Flash per browser come concorrente più decine di altri concorrenti per Android) poi dimmi se ho fumato tabacco sbagliato

 

[LucaMs]

.... un framework per fare giochi ???

Non è che hai interpretato male e pensi che io cerchi di programmare uno... sviluppatore di giochi? Non è così, eh!

 

[LucaMs]

Prova a guardare il numero di download di

App                                      Download

Zynga poker                      10.000.000 - 50.000.000
DH Texas Poker - Texas Hold'em   10.000.000 - 50.000.000
Zynga Poker Classic TX Holdem     1.000.000 -  5.000.000
Luxy Poker-Online Texas Holdem    1.000.000 -  5.000.000
Texas HoldEm Poker Deluxe        10.000.000 - 50.000.000

Sono i primi che ho trovato... potrei continuare con decine e decine.

[ma... il mio gioco è inedito, non esiste su alcun Market, nemmeno su Google Play !!!]

 

[LucaMs]

Uhm... il mio ultimo post mi fa pensare che... non avendo rivali, me ne frego se non sarà perfetto (dal punto di vista della progettazione)... da quell'elenco, molto parziale, si capisce che SOLO i vari Poker hanno ottenuto molte CENTINAIA DI MILIONI di download; dato che a me bastano 20-50.000 INSTALLAZIONI per arricchirmi...
vado avanti e basta, senza troppe pi... mentali!

 

[sirjo66]

Non è che hai interpretato male e pensi che io cerchi di programmare uno... sviluppatore di giochi? Non è così, eh!

ah ecco, avevo capito male allora

 

[LucaMs]

Ragassi, che burdel! (se vede che so' romano, no?)

Già la cosa è molto complicata; aggiungiamoci il fatto che IL COMPORTAMENTO della Nazionale (e soprattutto le scelte di Conte) più che la sua eliminazione, ieri, me le ha fatte girare... sono ancora indeciso su come implementare tutta 'sta roba.

Possibile che tra noi italiani non ci sia un semplice laureato in ingegneria informatica in grado di indicarmi la strada migliore (non per quel Paese, questa indicazione la ricevo spesso ).

Dai, che non voglio dover chiedere nel forum internazionale; voglio essere orgoglioso di noi italiani.

Ho preparato un disegnino molto approssimativo, con molte lacune (mancano parecchie cose da considerare) e per niente esplicativo:

1) potrei fare in modo che la WHS sostituisca la User class (che in effetti attualmente non esiste, è proprio fatto in questo modo)
2) gli altri 3 tipi di "persona", Player, Bot e Chatter, potrebbero essere sia un'unica classe che si comporti diversamente in base ad una variabile che ne indichi il tipo, oppure "derivare" in qualche modo da User, boh
3) potrei assegnare WHC come proprietà delle altre "classi persona" [Bot non ha bisogno di un proprio websocket]
4) potrei assegnare il solo oggetto websocket presente nella WHC alle altre...[Bot non ha bisogno di un proprio websocket]

Due cose sono importanti da considerare:

a) le classi WHC (le loro istanze, ovviamente) sono particolari; girano ciascuna nel proprio thread e "ricevono in automatico" un oggetto websocket (intendo dire che il websocket non lo creo io, viene fornito alla classe da... l'ambiente, diciamo);
b) su questi server b4j esistono map di tipo thread safe (per cui possono essere condivise con pochi rischi di "interferenze")

Forse la cosa principale da capire e come utilizzare la WHC; potrei metterci dentro solo una specie di "interprete di comandi", inviati/ricevuti dal client e dalle "classi persona".

Niente da fare; è troppo tosta da chiedere, sia qui che nel forum internazionale. Serve davvero un esperto ingegnere del software oppure... me devo arrangia' e magari proseguire come è attualmente; perlomeno, anche se avrà problemi di velocità e/o memoria, di codice duplicato, etc... riuscirò a pubblicarlo.


Cmq, non dispero. Se c'è qualcuno che si è occupato di websocket server o che sia un buon progettista sw...

 

[LucaMs]

Ma vi pare giusto andare al mare anziché scervellarvi per trovare la soluzione ai miei problemi?!?!

Davvero inconcepibile!




Basta, non scrivo più niente fino a novembre (e nemmeno specifico l'anno!)

 

[LucaMs]

Questo forum sì che è di grande aiuto; a parte @sirjo66 che mi ha dato del pazzo drogato , non un'anima che abbia messo bocca.

Però capisco, è già un casino per me che ce l'ho sottomano, figuriamoci senza aver visto nemmeno parte del codice.

Va beh, ci riprovo, ci rimetto le mani (sperando che non mi venga voglia per l'ennesima volta di "rivoluzionare" tutto ).

 

[LordZenzo]

(sperando che non mi venga voglia per l'ennesima volta di "rivoluzionare" tutto ).

ma invece dei bot....perché non ti metti tu a giocare contemporaneamente con tutti..barando

 

[LucaMs]

ma invece dei bot....perché non ti metti tu a giocare contemporaneamente con tutti..barando

Non mi servirà barare: preleverò il 10% di ogni puntata dei giocatori ("costo giocata" o "diritti casa da gioco" ).

I bot mi servono per "fare numero": dato che in ogni stanza il gioco inzierà solo se ci sarà un numero minimo di giocatori, se un utente umano entra e nessuno entra nella stessa stanza, si rompe le balle ed esce; invece, ogni tot tempo, gli appioppo un bot (riconoscibile, non un finto utente) in modo che l'utente possa giocare.
Oltretutto, l'utente non avrà "intelligenza"; giocherà carte random, benché seguendo le regole del gioco.

Piuttosto, potrei, almeno inizialmente, non aggiungere una chat "parallela" (volevo fare in modo che l'utente, una volta identificato, potesse scegliere una stanza da gioco oppure una stanza chat) e magari consentirgli "solo" una chat pubblica durante il gioco (questa però penso che sarebbe poco utilizzata, perché mentre uno gioca, chattere, magari con uno smartphone (!) diventa quasi impossibile, non è come su un PC con schermo da 17" (come il mio mega portatile che adesso, nominato e "vecchietto", mi abbandonerà di sicuro).

 

[LucaMs]

Penso che tornerò alla mezza seconda idea che ebbi:

la prima idea fu che la classe websocket handler dovessere rappresentare un Player - natualmente iniziai subito lo sviluppo e poi dovetti cambiare (!);

la seconda, che rappresentasse un utente e, in base ad una Variabile-tipo-utente, fargli eseguire questo o quel codice;

la terza - attuale - la classe WHC rappresenta un utente, il quale si "trasforma" in player o chatter, ovvero avvia la creazione di un oggetto Player o Chatter in base al tipo di stanza scelta.

Questa terza sarebbe la più logica, forse, ma poi ci sarebbero molte chiamate duplicate: l'Utente (classe websocket handler, unica che comunica col Client) riceve il comando "gioca carta"; chiama il comando "gioca carta" del Player (quindi chiamata duplicata in due posti) ed il Player informa la stanza, che il Player "contiene" come riferimento, di aver giocato una carta; da qui la "reazione" della stanza, che informa il player che informa l'Utente (classe WHC). Troppi "saltelli" e codice duplicato.

Ergo, torno QUASI alla seconda scelta: la classe websocket handler rappresenta un Player (ma anche un Bot); ma non è che posso riprendere un vecchio progetto, perché in quello attuale sono presenti anche altre modifiche apportate successivamente e non relative a tutto quanto sopra e quindi... un casino!

... un casino... per questo bisogna essere bravi progettisti sw (ed io non lo sono!), per prevedere "tutto" in anticipo e saperlo esprimere con diagrammi ben fatti.

Un conto è essere un programmatore, altro è essere un analista-programmatore!

Inoltre, dovresti essere anche un bravo "designer", inteso proprio come disegnatore grafico.

Infine, se non sei pure un esperto di marketing, la tua app ti farà guadagnare a sufficienza per... comprarti un gelato ogni estate!

 

[LucaMs]

C'è anche un altro fatto:

potrei avere un oggetto Player, un oggetto Bot (il quale dovrebbe possedere molte delle proprietà e metodi del Player, magari leggermente differenti, e proprietà e metodi propri; questo significa che si dovrebbe poter avere le interfacce OOP e classi derivate, ma in B4A non è così) e un oggetto Chatter.

Ognuno di questi 3 oggetti (Player, Bot, Chatter) dovrebbe poter comunicare direttamente col client, quindi possedere un oggetto Websocket connesso col Websocket del client. Potrei semplicemente passare a questi oggetti l'oggetto Websocket della classe websocket handler, ma la cosa non funziona, perché il codice sul client DEVE chiamare le routine della CLASSE websocket handler. Questo per come è stato previsto da B4A per facilitare le cose!

AAAHHHHRRRRRGHHHHH... ho fuso!

 

[LucaMs]

DITEME ARMENO se secondo voi dovrei fare così:

1) classe OBBLIGATORIA websocket handler, che contiene l'oggetto websocket per la comunicazione col websocket del client:
se ci mettessi una sorta di interprete di comandi (inviati come stringhe JSON - da studiare, oltretutto)?

Questi comandi, codificati e quindi studiati (ancora!) in un certo modo, potrebbero essere comandi di:

1) log-in o sign-in
2) ricevuti dal client e poi passati all'oggetto "destinatario" (Player-Bot, putroppo oggetto unico, oppure Chatter)
3) ricevuti dal Player(Bot) oppure dal Chatter ed inviati al Client.

Esempio abbozzatissimo di comando ricevuto dal Client:

Campo1: "Auth" per autenticazione, "P" per Player, "B" per Bot, "C" per Chatter
Campo2: NomeRoutine
Campo3: parametri

Dopo l'autenticazione (log o sign in), vengono creati i due oggetti (Player-Bot e Chatter) nella WHC

Interpretazione comando:
CallSub([oggetto player o chatter in base a Campo1], NomeRoutine, parametri)

e già non va bene, perché campo1 non è solo P B o C ma anche Auth.

Beh, qualcosa di simile. Autenticazione separata e poi quell'interprete comandi (poi servirà un interprete per il senso inverso - da server a client - oppure una modifica di quell'interprete affinché possa agire in entrambi i sensi).

Ve sto a rincojoni' per bene, eh?

Beh, io me sto a rincojoni' moRto peggio!

State pronti a chiamare la "croce verde", se ancora esiste; insomma, fateme ricovera', per favore. Grazie

 

[LordZenzo]

io ce sto a capi' poco, pero' penso che dovresti avere tre funzioni distinte per i tre tipi, se non altro per non fare confusione sulle routine di controllo/interpretazione del tipo
callsub(tipo,parametri,routine) che richiama routineP(parametri) o routineC(parametri) o routineB(parametri)
sembra che si complica ma poi puoi gestire separatamente le tre condizioni(player, bot, chatter) o meglio le sei condizione(Pin,Bin,Cin,Pout,Bout,Cout)

 

[LucaMs]

io ce sto a capi' poco

Anch'io

E' che ancora non ho capito quali oggetti creare, in che modo, con quali relazioni tra loro, etc. Devo trovare almeno un'ora "libera" ed in cui io abbia la mente lucida, sgombra da pensieri...(!), cosa praticamente impossibile, nelle mie giornate.


Se dovessi decidere per una cosa tipo quella del post precedente (come vedi ancora non sono affatto deciso né convinto), la classe Websocket handler dovrebbe contenere un oggetto Player (che sia anche Bot) e uno Chatter, solo dichiarati, non istanziati (cioè non initializzati).
Ad esempio:
Private mPlayer as clsPlayer
Private mChatter as clsPlayer

Una parte del codice della Websocket Handler Class (WHC) si occuperebbe del "log-in" (previa eventuale Sign-In, registrazione).
La routine interprete dei comandi ricevuti dal client, come dicevo, potrebbe ricevere questi "campi":

CodiDest: "P" per Player, "C" per Chatter (eventuale distinzione per Bot ancora da studiare, sto ragionando mentre scrivo)
NomeRoutine
Parametri (probabilmente una map in formato JSON)

La callsub potrebbe essere (ci sto ancora pensando mentre scrivo, eh!):

CallSub2(mapDestObj.Get(CodDes), NomeRoutine, Parametri)

la mapDestObj dovrebbe contenere:

mapDestObj.Put("P", mPlayer)
mapDestObj.Put("C", mChatter)

La faccenda Bot è risolta "intrinsecamente", perché il client non deve far dsistinzione tra i due, dovrà inviargli gli stessi messaggi che invia ad un player umano.

Comunque, oltre ad essere UNA delle soluzioni (un'altra, come dicevo, è che la stessa classe WHC faccia da player, bot o chatter, tutto il codice in un'unica classe, ma ne esistono ancora altre) oltre a questo, dicevo, quanto sopra è da valutare, perché non è detto che funzioni, in questo momento qualcosa mi sfugge (tipo l'associazione mPlayer con una istanza Player esistente... creata come? quando? dove? perche? hehehe sto scherzando e dando i numeri; uhm... la WHC dovrebbe creare un oggetto player semplicemente quando riceve un comando "giocatore ha scelto una game room" (comando separato, che non faccia parte del cosidetto "interprete di comandi").

Insomma, il problema non è solo quello di come interpretare questi comandi; anzi, questo è relativamente un problema. Il problema è proprio quali oggetti mettere in campo, quali relazioni tra loro, etc.

Va beh, se trovo una soluzione decente, ve la scrivo (benché non penso vi interessi ).

Fatto sta che SE riuscissi a sviluppare tutta 'sta roba in maniera ben fatta, passare poi da un Poker ad un Black Jack o a Briscola, non dico che sarebbe automatico, ma richiederebbe poche modifice e poco tempo; una volta che hai creato e gestito stanze, creato e gestito giocatori (bot compresi) e chatter, gestito le comunicazioni client-server, inserito pubblicità, etc. le regole ed i controlli sulle azioni effettuate dai giocatori in base al gioco specifico si dovrebbero piazzare in classi separate, e modificando queste e un po' di grafica lo sviluppo di ogni nuovo gioco prenderebbe al massimo un mese di tempo!