Porting di jRisk in Python

[gennaro]

@Alessio
Visto che questo programma avrà anche una grafica non dovremmo magari cercare di descrivere nei casi d'uso anche il modo in cui l'utente interagisce con la grafica, per esempio:

* Il Sistema mostra il tabellone con i Continenti e i vari territori colorati in maniera diversa per ogni Giocatore
* Il Giocatore seleziona l'azione Battaglia dal menù
* Il Giocatore clicca sul territorio dal quale far partire l'attacco
* Il Giocatore clicca sul territorio sul quale portare l'attacco
...

... solo per fare un'esempio... oppure per ora tralasciamo l'aspetto grafico?

[`Alessio`]

I casi d'uso servono per descrivere a grandi linee le interazioni fra l'utente (gli utenti, altro) e il Sistema.
Il resto viene dopo

[gennaro]

Si però il fatto di dire (per esempio) che il Sistema stampa qualcosa sullo schermo è un pò come descrivere il modo in cui l'utente interagisce con l'interfaccia testuale (descrizione che perde di senso se poi ci facciamo la grafica)... comunque se dici che per la grafica ci pensiamo dopo va bene! 

[gennaro]

Ho un'altra domanda... una volta che avremo descritto i casi d'uso qual'è la fase 2 ?

[sospiro]

Ho un'altra domanda... una volta che avremo descritto i casi d'uso qual'è la fase 2 ?

lol

da come la vedo io il progetto è la cosa più importante di tutte....fatto bene quello evitiamo di perdere tempo dopo con la scrittura del codice...

la tua idee del client-server ha dei difetti secondo me è di difficile realizzazione...

la mia idea era questa:
creare un "pacchetto" (non so se in python abbian questo nome) in cui saranno contenuti i dati utili per giocare (giocatori, mappa, carte...) , un pacchetto che si occupa della logica (quindi modificare secondo le regole le classi dei dati) e una interfaccia (anche qui non so se in python si chiami come in java) che deve essere implementata da qualsiasi classe che voglia essere una gui del risiko...
naturalmente la logica vede i dati e una interfaccia, mentre la gui vede sia i dati che la logica...

in questo modo la parte della logica e dei dati rimarrebbe indipendente e sarebbe possibile implementare anche diverse gui, in gtk, qt oppure anche gui online...

questa è la mia idea...aspetto le vostre!!!

[gennaro]

Ok ma con questo sistema come si farà poi ad implementare la possibilità di giocare online fra più giocatori? Tra l'altro anche l'idea del client-server permette di avere più tipi di gui, infatti se il server è uno solo non è detto che debba esserci un solo programma client...

[sospiro]

nel modo che dico io basta implementare al posto della classe che estende l'interfaccia che connette la logica alla gui un server a cui si collega un client di un giocatore....

secondo me questa è la scelta migliore perchè il programma rimane molto modulare ed è molto adattabile

[gennaro]

Cioè la stessa interfaccia che usiamo per implmentare la gui la usiamo anche per il server? Vabè... se dici che si può fare mi fido... allora adesso dobbiamo definire meglio i quattro elementi del nostro programma (dati, logica, interfaccia, gui). Per la logica potrebbero aiutarci molto i casi d'uso che ha postato Alessio, i dati potrebbero comprendere i 43 Territori, le informazioni rigurdanti i confini e gli obbiettivi... per quanto riguarda l'interfaccia non ho un'idea molto chiara di come dovrà essere... qual'è la tua idea? 

[sospiro]

Cioè la stessa interfaccia che usiamo per implmentare la gui la usiamo anche per il server?

secondo me è una cosa semplice....l'interfaccia specifica alcuni metodi che devono implementare le gui, ad esempio chiediGiocatore(), notificaSpostamento() etc etc....
una i queste classi si preoccuparà di stampare le cose con gtk (quando si gioca su un solo computer) mentre una altra si preoccuparà di mandare ad un client dei messaggi e leggere le risposte ricevute...
se hai dubbi chiedi pure...

Per iniziare secondo me la cosa più conveniente da fare è iniziare ad implementare le strutture dei dati e dopo la logica con una interfaccia testuale per il debug...

se facciamo il lavoro in maniera ordinata, in tre in un mesetto scarso facciamo un capolavoro :P :P

[gennaro]

Ok ora è più chiaro! 

Per iniziare secondo me la cosa più conveniente da fare è iniziare ad implementare le strutture dei dati e dopo la logica con una interfaccia testuale per il debug...

E per descrivere tutto questo (la logica, i dati etc...) useremo l'UML o scriviamo direttamente il codice?

[sospiro]

l'uml può risultare molto comodo, perchè si ha una panoramica generale e a 360 gradi del progetto e si riesce ad evitare prima di fare cavolate che ci portino a punti morti....

tu lo conosci l'uml??
io ho delle conoscenze un po approssimative :P però per fare un diagramma delle classi me la posso cavare più o meno....

[gennaro]

tu lo conosci l'uml??

No, per niente... però sto leggendo questa guida... forse un paio di diagrammi riesco a disegnarli! Nel caso decidiamo di usare UML potremmo usare tutti lo stesso programma così è più facile aiutarsi? Io adesso sto usando umbrello ma se conoscete un programma migliore usiamo quello...

[sospiro]

si anchio uso umbrello....
soo che ha ancora qualche bug e spesso mi si chiude con una segmentation fault all'improvviso...

ho usato anche eUMLfree, un plugin per eclipse, è stabile però ha i suoi difetti (specialmente è lento come la morte)...

ma in python ci sono le classi, le interfaccie e i package come in java?

[`Alessio`]

allora...

la parte logica andrebbe in un modulo, pyrisk.py, i dati invece si potrebbero leggere da un file di configurazione (pyrisk.rc? magari inserendo anche le regole)

d'altronde alcuni aspetti come i colori dei giocatori e le mappe potranno essere personalizzabili (dovrà essere possibile creare delle mappe con n territori a piacere)

io per ora lascerei perdere l'idea del client/server, per quanto riguarda l'UML qui c'è una lista di programmi open source


ragazzi, se vi registrate su Savannah diventa tutto più facile, così possiamo comunicare anche tramite mailing list

[gennaro]

ma in python ci sono le classi, le interfaccie e i package come in java?

Certo! Ci sono sia le classi che i package... le interfacce no!  Le realizzeremo semplicemente costruendo una classe nella quale dichiariamo tutti i metodi dell'interfaccia e che poi sarà ereditata da un'altra classe che ne sovrascriverà opportunamente i metodi...

[gennaro]

dovrà essere possibile creare delle mappe con n territori a piacere

Altri pianeti ? Wow...  (good)

[gennaro]

Ok mi sono iscritto a savannah, il mio nome utente è gennaro, come faccio ad unirmi al progetto? Ma adesso dobbiamo aprire un nuovo progetto chiamato pyrisk o è stato già aperto?

[`Alessio`]

no no, usiamo quello

vai qui https://savannah.nongnu.org/projects/jrisk/ e fai richiesta di joinare il gruppo, poi io ti abilito

[gennaro]

emh... scusa dov'è il tasto join nella pagina che mi hai indicato? Non riesco a trovarlo...  :-[

[`Alessio`]

ti ho già aggiunto