View Full Version : [CICLO 6/bis] Storia di Natale
Dato che a Natale siamo tutti più buoni, oggi apriamo un ciclo "speciale", dalla durata superiore al solito, e che si chiuderà il 6 gennaio 2006 (giorno fino al quale siamo formalmente - ma non effettivamente - in pausa). Si tratterà di un ciclo differente perchè stavolta sarà aperto, e quindi è possibile che dei nuovi task vengano aggiunti in seguito. Quindi, sbirciate spesso questo post... potreste trovare qualche sorpresa di tanto in tanto ;)
Storia: Storia di servizio. Quando la colonna centrale in cui le gemme entrano nell'area di gioco è piena, il gioco deve smettere di crearle, e deve far comparire al centro dello schermo una png con la scritta Game Over. Occorre anche fare in modo che, quando viene premuto un tasto direzionale (sinistra o destra) mentre l'altro opposto è già premuto, venga eliminata l'incertezza sulla colonna di posizionamento della gemma, che deve restare fissa nella colonna in cui si trovava un istante prima della pressione del tasto contrastante.
To be continued...
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
Ecco i task per il ciclo natalizio.
Task:
Xmas.1.1: 71104:
Interrompere l'inserimento di nuove gemme quando la colonna centrale si riempie dopo di che si deve mostrare la scritta "Game Over" all'interno della griglia.
Xmas.1.2: cisc: 3 giorni
Aggiungere un ritardo di 300 millisecondi tra l'istante in cui la gemma si ferma e la creazione di una nuova gemma.
Xmas.1.3: cionci: 2 giorni
Ignorare la pressione del tasto direzionale finche quello con direzione opposto rimane premuto.
Xmas.1.4: Ufo13: completo
Portare a 50 millisecondi il repeat delay dopo la prima volta che è stato superato. E riportarlo al suo valore originale quando il tasto viene rilasciato.
ciao ;)
Specifico meglio il task 3 per evitare incomprensioni.
Attualmente, se tengo premuto un tasto direzionale (ad esempio destra), ed in seguito premo quello opposto (in questo caso sinistra) senza rilasciare il precedente, spesso la gemma, prima di continuare la sua caduta senza spostarsi lateralmente, ha un comportamento imprevedibile: può rimanere nella stessa colonna, finire in una adiacente, oppure spostarsi temporaneamente e tornare in quella iniziale.
Lo scopo del task è fare in modo che questo non avvenga, e che - finchè entrambi i tasti restano premuti - la gemma rimanga nella stessa colonna, e continui a cadere in questa, senza incertezze (che, nella foga del gioco vero e proprio, possono portare a un posizionamento errato).
La necessità di apportare questa correzione nasce dalla possibilità che il giocatore cambi idea all'ultimo secondo, e decida di posizionare la gemma da un'altra parte: questo evento può comportare la pressione contemporanea di due direzioni contrastanti, e non possiamo permetterci di avere imprecisioni in questa circostanza ;)
UAO LA STORIA DI NATALE, A ME A ME!!! :D
li voglio fare tutti io!!! :Prrr:
comincio col primo ^^
dubbi: la scritta "Game Over" come ce la scrivo? c'è qualche texture? e a che coordinate la scrivo?
ora penso alla test list
Jocchan; mi puoi spiegare emglio il problema che vuoi risolvere ?
a) pressione continua del tasto a dx...pressione del tasto sx, la gemma si deve fermare
b) pressione contemporanea di entrambi i tasti la gemma deve restare ferma...
UAO LA STORIA DI NATALE, A ME A ME!!! :D
li voglio fare tutti io!!! :Prrr:
comincio col primo ^^
dubbi: la scritta "Game Over" come ce la scrivo? c'è qualche texture? e a che coordinate la scrivo?
ora penso alla test list
Jocchan fra un po prepara la texture tu non devi far altro che metterla al centro della griglia.
ciao ;)
volevo fare la stessa domanda di cionci, cmq, vorrei prenotarmi per il Xmas.1.2, tempo 3 giorni (meglio essere larghi:D)
volevo fare la stessa domanda di cionci,
Anche perchè risolvendone uno si cambia l'altro...
Risolvendo il problema a)...se si premono entrambi i tasti la gemma si sposta nella cella corrispondente al tasto premuto prima fra i due (se la pressione va a cavallo fra due polling)
Al massimo possiamo lasciare il b) com'è ora e risolvere il problema a)...
Texture committata.
Per il problema della pressione contemporanea, si tratta solo dell'incertezza che si ha quando si preme un tasto opposto a quello già in pressione.
La gemma ogni tanto o si sposta di una colonna, e non deve accadere, oppure si sposta e torna nella precedente.
In realtà bisogna fare in modo che, quando si preme il secondo tasto, oltre a quello premuto, la gemma non abbia questa incertezza.
Se sto tenendo premuto destra e, quando sono nella casella 4, inizio a tenere premuto anche sinistra, la gemma deve continuare a cadere nella casella 4 fino a quando non rilascio uno dei due pulsanti.
ho letto il codice attuale e riflettuto, e per la cronaca mi sono anche fatto consigliare da Jocchan; inoltre mi sono fatto un panino con insalata e mortazza, due solitari di Windows, una partita a campo minato, fumato una sigaretta, guardato in aria, fatto una cosa che non si dice, ed infine rieccomi qua sul forum :D
il problema è il seguente: il codice per catturare l'eccezione e visualizzare uno sprite con scritto "Game Over" dove lo metto, in Grid, in Game o in una classe apposta? :mc:
Jocchan dice Grid e io mi trovo d'accordo...
questo è il test che ho fatto (si troverebbe in TestGrid):
public void testGridStops()
{
grid.insertGem(1, 4, gem1);
grid.getGemUnderControl().dropGem();
grid.insertGem(0, 4, gem2);
try
{
grid.update();
}
catch(IllegalArgumentException e)
{
fail("Grid.update is trying to put other gems");
}
}
eventualmente poi potrei anche creare una nuova classe GameOverException in modo tale che insertNewGem cattura la IllegalArgumentException causata dall'inserzione di una gemma quando non c'è spazio e la converte lanciando una GameOverException.
poi magari la test listi si potrebbe completare con un test per verificare col MockEngine che Grid.update, una volta catturata l'eccezione, disegni lo sprite "Game Over".
ho letto il codice attuale e riflettuto, e per la cronaca mi sono anche fatto consigliare da Jocchan; inoltre mi sono fatto un panino con insalata e mortazza, due solitari di Windows, una partita a campo minato, fumato una sigaretta, guardato in aria, fatto una cosa che non si dice, ed infine rieccomi qua sul forum :D
Ma la test list non include una descrizione dettagliata delle tue sessioni onaniste :D
il problema è il seguente: il codice per catturare l'eccezione e visualizzare uno sprite con scritto "Game Over" dove lo metto, in Grid, in Game o in una classe
Jocchan dice Grid e io mi trovo d'accordo...
apposta? :mc:
Allora prima di mettere dell'altro codice in Grid, devi avere un'ottima ragione, ma proprio ottima, e spiegarcela dettagliatamente e poi giustificarla e poi, quando hai finito, devi pensare di nuovo se per caso non c'e' una soluzione migliore.
Tradotto: non mettere nulla in Grid se non strettamente necessario ma anche di piu'.
eventualmente poi potrei anche creare una nuova classe GameOverException in modo tale che insertNewGem cattura la IllegalArgumentException causata dall'inserzione di una gemma quando non c'è spazio e la converte lanciando una GameOverException.
Non mi piace come idea, perche' le eccezioni servono solo per comunicare condizioni eccezionali nell'esecuzione del programma, ovvero condizioni che non dovrebbero mai accadere in una normale esecuzione (sono per l'appunto eccezionali). Il Game Over e' una condizione normale alla fine del gioco, quindi quest'informazione non andrebbe veicolata per mezzo di un'eccezione.
prendo il secondo task :)
prendo il secondo task :)
E' già prenotato da cisc :(
Se sto tenendo premuto destra e, quando sono nella casella 4, inizio a tenere premuto anche sinistra, la gemma deve continuare a cadere nella casella 4 fino a quando non rilascio uno dei due pulsanti.
Ok...allora vedo di mantenere la situazione com'è per la situazione b) e correggo la situazione a)...
Mi prendo 2 giorni di tempo...
L'acceptance test list sarà come segue:
- se un tasto freccia è premuto continuamente e premo il tasto freccia opposta la gemma deve stare ferma
- se due tasti freccia vengono premuti due tasti freccia e la pressione risulta a cavallo fra due aggiornamenti la gemma deve tornare alla posizione iniziale (quindi mantennedo la condizione attuale)
Test list per il task Xmas.1.3:
public void testLeftAndRightBothPressed()
{
grid.insertGem(2, 4, gem);
grid.setGemUnderControl(gem);
input.generateKey(KeyCode.vk_Left);
input.generateKey(KeyCode.vk_Right);
grid.reactToInput(input, timer);
assertTrue("Gem may not move when Left & Right key are both pressed",
grid.isGemAt(2, 4));
}
public void testLeftAndRightSequenceInTwoPollings()
{
grid.insertGem(2, 4, gem);
grid.setGemUnderControl(gem);
input.generateKey(KeyCode.vk_Left, timer.getTime());
grid.reactToInput(input, timer);
timer.advance(grid.getRepeatDelay() - 1);
input.generateKey(KeyCode.vk_Right, timer.getTime());
grid.reactToInput(input, timer);
assertTrue("Gem may not move when Left & Right key are both pressed",
grid.isGemAt(2, 4));
}
public void testLeftStillPressedAndRightPressed()
{
grid.insertGem(2, 4, gem);
grid.setGemUnderControl(gem);
input.generateKey(KeyCode.vk_Left, timer.getTime());
grid.reactToInput(input, timer);
timer.advance(grid.getRepeatDelay() + 1);
input.generateKey(KeyCode.vk_Right, timer.getTime());
grid.reactToInput(input, timer);
assertTrue("Gem may not move when Left key is repeated & Right key is pressed",
grid.isGemAt(2, 3));
}
public void testRightStillPressedAndLeftPressed()
{
grid.insertGem(2, 4, gem);
grid.setGemUnderControl(gem);
input.generateKey(KeyCode.vk_Right, timer.getTime());
grid.reactToInput(input, timer);
timer.advance(grid.getRepeatDelay() + 1);
input.generateKey(KeyCode.vk_Left, timer.getTime());
grid.reactToInput(input, timer);
assertTrue("Gem may not move when Right key is repeated & Left key is pressed",
grid.isGemAt(2, 5));
}
Ma vi state mangiando quattro task al giorno voi? E' cosi' che mi piace, duri, cattivi e produttivi.
E per premiarvi, vi diamo altri task di Natale :D
Fatto il commit del task Xmas.1.3
Siete delle belve. :D
ciao ;)
la mia test list:
- Un pulsante viene premuto e viene sorpassato il repetitionDelay corrente. Il repetitionDelay in grid deve valere 50.
- Un pulsante viene rilasciato ed il repetitionDelay deve tornare al valore iniziale.
Ufo13: ho fatto un bel po' di refactoring... Ho estratto una nuova classe (InputReactor) da Grid... Quindi magari parti da quello o cerca di fare un merge...
DanieleC88
13-12-2005, 17:14
Non è possibile. Mi disconnetto che non si conoscono ancora i task e mi riconnetto che sono già bell'e prenotati!! Arrrrhhhhgggghhhhh!!!! :mad: :muro:
Lasciate qualcosa pure a noi! :D
C'è la prossima storia...prometto che non en tocco nemmeno uno... Ho fatto troppo negli ultimi tempi :D
DanieleC88
13-12-2005, 17:27
Lo so, ma ancora non è stata divisa in task... :D
Chiedi a Jocchan o VICIUS di lasciarti un task...
Lo so, ma ancora non è stata divisa in task... :D
Si' ragazzi adesso non litigatevi i task, che c'e' sempre in tempo ad aggiungere nuove Storie, ne abbiamo pronte per altri tre mesi :D
ragazzi, allora, task Xmas.1.2, il time da aspettare lo inserirei in GameConfig, poi avrei pensato di aggiungere uno stato di "wait" a grid, quindi i seguenti tests:
public class TestdelayBetweenTwoGems extends TestCase
{
private Grid grid;
private Gem gem1;
private Gem gem2;
private MockTimer timer;
public void setUp()
{
grid = Grid.createForTesting();
gem1 = Gem.createForTesting();
gem2 = Gem.createForTesting();
timer = new MockTimer();
}
public void testGridWaitState()
{
grid.setGravity(1);
grid.insertGem(14,3,gem1);
grid.update(timer);
assertTrue("grid isn't in wait state", grid.waitState());
}
public void testCantGetGemUnderControlWhileWait() {
grid.setGravity(1);
grid.insertGem(14,3,gem1);
grid.update(timer);
try
{
grid.getGemUnderControl();
} catch (IllegalStateException e)
{
return;
}
fail();
}
public void testCantInsertNewGemWhileWait() {
grid.setGravity(1);
grid.insertGem(14,3,gem1);
grid.update(timer);
try
{
grid.insertGem(1,1,gem2);
} catch (IllegalStateException e)
{
return;
}
fail();
}
public void testCantSetGemUnderControlWhileWait() {
grid.setGravity(1);
grid.insertGem(14,3,gem1);
grid.update(timer);
try
{
grid.setGemUnderControl(gem1);
} catch (IllegalStateException e)
{
return;
}
fail();
}
public void testGridWaitStateAfterDelay() {
grid.setGravity(1);
grid.insertGem(14,3,gem1);
grid.update(timer);
timer.advance(300);
assertFalse("grid isn't in wait state", grid.waitState());
}
}
fatemi sapre se posso continuare su questa strada;)
Come dice fek: posta solo gli acceptance test... Tutta la test list non è interessante, anzi è controprooducente perchè i test devono essere sviluppati uno alla volta...ed ogni test deve portare ad un minimo cambiamento all'interno del codice...
ma infatti questi test li farò passare uno alla volta, e non è detto che introduca altri test in mezzo, questo è per farsi un'idea di quello che ho in mente
Attenzione che la gemma non deve entrare nello stato di wait quando viene usata insertGem (altrimenti tutti i test che usano inserGem subiranno il ritardo), ma solo quanto viene richiamata insertNewGem...
lo stato di wait è uno stato di attesa, in cui la grid aspetta un tot di tempo prima di tornare alla sua normale esecuzione, quindi per me logicamente anche insertGem "deve attendere", cmq, perchè insertNewGem è private e insertGem è public?
insertGem potrebbe servire genericamente sia per testare che per aggiungere gemme a Grid (come ad esempio le "gemmone" o eventuali ostacoli messi dall'avversario)...oppure ad esempio, nel gioco in rete per inserire le gemme nella posizione ottenuta dal protocollo di rete...
Inoltre il ritardo deve essere applicato solo alle nuove gemme prese da GemQueue...
InsertNewGem è privata perchè non ha bisogno di essere chiamata dall'esterno...
Se vuoi testare insertNewGem puoi usare insertGem per mettere una gemma sulla riga 13... Chiami update ed a questo punto viene generata una nuova gemma in (4,0) che viene controllata dai tasti... Credo anche che tu debba testare che la gemma drante l'attesa non reagisca ai tasti (e che i tasti premuti durante questo periodo vengano eliminati dalla coda)...
insertGem potrebbe servire genericamente sia per testare che per aggiungere gemme a Grid (come ad esempio le "gemmone" o eventuali ostacoli messi dall'avversario)...oppure ad esempio, nel gioco in rete per inserire le gemme nella posizione ottenuta dal protocollo di rete...
Inoltre il ritardo deve essere applicato solo alle nuove gemme prese da GemQueue...
questo mio test derivava dalla volontà di creare una condizione di stato di grid diciamo di pausa, ma mi rendo conto che è una cosa non richiesta, quindi mi limiterò a testare l'attesa (impedendo la insertNewGem in stato di wait)
Se vuoi testare insertNewGem puoi usare insertGem per mettere una gemma sulla riga 13... Chiami update ed a questo punto viene generata una nuova gemma in (4,0) che viene controllata dai tasti... Credo anche che tu debba testare che la gemma drante l'attesa non reagisca ai tasti (e che i tasti premuti durante questo periodo vengano eliminati dalla coda)...
io, se guardi il mio test, inserisco una gemma alla 14sima riga, e do update, a questo punto, nell'esecuzione attuale, genera una nuova gemma, ma io invece voglio che vada in stato di wait.., per l'input, al momento, dato che si basa tutto sul metodo getGemUnderControl() che lancia un'eccezione se viene invocato in stato di wait, va aggiustato, ed effettivamente devo aggiungere i tests anche per quello, magari un test per l'input potrebbero essere:
- testare che la pressione di un tasto in wait state venga ignorato e non inserito in coda
ma infatti questi test li farò passare uno alla volta, e non è detto che introduca altri test in mezzo, questo è per farsi un'idea di quello che ho in mente
Il discorso di cionci e' corretto, non serve il codice di ogni test ma serve solo una lista di test che hai intenzione di implementare. Questo perche' il codice di ogni test poi dipendera' fortemente dal codice che andrai scrivere di volta in volta e che i test guidano. E' un processo iterattivo.
Stiamo giusto puntalizzando qui, non e' una questione di vita o di morte :)
Ma e' buona cosa entrare in questa mentalita', ad esempio guarda l'ultimo topic di Pair Programming fra me e cionci: siamo partiti con un elenco di test, poi abbiamo preso il primo test e lo abbiamo scritto, poi il codice, poi il secondo test, poi abbiamo aggiunto altri test alla lista che ci sono venuti in mente nel frattempo. E cosi' via fino alla fine del task...
lo stato di wait è uno stato di attesa, in cui la grid aspetta un tot di tempo prima di tornare alla sua normale esecuzione, quindi per me logicamente anche insertGem "deve attendere", cmq, perchè insertNewGem è private e insertGem è public?
Un'altra precisazione: Grid ora e' diventato un oggetto passivo che accetta solo comandi e li porta a termine immediatamente, non gestisce l'input quindi non ha stati, quindi non puo' entrare in stato di attesa. Questo perche' Grid stava diventando un contenitore di tutto il codice che non sapevamo dove mettere.
A questo serve postare la test list, di modo che sia possibile discutere l'idea di implementazione e intervenire subito in caso vada in conflitto con la direzione che sta prendendo il design come in questo caso.
fek, per i test, sono d'accordo, solo che ormai li avevo postati i test:D, infatti il test sull'input non l'ho scritto;)
il problema è che cmq è dentro grid che viene generata la nuova gemma....
fek, per i test, sono d'accordo, solo che ormai li avevo postati i test:D, infatti il test sull'input non l'ho scritto;)
il problema è che cmq è dentro grid che viene generata la nuova gemma....
Non ti chiedo mica di cancellarli i test adesso eh :)
Va bene cosi', era solo per puntualizzare il discorso sulla test list.
Dunque, se il fatto che una nuova gemma viene creata in Grid e la cosa ti disturba, vedi se puoi fare un po' di refactoring di modo da tirare questa funzionalita' fuori da Grid magari. Anche creando una nuova classe, non so, qualcosa tipo GameControl che includa anche InputReactor e una griglia. Vedi un po' come il codice vuole farsi fattorizzare.
allora il punto chiave secondo me è il metodo update di grid, che fa due cose, aggiorna la griglia e controlla se la gemma sotto controllo non può più muoversi, e in tal caso crea la nuova gemma, adesso magari sposterei questo controllo in altro metodo, però a me sembra naturale che sia grid a preoccuparsi se la gemma sotto controllo abbia colliso, a meno che non vogliamo spostare tutta la gestione della collisione in una nuovla classe.....
e quindi di conseguenza anche il compito di inserire una nuova gemma
allora il punto chiave secondo me è il metodo update di grid, che fa due cose, aggiorna la griglia e controlla se la gemma sotto controllo non può più muoversi, e in tal caso crea la nuova gemma, adesso magari sposterei questo controllo in altro metodo, però a me sembra naturale che sia grid a preoccuparsi se la gemma sotto controllo abbia colliso, a meno che non vogliamo spostare tutta la gestione della collisione in una nuovla classe.....
Dunque, e' naturale che Grid controlli le collisioni e questo ci sta bene. E' un po' meno naturale che a seguito di una collisione allora decida di inserire una nuova gemma (azione attiva), ma ci puo' anche stare per ora. Se pero' questo significa essere costretti ad inserire altre funzionalita' attive oppure addirittura uno stato di pausa per Grid, allora la cosa comincia a diventare troppo complessa. Quindi io tirerei fuori l'azione di inserimento di una nuova gemma.
Resta da capire come comunicare lo stato di collisione avvenuto tale che "qualcun altro" possa decidere di reagire a questo evento e mandare un nuovo messaggio di inserimento a Grid. Eventi, reazioni agli eventi, stiamo parlando di un Observer Pattern qui :)
Allora possiamo muoverci in questa direzione, magari registrando una callback in Grid che Grid puo chiamare al momento della collisione. Non e' detto che la soluzione sia piu' semplice di quella che proponi tu, perche' un Observer piazzato cosi' tende ad offuscare la logica di esecuzione. Prova un po' e dicci le tue sensazioni. Facciamo sempre in tempo a cambiare strada e trovarne una alternativa.
allora, magari faccio un po di refactoring introducendo l'observer (mhmhm..GridController?), in modo che Grid notifica l'avvenuta collisione all'oggetto controller, che agisce di conseguenza, e poi magari discutiamo se mantenere la nuova soluzione oppure tornare alla vecchia, ok?
allora, magari faccio un po di refactoring introducendo l'observer (mhmhm..GridController?), in modo che Grid notifica l'avvenuta collisione all'oggetto controller, che agisce di conseguenza, e poi magari discutiamo se mantenere la nuova soluzione oppure tornare alla vecchia, ok?
Ok. Prova a vedere cosa esce, con alcune avvertenze:
- fai le cose semplici
- non implementare tutto l'Observer, e' piuttosto complesso e ridondante; implementa solo la piccola parte che ti serve
- fai tutto test-driven e postaci la lista di test
- poni molta attenzione alla classe GameController e mantienila semplice, non aggiungere nulla che non ci serva adesso
- fai le cose semplici :)
Magari visto che il compito e' un po' delicato, lo si potrebbe fare in Pair Programming, che ne dici? Chi si offre volontario?
se si riesce ad essere rapidi nel pair programming, volentieri, purtroppo non ho moltissimo tempo a disposizione, per me andrebbe bene anche cominciare stasera.....
ok, parto da solo, faccio un elenco dei test da implementare, tenendo sempre presente che poi test driven posso sorgere cambiamenti
GridController deve attendere una notifica da parte di Grid dell'avvenuta collisione, e agire di conseguenza inserendo una nuova Gem, anche se GridController potrebbe gestire altre situazioni, per il momento mi concentro su questa
test list:
- se grid non ha controllore, verificare che non venga aggiunta nessuna gemma dopo una collisione
- aggiungere un controller a grid e controllare che l'aggiunta abbia avuto successo
- verificare che dopo una collisione venga effettuta la notifica al controllore
- verificare che il controllere inserisca la nuova gemma dopo una notifica
per il momento mi vengono in mente questi, cmq, testdriven ne uscirano sicuramente altri, a dopo;)
No cisc, Grid e' un oggetto passivo, non deve contenere un controllore. Un controllore deve usare Grid e, eventualmente, registrare un handler per rispondere ad eventuali eventi di Grid stessa.
Perchè non mettere un metodo update in GridControl che chiama l'update di grid ed in caso che la gemma controllata isStopped crei una nuova gemma (con il ritardo opportuno) ?
Perchè non mettere un metodo update in GridControl che chiama l'update di grid ed in caso che la gemma controllata isStopped crei una nuova gemma (con il ritardo opportuno) ?
Adoro le soluzioni semplici :D
Perfetto, non ci serve l'Observer. Mi hai tolto un peso.
No cisc, Grid e' un oggetto passivo, non deve contenere un controllore. Un controllore deve usare Grid e, eventualmente, registrare un handler per rispondere ad eventuali eventi di Grid stessa.
ok, tu mi avevi parlato di Observer, e io Observer andavo ad implementare, cioè davo la possibilità a Grid di registrare quale oggetto lo andava a "osservare", cmq, penso che la soluzione di cionci sia effettivamente + semplice, la implementiano sempre in pair io e 71104?
ok, tu mi avevi parlato di Observer, e io Observer andavo ad implementare, cioè davo la possibilità a Grid di registrare quale oggetto lo andava a "osservare", cmq, penso che la soluzione di cionci sia effettivamente + semplice, la implementiano sempre in pair io e 71104?
Si', la mia idea dell'Observer era sbagliata :)
Implementate pure la soluzione di cionci.
Si', la mia idea dell'Observer era sbagliata :)
Implementate pure la soluzione di cionci. perfetto; ho deciso di lavorare io insieme a cisc perché questa idea del GridController servirà anche per il mio task, quello della scritta Game Over: il codice andrà nel controller, e così non dovrò aggiungere nulla a Grid :D
ora sto uscendo, torno dall'università alle 5 e mezza, 6 meno 1/4 e ci mettiamo a lavorare.
ciao
perfetto; ho deciso di lavorare io insieme a cisc perché questa idea del GridController servirà anche per il mio task, quello della scritta Game Over: il codice andrà nel controller, e così non dovrò aggiungere nulla a Grid :D
ora sto uscendo, torno dall'università alle 5 e mezza, 6 meno 1/4 e ci mettiamo a lavorare.
ciao
Ottimo, questo da' un senso alla classe GridController, che alla fine non sara' altro che quello che era fino ad oggi Grid, ma ad un livello di astrazione piu' alto.
Mi piace come questo concetto di GridController sia letteralmente emerso dal codice piuttosto che essere imposto da noi all'inizio. Ho appena avuto un lungo meeting in ufficio esattamente su questo concetto, e sono molto fresco a riguardo :)
KISS, Keep It Simple Stupid.
DanieleC88
14-12-2005, 15:22
Si' ragazzi adesso non litigatevi i task, che c'e' sempre in tempo ad aggiungere nuove Storie, ne abbiamo pronte per altri tre mesi :D
Tranquillo, io non litigo per un task (sto anche sviluppando due giochini per conto mio, di lavoro ne ho da fare :D), ma voglio ricordare a loro che sono DEI LUPI FAMELICI! :D :rotfl:
ho committato il task Xmas.1.1 (finalmente abbiamo sta cavolo di scritta "Game Over"!! :D) ma il Layer Manager sembra avere un problema: nonostante lo sprite della scritta game over venga inserito nel Layer Manager necessariamente dopo l'oggetto Grid (poiché la grid viene inserita in fase di inizializzazione, mentre il messaggio ovviamente viene inserito al termine della partita), questo viene disegnato dietro la griglia... credo che il layer manager disegni gli sprites di ciascun layer nell'ordine sbagliato, anche se i diversi tipi di layers (trasparenti e opachi) sembra disegnarli nell'ordine corretto (il background infatti si trova dietro la griglia); forse dipende anche da OpenGL...
ne ho parlato con fek, eravamo rimasti che avrei cercato l'errore, ma mi si sono messi a messaggiare in 4 su MSN e non ce l'ho fatta ^^'
sorry, ci penserò domani, o molto più probabilmente dopodomani.
per adesso accontentatevi di un GAME OVER in semitrasparenza :D
public void drawLayers(AbstractEngine engine)
{
for(ArrayList<Drawable> layer : opaqueLayers)
{
drawLayer(layer, engine);
}
for(ArrayList<Drawable> layer : transparentLayers)
{
drawLayer(layer, engine);
}
}
Basta che guardi qui... I layer opachi vengono disegnati prima di quelli trasparenti :)
Ti conviene per ora metterlo nei transparentLayers poi si vedrà coi prossimi refactoring...
Ho corretto il bug cambiando Opaque con Transparent.
ciao ;)
ah è vero, avete ragione... ^^'
ma scusate, qual è il motivo percui i layers opachi vengono disegnati tutti prima di quelli trasparenti? :D
ah è vero, avete ragione... ^^'
ma scusate, qual è il motivo percui i layers opachi vengono disegnati tutti prima di quelli trasparenti? :D
Per la spiegazione tecnica dobbiamo aspettare Vifani. Io l'ho scritto in questo modo perché cosi mi è stato detto :p
ciao ;)
probabilmente perchè tu scrivi il buffer con i layer opachi e poi per l'effetto trasparenza fai il modulate tra texture semitrasparente e framebuffer
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.