View Full Version : [CICLO 17] Storia 1
Storia di refactoring:
- Completare il refactoring di BigGem, uniformando le interfacce di Droppable e BigGem. Cell deve diventare una Region, ovvero un gruppo di celle rettangolari. Un diamante e' una Region 1x1: Bonfo + Ufo13
- Consolidare le responsabilita' di Dynamite al momento sparse in piu' classi: thebol + Jappilas + ...
- Testare il codice di input: cdimauro: completato
La storia è già divisa in task: fatevi sotto! ;)
Siccome siamo in ballo...continuiamo a ballare. :D
Io e Ufo andiamo avanti con il refactoring di BigGem.
Siccome siamo in ballo...continuiamo a ballare. :D
Io e Ufo andiamo avanti con il refactoring di BigGem.
Una stima sul tempo necessario per completare il refactoring?
ciao ;)
Visto che ci siamo anche gli altri due task sarebbe meglio farli in pair. Quindi fatevi avanti. :)
Per il terzo task sarebbe utile rifattorizzare keymapping in modo da caricare i tasti da un file di configurazione come GameConfig (quindi uso della classe properties) in modo da poter cambiare i tasti agilmente e usare un file standard per i test.
ciao ;)
cdimauro
30-05-2006, 07:30
Per il terzo task ci potrei pensare io e qualcun altro. Tempo previsto: 2 giorni per rifattorizzare qualcosina :fiufiu: e uno per aggiornare i test.
Un paio di domande:
- per la configurazione dei tasti posso usare sempre GameConfig oppure un altro file (o due: uno il mapping di ogni giocatore);
- con uso della classe properties cosa intendi?
Comunque la mia idea è di sganciare KeyMappings dalla particolare implementazione della tastiera, rendendola quindi un elemento a sé stante, facendo sì che la tastiera diventi un semplice dispositivo di input che trasli già al suo interno i codici "raw" della tastiera sui relativi Event "standard" di Diamonds, per poi notificare questo evento ai listener a essa legati.
Sarà poi la routine di notify del listener a traslare, tramite il keymapping che usa e relative impostazioni del file di configurazione, l'evento della pressione di un particolare tasto in quello di Event.UP, Event.DOWN, Event.BUTTON1, ecc.
Per il terzo task ci potrei pensare io e qualcun altro. Tempo previsto: 2 giorni per rifattorizzare qualcosina :fiufiu: e uno per aggiornare i test.
Un paio di domande:
- per la configurazione dei tasti posso usare sempre GameConfig oppure un altro file (o due: uno il mapping di ogni giocatore);
Secondo me ci conviene usare un file separato. GameConfig in questo momento contiene proprietà che sicuramente non saranno modificabili dall'utente finale. Per il parsing potete usare sempre Config anche se probabilmente dovrete aggiungere una getString.
- con uso della classe properties cosa intendi?
Era solo per evitare di ritrovarmi con un file .xml nel repository :D
ciao ;)
Secondo me ci conviene usare un file separato. GameConfig in questo momento contiene proprietà che sicuramente non saranno modificabili dall'utente finale. Per il parsing potete usare sempre Config anche se probabilmente dovrete aggiungere una getString.
Anche secondo me andrebbe usato un file differente e la classe Config per leggerlo.
cdimauro
30-05-2006, 10:44
Secondo me ci conviene usare un file separato. GameConfig in questo momento contiene proprietà che sicuramente non saranno modificabili dall'utente finale. Per il parsing potete usare sempre Config anche se probabilmente dovrete aggiungere una getString.
OK, quindi vada per un file contenente le configurazioni dei tasti di entrambi i giocatori
Era solo per evitare di ritrovarmi con un file .xml nel repository :D
Ehm, scusa la mia ignoranza, ma non ho ancora capito cosa intendi per "uso della classe properties".
Oggi sono un po' intronato. :(
EDIT: Ho appena visto config e ho capito cosa volevi dire. Oggi non è proprio giornata. :cry:
Comunque ho già rifattorizzato un po' di roba, semplificando KeyboardInterface, eliminato KeyMappings e facendola diventare una classe a sé stante, che non dipende dall'implementazione della tastiera.
Inoltre la traslazione dell'evento (usando il mapping apposito) adesso avviene in notifyEvent. Di conseguenza cambia anche il modo di usare questo metodo.
A motivo di ciò, ho dovuto cambiare un bel po' di test che usavano input senza impostare alcun KeyMapping, oppure che passavano a notifyEvent direttamente l'evento processato (es: al posto di Event.LEFT adesso si deve passare Event.KEY_LEFT).
scrivendo un file di properties secondo lo standard prop = value, e facendolo parsare dalla classe java properties, ottieni un oggetto su cui facendo getProperties(prop) restitusice value.
cmq è utilizzata anche nella gestione del file di config(classe Config).
Una stima sul tempo necessario per completare il refactoring?
ciao ;)
Allora...adesso parlo senza aver sentito Ufo.
La situazione è "grave"...ovvero ogni volta che cerchiamo di mettere mano a qualcosa va ad impattare su gran parte del codice, richiedendo sempre la presenza di refactoring che non siamo ancora riusciti a fare.
Insomma ...una cane che si morde la coda :muro:
In ogni caso stiamo cercando i punti di attacco.
Se tutto va come prevediamo ci troveremo alla fine con il codice praticamente "nuovo". :sofico:
Quindi i tempi sono lunghi...anche perchè biosgna mettere le mani in un sacco di posti (Grid, Action, State, tutti i Droppable, Sprite, Cell e via così...praticamente tutto :cry: :cry: )
Allora...adesso parlo senza aver sentito Ufo.
La situazione è "grave"...ovvero ogni volta che cerchiamo di mettere mano a qualcosa va ad impattare su gran parte del codice, richiedendo sempre la presenza di refactoring che non siamo ancora riusciti a fare.
Insomma ...una cane che si morde la coda :muro:
In ogni caso stiamo cercando i punti di attacco.
Se tutto va come prevediamo ci troveremo alla fine con il codice praticamente "nuovo". :sofico:
Quindi i tempi sono lunghi...anche perchè biosgna mettere le mani in un sacco di posti (Grid, Action, State, tutti i Droppable, Sprite, Cell e via così...praticamente tutto :cry: :cry: )
Ok. Allora andate piano, scrivete un sacco di test e lanciate ant fino a consumare il tasto di eclipse :D
Se avete bisogno di consigli e idee nuove io sono sempre disponibile di sera.
ciao ;)
jappilas
30-05-2006, 17:05
esaminando il comportamento attuale (di fino a ieri sera, cioe' ) della dynamite, mi veniva un dubbio: attualmente il candelotto viene rimosso all' evento di BLOW.released ma la griglia aggiornata alla fine del "turno" (se il tasto viene rilasciato durante il gioco, statisticamente capitera' con maggiore probabilita' durante la caduta della gempair, quindi nel gemPairOnControlState)
il comportamento del cadelotto deve verificarsi (cancellazione + caduta della/e droppable che la sovrastano, per ora, animazione + cancellazione + caduta, nella storia successiva) appena si rilascia il tasto o si ha il timeout , anche se nel frattempo c e' una gempair in gioco che sta cadendo?
Forse bisognera' aggiungere allo stato il controllo e la gestione della dynamite, o uno stato apposito (la mai idea e' di trattare anche la dynamite analogamente al crushState per far cadere le droppable) parlandone con vic e' emerso che a seconda dei casi "potrebbe" rendersi necessario o consigliabile rivedere gli state, quindi e' necessario chiarire
Ok. Allora andate piano, scrivete un sacco di test e lanciate ant fino a consumare il tasto di eclipse :D
Se avete bisogno di consigli e idee nuove io sono sempre disponibile di sera.
ciao ;)
Ed e' proprio il fatto che toccando qualcosa si va ad inficiare molto codice il motivo per il quale e' assolutamente necessaria questa fase di refactoring. Cercate di mantenere ogni classe il piu' possibile coesa e indipendente dal resto del sistema: vi accorgete della coesione guardando i test della classe. Se i test non richiedono tanti altri oggetti per funzionare, vuol dire che la classe e' molto coesa ed e' un ottimo segno.
Forza ragazzi che il lavoro che state facendo e' importantissimo. Vedrete che appena iniziate a svolgere i primi nodi il resto del codice andra' a posto da solo. L'importante come dice Vic e' procedere passettino per passettino, e scrivere tanti test che vi proteggono dai problemi.
Un ultimo consiglio: fate commit spesso e volentieri, cosi' permettete agl'altri che lavorano di sincronizzarsi al refactoring, ed evitate noiosi merge.
Inoltre mettersi in testa di fare commit spesso vi aiuta a sforzarvi di rendere ogni passo del refactoring molto breve, quindi meno rischi di fare casini. E piu' tranquillita' per voi. E' una lotta :D
cdimauro
31-05-2006, 08:02
'na parola. :D Con le grosse rifattorizzazioni che ho fatto mi succedeva spesso e volentieri che, dopo una modifica, saltavano fuori degli errori in altre classi. Corretto un errore, se ne saltava fuori un altro a esso legato, e così via, modello catena di Sant'Antonio.
Ho vissuto con l'incubo di effettuare merge chilometrici in questi momenti. :(
Per fortuna che modifiche così pesanti non si fanno tutti i giorni. :p
Allora... Il refactoring di BigGem con Cell procede... Qualcuno riesce a darmi una mano?
Vi posto la BigGem refattorizzata, la build è rossa e non capisco perchè :D
cdimauro
31-05-2006, 10:33
Per favore, NON committate in questo momento: ho per le mani una rifattorizzazione piuttosto pesante, e non vorrei che si creassero casini!!!
cdimauro
31-05-2006, 11:01
Commit effettuato. Adesso Diamonds è event-based. :D
Allora... Il refactoring di BigGem con Cell procede... Qualcuno riesce a darmi una mano?
Vi posto la BigGem refattorizzata, la build è rossa e non capisco perchè :D
Ho visto qualcosa di strano...perchp in addColumn e addRow le gem sono dichiarate FINAL ?? :mbe: :mbe:
Ho visto qualcosa di strano...perchp in addColumn e addRow le gem sono dichiarate FINAL ?? :mbe: :mbe:
Non mi risulta :o
ah in canAdd...
Perchè non subiscono modifiche... Non è un problema
ah in canAdd...
Perchè non subiscono modifiche... Non è un problema
aaahhh... :uh:
Penso di aver sistemato, ho convertito Cell nel sistema utilizzato da Rectangle e tutto sembra funzionare :)
cdimauro
31-05-2006, 14:45
Ho aggiunto la possibilità di caricare la configurazione dei tasti per i giocatori dal file KeysConfig. E relativi test, ovviamente.
Rimane "soltanto" da aggiungere un po' di test a engin.input.*
Mi fate un aggiornamento?
News? Aggiornamenti?
Il task del input è completato? E quello delle dinamiti chi se lo vuole prendere?
ciao ;)
Ragazzi serve un aggiornamento, siamo ad un solo task completato in una settimana. Di questo passo finiamo nel 2020.
Io negli ultimi 3 giorni ho potuto collaborare poco con Ufo.
In ogni caso anche Daniele sta lavorando sul task...e comuqnue non ne veniamo fuori :(
Il task è complesso. Ogni piccola modifica impatta su tutto il resto...stiamo andando avanti a passettini piccolissimi ed ogni scoprire dove si può lavorare richiede tempo.
Io sono un po' impegnato questo weekend, dopo martedì torno a studiare bene il refactoring :)
confermo quanto detto da Bonfo, forse oggi riesco a committare la modifica ad AbstractDroppable a cui ha lavorato Ufo e adesso io, che utilizzi un offset verticalerelativo alla riga....cmq c'è moltissimo lavoro da fare ancora
sì c'è molto lavoro da fare e sono certo che alla fine dei refactoring il codice avrà guadagnato davvero molti punti in leggibilità :)
Ogni tanto la sera ho tempo libero. Se mi dite cosa fare posso vi aiuto anche io a sistemare tutto sto macello cosi facciamo prima.
ciao ;)
mi sono perso di nuovo tra i tests che falliscono.... :(
Ogni tanto la sera ho tempo libero. Se mi dite cosa fare posso vi aiuto anche io a sistemare tutto sto macello cosi facciamo prima.
ciao ;)
Passi da fare per il momento:
- BigGem non deve più contenere nessun riferimento a Droppable.
- canMoveDown e moveDown di Droppable devono essere riffattorizzati evitando la gestione basata sulla Y della Sprite ma utilizzando una variabile "yOffsetInCell".
- BigGem non deve più implementare Drawable, il draw della BigGem viene eseguito da una TiledSprite.
cdimauro
05-06-2006, 10:46
News? Aggiornamenti?
Il task del input è completato?
ciao ;)
Nella pausa pranzo lo finisco.
Nella pausa pranzo lo finisco.
Perfetto. Ora se hai un po' di tempo libero prova a dare una mano anche tu con il primo.
ciao ;)
cdimauro
06-06-2006, 08:41
Avrei voluto finire, se il repository avesse funzionato. :muro:
Comunque ci sto già lavorando (un primo commit l'ho già fatto pochi minuti fa).
sto guardando il refactoring sulle dinamiti...
per quanto riguarda la gestione delle dinamiti nella queue, non si puo spostare, ma si potrebbe usare un pattern strategy, da usare nell'estrazione, che accetti come input la droppable estratta dalla randomDroppableFactory, e restituisca una droppable(quella da inserire, che puo essere quella di padding).
In questa maniera posso fare 2 classi della strategi, una che restituisce quello che prende come input(normal mode), e una con la gestione della dinamiti e padding(advanced mode).
In questa maniera il padding e compagnia verrebbe usato solo nel normal mode(ora cè ma non viene usato).
Per quanto riguarda invece la gestione dell'update della dinamite in caso di esplosione, pensavo di introdurre un nuovo stato, con relativa gridAction, ma ci devo guardare meglio.
Intanto procedo con il primo refactoring :)
cdimauro
06-06-2006, 14:33
Finito e committato. Ho aggiunto un bel po' di test per engine.input.* e fatto un po' d'ordine.
jappilas
06-06-2006, 15:12
sto guardando il refactoring sulle dinamiti...
anch'io :D
per quanto riguarda la gestione delle dinamiti nella queue, non si puo spostare,
non e' detto si debba avere la responsabilita' SOLO nella gemqueue o SOLO da un' altra parte...
imho la cosa migliore e' una ripartizione in cui nella gemqueue resta solo quello che proprio non puo' essere spostato, un passaggio dal modello "gridAction+full_grid_scan" a uno piu' streamlined (ad esempio, mi e' parso di capire che anche ufo avrebbe preferito usare una coda ausiliaria per gestire il conteggio e l' esplosione della dinamite piu' vecchia) e soprattutto, affrancarsi dall' attuale affidamento al frame usato ( e' una catena aperta, e quindi parecchio labile)
ma si potrebbe usare un pattern strategy, da usare nell'estrazione, che accetti come input la droppable estratta dalla randomDroppableFactory, e restituisca una droppable(quella da inserire, che puo essere quella di padding).
sicuro che non sia una complicazione inutile?
Per quanto riguarda invece la gestione dell'update della dinamite in caso di esplosione, pensavo di introdurre un nuovo stato, con relativa gridAction, ma ci devo guardare meglio.
imho l' update della dinamite non e' problematico e contingente quanto una soluzione al problema della caduta delle gemme sovrastanti appena la dynamite e' rimossa, questo perche':
- si puo' originare una cancellazione, o al limite anche una catena di Crush
- tutta la sequenza caduta + eventuale crush o catena di crush e' asincrona rispetto al resto del gioco : la gemspair sta cadendo sotto il controllo del giocatore, mentre cio' avviene (e non credo che abbiamo il lusso di poter fermare il gioco per gestirlo), e dei nuovi stati serviranno forse in questo contesto, piu' che per l' update della dynamite
avevo iniziato a pensarci su... poi ho pensato che il task 2.3 fosse affrontabile, se in modo semplice, prima di questo problema... :stordita:
Finito e committato. Ho aggiunto un bel po' di test per engine.input.* e fatto un po' d'ordine.
Ottimo lavoro come sempre :mano:
ciao ;)
anch'io :D
non e' detto si debba avere la responsabilita' SOLO nella gemqueue o SOLO da un' altra parte...
imho la cosa migliore e' una ripartizione in cui nella gemqueue resta solo quello che proprio non puo' essere spostato, un passaggio dal modello "gridAction+full_grid_scan" a uno piu' streamlined (ad esempio, mi e' parso di capire che anche ufo avrebbe preferito usare una coda ausiliaria per gestire il conteggio e l' esplosione della dinamite piu' vecchia) e soprattutto, affrancarsi dall' attuale affidamento al frame usato ( e' una catena aperta, e quindi parecchio labile)
sicuro che non sia una complicazione inutile?
per quanto riguarda lo strategy, secondo me è molto comodo perche permette di separare la gestione dell'normal mode dall'advanced mode(sia in estrazione, che in fill, per come l'ho implementato).
sul fatto della coda ausiliaria, mi rendo conto che sarebbe comoda(sarebbe comodo avere una coda ausiliaria per qualunque tipo di drop..)pero si introduce una duplicazione(nel caso di dinamiti piccola). Si potrebbe passare anche a una versione di grid totalmente a lista, ma si perderebbero i riferimenti alle droppable vicine(e qua si scorrerebbe tutta la lista per sapere qual'è il drop che sta alla sx della dinamite).
imho l' update della dinamite non e' problematico e contingente quanto una soluzione al problema della caduta delle gemme sovrastanti appena la dynamite e' rimossa, questo perche':
- si puo' originare una cancellazione, o al limite anche una catena di Crush
- tutta la sequenza caduta + eventuale crush o catena di crush e' asincrona rispetto al resto del gioco : la gemspair sta cadendo sotto il controllo del giocatore, mentre cio' avviene (e non credo che abbiamo il lusso di poter fermare il gioco per gestirlo), e dei nuovi stati serviranno forse in questo contesto, piu' che per l' update della dynamite
avevo iniziato a pensarci su... poi ho pensato che il task 2.3 fosse affrontabile, se in modo semplice, prima di questo problema... :stordita:
questo si potrebbe risolvere cambiando il comportamento di gemFAllState in modo che non funzioni per la gemsPair, e chiamandolo dopo la gemsPairOnControllState.
se poi dopo che le gemme sono cadute si devono generare le eventuali crush, oppure aspettare il drop della gemsPair, questo non mi è chiaro dalle specifiche.
joc?
ps.io lo strategy l'ho gia implementato, mancano solo i test per la nuova classe. L'unica cosa che non mi piace è che la classe strategy per la modalità normal non fà nulla, e questo non mi convince molto.
ps.io lo strategy l'ho gia implementato, mancano solo i test per la nuova classe. L'unica cosa che non mi piace è che la classe strategy per la modalità normal non fà nulla, e questo non mi convince molto.
Forse perchè più ch euno strategy è un decorator...aggiunge responsabilità in modo dinamico :D
Inoltre gestire la grid a lista è già in atto: il costo delle full-scan della lista è una cosa accettabile. ;)
Inoltre penso che l'esplosione in volo delle dinamiti sia fuori dai coppi :eek:
...non tanto dal punto di vista del game play ma dal punto di vista dell'implementazione: considerando come si sta procedendo per task, io concluderei la gestione della dinamite da "ferma", poi in futuro se si riterrà una feature importante si agggiungerà la gestione "al volo" :O
Jocchan confermi che le dynamite esplodono solo a terra?
Forse perchè più ch euno strategy è un decorator...aggiunge responsabilità in modo dinamico :D
sono ancora all'adapter sul gof :asd:
Inoltre gestire la grid a lista è già in atto: il costo delle full-scan della lista è una cosa accettabile. ;)
è accettabile allora anche scorrere la lista in cerca di dinamiti ;)
bisogna solo decidere quale approccio seguire
Inoltre penso che l'esplosione in volo delle dinamiti sia fuori dai coppi :eek:
...non tanto dal punto di vista del game play ma dal punto di vista dell'implementazione: considerando come si sta procedendo per task, io concluderei la gestione della dinamite da "ferma", poi in futuro se si riterrà una feature importante si agggiungerà la gestione "al volo" :O
se questo fosse vero, semplificherebbe di molto le cose, solo non capisco se sarà da fare in un futuro task, oppure non è stata prevista la specifica ed è da fare al piu presto
Jocchan confermi che le dynamite esplodono solo a terra?
Confermo.
Questo è un errore mio, ho sottovalutato la possibilità che la dinamite potesse essere detonata prima del drop.
Quindi, la soluzione migliore è attivare la dinamite solo dopo il drop, per far capire al giocatore che è diventato possibile utilizzarla, ed evidenziare il tutto mostrando il frame vuoto sia durante la caduta che nel box next (come aveva fatto Jappilas all'inizio, e gli avevo chiesto di cambiare).
Purtroppo nessuno è infallibile, questo mio errore significa un'altra perdita di tempo (per fortuna non molto grande), così come significa che nessuno è esente dalla regola del DISCUTIAMO TUTTI I DETTAGLI, nemmeno io.
Di questo dettaglio ne abbiamo discusso in privato io e Jappilas, se l'avessimo fatto pubblicamente magari a qualcuno "e quando la gemspair sta cadendo?", a differenza di me, sarebbe venuto in mente.
Quindi, per dettagli simili, vedremo di parlarne qui sul foro ;)
imho l' update della dinamite non e' problematico e contingente quanto una soluzione al problema della caduta delle gemme sovrastanti appena la dynamite e' rimossa, questo perche':
- si puo' originare una cancellazione, o al limite anche una catena di Crush
- tutta la sequenza caduta + eventuale crush o catena di crush e' asincrona rispetto al resto del gioco : la gemspair sta cadendo sotto il controllo del giocatore, mentre cio' avviene (e non credo che abbiamo il lusso di poter fermare il gioco per gestirlo), e dei nuovi stati serviranno forse in questo contesto, piu' che per l' update della dynamite
avevo iniziato a pensarci su... poi ho pensato che il task 2.3 fosse affrontabile, se in modo semplice, prima di questo problema... :stordita:
Hai perfettamente ragione, non è una cosa rinviabile e va affrontata adesso.
La soluzione migliore, sia in termini di gameplay (visto che sposta il punto di vista del giocatore su quello che accade nell'area di gioco) che di semplicità (non doverci curare delle variazioni di gravità, nè dei contemporanei input del giocatore) è appunto quella che hai suggerito: fermare il gioco ed effettuare le cancellazioni del caso, per poi riprenderlo.
Se è una cosa a cui possiamo arrivare con i refactoring, ben venga, altrimenti vedremo come ci conviene organizzarci per arrivare a questo obiettivo.
Allora io domani mi butto sul refactoring di BigGem... Bonfo, cisc, Cesare voi ci siete?
Purtroppo domani sono out tutto il giorno :(
...e per di più sono sotto con gli esami :(
Comunque se trovi cose relativamente brevi e sufficentemente "atomiche" sono a totale disposizione anche nei prossimi giorni ;)
cdimauro
07-06-2006, 07:26
Allora io domani mi butto sul refactoring di BigGem... Bonfo, cisc, Cesare voi ci siete?
Mi studio BigGem e Droppable.
riassumo qua i sotto-task per il refactoring della dinamite:
--la dinamite viene creata nella queue con il frame senza numero
--quando arriva a terra verrà assegnato il frame opportuno(rispetto a quelli contenuti nella griglia).
--deve essere impedito alla dinamite di esplodere in aria(probabile ci verrà gratis dal primo task, visto che avrà il frame senza numero)
--all'esplosione della dinamitela caduta della gemsPair si deve fermare->viene cancellata la dinamite->vengono fatte scendere le gemme(tranne la gemsPair)->riprende a scendere la gemsPair
Casi particolari:
----se la gemsPair si è gia divisa, percui o la pivot o la slave sta gia cadendo velocemente e senza controllo, questa deve essere coinvolta nella caduta post esplosione?
----se la gemsPair e vicina a dove esplode la dinamite, deve essere coinvolta nella cancellazione?(non è una specifica propria di questo task, ma preferisco sciogliere il prima possibile il dubbio)
----se la gemsPair si è gia divisa, percui o la pivot o la slave sta gia cadendo velocemente e senza controllo, questa deve essere coinvolta nella caduta post esplosione?
Ovviamente sì.
----se la gemsPair e vicina a dove esplode la dinamite, deve essere coinvolta nella cancellazione?(non è una specifica propria di questo task, ma preferisco sciogliere il prima possibile il dubbio)
Nelle esplosioni sì, nelle cancellazioni scatenate da un'esplosione no.
Faccio un esempio:
X= gemma qualsiasi
B= baule rosso
R= gemma rossa
D= dinamite
Stato iniziale:
XXXXXB
XXXXXD
XXXXXX
XXXXXX
XXXXXXXXXXXXX
Supponiamo che io stia facendo cadere una coppia di gemme rosse RR:
XXXXXB
XXXXXDRR
XXXXXX
XXXXXX
XXXXXXXXXXXXX
Faccio saltare la dinamite, che per ora elimina soltanto sè stessa:
XXXXX
XXXXXBRR
XXXXXX
XXXXXX
XXXXXXXXXXXXX
Avrei un baule accanto alla coppia, che però - anche se al momento è immobile - non è dropped, dunque non deve essere cancellata.
Più avanti, però, quando la dinamite distruggerà il contenuto delle caselle adiacenti, sarebbe molto strano se non venissero coinvolte anche le gemme nella coppia.
Il nostro primo obiettivo è avere un comportamento coerente: abbiamo delle "regole di base", tra cui "la dinamite distrugge il contenuto delle celle circostanti", e dobbiamo fare in modo che vengano rispettate sempre, altrimenti il giocatore si chiederà che diavolo sta succedendo.
Quindi, bisognerà distruggere il contenuto delle celle anche se contengono una gemspair. Queste, però, sono in movimento.
Dunque, bisognerà tenere conto di tre possibilità (negli esempi consideriamo un'esplosione a croce):
1. le due gemme in caduta si trovano allineate, e solo una delle due occupa la casella interessata dall'esplosione (a destra di D):
| X |
|---|---|
| D | R |
|---|---|
| X | R |
In questo caso, la gemma accanto a D verrà cancellata, e l'altra verrà fatta cadere a velocità accelerata.
2. le due gemme in caduta si trovano a metà della casella interessata dall'esplosione (a destra di D):
| X |---
|---| R |
| D |---|
|---| R |
| X |---
L'unico comportamento coerente sarebbe eliminarle entrambe.
3. una via di mezzo tra i primi due casi:
Qui basta utilizzare un valore di tolleranza di pochi pixel, in modo da consentire al gioco di capire in quale dei primi due casi ci troviamo.
Ovviamente sì.
perfetto, questo semplifica un po le cose(potremo riutilizzare la gemsFallState).
io mi prendo i primi 3 sotto-task, poi se nessuno prende il 4, faccio anche quello
[...]
| D |---|
|---| R |
| X |---
L'unico comportamento coerente sarebbe eliminarle entrambe.
3. una via di mezzo tra i primi due casi:
Qui basta utilizzare un valore di tolleranza di pochi pixel, in modo da consentire al gioco di capire in quale dei primi due casi ci troviamo.
Per come la vedo io la GemsPair non dovrebbe essere influenzata dal esplosione di una Dynamite. Personalmente trovo incredibilmete oscuro che qualcosa che si muove e sembra fuori dal sistema sia influenzato da un pezzo che è fermo e immobile e si trova sul campo come un candelotto.
Oltretutto questo comportamento riempie il codice di cosi particolari. Cosa succede se l'esplosione elimina completamente la gemspair? E se esplode mentre stanno cadendo delle stone che non si sono ancora fermate?
Per non parlare di quando dovremo evidenziare le gemme nelle caselle adiacenti. Dovremmo evidenziare le gemme della gemspair o le stone anche se sono in movimento.
Ma soprattutto come ci comportiamo con le BigGem.Evidenziamo tutto? Solo le caselle come se fossero gemme normali? E quando esplode cancelliamo tutto oppure "spezziamo" la bigGem rendendola più piccola?
ciao ;)
Per come la vedo io la GemsPair non dovrebbe essere influenzata dal esplosione di una Dynamite. Personalmente trovo incredibilmete oscuro che qualcosa che si muove e sembra fuori dal sistema sia influenzato da un pezzo che è fermo e immobile e si trova sul campo come un candelotto.
Il fatto è che stiamo entrando in un campo in cui non esistono precedenti noti (sinceramente, non conosco nessun puzzle game con una griglia e pezzi che cadono dall'alto in cui esistono pezzi che funzionino come la dinamite), dunque non è possibile sapere a priori quale sia l'approccio migliore.
L'unico modo è provare sul campo.
Prima di coinvolgere la gemspair, ovviamente sarà necessario implementare l'effetto dell'esplosione solo sui pezzi già fermi, dunque implementeremo l'ipotesi che hai introdotto: se questa si rivelerà già funzionale in toto, e vedremo di dare tutti il nostro contributo testando le situazioni più inverosimili, valuteremo se converrà o no considerare la gemspair.
Oltretutto questo comportamento riempie il codice di cosi particolari. Cosa succede se l'esplosione elimina completamente la gemspair? E se esplode mentre stanno cadendo delle stone che non si sono ancora fermate?
Per non parlare di quando dovremo evidenziare le gemme nelle caselle adiacenti. Dovremmo evidenziare le gemme della gemspair o le stone anche se sono in movimento.
Per i casi che hai evidenziato, non ci sarebbe nessuno strappo alla regola: se viene eliminata la gemspair, sarà considerata dropped, e si continuerà normalmente.
Se esplode mentre stanno cadendo delle stone, queste avranno comunque il tempo di finire di cadere (e non ci saranno gemspair, perchè queste cadono solo quando non c'è nessuna coppia in caduta... non fermiamo il tempo, fermiamo solo la coppia).
Evidenziare le gemme della gemspair non sarebbe nemmeno un problema, visto che la coppia sarà immobile al momento.
L'unica difficoltà riguarda le stone in caduta, ma se consideriamo la velocità con cui cadono non credo ci siano problemi per eventuali imprecisioni.
P.S.: per la biggem evidenziamo tutto, e la facciamo saltare in aria tutta.
jappilas
07-06-2006, 13:48
P.S.: per la biggem evidenziamo tutto, e la facciamo saltare in aria tutta.
però ehm, se la "vampata" che lambisce la bigGem non ne copre tutte le caselle , l' effetto grafico risultante potrebbe ( sto andando a immaginazione ) risultare poco soddisfacente... intuitivamente, chi vedesse una fiammata a croce coprire solo due delle ( ad es) 9 celle di una bigGem potrebbe aspettarsi che solo le parti coinvolte nella vampata vengano cancellate ( e in qualche caso la bigGem "riscindersi" in una bigGem più piccola ed eventualmente qualche gemmina più piccola)
al che, ipotizzo, potrebbe essere il caso di creare delle "mini vampate 1x1" da usare per distribuire l' esplosione su tutta la superficie della bigGem, prima di applicare l' effetto di rimpicciolimento?
però ehm, se la "vampata" che lambisce la bigGem non ne copre tutte le caselle , l' effetto grafico risultante potrebbe ( sto andando a immaginazione ) risultare poco soddisfacente... intuitivamente, chi vedesse una fiammata a croce coprire solo due delle ( ad es) 9 celle di una bigGem potrebbe aspettarsi che solo le parti coinvolte nella vampata vengano cancellate ( e in qualche caso la bigGem "riscindersi" in una bigGem più piccola ed eventualmente qualche gemmina più piccola)
al che, ipotizzo, potrebbe essere il caso di creare delle "mini vampate 1x1" da usare per distribuire l' esplosione su tutta la superficie della bigGem, prima di applicare l' effetto di rimpicciolimento?
No, niente di tutto ciò.
La biggem è una e indivisibile, se tu ne distruggi una parte la distruggi inevitabilmente tutta. Non sembra strano perchè provvederemo a evidenziarla integralmente, dunque il giocatore lo saprà subito, ed inoltre - semmai - potremo vedere di aggiungere un paio di frame (giusto DUE, e guarda caso nella grafica delle gemme abbiamo due caselle libere) per le gemme che vanno in pezzi ;)
riassumo qua i sotto-task per il refactoring della dinamite:
--la dinamite viene creata nella queue con il frame senza numero
--quando arriva a terra verrà assegnato il frame opportuno(rispetto a quelli contenuti nella griglia).
--deve essere impedito alla dinamite di esplodere in aria(probabile ci verrà gratis dal primo task, visto che avrà il frame senza numero)
--all'esplosione della dinamitela caduta della gemsPair si deve fermare->viene cancellata la dinamite->vengono fatte scendere le gemme(tranne la gemsPair)->riprende a scendere la gemsPair
Casi particolari:
----se la gemsPair si è gia divisa, percui o la pivot o la slave sta gia cadendo velocemente e senza controllo, questa deve essere coinvolta nella caduta post esplosione?
----se la gemsPair e vicina a dove esplode la dinamite, deve essere coinvolta nella cancellazione?(non è una specifica propria di questo task, ma preferisco sciogliere il prima possibile il dubbio)
i primi 2 sotto task li ho fatti(committo stasera).
per il terzo, è venuto gratis a meta...nel senso che a mezz'aria la dinamite non esplode ma lampeggia..poi quando arriva a terra si setta col frame corretto e non fa nulla, ma è cmq una cosa da togliere.
i primi 2 sotto task li ho fatti(committo stasera).
per il terzo, è venuto gratis a meta...nel senso che a mezz'aria la dinamite non esplode ma lampeggia..poi quando arriva a terra si setta col frame corretto e non fa nulla, ma è cmq una cosa da togliere.
sistemato anche il 3, ora committo e poi passo al quarto
ps.ho modificato dynamiteCountAction in modo che ritorni la lista delle dinamiti in grid.
In questa maniera l'introduzione eventuale di una lista per le dinamiti in grid, sarebbe ancora piu comoda.
--all'esplosione della dinamitela caduta della gemsPair si deve fermare->viene cancellata la dinamite->vengono fatte scendere le gemme(tranne la gemsPair)->riprende a scendere la gemsPair
per quanto riguarda questa parte, ho un dubbio...
la cancellazione della dinamite puo essere innescata solo mentre la gemsPair scende(intera o divisa), non negli altri stati(crush, post crush, ricezione stone, etc)?
giusto?
per quanto riguarda questa parte, ho un dubbio...
la cancellazione della dinamite puo essere innescata solo mentre la gemsPair scende(intera o divisa), non negli altri stati(crush, post crush, ricezione stone, etc)?
giusto?
sono andato avanti a mo di spike, per vedere se la strada che stavo seguendo era fattibile(fare in modo che quando avvenisse l'esplosione, venisse sostituito allo state corrente gemFallState, che alla sua fine restituisse lo stato precedente).
Questo sono riuscito a farlo, solo che mi trascina giu pure la gemsPair, dovrei trovare il modo di far funzionare questo metodo solo per le gemme che non appartengono alla gemsPair..solo che non so come individuarle(avendo una droppable, posso capire se è fa parte della gemsPair? o devo avere un riferimento all'oggetto gemsPair?)
penso che risolto questo il tutto possa funzionare, reverto e riparto con i test
Questo sono riuscito a farlo, solo che mi trascina giu pure la gemsPair, dovrei trovare il modo di far funzionare questo metodo solo per le gemme che non appartengono alla gemsPair..solo che non so come individuarle(avendo una droppable, posso capire se è fa parte della gemsPair? o devo avere un riferimento all'oggetto gemsPair?)
Purtroppo un droppable.isInAGemsPair() non c'è però nella update di gemsFallState ti viene passato il gridController. Da li puoi ottenere la gemsPair e quindi anche un riferimento alle due gemme sotto controllo.
ciao ;)
Purtroppo un droppable.isInAGemsPair() non c'è però nella update di gemsFallState ti viene passato il gridController. Da li puoi ottenere la gemsPair e quindi anche un riferimento alle due gemme sotto controllo.
ciao ;)
immaginavo una via del genere, ma speravo che in quel popo di interfacce che si ritrova droppable ci fosse qualcosa =D...
immaginavo una via del genere, ma speravo che in quel popo di interfacce che si ritrova droppable ci fosse qualcosa =D...
ieri sera ci ho provato e ho fallito(ed ero troppo stanco per riprovarci...)
in questo momento mi servirebbe proprio il refactoring sulle droppable per riconoscere una gemsPair, ma pazienza...
pensavo di fare la updateFalls di grid, in modo che accetti un array di droppable da escludere nel controllo(da passare percio alla forEachDroppable).
Manterrei cmq gli attuali metodi senza paramentri.
stessa cosa per la droppedGemCanMoveDown.
sto portando avanti la cosa, ora ho implementato la gemsFallState in modo che faccia scendere tutte le droppable tranne la gemsPair, e ho finalmente tutti i test verdi(volevo commitare ma cè il server giu)
Domani dovrei riuscire a finire.
altra domanda su sto task....
siamo in questa situazione
C
D
G
C è una chest diamond
D è una dinamite
G è una gem diamond
faccio scoppiare la dinamite, la gemsPair si ferma, faccio scendere le gemme e la chest arriva su gem.
Devo scatenare la crush, o aspetto che la gemsPair arrivi a terra?
altra domanda su sto task....
siamo in questa situazione
C
D
G
C è una chest diamond
D è una dinamite
G è una gem diamond
faccio scoppiare la dinamite, la gemsPair si ferma, faccio scendere le gemme e la chest arriva su gem.
Devo scatenare la crush, o aspetto che la gemsPair arrivi a terra?
Ovviamente crush! Tanto la gemspair verrà fermata a mezz'aria ;)
E' proprio questo lo scopo della dinamite: scatenare Crush a proprio piacimento, dando al giocatore (che abbia l'abilità strategica di posizionare bene gemme, bauli e dinamite) di creare combinazioni ben più lunghe!
ora quando la dinamite esplode, le gemme scendono.
ora manca che vengano generate le crush, e il fatto che la dinamite non possa scoppiare in determinati stati(crush su tutti)
Benissimo :)
fatte pure le crush =D
ora manca l'abilitazione della dinamite solo in determinati stati:
la prima domanda è quali?
gli stati sono:
GemsPairOnControllState
StoneTurnState
CrushState
WaitCrushState
GemFallState
StoneFallState
WaitBeforeNewGemsPairState
GameOverState
io per ora abiliteri solo gemsPairOnControllState, ma ditemi se ne volete altri.
la secenda è come gestiamo la non abilitazione della dinamite?
io farei che se il tasto per la dinamite viene rilasciato in uno stato non valido, non succede nulla(sarebbe carino implmentare un beep per farlo capire al giocatore).
In questa maniera è possibile incominciare quando si vuole la sequenza della dinamite, ma la si puo portare a termine solo in determinati stati.
mi rimetto ovviamente a jocchan ;)
ps.non ho guardato, ne testato la gestione del punteggio, delle crush multiple, e delle stone
ps.ho anche tolto da grid droppedGemCanMoveDown e updateFalls, perche non piu usate nel codice di produzione. Nei test erano usate, e le ho messe in gridTestCase, e in altri test.
fatte pure le crush =D
ora manca l'abilitazione della dinamite solo in determinati stati:
la prima domanda è quali?
gli stati sono:
GemsPairOnControllState
StoneTurnState
CrushState
WaitCrushState
GemFallState
StoneFallState
WaitBeforeNewGemsPairState
GameOverState
io per ora abiliteri solo gemsPairOnControllState, ma ditemi se ne volete altri.
la secenda è come gestiamo la non abilitazione della dinamite?
io farei che se il tasto per la dinamite viene rilasciato in uno stato non valido, non succede nulla(sarebbe carino implmentare un beep per farlo capire al giocatore).
In questa maniera è possibile incominciare quando si vuole la sequenza della dinamite, ma la si puo portare a termine solo in determinati stati.
mi rimetto ovviamente a jocchan ;)
ps.non ho guardato, ne testato la gestione del punteggio, delle crush multiple, e delle stone
ps.ho anche tolto da grid droppedGemCanMoveDown e updateFalls, perche non piu usate nel codice di produzione. Nei test erano usate, e le ho messe in gridTestCase, e in altri test.
Credo che abilitare il pulsante solo in gemsPairOnControllState e WaitBeforeNewGemsPairState vada benissimo.
Per quel che riguarda il rilascio in uno stato proibito, direi che non si può dire a priori, dipende dalla lunghezza degli stati in questione (se l'intervallo di tempo è molto breve, come ad esempio la caduta delle stone o delle gemme, può anche andare bene un brevissimo ritardo nell'esplosione - che peraltro comporta anche un'altra caduta di gemme, e dunque sarebbe compatibile con gli stati elencati - prolungando l'animazione con i frame alternati... ma è una cosa che va testata sul campo).
Insomma, pressione e rilascio potrebbero dover essere abilitati in stati non necessariamente coincidenti tra loro.
Il beep nei momenti sbagliati lo eviterei: il giocatore vuole che i suoi comandi abbiano effetto sempre, ed il nostro obiettivo deve essere fare in modo che, in ogni circostanza, la risposta sia il più possibile coerente con la sua volontà.
Un beep perchè ha scelto il momento sbagliato sarebbe solo controproducente, perchè il giocatore non avrebbe ben chiaro dove ha sbagliato, con conseguente frustrazione.
Piccolo problema :(
Il tutto funziona bene, ma se un giocatore, anche non in presenza di Dynamite, incomincia a premere ripetutemente il tasto dell'esplosione, la gemsPair rimane praticamente bloccata al suo posto mentre le gemme avversarie continuano a cadere.
Non mi sembra molto Fair :muro:
Piccolo problema :(
Il tutto funziona bene, ma se un giocatore, anche non in presenza di Dynamite, incomincia a premere ripetutemente il tasto dell'esplosione, la gemsPair rimane praticamente bloccata al suo posto mentre le gemme avversarie continuano a cadere.
Non mi sembra molto Fair :muro:
avevo pensato a una cosa del genere qualche giorno fa, ma in effetti oggi non ho provato se succedeva...
stasera la risolvo
Piccolo problema :(
Il tutto funziona bene, ma se un giocatore, anche non in presenza di Dynamite, incomincia a premere ripetutemente il tasto dell'esplosione, la gemsPair rimane praticamente bloccata al suo posto mentre le gemme avversarie continuano a cadere.
Non mi sembra molto Fair :muro:
Ovviamente senza dinamiti su schermo il tasto non deve funzionare.
Ovviamente senza dinamiti su schermo il tasto non deve funzionare.
fatto e committato
Ottimo :)
In definitiva, cosa è stato implementato riguardo la dinamite, e cosa manca ancora?
Ottimo :)
In definitiva, cosa è stato implementato riguardo la dinamite, e cosa manca ancora?
Quella che manca finisce nel prossimo Ciclo.
Qualcuno puo' prendere il tag di questo Ciclo per favore?
Ottimo :)
In definitiva, cosa è stato implementato riguardo la dinamite, e cosa manca ancora?
manca il discorso sull'esclusione della dinamite in determinati stati(o meglio, delay dell'esplosione al primo stato abilitato), e la gestione(non so cosa funzioni gia, cmq ci vogliono dei test) per le crush/stone/punteggio per le dinamiti.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.