View Full Version : [CICLO 14] Storia 1
Storia 1: Ogni volta che il giocatore droppa una coppia di gemme, e prima che la coppia successiva inizi a cadere, un numero di pietre pari al valore del contatore situato sotto la propria area di gioco, e di colore scelto seguendo il pattern definito in basso, verrà fatto cadere (a velocità accelerata) nella sua schermata, da sinistra verso destra, ed eventualmente su più strati in verticale. Al termine di questa operazione, il contatore verrà riportato a zero, e le gemme torneranno a cadere.
Prima della trasformazione in gemma, una pietra potrà essere cancellata solo ed esclusivamente in seguito alla cancellazione di una gemma adiacente dello stesso colore. Il suo punteggio sarà nullo, ma conterà ugualmente per il numero di pietre da inviare all’avversario.
Questo numero verrà sottratto da quello delle pietre in arrivo: se il risultato sarà minore di 0, il giocatore ne riceverà un numero minore, pari al risultato appena ottenuto. Altrimenti, verrà mostrata una png con la scritta “Counter!”, e - se il valore sarà maggiore di 0 - sarà l’avversario a riceverle.
Pattern:
Il pattern è definito da una matrice 8x1, replicabile all'infinito in verticale, e contenente una serie di numeri compresi tra 1 e 5. All'inizio di ogni partita, questi numeri vengono abbinati casualmente a dei colori, e questo definirà il colore delle gemme da inserire nell'area di gioco.
Il pattern da seguire attualmente è: 1 2 2 3 3 4 4 5.
Punti cardine da tenere a mente durante i lavori:
* Mai fare a gara a chi finisce il task per primo, meglio procedere con calma, altrimenti perderemo molto più tempo in seguito
* Evitiamo di complicarci la vita, esiste di certo una soluzione più semplice di quella che abbiamo pensato di implementare
* MAI aggiungere elementi non richiesti esplicitamente dai task: se mai serviranno, se ne parlerà nelle prossime storie
* Comunichiamo il più possibile, se qualcosa non è chiaro discutiamone tutti i dettagli fino ad eliminare ogni dubbio, anche il più insignificante
* Postare sempre la test list PRIMA di mettere mano al codice
Task 14.1.1: Bonfo (Completato)
Introdurre il Pattern. Corrisponde ad una matrice 8x1 dove ogni cella può contenere un valore intero compreso tra 1 e 5 inclusi.
Per il momento il Pattern viene inizializzato per default con i seguenti valori: {1, 2, 2, 3, 3, 4, 4, 5}
All'inizio della partita ognuno di questi 5 valori viene associato ad un tipo di gemma (il rapporto deve essere: 1 colore <-> 1 valore).
Task 14.1.2 (In Pair): 71104 & redcloud (Completato)
Ogni volta che una coppia di gemme viene droppata si guarda il valore del numero di Stone in Arrivo si inserisce un numero pari di Stone all'interno della griglia. L'inserimento avviene dalla prima colonna a sinistra. Ad ogni Stone inserita si scorrono le colonne verso destra. Quando si raggiunge il fondo si riparte dalla colonna più a sinistra. Durante l'inserimento la gravità è settata come "accelerata".
Task 14.1.3: Ufo13 (2 Giorni)
Una Gemma di tipo Stone è cancellata quando una delle 4 gemme adiacenti (sopra, sotto, sinistra, destra) viene cancellata. Le Stone cancellate non vengono contate nel punteggio ma vengono contate per l'invio delle Stone all'avversario.
Task 14.1.4: Bonfo (Completato)
Ogni volta che si devono inviare delle Stone all'avversario si effettua questo calcolo:
incomingStones - stonesToSend
dove incomingStones sono le pietre in arrivo e stonesToSend quelle da mandare all'avversario.
Se il risultato è > 0 si riceverà un numero di Stone pari al risultato dell'operazione.
Se il risultato è <= 0 viene mostrata la PNG Counter! e viene inviato all'avversario un numero di Stone pari al risultato dell'operazione.
Task 14.1.3:
Una Gemma di tipo Stone è cancellata quando una delle 4 gemme adiacenti dello stesso colore (sopra, sotto, sinistra, destra) viene cancellata. Le Stone cancellate non vengono contate nel punteggio ma vengono contate per l'invio delle Stone all'avversario.
Correzione giusta??
Mi prenoterei per il task 4.
Tempo: 4 giorni per stare largo ;)
Correzione giusta??
EDITATO (leggere sotto plz).
No, errore mio. E' sufficiente che avvenga una cancellazione, di colore qualsiasi.
Questo perchè abbiamo 5 tipi di gemme (e sono tanti), e la possibilità che si raccolgano parecchie stone. Quindi, dobbiamo poterle smaltire più facilmente.
redcloud
03-04-2006, 14:59
Sono sempre disponibile per il pair, come tirocinante ;) Qualcuno mi si accolla?
Sono sempre disponibile per il pair, come tirocinante ;) Qualcuno mi si accolla?
Se non si offre nessuno te la do io una mano :)
Cionci, puoi stickare i questo topic e spostare gli altri per favore?
ehm... ehm... ehm... ^^
molto timidamente (causa lungherrima assenza dal progetto) vorrei propormi per il pair assieme a redcloud ^___^
redcloud, quando sei libero tu? per me va bene qualsiasi giorno di sera (con pausa-cena :D)
redcloud
04-04-2006, 00:42
Di sera ci sono sempre fino a giovedi (incluso).
Di sera ci sono sempre fino a giovedi (incluso). be', a domani sera allora... :)
Felice di rivederti "in azione", 71104 ;)
Un quesito sul task4 :confused:
Le stonesToSend sono quelle che si inviavano prima giusto??? Quindi se c'è una sola crushedGem le stoneToSend = 0 ??
Se mi viene in mente altro chiedo :D
A proposito...per poter fare il mio task devo attendere il task 2.
Come siamo messi??
Se nessuno si mette faccio io il task 1. :sofico:
OK??
Se nessuno si mette faccio io il task 1. :sofico:
OK??
Per me è ok :)
Il tuo dubbio nel post sopra sinceramente non l'ho afferrato ^_^;;;
Il tuo dubbio nel post sopra sinceramente non l'ho afferrato ^_^;;;
Allora abbiamo detto che ci sono incomingStone se l'avverasrio fa un crush di almeno 2 gemme, ovvero GEM-GEM-CHEST
Quindi mi chiedevo se le stoneToSend rispondessero a questa regola.
Esempio:
l'avversario ha fatto GEM GEM CHEST---> io vedo nel warningBox 2
Io faccio CHEST-GEM-GEM e mi vedo arrivare 0
Io faccio CHEST-GEM cosa mi vedo arrivare 1 o 2.
Anche perchè se io avessi fatto CHEST-GEM nonavrei inviato alcuna stone.
Spero di essermi spiegato :rolleyes:
Allora abbiamo detto che ci sono incomingStone se l'avverasrio fa un crush di almeno 2 gemme, ovvero GEM-GEM-CHEST
Quindi mi chiedevo se le stoneToSend rispondessero a questa regola.
Esempio:
l'avversario ha fatto GEM GEM CHEST---> io vedo nel warningBox 2
Io faccio CHEST-GEM-GEM e mi vedo arrivare 0
Io faccio CHEST-GEM cosa mi vedo arrivare 1 o 2.
Anche perchè se io avessi fatto CHEST-GEM nonavrei inviato alcuna stone.
Spero di essermi spiegato :rolleyes:
Ovviamente sì, le mie incomingStone sono le stoneToSend del mio avversario ;)
Quindi
l'avversario ha fatto GEM GEM CHEST---> io vedo nel warningBox 2
Io faccio CHEST-GEM ---> mi vedo arrivare 2
TASK 1:
Ma cosa si deve poter fare sulla classe Pattern??
L'unica cosa che mi sembra giustro mostrare allesterno è:
publi Pattern();
public DroppableType getDroppableType(int index);
Cosa mi sto perdendo per strada ? :wtf:
Sinceramente anche io non ho capito molto di questa classe pattern...
Vero... Praticamente le Stone vengono droppate seguendo lo schema indicato nella pattern :)
Ecco la testList che ho seguito:
- testare che Pattern ritorni il Color secondo i valori di default {1,2,2,3,3,4,4,,5}
- testare che il numero di elemnti in pattern sia 8
- testare che il colore NO_COLOR non sia presente
- testare che una nuova istanza di Pattern abbia il mapping Numero-Colore diverso
TASK terminato. :yeah:
P.S.: se il task non va bene reverto senza problemi...basta cancellare 2 file :asd: :asd: :asd:
testDifferentMappingIfNewIstance()
mi fallisce sto test.
puo essere che sia il mio workspace incasinato..
Bonfo devi anche testare che il pattern sia giusto e che quindi i colori siano restituiti correttamente dopo essere stati assegnati.
Devi anche testare il pattern default :)
testDifferentMappingIfNewIstance()
mi fallisce sto test.
Ho scoperto cos'è....ogni tanto, casualmente, il random ritorna lostesso numero...e quini le due iistanze hanno lo stesso mapping :(
Cambio subito :D
Bonfo devi anche testare che il pattern sia giusto e che quindi i colori siano restituiti correttamente dopo essere stati assegnati.
Devi anche testare il pattern default :)
:eekk: :eekk:
E questo test che ho fatto allora cosa fa????
EDIT: mi sono scordato il nome: testDefaultPatternValues :rolleyes:
:eekk: :eekk:
E questo test che ho fatto allora cosa fa????
Io ho solo guardato la test list.. Quando fai commit guardo il codice... Lo hai già fatto? :)
Il commit lo fatto ieri notte :sofico: :sofico:
Quindi è già li da stamattina :D :D
Comunque ora ho coretto il test che falliva random.
Ho modificato il costruttore di Pattern perchè possa avere in ingresso un RandomGeneratorInterface...così ho risolto il problem del test ;)
71104, redcloud vi ho assegnato il task con 2 giorni visto che redcloud c'è fino a Giovedì sera. Se volete dare un'altra tempistica postatelo :)
redcloud
05-04-2006, 17:01
Io ci sono anche
venerdi tra le 19 e le 20, tra le 24 e le 2
sabato tra le 8 e le 13:30, tra l'1 e le 2
domenica tra le 8 e le 13:30, tra l'1 e le 2
purtroppo io sono ancora una matricola o spina che dir si voglia, lascio decidere a 736268127 ;)
Io ci sono anche
venerdi tra le 19 e le 20, tra le 24 e le 2
sabato tra le 8 e le 13:30, tra l'1 e le 2
domenica tra le 8 e le 13:30, tra l'1 e le 2
purtroppo io sono ancora una matricola o spina che dir si voglia, lascio decidere a 736268127 ;) sabato non se ne parla neanche :Prrr:
stasera non va bene? oggi è giovedì no... :wtf: ?
se non va bene stasera allora vada per venerdì dalle 7 alle 8 e casomai pure dopo mezzanotte.
PS: carini i soprannomi deliranti che mi attribuisci ogni volta :D
noto che iniziano sempre col 7 :D
redcloud
06-04-2006, 17:42
Per me non c'è problema :) Gli orari sono quelli, ci becchiamo stasera allora, caro il mio 762391! :cool:
Chi prende 14.1.3?
Ragazzi, siamo a Venerdi' ed abbiamo completato un solo task. Se entro domenica sera i task assegnati non sono completati, rientrano in circolo per l'assegnazione.
Se alla fine del Ciclo i task non sono tutti completati, si riparte col Ciclo 14. Tradotto: o ci si mette in testa che i task vanno completati entro il tempo che e' stato previsto oppure si butta a mare un anno di lavoro.
prendo io il task 3, finisco entro domenica sera :)
Ehm...:flower:
..per fare il mio task ho bisogno del task 2 finito.
Io in realtà ho già iniziato...ma senza l'inserimento delle stone non posso fare dei test adeguati.
Posso avere la proroga :ave: :ave:
:D :D
Ok, se il task 2 non e' completato stasera, va bene se se ne occupano Ufo o cionci nel finesettimana cosi' possiamo andare avanti?
ARGH!! no, stavolta diventa una questione personale tra me e il task!! :mad:
tu task, mi hai provocato, e ora io ti finisco!! :mad:
redcloud, rispondimi su MSN!!! :cry:
Prendo io il task 3, se qualcuno lo vuole glielo lascio tranquillamente :)
prevedo di impiegare 2 giorni dopo la fine del task 2
Bonfo, manca questo test:
All'inizio della partita ognuno di questi 5 valori viene associato ad un tipo di gemma (il rapporto deve essere: 1 colore <-> 1 valore).
Ufo ha perfettamente ragione.
Il fatto è che per testare questo comportamento dovrei aggiungere un metodo getPattern() in playField o addirittura in GameLoop.
Infatti non è stato specificato se il pattern è uno per entrambi i playField o se sono un per ciascun playField??
In ogni caso questo metodo mi piace poco perchè non è utile.
I test possono comunque essere effetuati testando come le incomingStone sono inserite nella griglia.
Ma questo punto la randomizzazione del pattern a inizio partita passa al task2.
Come mi comporto?? :confused:
Altra cosa che mi è venuta in mente.
in pattern la mia assegnazione Valore->Colore non è proprio random. :fiufiu:
Infatti l'attuale implementazione fa si che se l'ordine è
Rosso Giallo Blu Bianco Verde
ci possano essere solo altre 5 possibilità, in quanto i colori sono "circolari",
ovvero il caso successivo sarebbe
Verde Rosso Giallo Blu Bianco
E' un comportamento inaccettabile che va cambiato???
Jocchan fammi sapere ;)
Altra cosa che mi è venuta in mente.
in pattern la mia assegnazione Valore->Colore non è proprio random. :fiufiu:
Infatti l'attuale implementazione fa si che se l'ordine è
Rosso Giallo Blu Bianco Verde
ci possano essere solo altre 5 possibilità, in quanto i colori sono "circolari",
ovvero il caso successivo sarebbe
Verde Rosso Giallo Blu Bianco
E' un comportamento inaccettabile che va cambiato???
Jocchan fammi sapere ;)
Ne abbiamo parlato stamattina con Joc ed avevo pure postato (poi ho editato).
Abbiamo deciso che per ora va bene così poi si vedrà :)
:kiss: :kiss:
:asd: :asd:
Dal thread relativo al task 14.1.2 è venuto fuori come in realtà Pattern fosse stato pensato come:
new Pattern({1,2,2,3,3,4,4,5});
Ora non è così.
Modificarlo è YAGNI o è da fare???
:help: :help:
Dal thread relativo al task 14.1.2 è venuto fuori come in realtà Pattern fosse stato pensato come:
new Pattern({1,2,2,3,3,4,4,5});
Ora non è così.
Modificarlo è YAGNI o è da fare???
:help: :help:
ma in teoria nn dovrebbe essere new Pattern() e poi quell'array lo crei nel costruttore?(sempre che nn sia gia previsto un possibile cambio del pattern)
ora come ora secondo me è YAGNI perchè abbiamo solo un pattern...
Ho notato come si commporta l'inserimento delle stone.
Ma non si sovraccarica così la sola parte a sinistra dell'area di gioco??
Ora come ora supponendo prima 4 stone e poi 5 si ha (S1 primo gruppo, S2 secondo gruppo)
S2 S2 S2 S2
S1 S1 S1 S1 S2
Non sarebbe meglio
S2
S1 S1 S1 S1 S2 S2 S2 S2
:confused: :confused:
P.S: il task 2 è terminato??
Ho notato come si commporta l'inserimento delle stone.
Ma non si sovraccarica così la sola parte a sinistra dell'area di gioco??
Ora come ora supponendo prima 4 stone e poi 5 si ha (S1 primo gruppo, S2 secondo gruppo)
S2 S2 S2 S2
S1 S1 S1 S1 S2
Non sarebbe meglio
S2
S1 S1 S1 S1 S2 S2 S2 S2
:confused: :confused:
P.S: il task 2 è terminato??
Hai perfettamente ragione, è una cosa che ho sottovalutato.
La soluzione che proponi, però, sballa il pattern. Molto meglio fare in modo che le prime caselle a riempirsi siano quelle a "profondità" maggiore.
Ne parlo con Berto e, se la cosa è troppo complessa, aggiungiamo il tutto alla storia 2.
TASK 14.1.2 COMPLETATO.
passo alla correzione di alcuni bug: ne ho trovati tre, per due me la cavo da solo, per un'altro (quello di OpenAL) mi serve thebol. nel frattempo potete iniziare i task successivi.
domani quando ho tempo vedo di refattorizzare lo StoneFallState: ho in mente una soluzione più semplice per correggere sia una delle due attuali cause di crash (non quella di OpenAL, quell'altra) sia un problema di visualizzazione che abbiamo quando in una colonna devono cadere più stones.
per la cronaca il problema è che le stones risultano sovrapposte all'incirca per metà, e la cosa è dovuta al fatto che l'hot spot dello sprite (la cui posizione corrisponde a riga e colonna corrente del Droppable associato) non si trova in alto a sinistra ma al centro (se ricordo bene); questo fa sì che quando le stones devono essere disposte su più righe, la prima riga venga liberata quando gli hot spot della prima fila di stones si trovano nelle celle della seconda riga, ma quando questo avviene per la prima volta un pezzo di sprite (quasi tutta la metà superiore) si trova ancora nella prima riga.
piuttosto che attendere che la prima riga sia libera è meglio riempire le righe dall'alto al basso tutte direttamente in una sola volta; e se non c'è abbastanza spazio per inserire alcune stones allora è game over.
comunque sia ribadisco che potete tranquillamente iniziare i task rimanenti di questa storia :D
Task 4
Se il risultato è <= 0 viene mostrata la PNG Counter!
Dove??
Iniziando il task 4 mi sono reso conto come il conteggio delle effettive stone che devono essere inserite debba essere fatto durante il lo StonesFallState.
Ovvero se ho 10 incomingStone faccio il conto delle gemme appena crushed e le tolgo da questo conto.
Per come è fatto ora lo state non è possibile farlo elegantemente. :(
Il problema è che per gestire un numero di stoneToInsert>8 invece di fare tutto all'interno si usano i metodi di grid set e get IncomingStone. :nonsifa:
Seconda questione.
In realtà il setIncomingStones che adesso è a livello di playField, il cui valore è successivamente passato a gridController (già mi suonava male ), deve essere eseguito solamente ed unicamente da StonesFallState. :O
Infatti è questo stato che sapendo il numero delle crushedGem e delle IncomingStone determina se e quante stone inviare all'avversario. :asd:
Sarebbe sufficente che questo state settasse le incomingStone avversarie.
Per simmetria il tutto funzionerebbe perfettamente. :D
Ora ecco il vero problema: la conoscenza delle playField avversario lo ha solo playField... e StoneFallState non ha la più pallida idea che esisti un palyField
:muro: :muro:
Che si fa ??? :help: :help:
@71104 : manca ancora da intergare insertStoneIntoColumn() di grid per la coretta visualizzazione dei Frame delle stone. ;)
Task 4
Dove??
Nella stessa cartella del box Warning (al posto del quale deve essere mostrata) ;)
Riprendo il problema esposto qua
http://www.hwupgrade.it/forum/showpost.php?p=11981400&postcount=54
Siccome la conoscenza di opponentPalyField lo ha solo playField ho pensato ad un modo in cui gridController potesse comunicare con PlayField senza rompere l'incapsulamento.
Ho creato tre metodi
- setStonesToSend()
- getStonesToSend()
- areStonesToSend(): forse questo non serve neppure ;)
in questo modo il StoneFallState setta l'eventuale numero di stones da inviare e playField se lo va a leggere e setta il numero delle incomingStone dell'avversario.
Ecco come il codice verrebbe:
private void updateWarningBox()
{
if(lastNumberOfPairInserted < gridController.getNumberOfPairInserted())
{
warningBox.hide();
lastNumberOfPairInserted = gridController.getNumberOfPairInserted();
}
if(opponentPlayField != null)
{
if(gridController.areStonesToSend())
{
opponentPlayField.addIncomingStones(gridController.getStonesToSend());
}
}
e non mi sembra tanto male. :sofico:
Ecco il problema.
Il setStonesToSend lo StoneFallState, che però NON viene "attivato" :muro: :muro:
Nei test pensavo dipendesse dal numero di update...ma neanche nel gioco lo fa.
Qualcuno mi può dare una mano :help: :cry: :help: :cry:
Sono su MSN ...
Forse ho risolto....
...andavo a lavoraare in una parte di codice che era già sotto una certa condzione...quindi non veniva eseguito...giustamente.
Sono salito di livello e penso che vada....
.... ma ora questo :cry: :
public int getCrushedGemsCounter()
{
int result = crushedGemsCounter;
crushedGemsCounter = 0;
return result;
}
Come faccio ad usarlo 2 volte?? :muro: :muro:
EDIT: che poi in realtà lo si usa una volta sola nel codice...
...ma ai test non piace :(
Allora..ecco il punto della situazione.
Siccome era difficile proceder perchè StonesFallState mi era tutto tranne che chiaro, ci ho messo le mani sopra per ordinarlo un po'. ;)
ALcune cose funzionavano ma non erano semplici ne chiare....quindi ho iniziato con quello.
Dopo averle rese per quanto nelle mie possibilità semplice e chiare...mi sono reso conto che alcune cose non facevano quello che dicevano fare. :(
Insomma dopo un po' di duro lavoro ora sembra funzioanre bene....ma alcuni test non passano...e sinceramente non so nemmeno bene cosa testano :wtf:
Il fatto è che ora uno dei bug è RISOLTI. Il pattern ora è rispettato ;)
Come mi comporto??? :help: :help:
Questo
public void testMoreThanEightStones()
{
controller.setIncomingStones(13);
state.update(timer, controller);
assertEquals(5, controller.getIncomingStones());
}
Per me è sbagliato.
Le incoming Stone sono 13. E lo rimangono finchè non sono inserite tutte.
Quindi, per me, prima che la get dia un nuovo numero deve passare per zero.
Forse ho risolto....
...andavo a lavoraare in una parte di codice che era già sotto una certa condzione...quindi non veniva eseguito...giustamente.
Sono salito di livello e penso che vada....
.... ma ora questo :cry: :
public int getCrushedGemsCounter()
{
int result = crushedGemsCounter;
crushedGemsCounter = 0;
return result;
}
Come faccio ad usarlo 2 volte?? :muro: :muro:
EDIT: che poi in realtà lo si usa una volta sola nel codice...
...ma ai test non piace :( AAAAAARGH, TI PREGO QUELLO NON TOCCARLO!!! :cry: :cry:
l'istruzione di azzeramento l'ho messa io ieri (testata ovviamente) per correggere uno dei 4 bug che ho corretto, l'ultimo mi sembra; ammetto le mie colpe: avrei dovuto rinominare il metodo in "getCrushedGemsCounterOnce"!! :cry:
Ho finito di mettere a posto StoneFallSate.
Ora cadono proprio bene queste stone :sofico:
Forse l'unico problema è questo
[junit] Testsuite: it.diamonds.tests.TestStoneFallState
[junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 7,609 sec
:mad: :mad:
Ora non è un grosso problema...ma dopo la FP bisogna fare qualcosa. :O
AAAAAARGH, TI PREGO QUELLO NON TOCCARLO!!! :cry: :cry:
l'istruzione di azzeramento l'ho messa io ieri (testata ovviamente) per correggere uno dei 4 bug che ho corretto, l'ultimo mi sembra; ammetto le mie colpe: avrei dovuto rinominare il metodo in "getCrushedGemsCounterOnce"!! :cry:
Io non ci penso manco morto a cambiarlo.
Ma il problema è che io utilizzo quel metodo in StoneFallState.... e quindi particamente il 90% dei test in TestGridScore Falliscono :muro: :muro:
Io devo fare sto task...la FP incombe...per non parlare dei miei esami. :cry:
Ho bisogno di una mano per far ripassare tutti quei test che falliscono :muro: :muro:
Per andare avanti ho fatto una cosa un po' oscena...
...così se avete due minuti da spendere cercate di fare qualcosa che sia meglio ;)
public int getCrushedGemsCounter(boolean reset)
{
int result = crushedGemsCounter;
if(reset)
{
crushedGemsCounter = 0;
}
return result;
}
public int getCrushedGemsCounter()
{
return getCrushedGemsCounter(true);
}
In questo modo per tutti resta il metodo uguale a prima, ma in StoneFallState lo invoco con false come parametro...così nessuno si accorge che ci è passato :D
Ricordo però che per adesso è solo per far passare dei test...il codice che quei test esercitano non è cambiato...ma il fatto che StoneFallState lo usi prima di loro li mette in difficoltà. :muro:
Per andare avanti ho fatto una cosa un po' oscena...
...così se avete due minuti da spendere cercate di fare qualcosa che sia meglio ;)
public int getCrushedGemsCounter(boolean reset)
{
int result = crushedGemsCounter;
if(reset)
{
crushedGemsCounter = 0;
}
return result;
}
public int getCrushedGemsCounter()
{
return getCrushedGemsCounter(true);
}
In questo modo per tutti resta il metodo uguale a prima, ma in StoneFallState lo invoco con false come parametro...così nessuno si accorge che ci è passato :D
Ricordo però che per adesso è solo per far passare dei test...il codice che quei test esercitano non è cambiato...ma il fatto che StoneFallState lo usi prima di loro li mette in difficoltà. :muro:
Questo metodo sta evidentemente cercando di fare due cose allo stesso momento. Urge un refactoring, perche' una situazione simile e' molto pericolosa e puo' creare potenzialmente problemi anche alla FP. 71104 te ne occupi tu? Perche' vedo Bonfo piuttosto incasinato ultimamente. Comunque bel lavoro su questo task.
Mi fate un aggiornamento sullo status dei task per favore?
Sono a metà del 4.
Purttroppo i test passano tutti, ma ho dei comportamenti strani.
Il che mi fa pemsare cho ho perso qualche test per strada.
A proposito ecco la test list :D:
- gemme crushate uguali nei 2 campi-->0 incoming stone
- crush di 1 chest e 1 gemma contro un crush n gemme -> n incoming stone
- crush di n+1 gemme contro un crush di n stone -> 1 incoming stone per l'avversario
- crush di n+1 gemme contro un crush di n stone viene mostrata la png COUNTER
I primi 3 test sono fatti...ma i risultati sul gioco non sono confortanti :cry:
Ci siamo !!! :yeah: :yeah:
Allora dopo attena ricerca ecco cosa ho scoperto.
Quando c'è da fare il calcolo sulle stone per qualche motivo quando si va a fare getCrushedGemCounter il valore era sempre nullo.
Il fatto è che in Grid l'updateCrushes, quando è presente un singolo crush, viene invocato come minimo 2 volte.
Questo comporta che al 2° invocazione il crushedGemCounter viene sovrascritto a 0.
A questo punto quando si va a leggere il valore è sempre 0.
Prima funzionava perchè updateWarningBox di PlayField interveniva nel mezzo e riusciva a beccarsi il valore prima che venisse azzerato.
Ora che lo fa StoneFallState non va più bene.
Mi sembra quindi ovvio che ora il dato vada "cachato" da Grid. In realtà basta un più.
public void updateCrushes()
{
forEachGem(crushByFlashAction);
crushByChestAction.reset();
forEachGem(crushByChestAction);
crushedGemsCounter += crushByChestAction.getCrushedGemsCounter();
if(crushByChestAction.isCrushed())
{
chainCounter++;
}
}
E questo dovrebbe anche risolvere un baco risolto da 71104 in maniera più coretta. Anche perchè questi 2 test risolvevano il baco, ma non mi sembrano proprio "corretti".
Ovvero una volta aggiunte le incomingStone quelle verranno messe...praticemnte è un SET...bisogna cambiarli nome???
public void testAdditiveIncomingStonesNumber()
{
playField.addIncomingStones(5);
playField.addIncomingStones(7);
assertEquals(12, playField.getGridController().getIncomingStones());
}
public void testAdditiveWarningBoxCounter()
{
playField.addIncomingStones(6);
playField.addIncomingStones(2);
assertEquals(8, playField.getWarningBox().getCounter());
}
Ora comunque mi metto ad aggiungere i test finchè non arrivo a quello che voglio io ;) :sofico:
VITTORIA.... :yeah: :yeah:
...ragazzi, a sto giro è stata proprio una lotta :boxe:
Ho completato la gestione delle stonesToSend.
Non ho mai lavorato così tanto coi test per così poco codice :D
Ora manca solo la PNG Counter!!!
Per quanto tempo la PNG Counter deve essere mostrata??
Per adesso mi regolo coi tempi di CrushBox ....appena ci sono news modifico ;)
VITTORIA.... :yeah: :yeah:
...ragazzi, a sto giro è stata proprio una lotta :boxe:
Ho completato la gestione delle stonesToSend.
Non ho mai lavorato così tanto coi test per così poco codice :D
Ora manca solo la PNG Counter!!!
Bravissimo! :D
Se vuoi farci un resoconto di che cosa ti ha tenuto piu' impegnato, possiamo provare ad individuare le aree dove concentrare i refactoring. Parlo anche dei refactoring dei test, ieri ho notato che la qualita' del codice dei test si sta abbassando notevolmente.
Il codice dei test va curato e rifattorizzato come il codice di produzione.
Naturlamente alcuni test non erano ottimi e quindi hanno richiesto un po' di tempo.
Sicuramente StoneFallState era agli inizi e quindi diciplinarlo non è stato facile.
Grid è un macello... :(
Altra cosa che mi mette molto in difficoltà sono gli update nei test, ovvero non so mai quanti update devo fare per ottenere quello che voglio.
E considerando che l'update si usa un test sì e l'altro pure.... :coffee:
Sicuramente la cosa che mi ha messo più in crisi è stato la sovrascrittura del numero di crushedGem dopo 2 updateCrush()...ma questo non è colpa di nessuno :D :D
Ecco un'altra cosa che mi lascia senza parole :eek:
PlayFieldDescriptor è testato 0 !!!
Penso che sia un refactoring e che quindi i test indiretti ci sono.
Ma a questo punto mi chiedo...ma il refactoring del codice non deve essere accompaganto anche dal refactoring dei test??
In ogni caso siccome questo task sta chiedendo troppo tempo mi appogio ataler classe...
Ecco un'altra cosa che mi lascia senza parole :eek:
PlayFieldDescriptor è testato 0 !!!
Penso che sia un refactoring e che quindi i test indiretti ci sono.
Ma a questo punto mi chiedo...ma il refactoring del codice non deve essere accompaganto anche dal refactoring dei test??
In ogni caso siccome questo task sta chiedendo troppo tempo mi appogio ataler classe...
Il refactoring del codice dovrebbe essere accompagnato anche dal refactoring dei test dove necessario. Poi dipende sempre dalla situazione: e' inutile scrivere test tanto per scriverli, ad esempio aggiungere dei test di condizioni gia' testate ad alto livello. Significa solo duplicare codice e questo non lo vogliamo.
Nel caso di PlayFieldDescriptor, e' una classe puramente descrittiva, non contiene alcun 'comportamento', quindi non c'e' nulla da testare. C'e' pero' da rifattorizzare quell'orribile costruttore: dopo la FP scrivere i PlayFieldDescriptor in file di testo e li caricheremo da li'.
Il refactoring del codice dovrebbe essere accompagnato anche dal refactoring dei test dove necessario. Poi dipende sempre dalla situazione: e' inutile scrivere test tanto per scriverli, ad esempio aggiungere dei test di condizioni gia' testate ad alto livello. Significa solo duplicare codice e questo non lo vogliamo.
Nel caso di PlayFieldDescriptor, e' una classe puramente descrittiva, non contiene alcun 'comportamento', quindi non c'e' nulla da testare. C'e' pero' da rifattorizzare quell'orribile costruttore: dopo la FP scrivere i PlayFieldDescriptor in file di testo e li caricheremo da li'.
ho finito(o meglio mi blocco per la FP) il refactoring degli state. Il passo successivo sarebbe testarli, ma non so fino a che punto spingermi(contando che molte condizioni sono gia testate ad alto livello, ed altre piu in basso).
Una cosa sicuramente da testare sono le condizioni di passaggio fra gli state.
Poi il resto nn penso di testarlo(al max le condizioni in cui si verifica ad esempio una crush, ma nn verifico la crush stessa).
Sarebbe ok cosi?
TASK 4 COMPLETATO.
:coffee: :coffee:
:yeah: :yeah: :yeah:
Una cosa sicuramente da testare sono le condizioni di passaggio fra gli state.
Poi il resto nn penso di testarlo(al max le condizioni in cui si verifica ad esempio una crush, ma nn verifico la crush stessa).
Sarebbe ok cosi?
Se gli altri comportamenti sono testati ad alto livello, allora testa solo le condizioni di passaggio. Va benissimo.
Se gli altri comportamenti sono testati ad alto livello, allora testa solo le condizioni di passaggio. Va benissimo.
sto procedendo ma la cosa non mi convince moltissimo.
Cosi comè implementato ad esempio, non riesco a trovare un modo per dimostrare il cambio di stato fra gemspairundercontrollState e crushState, visto che la update di crushState ritorna sempre un altro tipo di state...
bisognerebbe fare in modo che ogni stato quando passa al successivo non chiami la corrispettiva update...ma non so quanto sia fattibile
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.