Progetto Diamonds o Diamond Crush: la rinascita

[redcloud]

Riprendiamo qui il discorso sulla riorganizzazione del progetto. Personalmente mi interessa riprendere l'attività per capire veramente come è strutturato un progetto simile. Nella scorsa edizione ho avuto difficoltà nel comprendere quale fosse la reale struttura del progetto. Per una persona che arriva a "gioco iniziato" può essere molto difficile allinearsi al gruppo ed è per questo motivo che in questa tornata dovremmo poter organizzare il tutto in modo più chiaro soprattutto per le nuove leve che vorranno darci una mano. Mi interessa anche passare a sourceforge perchè mette a disposizione strumenti molto utili che non mi dispiacerebbe imparare ad usare!

[71104]

ostrega, non avevo pensato a una cosa però... su SourceForge mi sa che non abbiamo nessuna forma di BuildMachine

avevo letto di sfuggita accenni ad una Compile Farm, o qualcosa del genere, che non so se valga anche per Java... devo informarmi decentemente.

poi, per quanto riguarda il Coach: chi è disposto ad esserlo alzi la mano -- io no :|

[redcloud]

Io purtroppo sono il più novizio e non ho esperienza in coaching, non ci converrebbe se lo fossi io

[71104]

https://sourceforge.net/forum/forum.php?forum_id=665363

ah bene, come non detto, LOL

[71104]

Originariamente inviato da redcloud

Io purtroppo sono il più novizio e non ho esperienza in coaching, non ci converrebbe se lo fossi io

jappilas allora? è molto portato per le decisioni di design.

per la Build Machine che si fa?

[redcloud]

Per me va bene.

[jappilas]

riprendo qui il discorso iniziato nell' altro thread

in sostanza avevo avviato un refactoring di alcune parti di DC con l' obiettivo di mettere le basi per funzioni a mio avviso fondamentali per considerare il gioco completo, quali:

- menu: menu iniziale e, menu secondari accessibili dalla schermata principale, nonchè menu in game (resume game/restart game/quit to main menu ) accessibile mettendo il gioco in pausa
questo ha richiesto che al termine del loop dell' oggetto GameLoop si tornasse al loop del menu, e il modo più pulito di farlo secondo me era un pattern state gestito a livello della classe principale Game
inoltre ha richiesto modifiche alla classe delle voci di menu
inoltre richiederebbe modifiche alla gestione dei layer, qualora si voglia rendere più pulito il redraw di sprites e layer nella schermata dei menu

- impostazione dei tasti dal menu opzioni: questo richiederebbe modifiche alla parte grafica del menu per visualizzare il codice dei tasti premuti e associati al tale evento per il giocatore 1 o 2

- gioco con gamepad questo richiederebbe interventi alla sezione di input dell' engine, nonchè al menu che consentirebbe di scegliere il pad come periferica per il primo o secondo giocatore

- gioco con connessione remota: questo richiederebbe oltre al protocollo di netgame funzionante, modifiche alla parte grafica del menu per impostare la modalità di gioco (connessione o in hosting) nonchè l' indirizzo remoto (introduzione dei caratteri nella schermata del menu), nonchè, magari, una schermata introduttiva del tipo "waiting for other player"

- gioco personalizzato: selezione oltre a modalità di input per i giocatori e del fondale e della musica di sottofondo: questo richiederebbe oltre all' apposita voce di menu, la gestione di layer intermedi nell' area di gioco

Originariamente inviato da 71104

jappilas allora? è molto portato per le decisioni di design.

design ancora ancora, coaching non garantisco ... non sono certo all' altezza di fek
e poi non vorrei preso dalla foga, spezzare le ditine al primo che non segue le mie direttive o a cui non vada bene questa lista di obiettivi...

pensavo quantomeno a vicius e ufo13

[cisc]

sono d'accordo per jappilas coach, per la build machine è un problema...se ne fa a meno?

[cisc]

Originariamente inviato da jappilas

riprendo qui il discorso iniziato nell' altro thread

in sostanza avevo avviato un refactoring di alcune parti di DC con l' obiettivo di mettere le basi per funzioni a mio avviso fondamentali per considerare il gioco completo, quali:

- menu: menu iniziale e, menu secondari accessibili dalla schermata principale, nonchè menu in game (resume game/restart game/quit to main menu ) accessibile mettendo il gioco in pausa
questo ha richiesto che al termine del loop dell' oggetto GameLoop si tornasse al loop del menu, e il modo più pulito di farlo secondo me era un pattern state gestito a livello della classe principale Game
inoltre ha richiesto modifiche alla classe delle voci di menu
inoltre richiederebbe modifiche alla gestione dei layer, qualora si voglia rendere più pulito il redraw di sprites e layer nella schermata dei menu

- impostazione dei tasti dal menu opzioni: questo richiederebbe modifiche alla parte grafica del menu per visualizzare il codice dei tasti premuti e associati al tale evento per il giocatore 1 o 2

- gioco con gamepad questo richiederebbe interventi alla sezione di input dell' engine, nonchè al menu che consentirebbe di scegliere il pad come periferica per il primo o secondo giocatore

- gioco con connessione remota: questo richiederebbe oltre al protocollo di netgame funzionante, modifiche alla parte grafica del menu per impostare la modalità di gioco (connessione o in hosting) nonchè l' indirizzo remoto (introduzione dei caratteri nella schermata del menu), nonchè, magari, una schermata introduttiva del tipo "waiting for other player"

- gioco personalizzato: selezione oltre a modalità di input per i giocatori e del fondale e della musica di sottofondo: questo richiederebbe oltre all' apposita voce di menu, la gestione di layer intermedi nell' area di gioco

design ancora ancora, coaching non garantisco ... non sono certo all' altezza di fek...
e poi non vorrei preso dalla foga, spezzare le ditine al primo che non segue le mie direttive o a cui non vada bene questa lista di obiettivi...

credo che queste features siano fondamentali, io darei un'occhiata anche a questo http://www.hwupgrade.it/forum/showthread.php?t=1216896

[Jocchan]

Più che altro, direi che bisogna mettere le feature in ordine di priorità: rimettere in piedi un progetto defunto è tutt'altro che semplice, ed il rischio di una ri-caduta nell'oblio è molto forte.
Quindi, prima occorre pensare alle cose più importanti e poi a tutto il resto.

Dipendesse da me, andrei con una TODO list di questo tipo:

1. riportare il codice ad uno stato riutilizzabile
2. tagliare via la modalità Advanced, non c'è il tempo per completarla
3. inserire il netplay, per dare uno scopo vero e proprio di esistere al gioco (per il multi locale c'è già la demo)
4. inserire tutti i menu, in ordine di utilità

Una volta completati questi quattro passi, si potrà pensare ad un'altra release, che potrebbe essere quella definitiva (a meno che non si voglia poi pensare ad aggiungere tutta la roba che è stata tolta, ma questo è decisamente YAGNI).

[71104]

Originariamente inviato da cisc

sono d'accordo per jappilas coach, per la build machine è un problema...se ne fa a meno?

ASSOLUTAMENTE NO.

ne sto discutendo giusto ora con jappilas su MSN: il clima di terrore del checkstyle e della build rossa è assolutamente indispensabile

[71104]

hola Jocchan quanto tempo!

[Jocchan]

Originariamente inviato da 71104

hola Jocchan quanto tempo!

Ciao Bertuzzo, non ti vedo su msn da una vita

[cisc]

Originariamente inviato da Jocchan

Più che altro, direi che bisogna mettere le feature in ordine di priorità: rimettere in piedi un progetto defunto è tutt'altro che semplice, ed il rischio di una ri-caduta nell'oblio è molto forte.
Quindi, prima occorre pensare alle cose più importanti e poi a tutto il resto.

Dipendesse da me, andrei con una TODO list di questo tipo:

1. riportare il codice ad uno stato riutilizzabile
2. tagliare via la modalità Advanced, non c'è il tempo per completarla
3. inserire il netplay, per dare uno scopo vero e proprio di esistere al gioco (per il multi locale c'è già la demo)
4. inserire tutti i menu, in ordine di utilità

Una volta completati questi quattro passi, si potrà pensare ad un'altra release, che potrebbe essere quella definitiva (a meno che non si voglia poi pensare ad aggiungere tutta la roba che è stata tolta, ma questo è decisamente YAGNI).

sono d'accordo, per lo sviluppo farei una TODO list a livello di task, completa di tutte le features che si vogliono implementare, sempre con delle priorità, in modo da fare qualcosa di meno lineare, ma più flessibile

Originariamente inviato da 71104

ASSOLUTAMENTE NO.

ne sto discutendo giusto ora con jappilas su MSN: il clima di terrore del checkstyle e della build rossa è assolutamente indispensabile

secondo me se ci sta una certa onesta mentale tra chi collabora se ne può fare a meno, basta che si stabiliscano delle regole e si rispettino

[71104]

Originariamente inviato da cisc

secondo me se ci sta una certa onesta mentale tra chi collabora se ne può fare a meno, basta che si stabiliscano delle regole e si rispettino

no no: ribadisco il clima di terrore :P

mettila così: quando entra un nuovo membro nel team si fa molto prima a dire "guai a te se rompi la build" piuttosto che elencargli tutte le regole di buona creanza diamondcrusciana

la build machine è semplicemente un'automatizzazione di quella che hai chiamato onestà mentale

[jappilas]

Originariamente inviato da cisc

sono d'accordo, per lo sviluppo farei una TODO list a livello di task, completa di tutte le features che si vogliono implementare, sempre con delle priorità, in modo da fare qualcosa di meno lineare, ma più flessibile

per me va bene

secondo me se ci sta una certa onesta mentale tra chi collabora se ne può fare a meno, basta che si stabiliscano delle regole e si rispettino

anche quello è vero
però c'è devo dire che a me per primo, ai tempi, i continui messaggi di checkstyle sono serviti per interiorizzare le linee guida da adottare nella scrittura di codice per DC...
che essendo molto diverse da quelle che dovevo ( e devo ) usare in altri ambiti, università o lavoro, all' inizio mi hanno richiesto sforzo notevole - nonostante mi imponessi di fare come fek mi aveva inculcato
ora, non è per costringere chiunque a passare attraverso le mie stesse difficoltà, (anche se penso che sarebbero maggiori per chi si sia formato da un certo tempo in un certo modo e debba riabituarsi, minori per chi su Java e DC inizi...certo, pur dovendo interiorizzare la logica degli oggetti e i pattern ) ma è per non sacrificare quella pulizia almeno esterna che il codice di DC finora vanta - come dicevo tempo fa, mi sono arrivate (ma è come se fossero arrivate a tutto il team ) mail con oltre a richieste di dettagli e chiarimenti, complimenti per la chiarezza del codice
questo mi ha fatto sentire davvero orgoglioso del progetto ed è una cosa da cui secondo me non si può prescindere

[cisc]

guardate, non ho nulla contro la build machine, anzi, penso sia uno strumento utilissimo, sto solo dicendo che dobbiamo valutare se possiamo farne a meno e passare a sourceforge, per me se ne potrebbe fare a meno...

[jappilas]

è che al di là del checkstyle (che potrebbe bastare quello avviato in locale da ant, a patto che non si perda l' abitudine di provare la build prima di ogni commit - e la si inculchi a eventuali nuovi membri ) la build machine produceva anche gli eseguibili nativi ... ora, io non ricordo come si facesse per questi ultimi ( GCJ sulla macchina di fek ?) e attualmente non avrei idea di come fare passando a sourceforge

[Bonfo]

Ciao a tutti.
Daniele mi ha contattato ed eccomi qui a rapporto. Ovviamente non ho fatto in tempo a leggere tutto.

Vado per punti in modo molto "schematico":
- sono sotto laurea, devo praticamente scrivere giorno e notte se voglio fare in tempo. Tempo disponibile 0 e non per programmare, ma poroprio per leggere il forum.
- DC è stupendo e bellissimo, sono soddisfattissimo di tutto quello fatto, ma ora è morto. In che senso: quel codice li ( cioè sia di gioco ma soprattutto dei test), ora è un vecchio malato e per curarlo bisogna fare uno sfrozo tale che si fa prima a scrivere tutto da zero consocendo già quali possono essere i tranelli del percorso Se Jocchan è in forma può sempre buttar giù un progetto nuovo ... :P
- Il TDD è pericolossisimo e una delle metodologie più difficili oltre che tremendamente efficaci. Qualunque cosa si faccia o si decida bisognerà esser cattivissimi nel rispettare le sue regole.

In conclusione non sono molto propenso a rimettere le mani a DC. è bello così.... perchè è arrivato al FP in modo fantastico e funziona benissimo e pure perchè è morto per nostri errori. Averlo li mi ricorderà sempre tutto questo: la fatica e la soddisfazione, la bellezza e gli errori da non fare

In ogni caso devo aspettare il post laurea per dare una qualunque disponibilità... arrivato a quel punto mi siedo in poltrona e decido cosa fare della mia vita

[71104]

Originariamente inviato da jappilas

è che al di là del checkstyle (che potrebbe bastare quello avviato in locale da ant, a patto che non si perda l' abitudine di provare la build prima di ogni commit - e la si inculchi a eventuali nuovi membri ) la build machine produceva anche gli eseguibili nativi ... ora, io non ricordo come si facesse per questi ultimi ( GCJ sulla macchina di fek ?) e attualmente non avrei idea di come fare passando a sourceforge

uhm, e se FreshMeat o qualche altro sito offrisse servizi del genere? comunque la Compile Farm di SF sembrava proprio essere una specie di Build Machine da quanto ho capito... però l'hanno cassata.