Posso unirmi?

[Griffo]

Ciao a tutti!
Sono un nuovo utente di questo forum nonchè un novizio (molto novizio) programmatore Java. Ma esistono già delle beta di questo gioco o non sono ancora disponibili?
Ciao :D

[jappilas]

Ciao! :)
se ti riferisci a del codice da leggere e far girare, sì ;)
tra l'altro grazie allo sviluppo da sempre aperto e "progressivo" (in ogni momento ) il codice sorgente è stato visibile e disponibile dal repository (di cui ti consiglio di fare un bel checkout) da quando il progetto ha mosso i primi passi...
se invece vuoi sapere se il gioco si trovi a livello "beta" o "release candidate", cioè con tutto quello che ti aspetti dalla versione finale, (e solo bug o problemi di stabilità da rilevare e correggere) purtroppo devo deluderti, e ti rimando al thread sul punto della situazione per vedere che funzioni mancano rispetto a quello che ai tempi venne pianificato :O

[71104]

be', al massimo ci sta la First Playable scaricabile dal sito...
www.diamondcrush.net

[redcloud]

Qualcuno ha voglia di ritornarci su?

[jappilas]

Qualcuno ha voglia di ritornarci su?io in questi giorni stavo rifattorizzando il loop primario :O

la mia versione è basata su un interfaccia LoopInterface con metodi void loop()
LoopInterface update()
boolean mustContinue()
GameState (che è un enum) getState()implementata da GameLoop nonchè dalla nuova MenuLoop, che inoltre inplementa la MenuInterface (interfaccia ad uso delle menuaction e dei test)

inoltre Game istanzia un oggetto Launcher - che a sua volta tira su l' Environment e i due oggetti LoopInterface principali (oltre a mostrare uno splash screen) - e da questo ottiene il primo dei due su cui girare

l' implementazione è fatta, mi manca da fare la verifica e il porting della batteria di test attuale e fare auditing dei code path (un po' stravolti in seguito a tale rimaneggiamento :stordita: ) per testare le interfaccie

una volta finito questo, pensavo di dedicarmi al sistema di gestione dei Layer, di modo che non sia più necessario creare un oggetto LayerManager all' inizio del ciclo corrente per ridisegnare sfondo e sprites (l' idea sarebbe di poter attivare o nascondere singoli layer ed eliminare la distinzione tra layer opachi e trasparenti)

[redcloud]

Hum... arabo? :stordita: Beh innanzitutto ridammi il link del rep che quello segnalato non è raggiungibile! Poi cerco di tradurre quello che hai appena scritto :D

[jappilas]

Hum... arabo? :stordita: Beh innanzitutto ridammi il link del rep che quello segnalato non è raggiungibile! c'è un problema, anzi due :O
il repository all' indirizzo che conoscevo è offline, ma non mi risultano copie attive ad altri indirizzi (temo che essendo stato il progetto dato per morto, si sia staccata la spina al server svn) :O
inoltre allo stato attuale, la mia versione di DC è pesantemente br0ken e lo sarà finchè non avrò completato il refactoring e soprattutto il relativo auditing dei code path e adeguamento dei test :p
non mi azzardo a committare il codice su cui sto lavorando finchè non è terminato, al limite posso spedirti uno zip con le specifiche classi :O
Poi cerco di tradurre quello che hai appena scritto :Dnaaa, niente di trascendentale...
l' idea era rifattorizzare in modo da mettere le basi per un ciclo in cui finito il gioco si torni al menu
per questo, per prima cosa ho dato una ripulita al package root (it.diamonds) spostando alcune classi in un sottopackage più idoneo (..... .playfield)
poi in quello principale ho creato una Interface con quei 4 metodi, ho creato una classe MenuLoop partendo da una copia del gameloop preesistente e togliendo codice ( :D ), dopodichè ho adeguato Game e Main in modo da usare il metodi loop() di oggetti che implementano quell' interfaccia
il punto è che, appunto, questo stravolge un tantino il flusso operativo finora usato e quello che i test attuali si aspettavano, quindi devo verificarli e debuggarli uno a uno (perchè molti fanno conto sulla presenza di oggetti contenuti e ritornati dal solo gameloop, quindi ora danno nullpointerexception)

[71104]

vabbè regà cioè non lo so... a sto punto continuiamolo e via :|

facciamo una cosa: aprite un progetto su SourceForge (così finalmente abbiamo un repository coi controcazzi :Prrr: ) e allora cercherò il tempo di darvi una mano :Prrr:

chiariamo: non è che voglio fare il prezioso o che, però se mi fornite strumenti potenti cerco di trovare qualche minuto da dedicare. ma vi avviso che andrò molto a periodi, esattamente come prima: un periodo non ci dedicherò nulla e il periodo successivo ci lavorerò una settimana di fila senza mangiare ne' dormire.

se aprite il progetto su SF, il mio account da quelle parti è "a71104" (ho dovuto aggiungere una a all'inizio perché i nick completamente numerici danno problemi :D)

fatemi sapere.

[71104]

oh, a proposito... se per voi va bene vorrei discutere circa l'eliminazione del TDD: i test IMHO si rivelano un'arma a doppio taglio a causa dei nuovi membri privi di training, e la cosa implica che DC non può reclutare velocemente nuovi membri. vi ricordo che al 50% sono stati i test a uccidere DC, penso siate tutti d'accordo.

tuttavia mi piacerebbe mantenere assolutamente immutate tutte le altre guidelines stabilite per la scrittura del codice, guidelines che si riassumono in: "codice autoesplicativo" :)

[jappilas]

vabbè regà cioè non lo so... a sto punto continuiamolo e via :|finire lo sviluppo di DC è sempre stata la mia intenzione ... se ti ricordi, avevo detto che sarebbe stato il mio regalo di compleanno , e che quindi per il mio compleanno sarebbe stato completo e funzionante (non si era specificato di quale anno, quindi c'è tempo fino al prossimo dicembre :D ):O
facciamo una cosa: aprite un progetto su SourceForge (così finalmente abbiamo un repository coi controcazzi :Prrr: ) benissimo, basta che qualcuno abbia una copia dei sorgenti aggiornata almeno allo scorso autunno, da uppare su SF (la mia come dicevo è sotto pesante work in progress, e non vorrei dovermi spezzare le ditine da solo :p)
e allora cercherò il tempo di darvi una mano :Prrr:as always, il tuo contributo sarebbe prezioso ;)

[jappilas]

oh, a proposito... se per voi va bene vorrei discutere circa l'eliminazione del TDD: i test IMHO si rivelano un'arma a doppio taglio a causa dei nuovi membri privi di training, e la cosa implica che DC non può reclutare velocemente nuovi membri. vi ricordo che al 50% sono stati i test a uccidere DC, penso siate tutti d'accordo. secondo me è stata una combinazione di fattori, comprendente dalla mancanza di tenpo per i membri preesistenti, alla relativa poca chiarezza di parti del codice :O

i test, sarei per non eliminarli (quelli attuali giammai, piuttosto farne auditing laddove lascino dei path a rischio, scoperti) tutt' al più per , in caso di prosecuzione dello sviluppo, adottare un TDD più "lasco": scrivere i test piuttosto che rigorosamente prima del codice, contestualmente o dopo cercando di non lasciare percorsi scoperti - e comunque scrivendo sempre il codice sulla base di requisiti del tipo precondizioni/postcondizioni in fase di esecuzione
sicuramente così però il rischio di non rilevare eventuali bug e/o avere percorsi non coperti è maggiore :stordita:
tuttavia mi piacerebbe mantenere assolutamente immutate tutte le altre guidelines stabilite per la scrittura del codice, guidelines che si riassumono in: "codice autoesplicativo" :)codice autoesplicativo, metodi semplici, riduzione delle ridondanze, eccetera, sicuramente, guai a toglierli :O

come già tempo fa però proporrei un "task" di documentazione della code base, sotto forma di documento esterno o di commento nel codice ( eresia :eekk: ) - commento che comunque non indicherebbe "cosa fa il codice" (a quello ci penserebbero i nomi autoesplicativi delle classi e dei metodi), quanto la responsabilità delle singole classi nell' ambito del loro package e del gioco, o su che design pattern si erano concepite...

[Vifani]

Anche se ora lavoro, mi sento di dare la mia disponibilità. Però ragazzi è necessario organizzarsi in maniera seria. Nel senso che se jappilas sta eseguendo un refactoring così oneroso, sarebbe il caso che lo finisca, pubblichi il tutto su sourceforce, e si ricominci con la definizione dei task, ecc...

P.S: Non eliminate la distinzione tra layer trasparenti ed opachi. E' necessaria per la gestione delle trasparenze in OpenGL, altrimenti non funzionerà più nulla a livello grafico, garantisco.

[^TiGeRShArK^]

Io ora come ora sono veramente incasinato...
e non è una situazione che si risolverà in fretta dato che in 6 persone dobbiamo rifare in poco + di un anno il lavoro ke non sono riuscite a fare 80 persone in 6 anni :muro:
Quindi onestamente non mi sento di poter dare la mia disponibilità allo stadio attuale delle cose.
Se la situazione cambierà vi informerò appena potrò riprendere anch'io :p

[cisc]

premesso che a me piacerebbe portare ad una release decente diamonds, al momento sono abbastanza incasinato tra esami, e la tesi su cui devo cominciare a lavorare, però se veramente si riprende seriamente lo sviluppo cercerò anche io di dare il mio contributo.

Sono d'accordo sul creare un progetto su Sourceforge. Per quanto riguarda l'eliminazione del TDD, io direi di tramutare il ciclo di sviluppo in modo più flessibile, creare dei macro task da assegnare per più di una settimana, credo che un'altra cosa che abbia fatto morire Diamonds siano stati tempi troppo stretti per task troppo dipendenti gli uni dagli altri, avere più flessibilità nella consegna di un task produce sicuramente un lavoro migliore, ancora di più considerando che non siamo in un ambiente lavorativo

[71104]

i test, sarei per non eliminarli (quelli attuali giammai, piuttosto farne auditing laddove lascino dei path a rischio, scoperti) tutt' al più per , in caso di prosecuzione dello sviluppo, adottare un TDD più "lasco": scrivere i test piuttosto che rigorosamente prima del codice, contestualmente o dopo cercando di non lasciare percorsi scoperti uhm, forse ci potrei stare, anche se sarei un po' contrario perché comunque sul momento rallentano lo sviluppo... però così almeno non è un'arma a doppio taglio, in quanto suppongo che in questa nuova ottica saremmo liberi di cassare a occhi chiusi test che falliscono in seguito a refactoring, rifacendoli da zero casomai in un momento successivo :)

codice autoesplicativo, metodi semplici, riduzione delle ridondanze, eccetera, sicuramente, guai a toglierli :O sono perfettamente d'accordo :O

nomi lunghi, esplicativi ed appropriati, complessità ciclomatiche bassissime ed in particolare mai superiori a 4 (mi sentirei di dire addirittura 3...), nessuna ridondanza, design puliti ed estremamente lineari, zero commenti. il codice perfetto *___*

come già tempo fa però proporrei un "task" di documentazione della code base, sotto forma di documento esterno o di commento nel codice ( eresia :eekk: ) i commenti no!! :O

PS: ma lo sapete che SourceForge ha un Task Manager?? :):):)
può gestire anche l'assegnazione dei task; è assolutamente appropriato al nostro modo di lavorare.

PPS: ah, e ha anche un forum e uno spazio web virtualmente illimitato :)

[71104]

credo che un'altra cosa che abbia fatto morire Diamonds siano stati tempi troppo stretti per task troppo dipendenti gli uni dagli altri, nel Task Manager di SF puoi segnare anche le dipendenze dei task - è un amore :D :D :D

[redcloud]

Ok, per me va bene se lo si passa su sourceforge. Io controllo un attimo che versione di diamonds ho su backup e poi la posto.

EDIT: ecco il link http://www.autistici.org/redcloud/Diamonds.zip

Sono favorevole alla realizzazione del task di documentazione della code base proposto da jappilas.

P.s. ci spostiamo su un altro thread che siamo OT?

[cisc]

nel Task Manager di SF puoi segnare anche le dipendenze dei task - è un amore :D :D :D

guarda, il problema non è certo le dipendenze, è difficile fare task che siano completamente indipendenti gli uni dagli altri, aah, se elimini i test, perdi sostanzialmente anche il refactoring, quindi bisogna pianificare prima la progettazione a mio avviso...


Ok, per me va bene se lo si passa su sourceforge. Io controllo un attimo che versione di diamonds ho su backup e poi la posto.

EDIT: ecco il link http://www.autistici.org/redcloud/Diamonds.zip

Sono favorevole alla realizzazione del task di documentazione della code base proposto da jappilas.

P.s. ci spostiamo su un altro thread che siamo OT?

Credo che ci siano moltissime cose su cui discutere, vai cmq col nuovo thread=)

[jappilas]

Anche se ora lavoro, mi sento di dare la mia disponibilità. Però ragazzi è necessario organizzarsi in maniera seria. Nel senso che se jappilas sta eseguendo un refactoring così oneroso, sarebbe il caso che lo finisca, pubblichi il tutto su sourceforce, e si ricominci con la definizione dei task, ecc...ehm, il fatto è che l' avevo iniziato principalmente per mettere giù delle idee che avevo in mente prima di dimenticarmene, e lo sto portando avanti solo nel (poco) tempo libero, anche se qualcuno (Vic e Jocchan) ha dovuto subirne le conseguenze sotto forma di pressanti richieste di consigli :D
il codice non è assolutamente in uno stato sicuro, non lo userei per un repository ufficiale :stordita:
una cosa che potrei fare sarebbe postare un archivio con i file aggiunti (l' ideale forse sarebbe una patch diff ma non ho ben chiaro se con progetti java funzioni altrettanto bene) da visionare direttamente per poi fustigarmi a discrezione sul forum :O
P.S: Non eliminate la distinzione tra layer trasparenti ed opachi. E' necessaria per la gestione delle trasparenze in OpenGL, altrimenti non funzionerà più nulla a livello grafico, garantisco.parlando su msn con vicius mi ha detto di no nessere molto soddisfatto del LayerManager attuale, soprattutto delle liste separate di layer opachi e trasparenti quando quasi per tutto si usa un canale alpha... quindi semmai si disegnerebbe tutto come transparent layer :D

ma anche senza eliminare le due liste seprate di layer, il layermanager per come impostato attualmente è una soluzione non ottimale - quantomeno, se si approva lo schema del mio refactoring (due oggetti che si alternano al controllo del ciclo primario) - già la creazione di un nuovo LayerManager all' inzio del loop() dell' oggetto corrente o ad ogni riavvio della partita è una delle cose che più mi davano problemi (crash della VM per sfondamento della heap ) ma che anche al di là dell' errore mio ( :p ) resta comunque, imho, fragile e a rischio

[71104]

se elimini i test, perdi sostanzialmente anche il refactoring, quindi bisogna pianificare prima la progettazione a mio avviso... non ci montiamo la testa -.-
refactoring significa semplicemente modificare il codice, e fek ci ha insegnato molto chiaramente che pianificare la progettazione porta a discussioni tanto lunghe quanto inutili.

hai presente come sviluppavamo su DC? propongo di fare la stessa identica cosa, ma senza test. oppure con anche i test, ma in ottica molto "larga" senza troppe fastidiose limitazioni che a) i nuovi membri non possono immediatamente comprendere, e b) sono un'arma a doppio taglio (quante volte avrò usato st'espressione oggi :D)

Credo che ci siano moltissime cose su cui discutere, vai cmq col nuovo thread=) non si discute un bel niente secondo me: le discussioni causano la morte dei progetti perché si dilungano all'infinito. bisogna eleggere un altro Coach che sente le varie proposte e prende decisioni indiscutibili.

[cisc]

non ci montiamo la testa -.-
refactoring significa semplicemente modificare il codice, e fek ci ha insegnato molto chiaramente che pianificare la progettazione porta a discussioni tanto lunghe quanto inutili.

semplicemente modificare il codice, avendo la garanzia con i test di non andare a modificare la logica, oltre a non reintrodurre bug già risolti. La pianificazione ci sta sempre, ovviamente non si può fare come chiacchiere da bar tra tutti gli sviluppatori


hai presente come sviluppavamo su DC? propongo di fare la stessa identica cosa, ma senza test. oppure con anche i test, ma in ottica molto "larga" senza troppe fastidiose limitazioni che a) i nuovi membri non possono immediatamente comprendere, e b) sono un'arma a doppio taglio (quante volte avrò usato st'espressione oggi :D)

usare i test in un'ottica più "larga", ecco, questo si potrebbe fare per "alleggerire" lo sviluppo



non si discute un bel niente secondo me: le discussioni causano la morte dei progetti perché si dilungano all'infinito. bisogna eleggere un altro Coach che sente le varie proposte e prende decisioni indiscutibili.


Si, sono d'accordo, la cosa più importante adesso è eleggere un coach, senza una persona che guidi lo sviluppo e prenda le decisioni è inutile parlare..

[redcloud]

http://www.hwupgrade.it/forum/showthread.php?t=1424437