View Full Version : [CICLO 12] Storia 2
Storia 2: Introduzione della Flashing Gem, pezzo speciale SENZA colore nè punteggio. Quando questa collide con un’altra gemma (o baule), tutte le gemme e tutti i bauli dello stesso colore di quest’ultima devono essere cancellati dall’area di gioco, senza dare alcun punteggio, nè avere alcun peso nelle eventuali Crush scatenate o già attive.
Il colore delle gemme da cancellare verrà deciso in base al colore degli elementi (in ordine di priorità) al di sotto, a sinistra, a destra o al di sopra della Flashing Gem.
Questo pezzo deve quindi avere una percentuale di occorrenza molto bassa, quantificabile intorno al valore di default del 2% e modificabile via GameConfig, insieme alle percentuali di occorrenza delle singole gemme.
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
12.2.1: thebol: completato
Aggiungere a GemType un nuovo tipo di gemma di nome Flashing Gem. Questa nuova gemma non avrà ne colore ne punteggio. Quando la Flashing Gem collide con una gemma o un baule questa cancella dalla griglia tutte le gemme, biggem e bauli di quel colore.
12.2.2: cionci: completato
Animare la Flashing Gem usando la texture presente in data. L'animazione è composta da 8 frame e deve avvenire a ciclo continuo senza alcuna pausa tra il primo e l'ultimo frame.
12.2.3: Vifani: completato
Modificare ScoreCalculator in modo che tutte le gemme eliminate usando una Flashing Gem non siano considerate durante il calcolo del punteggio.
ciao ;)
Mi sono permesso di fare un refactoring del motore di crush, ora mi sembra più semplice iniziare una nuova catena di crush a partire dalla flashing gem...
L'ho fatto perchè mi volevo prendere il task 1, ma non ho molto tempo...quindi mi prendo il task 2, ma lo devo rimandare a lunedì... Considero 2 giorni a partire dalla fine del task 1...
prendo l'1, penso di finirlo entro oggi(se continua a piovere) o domani(se smette e vado a giocare a calcio :) )
test list provvisoria.
esistenza tipo gemma flash
esistenza texture flash
creazione gemma di tipo flash
correttezza crush(che vengano cancellate tutte le gemme e chest di quel colore)
cosa succede se la flashingGem tocca il fondo senza toccare nessun'altra gemma?
cosa succede se la flashingGem tocca il fondo senza toccare nessun'altra gemma?
Controlla se a sinistra, poi destra ed infine in alto se c'è qualcosa. Se non trovi niente lasciala li.
ciao ;)
il 2% lo tolgo a alla prob delle gemme o delle chest?
il 2% lo tolgo a alla prob delle gemme o delle chest?
Se si può fare, direi 1% alle gemme ed 1% ai chest :)
Se si può fare, direi 1% alle gemme ed 1% ai chest :)
k.
proporrei pero un refactoring.
ora come ora, è impostato via file di config la probabilita delle gemme, e la restante era per i chest.
Io farei la cosa un po piu pulita, inserendo :
FlashProbability = 2
GemProbability = 79
ChestProbability = 19
e usando questi valori.
A questo punto si potrebbe anche mettere un check in creazione di game, che controlli che la somma di queste 3 variabili sia 100 :)
k.
proporrei pero un refactoring.
ora come ora, è impostato via file di config la probabilita delle gemme, e la restante era per i chest.
Io farei la cosa un po piu pulita, inserendo :
FlashProbability = 2
GemProbability = 79
ChestProbability = 19
e usando questi valori.
A questo punto si potrebbe anche mettere un check in creazione di game, che controlli che la somma di queste 3 variabili sia 100 :)
Invece di un check perché non cancellare GemProbability dal config e lasciare solo le altre due. La probabilità delle gemme possiamo calcolarcela con una semplice sottrazione.
ciao ;)
Invece di un check perché non cancellare GemProbability dal config e lasciare solo le altre due. La probabilità delle gemme possiamo calcolarcela con una semplice sottrazione.
ciao ;)
truissimo :)
truissimo :)
ho modificato il test per essere indipendete dal file di config
public void testCorrectGemAndChestAndFlashProportion()
{
Config config = Config.createForTesting();
int chestProb = config.getInteger("ChestProbability") ;
int flashProb = config.getInteger("FlashProbability");
int startFlash = 0;
int endFlash = flashProb - 1;
int startChest = flashProb ;
int endChest = flashProb + chestProb - 1;
int startGem = flashProb + chestProb;
int endGem = 99;
int[] percentages = { startGem, 1, endGem, 1, startChest, 1, endChest, 1 , startFlash, endFlash};
factory = GemFactory.createForTesting(new MockRandomGenerator(
percentages));
Gem gem = factory.createRandomDroppable();
assertFalse("does not return a Gem", gem.getType().isChest());
assertFalse("does not return a Gem", gem.getType().isFlash());
gem = factory.createRandomDroppable();
assertFalse("does not return a Gem", gem.getType().isChest());
assertFalse("does not return a Gem", gem.getType().isFlash());
gem = factory.createRandomDroppable();
assertTrue("does not return a Chest", gem.getType().isChest());
assertFalse("does not return a Chest", gem.getType().isFlash());
gem = factory.createRandomDroppable();
assertTrue("does not return a Chest", gem.getType().isChest());
assertFalse("does not return a Chest", gem.getType().isFlash());
gem = factory.createRandomDroppable();
assertTrue("does not return a Flash", gem.getType().isFlash());
assertFalse("does not return a Flash", gem.getType().isChest());
gem = factory.createRandomDroppable();
assertTrue("does not return a Flash", gem.getType().isFlash());
assertFalse("does not return a Flash", gem.getType().isChest());
}
ora un quesito:
se entra in contatto con piu gemme di tipo diverso, deve cancellarle tutte?(diventerebbe molto potente...)
ora un quesito:
se entra in contatto con piu gemme di tipo diverso, deve cancellarle tutte?(diventerebbe molto potente...)
Non penso. Sarebbe decisamente troppo potente. Aspettiamo una conferma di Jocchan per essere sicuri. :)
ciao ;)
No, il colore da cancellare è unico e l'ordine di priorità delle direzioni è sempre lo stesso indicato nella storia ;)
No, il colore da cancellare è unico e l'ordine di priorità delle direzioni è sempre lo stesso indicato nella storia ;)
azz nn avevo letto per bene :)
FINITO :)
L'implementazione attuale prevede gia che le cancellazioni della flash non vengano conteggiate per le crush.
Vengono invece contate come punteggio(da risolvere nel task 3, se nessuno lo prende posso farlo io).
E rispettato (e testato) l'ordine down,sx,dx,up.
Mi prendo carico del task numero 3. Prevedo 3 giorni per farlo.
Ottimo lavoro thebol.
Vifani il task è tutto tuo. Buon divertimento.
ciao ;)
Ragazzi ho problemi con il repository. E' online?
No, offline anche per me... Mi stavo accingendo a guardare il codice per postare la test list, ma non posso senza aver aggiornato il codice...
Allora i test dovrebbero essere questi:
- se viene estratta una flashing gem la durata del frame iniziale deve essere 0
- se viene estratta una flashing gem la lunghezza delle animazioni deve essere pari ad 8
- se viene estratta una flashing gem la texture usata deve essere quella prevista
Il 3° test non è necessario perchè è normale che la texture sia giusta, visto che è una cosa già "testata" nell'abbinamento GemType - Gem...
Ho messo un factory method in Gem per creare la Flashing Gem, altrimenti diventava tutto troppo complicato... Purtroppo non si può determinare il numero di frame dalle texture...
Task completato...
ho un appunto da fare sulla mia implementazione.
Non è definito se in una situazione in cui:
-una flash e a contatto con una gemma rossa(per cui cancellera tutte le gemme rosse)
-una gemma rossa (o una biggem) è a contatto con un chest
-i 2 "blocchi" non si toccano
cosa debba succedere(è una situazione verificabile in gioco).
Ora come ora l'implementazione va a caso, o meglio dipende se nella scansione della griglia viene controllato prima il chest o la flash.
Si possono fare dei test per evidenziare questa cosa, e poi eventualmente risolverla(con un task ulteriore, o integrandolo nel 3, visto che questo puo dare problemi nei punteggi).
Non so se per stasera riesco a fare i test
IMHO la flashing gem deve avere la priorità sulle chest...ma la cosa diventa complessa... Eì un po' che stavo pensando a passare (o far coesistere) ad un tipo di memorizzazione diversa dalla matrice... Forse una lista di gemme potrebbe risolvere molti dei nostri problemi...
IMHO la flashing gem deve avere la priorità sulle chest...ma la cosa diventa complessa... Eì un po' che stavo pensando a passare (o far coesistere) ad un tipo di memorizzazione diversa dalla matrice... Forse una lista di gemme potrebbe risolvere molti dei nostri problemi...
ci avevo pensato anche io... ma solo con una lista si farebbe piu fatica a individurare se in posizione x,y cè o no una cella(ti devi scorrere la lista), cosa usata spesso ad esempio per le chest.
Certo si potrebbe organizzare una fat, ma sarebbe un pelo yangi:asd:
ci avevo pensato anche io... ma solo con una lista si farebbe piu fatica a individurare se in posizione x,y cè o no una cella(ti devi scorrere la lista), cosa usata spesso ad esempio per le chest.
Certo si potrebbe organizzare una fat, ma sarebbe un pelo yangi:asd:
Ma tenendo due strutture di memorizzazione potrebbe essere più semplice...
In aggiunta alla matrice potremmo tenere una ulteriore struttura dati che individua (all'inserimento e alla rimozione) le chest e le flashingGem presenti nel campo di gioco...
Ma tenendo due strutture di memorizzazione potrebbe essere più semplice...
In aggiunta alla matrice potremmo tenere una ulteriore struttura dati che individua (all'inserimento e alla rimozione) le chest e le flashingGem presenti nel campo di gioco...
Ma duplicare la rappresentazione mi sembra un po' azzardato. Si potrebbe provare con un hash table.
Io direi di estrarre una classe da Grid, chiamata ad esempio GemCollection o GemTable e spostarci TUTTI quei metodi che fanno riferimento all'implementazione interna via matrice. Poi sara' banale cambiare implementazione e vedere le differenze.
In pratica a noi, oltre alle normali funzioni di grid, ci serve una funzione di questo tipo:
getNextFlashingGem (che tra l'altro ad occhio deve essere l'ultima inserita)
getNextChest (anche qui l'ultima inserita)
Il problema nella situazione attuale è chiaramente che bisognerebbe fare due for e scorrere tutti gli elementi della matrice per ottenere la Chest e la FlashingGem...
Secondo me duplicare la struttura dati (ricordiamoci che sono solo riferimenti) solo per le FlashingGem e per i Chest non avrebbe un costo così alto...o comunque non sarebbe così brutto...ovviamente in una classe a parte...
Riguardo alla HashTable... Sapete come funziona l'hash map di Java ?
Se scorro tutti gli elementi si scorrono in base all'hash crescente ? Oppure con quale criterio ?
Prima ho detto una stupidata...sull'ordine...per le flashing gem credo che vada dare priorità all'ultima inserita...mentre per le chest dubbiamo attivare prima sempre quella più in alto...
Il problema nella situazione attuale è chiaramente che bisognerebbe fare due for e scorrere tutti gli elementi della matrice per ottenere la Chest e la FlashingGem...
Qual e' il problema a scorrere tutti gli elementi della matrice per ottenere Chest e FlashingGem?
Sicuramente non prestazinale... E' che mi "puzza"... Mi piacerebbe che fosse più semplice il codice...
Sicuramente non prestazinale... E' che mi "puzza"... Mi piacerebbe che fosse più semplice il codice...
Ok, questo lo capisco, ma aggiungere una seconda struttura mirror della prima e' una duplicazione e sicuramente e' meno semplice rispetto ad ora. Certo che una soluzione piu' elegante sarebbe ottima, ma secondo me quello che abbiamo adesso e' per il momento "the simplest thing that could possibly work".
ho fatto i test, e la situazione e come pensavo, in alcune situazione vince il chest(la crush viene contata) in altre vince la flesh(la crush non viene aumentata).
Ho i test sul portatile, fra un po li committo in ignore(uno deve fallire ma non so ancora quale :fagiano: ).
In pratica a noi, oltre alle normali funzioni di grid, ci serve una funzione di questo tipo:
getNextFlashingGem (che tra l'altro ad occhio deve essere l'ultima inserita)
getNextChest (anche qui l'ultima inserita)
il fatto che sia l'ultima inserita non funziona piu al secondo giro in una catena di crush.
il fatto che sia l'ultima inserita non funziona piu al secondo giro in una catena di crush.
Intendevo che quelle funzioni devono ritornare le flashing gem in ordine di inserimento... cioè, se ci sono due flashing gem nel campo di gioco debba ritornare l'ultima inserita...
FINITO :)
L'implementazione attuale prevede gia che le cancellazioni della flash non vengano conteggiate per le crush.
Vengono invece contate come punteggio(da risolvere nel task 3, se nessuno lo prende posso farlo io).
E rispettato (e testato) l'ordine down,sx,dx,up.
Puoi farmi un esempio in cui le gemme eliminate con una flashgem vengono considerate nel conteggio? Perché al momento attuale mi sembra che non vengano considerate già. La cosa interessante è che vedendo il codice non dovrebbe essere così.
Puoi farmi un esempio in cui le gemme eliminate con una flashgem vengono considerate nel conteggio? Perché al momento attuale mi sembra che non vengano considerate già. La cosa interessante è che vedendo il codice non dovrebbe essere così.
in teoria dovrebbero passare di qua
private void removeCrushedGem(Gem gem, BigGemList bigGemsToBeCrushed)
{
if(isCellInABigGem(gem.getCellRow(), gem.getCellColumn()))
{
bigGemsToBeCrushed.add(getBigGemAt(gem.getCellRow(), gem.getCellColumn()));
scoreCalculator.addGemWithBonus(gem);
}
else
{
scoreCalculator.addGem(gem);
}
if(!gem.getType().isChest())
{
crushedGemsCounter++;
}
removeAndClean(gem);
}
e la scoreCalculator.addGem(gem); dovrebbe essere eseguita...
forse ho capito perche :)
i punteggi vengono sommati solo se ce una chain(vengono moltiplicati per il numero di chain, che in questo caso è 0).
probabilmente con una flash + crush da chest il punteggio delle gemme viene contato.
ps. devo uscire, indaghero megliodomani.
in teoria dovrebbero passare di qua
private void removeCrushedGem(Gem gem, BigGemList bigGemsToBeCrushed)
{
if(isCellInABigGem(gem.getCellRow(), gem.getCellColumn()))
{
bigGemsToBeCrushed.add(getBigGemAt(gem.getCellRow(), gem.getCellColumn()));
scoreCalculator.addGemWithBonus(gem);
}
else
{
scoreCalculator.addGem(gem);
}
if(!gem.getType().isChest())
{
crushedGemsCounter++;
}
removeAndClean(gem);
}
e la scoreCalculator.addGem(gem); dovrebbe essere eseguita...
forse ho capito perche :)
i punteggi vengono sommati solo se ce una chain(vengono moltiplicati per il numero di chain, che in questo caso è 0).
probabilmente con una flash + crush da chest il punteggio delle gemme viene contato.
ps. devo uscire, indaghero megliodomani.
Va bene, non c'è problema. Aggiungerò un doppio controllo che tronchi via questo discorso.
Va bene, non c'è problema. Aggiungerò un doppio controllo che tronchi via questo discorso.
imho si puo evitare.
quando si capirà se va fatto prima il controllo sulle chest o sulle flash, verranno implmentati 2 cicli for sulla griglia, uno per le chest e uno per le flash.
Basta che dopo il ciclo delle flash venga chiamata scoreCalculator.closeChain(0), mentre dopo il ciclo per le chest venga chiamata scoreCalculator.closeChain(chainCounter)(comportamento attuale).
Jocchan: se sei fra di noi batti un colpo... Le flashing gem hanno la precedenza sulle chest ?
Jocchan: se sei fra di noi batti un colpo... Le flashing gem hanno la precedenza sulle chest ?
Sì :)
Scusate il ritardo, nel thread dei problemi ho spiegato che il mio hard disk ha salutato con la manina.
Altra cosa, bisogna anche evitare che vengano estratte due flash gem di fila. Fosse per me, farei in modo di rendere l'intervallo minimo pari a 12 (6 coppie). Le flash gem, come le smart bomb nei giochi, sono un aiuto che viene dato moooooolto raramente, e di cui è letale abusare.
Però, non voglio caricare il tutto di eccezioni, quindi per ora limitiamoci ad evitare che ne vengano create due nella stessa coppia.
Per il resto vedremo in seguito.
Mi dispiace per il disco :(
Riguardo alla precedenza ? Le flshing gem devo avere precedenza sulle chest ?
In pratica, quando andiamo a fare un crush e c'è una (o più) flashing gem, dobbiamo prima fare il crush della flashing gem e poi quello delle chest, giusto ?
Mi dispiace per il disco :(
Riguardo alla precedenza ? Le flshing gem devo avere precedenza sulle chest ?
In pratica, quando andiamo a fare un crush e c'è una (o più) flashing gem, dobbiamo prima fare il crush della flashing gem e poi quello delle chest, giusto ?
Il "sì" era riferito a questo. Se in una coppia abbiamo una chest ed una flashing gem, prima gestiamo la cancellazione causata dalla flashing gem, e solo dopo ci occupiamo delle chest.
Se per caso una flashing gem fosse già caduta in una zona "vuota" (magari due caselle sotto una big gem molto larga, che viene eliminata nella crush, e che fa cadere gemme sopra la flashing) allora, per coerenza, la crush si interromperà un istante (e le gemme del colore di turno verranno eliminate), e poi riprenderà da dove era rimasta.
Anche se attualmente questo evento può verificarsi solo se la flashing gem è sul fondo dell'area di gioco, non significa che non possano verificarsi altre cancellazioni successive, scatenate da questa, e sempre collegate alla crush iniziale. Nel prossimo ciclo, inoltre, introdurremo un altro pezzo (l'ultimo per la first playable) che consentirà di avere una flashing gem anche in posizioni diverse dal fondo, quindi meglio gestire fin da subito il comportamento in questi casi come regola generale, più che come eccezione :)
P.S.: grazie per la solidarietà :(
Scusate ma sbaglio o a questo punto bisogna rivedere l'implementazione del task 1? Attualmente non mi sembra che la flash gem venga gestita come dice Jocchan.
Scusate ma sbaglio o a questo punto bisogna rivedere l'implementazione del task 1? Attualmente non mi sembra che la flash gem venga gestita come dice Jocchan.
se volete me ne occupo io(stasera, se qualcuno puo prima meglio :) )
ricapitolando:
le flash hanno la precedenza sulle chest(2 cicli for su grid in successione)(questo potrebbe portare a un discreto refactoring di grid ora un po troppo cicciona)
vi posto 2 test che dimostreranno questa cosa
public void testCrushAndFlashing(){
insertAndUpdate(createGem(EMERALD), 13, 0);
insertAndUpdate(createGem(EMERALD), 13, 1);
insertAndUpdate(createGem(DIAMOND), 12, 0);
insertAndUpdate(createGem(DIAMOND), 12, 1);
insertAndUpdate(createGem(EMERALD), 11, 0);
insertAndUpdate(createGem(EMERALD), 11, 1);
insertAndUpdate(createGem(EMERALD_CHEST), 10, 1);
insertAndUpdate(createGem(FLASHING_GEM), 13, 2);
insertAndStopGemsPair();
makeAllGemsFall();
controller.update(timer);
assertEquals(4, grid.getNumberOfGems());
assertEquals(5, grid.getCrushedGemsCounter());
assertEquals(0, grid.getChainCounter());
}
//TODO questi 2 test dovrebbero comportarsi ugualmente...
public void testFlashingAndCrush(){
insertAndUpdate(createGem(EMERALD), 13, 0);
insertAndUpdate(createGem(EMERALD), 13, 1);
insertAndUpdate(createGem(DIAMOND), 12, 0);
insertAndUpdate(createGem(DIAMOND), 12, 1);
insertAndUpdate(createGem(EMERALD), 11, 0);
insertAndUpdate(createGem(EMERALD), 11, 1);
insertAndUpdate(createGem(FLASHING_GEM), 10, 1);
insertAndUpdate(createGem(EMERALD_CHEST), 13, 2);
insertAndStopGemsPair();
makeAllGemsFall();
controller.update(timer);
assertEquals(4, grid.getNumberOfGems());
assertEquals(5, grid.getCrushedGemsCounter());
assertEquals(0, grid.getChainCounter());
}
grid.getCrushedGemsCounter() restituisce 5 perche la flash viene contata(a differenza della chest, sara una cosa da modifcare nel 3 task penso)
controllo nella creazione di gemspair percui non ci siano 2 flash in una gems pair
Ecco i test che mi riguardano
public void testDiamondsChestAndFlashCrushing()
{
insertAndUpdate(createGem(DIAMOND), 13, 2);
insertAndUpdate(createGem(DIAMOND), 13, 3);
insertAndUpdate(createGem(DIAMOND), 13, 4);
insertAndUpdate(createGem(DIAMOND_CHEST), 13, 1);
insertAndUpdate(createGem(FLASHING_GEM), 13, 5);
grid.updateCrushes();
grid.closeChain();
assertEquals("score must be empty", 0, grid.getScoreCalculator().getScore());
}
public void testDiamondsFlashCrushing()
{
insertAndUpdate(createGem(DIAMOND), 13, 2);
insertAndUpdate(createGem(DIAMOND), 13, 3);
insertAndUpdate(createGem(DIAMOND), 13, 4);
insertAndUpdate(createGem(FLASHING_GEM), 13, 5);
grid.updateCrushes();
grid.closeChain();
assertEquals("score must be empty", 0, grid.getScoreCalculator().getScore());
}
Datemi conferma per il proseguio.
P.S: thebol non toccare nulla. Ho già in mente come risolvere i problemi di tutti in un colpo solo.
Datemi conferma per il proseguio.
P.S: thebol non toccare nulla. Ho già in mente come risolvere i problemi di tutti in un colpo solo.
avevo risolto il problema della precedenza fra chest e flash(2 cicli separati). E abbastanza brutta, ma dava il via a un refactoring interessante(fare una classe per le crush abstract e specializzarla per il crush da flash e crush da chest, in modo da alleggerire grid, ormai diventata molto lunga).
Per quanto riguarda invece la doppia flash, stava guardando l'implmentazione simile sulle chest, e non mi piaceva per nulla, io avrei spostato questo lavoro in gemQueue. Questa quando estrae una gemma se è flash controlla se la precedente è flash, se si ne estrae un altra.
cmq ok, nn committo nulla :)
Io ho pronto tutto. I test passano. Attendo conferma per la commit. Chiaramente ho separato i due cicli, ma non ho fatto altro refactoring prima di concludere ufficialmente il task. Non è necessario fare alcun controllo sullo score se le flashgem sono gestite prima delle chest. Il punteggio, infatti, viene assegnato quando non dovrebbe solo in presenza di una flash con una chest e solo se quest'ultima si attiva prima della flash ed entrambe si riferiscono allo stesso tipo di gemme. Cioè è un caso abbastanza raro, ma è necessario gestirlo e per farlo è necessario semplicemente eseguire il crush legato alla flash prima della chest. Dando precedenza alla flash, non c'è alcun problema.
Non è necessario fare alcun controllo sullo score se le flashgem sono gestite prima delle chest. Il punteggio, infatti, viene assegnato quando non dovrebbe solo in presenza di una flash con una chest e solo se quest'ultima si attiva prima della flash ed entrambe si riferiscono allo stesso tipo di gemme. Cioè è un caso abbastanza raro, ma è necessario gestirlo e per farlo è necessario semplicemente eseguire il crush legato alla flash prima della chest. Dando precedenza alla flash, non c'è alcun problema.
non mi è chiarissima questa cosa, ma dipende da come l'hai gestito.
nn vedo l'ora di vedere il commit :)
Ecco i test che mi riguardano
public void testDiamondsChestAndFlashCrushing()
{
insertAndUpdate(createGem(DIAMOND), 13, 2);
insertAndUpdate(createGem(DIAMOND), 13, 3);
insertAndUpdate(createGem(DIAMOND), 13, 4);
insertAndUpdate(createGem(DIAMOND_CHEST), 13, 1);
insertAndUpdate(createGem(FLASHING_GEM), 13, 5);
grid.updateCrushes();
grid.closeChain();
assertEquals("score must be empty", 0, grid.getScoreCalculator().getScore());
}
public void testDiamondsFlashCrushing()
{
insertAndUpdate(createGem(DIAMOND), 13, 2);
insertAndUpdate(createGem(DIAMOND), 13, 3);
insertAndUpdate(createGem(DIAMOND), 13, 4);
insertAndUpdate(createGem(FLASHING_GEM), 13, 5);
grid.updateCrushes();
grid.closeChain();
assertEquals("score must be empty", 0, grid.getScoreCalculator().getScore());
}
Mi sembrano ok. :)
ciao ;)
Commit effettuata.
Ottimo. A che punto siamo con la Storia? Vorrei che si concludesse oggi cosi' posso dare una ripassata al codice nel fine settimana prima di partire.
Ottimo. A che punto siamo con la Storia? Vorrei che si concludesse oggi cosi' posso dare una ripassata al codice nel fine settimana prima di partire.
I tre task sono completi quindi storia terminata. Quando jocchan ritorna in carreggiata col pc gli passiamo una build cosi ci dice che cosa ne pensa.
ciao ;)
I tre task sono completi quindi storia terminata. Quando jocchan ritorna in carreggiata col pc gli passiamo una build cosi ci dice che cosa ne pensa.
ciao ;)
Perfetto. Anche l'altra storia e' conclusa?
Perfetto. Anche l'altra storia e' conclusa?
L'ultimo refactoring è quasi terminato. C'è un bug su linux che riguarda alsa e oss ma da quello che non ha voluto nessuno. Dovrò guardarci io nel tempo libero.
ciao ;)
L'ultimo refactoring è quasi terminato. C'è un bug su linux che riguarda alsa e oss ma da quello che non ha voluto nessuno. Dovrò guardarci io nel tempo libero.
ciao ;)
E' uscita cmq una revisione nuova di LWJGL che forse risolve vari problemi. Bisognerebbe provare a sostituirla alla versione attualmente in uso.
E' uscita cmq una revisione nuova di LWJGL che forse risolve vari problemi. Bisognerebbe provare a sostituirla alla versione attualmente in uso.
Ho già messo la 0.99 sul repository. Ne è uscita un'altra? :confused:
ciao ;)
Commit effettuata.
secondo me non hai gesito il fatto di crush multiple con in mezzo una crush da flash.
provo a implementare un test per vedere se è vero
public void testScoreOnFlashAndChestCrush()
{
insertAndUpdate(createGem(RUBY), 13, 1);
insertAndUpdate(createGem(EMERALD), 12, 1);
insertAndUpdate(createGem(FLASHING_GEM), 13, 0);
insertAndUpdate(createGem(EMERALD_CHEST), 13, 2);
insertAndStopGemsPair();
makeAllGemsFall();
controller.update(timer);
assertEquals(4, grid.getNumberOfGems());//emerald, emerald chest, e 2 diamond della gemspair(OK)
assertEquals(1, grid.getCrushedGemsCounter());//restituisce 2, perche conta anche la flash(le chest nn vengono contate)
assertEquals(0, grid.getChainCounter());//(OK)
makeAllGemsFall();
timer.advance(config.getInteger("DelayBetweenCrushes"));
controller.update(timer);
assertEquals(2, grid.getNumberOfGems());//2 diamond della gemspair(OK)
assertEquals(1, grid.getCrushedGemsCounter());//la emerals
assertEquals(1, grid.getChainCounter());
timer.advance(config.getInteger("DelayBetweenCrushes"));
controller.update(timer);
int realScore = EMERALD.score();//40
assertEquals(realScore, grid.computeTotalScore());//restituisce 90, ossia 40 + 50(ruby)
}
lo committo in ignore, sperando nn rompa la build :|
public void testScoreOnFlashAndChestCrush()
{
insertAndUpdate(createGem(RUBY), 13, 1);
insertAndUpdate(createGem(EMERALD), 12, 1);
insertAndUpdate(createGem(FLASHING_GEM), 13, 0);
insertAndUpdate(createGem(EMERALD_CHEST), 13, 2);
insertAndStopGemsPair();
makeAllGemsFall();
controller.update(timer);
assertEquals(4, grid.getNumberOfGems());//emerald, emerald chest, e 2 diamond della gemspair(OK)
assertEquals(1, grid.getCrushedGemsCounter());//restituisce 2, perche conta anche la flash(le chest nn vengono contate)
assertEquals(0, grid.getChainCounter());//(OK)
makeAllGemsFall();
timer.advance(config.getInteger("DelayBetweenCrushes"));
controller.update(timer);
assertEquals(2, grid.getNumberOfGems());//2 diamond della gemspair(OK)
assertEquals(1, grid.getCrushedGemsCounter());//la emerals
assertEquals(1, grid.getChainCounter());
timer.advance(config.getInteger("DelayBetweenCrushes"));
controller.update(timer);
int realScore = EMERALD.score();//40
assertEquals(realScore, grid.computeTotalScore());//restituisce 90, ossia 40 + 50(ruby)
}
lo committo in ignore, sperando nn rompa la build :|
Risolto anche questo problema che evidentemente mi era sfuggito ;)
Ho aggiunto un booleano alla classe che scandisce quando si deve e quando non si deve aggiungere allo score il punteggio delle crush. E' chiaro che è impostato a FALSE quando esegue le crush legate alla flashgem.
manca ancora il fatto che la gemspair non possa contenere 2 flash(non avevo capito se lo faceva vifani, ma in effetti e una cosa da primo task).
Mi ci metto subito.
Ciclo terminato. Chiudo il thread.
ciao ;)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.