View Full Version : [CICLO 18] Storia 2
Storia: Fare in modo che tenere premuto il tasto per la dinamite per oltre 5 secondi faccia esplodere automaticamente il candelotto nella modalità normale. Questo evento sarà sottolineato da una velocità sempre maggiore dell’animazione, la cui durata dei frame sarà ridotta di 90 millisecondi ogni secondo che passa, con un valore minimo fissato a 50ms.
Se ci si trova in uno stato non permesso, l'animazione proseguirà fino al prossimo stato permesso.
Inoltre, finchè il tasto per la dinamite rimane premuto, il gioco dovrà switchare ogni 1.5 secondi tra le due modalità di esplosione presenti (normale o a croce, come in figura), evidenziando in maniera coerente il contenuto delle caselle circostanti.
Un candelotto di dinamite esploso, infine, darà punteggio nullo e non contribuirà alla creazione di Stones, ma conterà come 1 all'interno di una Crush.
Tutti i valori numerici indicati nella storia, a parte l'ultimo, devono essere modificabili in GameConfig.
http://lnx.rc6.it/diamonds/varie/schema_tnt.jpg
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 nelle specifiche 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:
18.2.1.: thebol: completato
fare in modo che, scaduti i 5 secondi durante i quali si ripete l'animazione con il frame vuoto e quello con lo zero, la dinamite esploda automaticamente.
18.2.2: Jappilas: completato
fare in modo che l'animazione dell'esplosione imminente sia sempre più rapida, sottraendo ogni secondo un valore fisso (90 ms) al delay tra un frame e l'altro, con un valore minimo di 50 ms.
18.2.3:
disabilitare il pulsante per la dinamite durante una crush.
18.2.4: Bonfo: completato
fare in modo che, finchè il tasto dell'esplosione resta premuto, si ciclino le due modalità di esplosione in figura, evidenziando coerentemente le caselle circostanti e passando da una all'altra ogni 1.5 secondi.
18.2.5: thebol: completato
fare in modo che un candelotto esploso conti come +1 in una Crush.
18.2.3: disabilitare il pulsante per la dinamite durante una crush.
anche in mezzo a una catena di crush giusto?(ovvero bloccare crushState e waitNextCrushState)
stessa domanda dell'altro thread:
se uno rilascia il tasto in uno di questi stati, l'esplosione viene posticipata al primo stato permesso successivo, giusto?
anche in mezzo a una catena di crush giusto?(ovvero bloccare crushState e waitNextCrushState)
stessa domanda dell'altro thread:
se uno rilascia il tasto in uno di questi stati, l'esplosione viene posticipata al primo stato permesso successivo, giusto?
Esatto. Gli stati da bloccare sono sempre crushState e waitNextCrushState.
Gli altri sono tutti permessi.
Task:
18.2.5: fare in modo che un candelotto esploso conti come +1 in una Crush.
prendo questo
tempo 2 giorni
testList provvisoria.
--setto il num di crush a 20, cancello una dinamite e il num di crush deve essere 1
prendo questo
tempo 2 giorni
testList provvisoria.
--setto il num di crush a 20, cancello una dinamite e il num di crush deve essere 1
Assegnato.
Forza, fatevi sotto :)
Io mi prenoto per questo: 18.2.4
Lo posso fare solo nel week-end, quindi non prima.
Tempo: 3 giorni.
jappilas
13-06-2006, 13:37
sto facendo il numero 2, dovrebbe essere terminato stasera o domani ;)
sto facendo il numero 2, dovrebbe essere terminato stasera o domani ;)
La lista dei test?? :read:
La lista dei test?? :read:
Infatti. Dove sta la lista? :D
ciao ;)
jappilas
13-06-2006, 14:48
Infatti. Dove sta la lista? :D
ciao ;)
sul mio pc di casa ... volevo farvi la sorpresa di farvi trovare tutto ( codice E test) già bello pronto e committato, una volta funzionante :O :D
comunque pensavo a questi test
- creo la dinamite, la attivo, mando avanti il timer di 1001 (*) ms, verifico che il frameDelay si sia ridotto (ero indeciso se far andare avanti di 411 ms e testare il frame o introdurre un getter ad hoc per il frameDelay corrente :stordita: )
- creo la dinamite , la attivo, mando avanti il timer di 5001 ms , verifico che il frameDelay sia arrivato a 50 ms
se avete in mente quali altri test servono... :O
(*) : si vuole che anche il parametro "frequency switch delay" sia acquisito da gameconfig?
jappilas
13-06-2006, 15:42
problemino:
se per testare il delay minimo dopo 5 secondi non uso (come in effetti preferirei non fare) un getter, per verificare che il frame cambi, ipoteticamente, entro 50 ms, dovrei andare a 5 sec più 50 ms
il che vorrebbe dire sforare il timeout oltre cui la dinamite non dovrebbe essere più animata (anzi non dovrebbe proprio più "essere" :D)
il che vuol dire che, in un intervallo utile da 0 a 4999 millisecondi, switch di frequenza distanziati di un secondo ne possono avvenire al massimo 4
quindi il minimo raggiungibile sarebbe 500-360 = 140 ms , con i 50 settati al momento dell' esplosione ma in pratica non usati e non testabili
problemino:
se per testare il delay minimo dopo 5 secondi non uso (come in effetti preferirei non fare) un getter, per verificare che il frame cambi, ipoteticamente, entro 50 ms, dovrei andare a 5 sec più 50 ms
il che vorrebbe dire sforare il timeout oltre cui la dinamite non dovrebbe essere più animata (anzi non dovrebbe proprio più "essere" :D)
il che vuol dire che, in un intervallo utile da 0 a 4999 millisecondi, switch di frequenza distanziati di un secondo ne possono avvenire al massimo 4
quindi il minimo raggiungibile sarebbe 500-360 = 140 ms , con i 50 settati al momento dell' esplosione ma in pratica non usati e non testabili
Consideriamo allora 140 come minimo.
I 50 servivano perchè i valori dati nella storia sono teorici, vanno sistemati sul campo agendo su GameConfig, ma in effetti a questo punto sono sovrabbondanti, e 140ms è già un valore sufficientemente basso.
Chi si prende il task 1? Berto? Tiger?
anche in mezzo a una catena di crush giusto?(ovvero bloccare crushState e waitNextCrushState)
stessa domanda dell'altro thread:
se uno rilascia il tasto in uno di questi stati, l'esplosione viene posticipata al primo stato permesso successivo, giusto?
Esatto. Gli stati da bloccare sono sempre crushState e waitNextCrushState.
Gli altri sono tutti permessi.
Mi sono accorto di aver dimenticato di rispondere al secondo punto.
In realtà il problema non si pone: quando si preme il pulsante, la gemspair si blocca, dunque non è possibile entrare in crushState e waitNextCrushState. L'unico modo perchè questo si verifichi è premere il pulsante in uno dei due stati in questione... ma se proibiamo la pressione durante una Crush (cosa che non dobbiamo neanche giustificare, visto che agli occhi dell'utente la Crush avrebbe il "focus" nell'area di gioco), otteniamo gratuitamente il risultato voluto, senza ritardi nè espedienti di alcun genere.
Mi sono accorto di aver dimenticato di rispondere al secondo punto.
In realtà il problema non si pone: quando si preme il pulsante, la gemspair si blocca, dunque non è possibile entrare in crushState e waitNextCrushState. L'unico modo perchè questo si verifichi è premere il pulsante in uno dei due stati in questione... ma se proibiamo la pressione durante una Crush (cosa che non dobbiamo neanche giustificare, visto che agli occhi dell'utente la Crush avrebbe il "focus" nell'area di gioco), otteniamo gratuitamente il risultato voluto, senza ritardi nè espedienti di alcun genere.
la gemspair si blocca quando si rilascia il pulsante, non quando si preme.
Percui è possibile premerlo in uno stato e rilasciarlo(attivare la dinamite) in un altro.
jappilas
13-06-2006, 16:39
Consideriamo allora 140 come minimo.
I 50 servivano perchè i valori dati nella storia sono teorici, vanno sistemati sul campo agendo su GameConfig, ma in effetti a questo punto sono sovrabbondanti, e 140ms è già un valore sufficientemente basso.
ma, in realtà l' alternativa sarebbe avere il delay dell' aumento di frequenza settabile da gameconfig, come pure la quantità di cui il frame delay viene ridotto...
però occorrerebbe cambiare i parametri del costruttore, aggiungere la property ecc, cosa che farei domani :D
per adesso, una prima stesura dei test con valori hardcoded viene fatta passare da poche righe di codice per lo più la sottrazione e le dichiarazioni dei parametri statici ;)
la gemspair si blocca quando si rilascia il pulsante, non quando si preme.
Percui è possibile premerlo in uno stato e rilasciarlo(attivare la dinamite) in un altro.
Hai ragione, errore mio.
Dobbiamo fare in modo che si blocchi da subito allora. In questo modo, il giocatore percepirà subito il cambio di focus ed il fatto che il tempo è "fermo".
ma, in realtà l' alternativa sarebbe avere il delay dell' aumento di frequenza settabile da gameconfig, come pure la quantità di cui il frame delay viene ridotto...
però occorrerebbe cambiare i parametri del costruttore, aggiungere la property ecc, cosa che farei domani :D
per adesso, una prima stesura dei test con valori hardcoded viene fatta passare da poche righe di codice per lo più la sottrazione e le dichiarazioni dei parametri statici ;)
Jap, tutti i valori numerici della storia (tranne il +1 nelle combo, che riguarda il quinto task) erano richiesti come settabili :eek:
Hai ragione, errore mio.
Dobbiamo fare in modo che si blocchi da subito allora. In questo modo, il giocatore percepirà subito il cambio di focus ed il fatto che il tempo è "fermo".
ma cosi uno puo rimanere fermo per 5 secondi, non mi sembra molto giusto..
ma cosi uno puo rimanere fermo per 5 secondi, non mi sembra molto giusto..
5 secondi è un valore di prova, che potremo benissimo (anzi, con tutta probabilità lo faremo per non spezzettare troppo i match) abbassare, è proprio per questo motivo che è settabile ;)
Inoltre, approfittare della dinamite per stare fermi è del tutto controproducente: non puoi contrattaccare, e nel frattempo l'avversario può riempirti di pietre, che arriverebbero tutte insieme (KO instantaneo).
jappilas
13-06-2006, 18:02
Jap, tutti i valori numerici della storia (tranne il +1 nelle combo, che riguarda il quinto task) erano richiesti come settabili :eek:
ops ehm... :stordita: :p
ma cosi uno puo rimanere fermo per 5 secondi, non mi sembra molto giusto..
Sono d'accordo... :O
Sono d'accordo... :O
Non c'è nulla di sbagliato. Se tu ti fermi (scelta tua), io ho tutto il tempo di massacrarti come voglio :)
mmmh....
Forse mi hai convinto :p
Vediamo quando giochiamo ;)
jappilas
13-06-2006, 22:27
task 2 completato, le nuove property si chiamano DynamiteBlinkingRateChangeDelay e DynamiteFrameDelayDelta
jappilas
14-06-2006, 11:50
potrebbe per caso essere utile parametrizzare la dinamite, invece che tramite intervallo di "frequency change" e valore iniziale del frame delay, tramite:
valore iniziale
valore minimo
numero di passi
e il calcolo del delta delay e dell' intervallo di cambio, internamente alla funzione?
così a occhio mi sembra che si avrebbe un controllo uno zinzino più fine e accurato... :stordita:
prendo questo
tempo 2 giorni
testList provvisoria.
--setto il num di crush a 20, cancello una dinamite e il num di crush deve essere 1
fatto e committato
prendo il 18.2.1
tempo stimato 3 giorni
prendo il 18.2.1
tempo stimato 3 giorni
Vai che sei lanciatissimo :D
ciao ;)
Vai che sei lanciatissimo :D
ciao ;)
mi stanno simpatiche le dinamiti
:D
cdimauro
15-06-2006, 09:09
potrebbe per caso essere utile parametrizzare la dinamite, invece che tramite intervallo di "frequency change" e valore iniziale del frame delay, tramite:
valore iniziale
valore minimo
numero di passi
e il calcolo del delta delay e dell' intervallo di cambio, internamente alla funzione?
così a occhio mi sembra che si avrebbe un controllo uno zinzino più fine e accurato... :stordita:
Se ti serve, direi che va bene. Se sono cose in più, è rigorosamente YAGNI. :p
jappilas
15-06-2006, 10:10
Se ti serve, direi che va bene. Se sono cose in più, è rigorosamente YAGNI. :p
in effetti non e' che mi "serva" in modo impellente... facendo cosi', tra l' altro la routine di cambio del frame in dynamite.update() potrebbe calibrare l' intervallo in modo da avere con certezza almeno un cambio utile prima dei 5 sec e risolvere in parte il prob di cui alla pgina prima :mc: :O
ma e' YAGNI , quindi la pianto e mi dedico a qualche altro task :p
prendo il 18.2.1
tempo stimato 3 giorni
il task è piu complicato del previsto...
ora il timer della dinamite viene gestito all'interno dell'oggetto dynamite, da cui non ho accesso ne a grid ne a gridController...
percui per potere eliminare la dinamite dopo tot tempo, dovrei rivedere pesantemente(ma neanche troppo) il giro.
La mia idea era di inserire uno stato, precedente a gemsPairUnderControll, che controlli se ci sono delle dinamiti da eliminare.
In caso negativo il tutto continuerebbe come ora.
Altrimenti verrebbe cancellata la dinamite e incominciato il giro delle crush.
Questo pero vuol dire che la dinamite verrebbe eliminata solo nel caso che il giocatore stia controllando la gemsPair...
Ma questo è un problema che risolverò dopo, inserendolo sempre come primo stato(tranne nelle crush).
in effetti non e' che mi "serva" in modo impellente... facendo cosi', tra l' altro la routine di cambio del frame in dynamite.update() potrebbe calibrare l' intervallo in modo da avere con certezza almeno un cambio utile prima dei 5 sec e risolvere in parte il prob di cui alla pgina prima :mc: :O
ma e' YAGNI , quindi la pianto e mi dedico a qualche altro task :p
Il 3 è libero :p
Immagino però serva prima completare il primo.
jappilas
15-06-2006, 10:50
il task è piu complicato del previsto...
ora il timer della dinamite viene gestito all'interno dell'oggetto dynamite, da cui non ho accesso ne a grid ne a gridController...
percui per potere eliminare la dinamite dopo tot tempo, dovrei rivedere pesantemente(ma neanche troppo) il giro.
La mia idea era di inserire uno stato, precedente a gemsPairUnderControll, che controlli se ci sono delle dinamiti da eliminare.
In caso negativo il tutto continuerebbe come ora.
Altrimenti verrebbe cancellata la dinamite e incominciato il giro delle crush.
Questo pero vuol dire che la dinamite verrebbe eliminata solo nel caso che il giocatore stia controllando la gemsPair...
Ma questo è un problema che risolverò dopo, inserendolo sempre come primo stato(tranne nelle crush).
quello che ipotizzavo vagamente, per il caso in cui avessi preso io quel task, era settare una flag (tipo "timeoutExpired") dall' interno dell' oggetto dynamite allo scadere dei 5 sec (mi pare la condizione timer<activationTimestamp+animationTimeOut sia gia' testata da qualche parte, potresti usare il secondo branch di quella) e interrogarla da fuori (piu' o meno come per isArmed()) nell' update dello state (magari non sempre, ma quando il controller "sa" che c' e' un' esplosione imminente)
... puo' avere un senso? :mbe: :stordita:
quello che ipotizzavo vagamente, per il caso in cui avessi preso io quel task, era settare una flag (tipo "timeoutExpired") dall' interno dell' oggetto dynamite allo scadere dei 5 sec (mi pare la condizione timer<activationTimestamp+animationTimeOut sia gia' testata da qualche parte, potresti usare il secondo branch di quella) e interrogarla da fuori (piu' o meno come per isArmed()) nell' update dello state (magari non sempre, ma quando il controller "sa" che c' e' un' esplosione imminente)
... puo' avere un senso? :mbe: :stordita:
avevo avuto la stessa idea.
Fra l'altro quel flag verrebbe alzato anche dalla blowDynamite
avevo avuto la stessa idea.
Fra l'altro quel flag verrebbe alzato anche dalla blowDynamite
ho fatto lo spike per verificarne la fattibilità e in effetti funziona.
fra l'altro ho anche beccato un bug su quello che ritorna gemFallState nel caso vengano generato crush da dinamite sbaglia a ritornare gemFallState...
ora risolvo il bug, poi proseguo col refactoring un po piu testDriven
Task 18.2.4.
Un problema grande come una casa: Dynamite non ha alcun modo di comunicare con grid.
Ovvero non so come fare per raggiungere le gemme da rendere Birght.
La soluzione che mi viene in mente essere più elegante è la seguente:
Grid implementa BlowingListener e si iscrive a Dynamite. Ogni volta che bisogna switchare il blowMode Dynamite invia un evento, ovvero invoca il metodo switchBlowMode di tutti i listener registrati.
Che ne dite...?? :stordita:
A me fa paura...perchè questa soluzione è completamente fuori dal design di Diamond :(
Task 18.2.4.
Un problema grande come una casa: Dynamite non ha alcun modo di comunicare con grid.
Ovvero non so come fare per raggiungere le gemme da rendere Birght.
La soluzione che mi viene in mente essere più elegante è la seguente:
Grid implementa BlowingListener e si iscrive a Dynamite. Ogni volta che bisogna switchare il blowMode Dynamite invia un evento, ovvero invoca il metodo switchBlowMode di tutti i listener registrati.
Che ne dite...?? :stordita:
A me fa paura...perchè questa soluzione è completamente fuori dal design di Diamond :(
un altra soluzione potrebbe essere aggiungere uno stato che guarda se cè una dinamite che innescata, guarda se è in stato croce o quadrato, e illumina le gemme di conseguenza.
Fra l'altro nel mio refactoring(ancora da fare..), andrò ad aggiungere uno stato che controlla se esiste una gemma da cancellare.
Non sarebbe coplicato fargli controllare anche questa cosa.
Ok...mi sa che sarà quella che andrò ad implementare.
Ma sono sincero: non mi piace affatto :mad:
Andiamo a polling su una variabile quando sarebbe sufficente un "interrupt".
Inoltre entrambe le soluzioni caricano di responsabilità grid, resposabilità che non do vrebbe avere.
Ok...mi sa che sarà quella che andrò ad implementare.
Ma sono sincero: non mi piace affatto :mad:
Andiamo a polling su una variabile quando sarebbe sufficente un "interrupt".
Inoltre entrambe le soluzioni caricano di responsabilità grid, resposabilità che non do vrebbe avere.
in effetti sta diventando molto pooling oriented sta cosa degli stati, ma non si puo avere la botte piena e la moglie ubriaca ;) (anche se ci si puo provare :p )
cmq nella mia versione, grid non si carica di nessuna responsabilità.
Semplicemente la update della dinamite(che gia cicla sui frame 0 e 1) settera lo stato cancellazioneCroce/Quadrato.
Poi sara il nuovo stato di gridController che controllerà se ci sono dinamiti in griglia con determinate caratteristiche, e nei vari casi le cancellerà/cambierà i frame alle gemme vicine, etc
In realtà questa cosa non lo può fare nessuno stato...
...mi sa che il pattern state non prevede stati concorrenti ;)
Infatti il blinking della dynamite può avvenire anche mentre altri stati avanzano.
Comuqnue penso di aver trovato il modo per far fare a grid meno cose possibili.
A fra un po' per la test list :D
Ho ragionato un po' sul task.
La TestList arribverà stanotte o domani mattina.
In ogni caso volevo eliminare dai test BigGem, non perchè sono un pazzo ( :D ), ma perchè i refactoring in atto nella storia 1 dovrebbero garantire la o0mogeneità tra smallGem e BigGem, rendendo la differenza trasparente al task.
Inosmma...finito il lavoro per smallGem mi butterò a finire i refactoring, per poi tornare a verificare che tutto sia corretto aggiungendo i test ;)
Ho ragionato un po' sul task.
La TestList arribverà stanotte o domani mattina.
In ogni caso volevo eliminare dai test BigGem, non perchè sono un pazzo ( :D ), ma perchè i refactoring in atto nella storia 1 dovrebbero garantire la o0mogeneità tra smallGem e BigGem, rendendo la differenza trasparente al task.
Inosmma...finito il lavoro per smallGem mi butterò a finire i refactoring, per poi tornare a verificare che tutto sia corretto aggiungendo i test ;)
a grandi linee, qualè la tua idea?
visto che anche io dovrei lavorare intorno alle dinamiti, è meglio se non ci pestiamo i piedi ;)
ps.ho fixato il bug che avevo scoperto, domani probabilmente procedo col refactoring
TestList 18.2.4:
- Lo switch tar i blowMode deve avvenire ogni DynamiteBlowModeChangeRate
- il blowMode=SQUARE rende Bright le celle a quadarto con i relativi controlli sulla presenza delle gemme e sui limiti della griglia.
- il blowMode=CROSS rende Bright le celle a quadarto con i relativi controlli sulla presenza delle gemme e sui limiti della griglia.
- Quando c'è il BlowModeChange si cambia tra i due BlowMode
- I BlowMode non si devono sovrappore
- Controllo dell'integrazione in UpdateAnimationAction
Io metterei anche un test che controlla che la modalità X è sempre la prima ad essere settata. Jocchan da quale si deve partire ?
ciao ;)
Io metterei anche un test che controlla che la modalità X è sempre la prima ad essere settata. Jocchan da quale si deve partire ?
ciao ;)
Opppss....l'ho fatto senza neanche rendermene conto. Intendo il test :D
Io sono partito dallo SquareMode.
Va bene??
Opppss....l'ho fatto senza neanche rendermene conto. Intendo il test :D
Io sono partito dallo SquareMode.
Va bene??
SquareMode è ok.
TASK 18.2.4: completato :winner:
TASK 18.2.4: completato :winner:
cazzo ho un mega merge da fare :|
per fortuna è andato meglio del previsto, tutti i test verdi :O
miracolosamente sembra andare tutto anche in game :O
anche il 18.2.1 è andato :winner:
Dunque manca solo il 18.1.3. Pensavo di volerlo fare io ma no riesco a capire che cosa chiede il task. Da quello che ho visto la Dinamite non pulsa mai tranne quando sta scendendo all'interno di una gemspair e solo quando è pivot.
ciao ;)
Notifiche al task completato (il 18.2.4)
Manca la gestione delle BigGem...penso che sia sufficente che il getDroppableAt di grid diventi più "generico" per risolvere il problema in automatico.
Cioè aspetto i refactoring della storia 1 :D
Secondo: c'è un problema strano con le dinamiti, ovvero non vengono illuminate.
Dunque manca solo il 18.1.3. Pensavo di volerlo fare io ma no riesco a capire che cosa chiede il task. Da quello che ho visto la Dinamite non pulsa mai tranne quando sta scendendo all'interno di una gemspair e solo quando è pivot.
ciao ;)
ora la cancellazione della dinamite, parte solo se stiamo controllando la gemsPair oppure si e bloccata la pivot o la slave e l'altra sta cadendo velocemente(il comportamento è cambiato dal mio ultimo task)
Le intenzioni del 18.1.3, erano che la cancellazione potesse avvenire in tutti gli stati tranne il crush e il waitNextCrush.
Io ho introdotto il checkDynamiteState, che controlla se esiste una dinamite da cancellare, e nel caso la cancella e fa l'update delle altre.
Questo stato l'ho messo prima di GemsPairOnControll, ed è il primo stato eseguito normalmente.
Per risolvere il task, si potrebbe mettere il checkDynamite come task eseguito sempre, a cui si passa lo stato che dovrebbe essere eseguito.
Se cè una cancellazione di dinamite, fa il giro di crush e poi esegue lo state passato.
Altrimenti esegue direttamente lo state passato.
Al che basterebbe eseguirlo solo se lo stato da passare è diverso da crush e waitNextCrush.
spero di essere stato chiaro, ma ho i miei dubbi :asd:
Notifiche al task completato (il 18.2.4)
Manca la gestione delle BigGem...penso che sia sufficente che il getDroppableAt di grid diventi più "generico" per risolvere il problema in automatico.
Cioè aspetto i refactoring della storia 1 :D
Secondo: c'è un problema strano con le dinamiti, ovvero non vengono illuminate.
scoperto il bug.
nella update di abstractDroppable, viene eseguita la setCurrentFrame, che è influenzata dal settare la texture illuminata o meno dello sprite.
Pero dynamite reimplementa la update, e questo lavoro non viene fatto.
Per risolvere il bug, basta che la dinamite in condizioni normali(non armed) esegua la super.update();
scoperto il bug.
nella update di abstractDroppable, viene eseguita la setCurrentFrame, che è influenzata dal settare la texture illuminata o meno dello sprite.
Pero dynamite reimplementa la update, e questo lavoro non viene fatto.
Per risolvere il bug, basta che la dinamite in condizioni normali(non armed) esegua la super.update();
testato, bugfixato, committato :)
testato, bugfixato, committato :)
Ottimo :D
Ho notato però che anche con le stone ci sono dei problemi.
Inoltre all'attivazione la dynamite che genera l'esplosione non si illumina subito, ma aspoetta un po'.
Ho guardato il codice e mi sembra veramente strano :eekk:
Non vorrei c'entrasse sempre l'override di update.
Altra cosa....quando ci sono più dinamiti e si tiene premuto il tasto per l'esplosione esplodono tutte in sequenza e non una ogni 5 sec.
Inoltre mantenendo premuto si riesce a "bloccare" la gemsPair durante la caduta...ma probabilemtne è il problema che deve risolvere il task 3 :D
Ottimo :D
Ho notato però che anche con le stone ci sono dei problemi.
Inoltre all'attivazione la dynamite che genera l'esplosione non si illumina subito, ma aspoetta un po'.
Ho guardato il codice e mi sembra veramente strano :eekk:
Non vorrei c'entrasse sempre l'override di update.
strano per le stone, si illuminano solo dopo un po...
per la dynamite, forse e da rivedere il suo codice di update.
jappilas
18-06-2006, 13:43
Ho notato però che anche con le stone ci sono dei problemi.
Inoltre all'attivazione la dynamite che genera l'esplosione non si illumina subito, ma aspoetta un po'.
Ho guardato il codice e mi sembra veramente strano :eekk:
Non vorrei c'entrasse sempre l'override di update.
intendi che "aspetta" un mezzo secondo di troppo prima di iniziare a lampeggiare?
l' avevo notato anch'io, in effetti potrebbe essere correlato con il fatto di usare un ciclo di aggiornamento per verificare blinking e nel caso, settarlo, insieme con l' activationTimeStamp: posso provare a settare l' activationTimeStamp nella activate() e vedere se:
i test passano
il problema persiste
invece ieri mi è parso di notare un altro problema: viene resa bright anche la dinamite che è stata attivata (se non ho capito male dovrebbero essere bright tutte e sole le droppable coinvolte) e soprattutto , dopo il primo lampeggiamento, le 8 caselle circostanti permanentemente bright :stordita:
invece ieri mi è parso di notare un altro problema: viene resa bright anche la dinamite che è stata attivata (se non ho capito male dovrebbero essere bright tutte e sole le droppable coinvolte) e soprattutto , dopo il primo lampeggiamento, le 8 caselle circostanti permanentemente bright :stordita:
Va resa bright anche la dinamite.
Il secondo problema mi sa che va risolto invece.
jappilas
18-06-2006, 14:48
Va resa bright anche la dinamite
ok che sono pure io cecato, ma così non riesco quasi a vedere il dislay lampeggiante... :stordita:
Il secondo problema mi sa che va risolto invece.e mo' penso come fare ;)
ps:
attualmente blow() è nel flusso di esecuzione diretto dentro update(), mentre ad intuito mi sembrerebbe più logico chiamarla nel 2o branch della condizione (timer < activationTimestamp + animationDelay) ;)
Va resa bright anche la dinamite.
Il secondo problema mi sa che va risolto invece.
in teoria il secondo problema, è un non problema, visto che quando si implementerà la cancellazione le gemme illuminate saranno cancellate ;)
in teoria il secondo problema, è un non problema, visto che quando si implementerà la cancellazione le gemme illuminate saranno cancellate ;)
Hai ragione :)
Abbiamo due non-problemi quindi :D
Altra cosa....quando ci sono più dinamiti e si tiene premuto il tasto per l'esplosione esplodono tutte in sequenza e non una ogni 5 sec.
Inoltre mantenendo premuto si riesce a "bloccare" la gemsPair durante la caduta...ma probabilemtne è il problema che deve risolvere il task 3 :D
forse riesco a farci qualcosa anche io...
ps:
attualmente blow() è nel flusso di esecuzione diretto dentro update(), mentre ad intuito mi sembrerebbe più logico chiamarla nel 2o branch della condizione (timer < activationTimestamp + animationDelay) ;)
nn penso, visto che la dinamite deve essere cancellata dopo che è scaduto il timeout
altro bug, se si cancella una dinamite, e una gemma dalla gemsPair puo crushare contro una chest, si cancella :|
bisogna fare in modo che nella crush non vengano conteggiata la gemsPair(come nella gemsFAll)
jappilas
18-06-2006, 21:30
nn penso, visto che la dinamite deve essere cancellata dopo che è scaduto il timeout
ah ok, il dubbio era a vedere questo codice:
public void update(long timer)
{
if(armed)
{
if (!blinking)
{
< inizializzazioni >
}
if((timer - lastBlowModeChange) >= dynamiteBlowModeChangeRate)
{
swicthBlowMode();
lastBlowModeChange = timer;
}
currentFrameDelay = animationFrameDelay
- frameDelayDelta
* (int)((timer - activationTimeStamp)/ blinkingRateChangeDelay);
if( timer < lastUpdateTimeStamp + currentFrameDelay)
{
return;
}
if (timer - activationTimeStamp < animationTimeout)
{
< cambi di frame >
}
blow();
}
lastUpdateTimeStamp = timer;
}
messa così mi pareva che venisse eseguita ad ogni ciclo di update e non solo se timer è maggiore di activationTimeStamp + animationTimeout :O :stordita:
ah ok, il dubbio era a vedere questo codice:
public void update(long timer)
{
if(armed)
{
if (!blinking)
{
< inizializzazioni >
}
if((timer - lastBlowModeChange) >= dynamiteBlowModeChangeRate)
{
swicthBlowMode();
lastBlowModeChange = timer;
}
currentFrameDelay = animationFrameDelay
- frameDelayDelta
* (int)((timer - activationTimeStamp)/ blinkingRateChangeDelay);
if( timer < lastUpdateTimeStamp + currentFrameDelay)
{
return;
}
if (timer - activationTimeStamp < animationTimeout)
{
< cambi di frame >
}
blow();
}
lastUpdateTimeStamp = timer;
}
messa così mi pareva che venisse eseguita ad ogni ciclo di update e non solo se timer è maggiore di activationTimeStamp + animationTimeout :O :stordita:
ero convinto di avere messo il ramo else :muro:
anzi, il ramo else c'è
jappilas
19-06-2006, 13:36
ti chiedo scusa se ho visto /capito male io, ultimamente sono davvero stordito... :O :p
Ragazzi, il task 3 è ancora libero. Su che manca poco, con la dinamite siamo ad un ottimo punto ;)
Ragazzi, il task 3 è ancora libero. Su che manca poco, con la dinamite siamo ad un ottimo punto ;)
io ho da risolvere qualche bug, quando ho tempo, poi se non ci si è messo ancora nessuno lo prendo io, che ormai il giro lo conosco bene ;)
ecco lo sapevo, dopo tutti questi discorsi non so piu come fare le cose :asd:
allora:
ho bisogno di inibire le crush sulle gemme della gemsPair. Sia per le flash che per le chest.
un idea poteva essere passare gemsPair al costruttore delle 2 action, e controllare che le gemme che scatenano o sono vittime della crush, non facciano parte della pair.
Tuttavia, le action vengono chiamate da grid, dove non ho il riferimento alla gemsPair.
Un idea poteva essere quella di spostare la updateCrush() di grid dentro a crushState(l'unico posto dove viene chiamata). Da qui ho accesso alla gemsPair percui nessun problema.
Tuttavia, dovrei introdurre 2 setter per grid, relativi al chainCounter e al crushedGemCounter. Anzi ho guardato, si possono spostare direttamente in gridController, visto che chi getta questi valori passa sempre per gridController.
L'idea non mi dispiace, se non fosse per quei setter in + da esporre...
Tuttavia la soluzione migliore sarebbe poter riconoscere scorrendo le droppable, chi fa parte della gemsPair e chi no.
Avevo pensato a un isInGemsPair per le droppable, settato dall'oggeto gemsPair.
Qualcuno ha qualche idea(anche elegante ;) )?
Cerchiamo di ragionare come ragionavamo alle origini.
KISS.
Prima fai refactoring del codice su cui stai lavorando.
Se lo hai già fatto e devi introdurre unanuova funzionalità fallo nel modo più semplice che ti viene in mente, anche se aggiunge complessità.
Avanza in TDD.
Quando hai finto rimetti a posto le porcate che hai fatto per farlo funzionare.
Sapendo però che ora ci sono i test ad aiutarti. :D :D
In ogni caso isInGemPair mi ricorda un getType :(
Secondo me per come hai esposto la situazione poi spostare updateCrushes nella Action.
Parla con 71104...ci sta lavornado sopsra anche lui ;)
In ogni caso isInGemPair mi ricorda un getType :( no, perché mai! ora non esageriamo, isInGemPair non è assolutamente una getType, indica solo (se ho capito bene) che un droppable fa parte del gem pair under control... o no? :mbe:
no, perché mai! ora non esageriamo, isInGemPair non è assolutamente una getType, indica solo (se ho capito bene) che un droppable fa parte del gem pair under control... o no? :mbe:
avevo anche io questo dubbio, ma in effetti non indica chi è, ma una sua propietà.
Genera per forza un if, ma mi sembra un if "buono" :asd:
ho risolto usando la propieta del fallingObject falling e isFalling, che è true per le gemme della gemsPair e false, quando si fermano(se ne occupa la gemsPair).
Fatti i test, ne falliscono 2(erano crush fra droppable sui cui non era stata eseguita la drop).
Domani committo.
ok, prima però fate sempre update ed eventualmente merge, che ho lavorato un tantinello tantino in quest'ultimo periodo :D
ok, prima però fate sempre update ed eventualmente merge, che ho lavorato un tantinello tantino in quest'ultimo periodo :D
l'evevo appena fatto ;)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.