[jappilas]

Originariamente inviato da Il Creativo

Ciao a tutti, vorrei avere informazioni sul progetto in questione, <cut>

ciao, rispondo in dettaglio più avanti

le uniche cose che so sono che si tratta di un'avventura 2D

più che un' avventura è un casual/arcade game per due giocatori
ognuno controlla la coppia di gemme e/o bauli (e se mai si riuscirà a reintrodurre una modalità avanzata, eventuali oggetti di altro tipo) che cade nella propria griglia di gioco - le gemme base si accumulano in griglia, e vengono eliminate con i bauli dello stesso colore, un' eliminazione ( "crush" ) di almeno due gemme fa partire un attacco diretto alla griglia avversaria, sotto forma di Stones (che dopo aver occupato la griglia per alcuni turni si trasformano in gemme )

ma a parte ciò, Diamonds può essere (anzi, andrebbe) considerato una palestra, e un esempio, di sviluppo Test Driven Object Oriented (con uso abbastanza intenso di design patterns di base) Test Driven, e con il meno possibile di commenti nel codice (pressochè superflui se il codice è autoesplicativo e racchiuso in metodi di lunghezza e complessità ciclomatica ridotte)

sviluppata interamente in Java.Grazie.

si era scelto Java per un paio di motivi:
Eclipse, l' IDE con i più evoluti (almeno all' avvio del progetto e tra i tool disponibili gratuitamente) strumenti di refactoring, e code assist ( almeno per java)
per l' integrazione di eclipse con l' infrastruttura di unit testing (junit, pressochè vitale per il TDD ) e tramite un plugin, con il repository subversion

di cosa/chi avete bisogno

in senso lato, di qualcuno che abbia, o almeno che voglia acquisire, dimestichezza con lo sviluppo a test

nello specifico, di qualcuno che voglia darsi una letta alla code base, rendersi conto dello stato attuale della test coverage (selezionando il task cover-report nelle opzioni "Run..." della build Ant, in Eclipse) e di come affrontare alcuni problemi di lunga data (ad esempio il refactoring di BigGem, che avrebbe fatto sì che le gemme aggregate siano viste allo stesso modo delle altre Droppable, che io sappia non è più stato terminato perchè chi lo intraprendeva si scontrava con il design di quella parte di codice)

in effetti, ci sarebbero anche caratteristiche il cui studio e sviluppo potrebbe procedere a latere, come il gioco via rete ...

e tutte le informazioni tecniche e non che potete darmi, in moda da farmi un'idea sul fatto che io possa o meno aiutarvi

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

per quanto riguarda struttura e funzionamento del gioco, credo la risposta più coerente con lo spirito del progetto e che ti avrebbero dato i membri storici del team sia all' incirca "il codice stesso fornisce la documentazione"...
in effetti la documentazione "ufficiale" si è sempre limitata all' essenziale, a un development plan con le funzioni da implementare nella release ( ma temo non sia più stato aggiornato dall' interruzione dei lavori avvenuta l'anno scorso), perchè la codebase essendo soggetta a refactoring continuo, era troppo "volatile" per documentarla esaustivamente

ciononostante credo di poter dire che da allora si sia relativamente stabilizzata, e la struttura dei package dovrebbe aiutare nella comprensione... comunque, come punto di partenza, considera che

l' entry point è nella classe Game, la quale in sostanza istanzia un oggetto GameLoop e ne usa i (due) metodi di loop

a parte il thread della musica di sottofondo (che però gestiamo solo tramite chiamate playMusic() e stopMusic() dal gameloop alla sezione audio dell' engine, quindi non esplicitamente ) il gioco è praticamente un ciclo di polling con stati, action ed eventi

il polling itera sulle Droppable presenti in griglia chiamandone il metodo update() (gestire il comportamento delle Droppable, quindi ad es cambiare sprite, è delegato a loro stesse) con lo stato attuale del Timer come argomento (notare che il Timer in Diamonds se non ricordo male va aggiornato esplicitamente o spostato in avanti di un numero arbitrario di millisecondi, prima che una nuova chiamata a getTime() possa restituire un valore diverso dalla precedente)

gli stati sono quelli in cui si viene a trovare la Grid dopo l' inizio della partita, partendo da un oggetto GemspairOnControlState - questo stato cede il controllo a uno che non gestisce la gempair in gioco (in effetti non c'è più nessuna gempair in gioco ) nè l' input, quindi al termine della caduta della pair il gioco "si ferma" per un attimo per controllare se ci sono delle crush da eseguire (controlli ed azioni operate tramite oggetti che ereditano da AbstractGridIteration e implementati nel package it.diamonds.grid.action), dopodichè si riprende da un nuovo gempaironcontrolstate, in pratica marcando un nuovo turno

gli eventi generati dai comandi utente sono gestiti da un Input associato al playfield del singolo giocatore ( primo o secondo ) - questo fa da tramite tra un dispositivo di input "concreto" (meglio, la sua classe proxy) su cui si registra come listener, e degli event handler , inoltre traduce gli eventi provenienti dalla classe dell' input device di cui sopra, in eventi target standard (questo era stato introdotto in vista della personalizzazione dei tasti)

i test: osservando la strutturazione dei subpackage sotto it.diamonds.test.* , dovrebbe essere abbastanza chiaro a quali classi del codice vero e propri si riferiscono quali test ...
è però da tenere presente che i test case possono non essere comprensibili come forma e come requisiti del codice che testano, inoltre la copertura andrebbe migliorata (alcune classi sono scarsamente testate) - per questo motivo tempo fa avevo proposto un sub task di revisione e report dei test, su cui poi lavorare ( l' obiettivo sarebbe renderli più consoni ai canoni e allo spirito del progetto - quindi i test, oltre a coprire adeguatamente il codice avrebbero dovuto essere concisi, atomici, autoesplicativi, manutenibili)
il volonteroso redcloud aveva prodotto un documento preliminare, che chi ha iniziato a seguire ha aggiunto al repository, con l' avviso di aggiornarlo insieme ai test modificati

(sempre che abbiate ancora bisogno di membri per il vostro team),

di membri, intesi come membri attivi c'è una grave penuria
personalmente stavo portando avanti nel tempo libero l' integrazione del Controller (aka joypad) , purtroppo sto per partire per non tornare nei pressi di una postazione internet-connessa prima di un mese, quindi non avrò modo di seguire il progetto e mi toccherà nominare un sostituto a cui fare riferimento .... chi sarebbe disponibile? Raffaele?

quindi sì, di nuovi membri ci sarebbe sempre bisogno, posto che ribadisco, siano interessati ad entrare nell' ottica ...