[CICLO 15] Storia 2

[Jocchan]

Storia 2: Bugfix e refactoring. Introduzione di un sistema di playback dei log.



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




Refactoring:
- Environment (cdimauro)
- Grid e trasformazione di BigGem in Droppable
- Omogenizazzione degli update degli State
- Action: definire meglio le responsabilità rispetto a Grid
- SoundBank
- TextureBank
-va finito il refactoring di Droppable ed AbstractDroppable creando le ultime interfacce ed eliminando alcune duplicazioni.
-sono presenti metodi non testati...
-Tutti i TODO del codice dovrebbero sparire in fretta perchè poi si finisce a portarseli dietro a lungo (addirittura c'è un test commentato con scritta una cosa tipo "qualcuno lo faccia passare" )

[Bonfo]

Io proporrei un bel refactoring e conseguente controllo delle Action.

Secondo me, molti metodi di Grid dovrebbero migrare in queste classi: si semplificherebbe grid e le Action diventerebbero molto più chiare, leggibili e probabilmente più semplici.

Primo esempio: in UpdateFallsAction sembra che grid.updateAlsoDroppedGem() venga richiamata 2 volte sulle gemme di una BigGem

Insomma...grid deve proprio dimagrire

[fek]

Procedi pure al refactoring.

[Bonfo]

Io l'ho proposto
..ma mica ho il tempo per farlo

Ieri ho dato un occhiata....è un matassa mica facile da sbrogliare

[VICIUS]

Visto che le parti di codice da toccare in questa storia sono completamente diverse da quelle della prima storia potete cominciare anche subito a fare refactoring e a modificare.
Non avendo una idea precisa di quello che c'è da fare ho preferito non scrivere task però fate come bonfo. Prima di partire a fare qualcosa provate a scrivere due righe e a proporle sul forum.

ciao

[thebol]

mi offro per il playbak del log
direi 5 giorni(sempre che nn lo dividiate in vari task )

[VICIUS]

Originariamente inviato da thebol

mi offro per il playbak del log
direi 5 giorni(sempre che nn lo dividiate in vari task )

Se ci scrivi qualche piccolo task giusto per capire come intendi procedere ti possiamo dare una mano tutti quanti.

ciao

[cionci]

Per il playback del log bisogna sincronizzare strettamente i vari timer del gioco...

Nel senso che bisogna fare 1 reactToInput ogni K update...inoltre anche tutti gli altri timeStamp ottenuti nel gioco devono essere sincronizzati con quelli del timer di update... Questo comporta un refactoring di timer che secondo me potrebbe essere di questo tipo:


timer.setTimeStamp(); <---da richiamare una sola volta per ogni ciclo di update
timer.getTimeStamp(); <---che dovrà essere richiamata da TUTTI i metodi che ora hanno bisogno di un timestamp

In questo modo la sinconizzazione dovrebbe essere perfetta...

[thebol]

Originariamente inviato da VICIUS

Se ci scrivi qualche piccolo task giusto per capire come intendi procedere ti possiamo dare una mano tutti quanti.

ciao

devo pensarci, cmq un idea preliminare potrebbe essere:

precaricare il file di log, con gli eventi key da generare
lavorare a livello di input o inputReactor(devo vedere bene) per assegnare gli eventi al tick giusto

il resto dovrebbe funzionare come ora.

Forse non importa neanche disabilitare i tasti del secondPlayer.

Le uniche perplessita possono essere sul precaricamento del log, potrei leggerlo mano a mano e poi usarlo, per evitare problemi di log molto lunghi, ma preferirei il caricamento manuale. Cmq si puo fare una classe che getta l'evento da assegnare, e poi si cambia l'implementazione.

[thebol]

altra cosa da valutare è l'inserimento della pair, ma mi sembra che nel log venga scritto il seed, percui bisogna settare nel caso della demo il seed a mano.

[Bonfo]

Originariamente inviato da thebol

devo pensarci, cmq un idea preliminare potrebbe essere:

precaricare il file di log, con gli eventi key da generare
lavorare a livello di input o inputReactor(devo vedere bene) per assegnare gli eventi al tick giusto

il resto dovrebbe funzionare come ora.

Forse non importa neanche disabilitare i tasti del secondPlayer.

Le uniche perplessita possono essere sul precaricamento del log, potrei leggerlo mano a mano e poi usarlo, per evitare problemi di log molto lunghi, ma preferirei il caricamento manuale. Cmq si puo fare una classe che getta l'evento da assegnare, e poi si cambia l'implementazione.

Sarebbe bello che il log fosse incapsulato da una classe "Player" che, costruito con un timer, al momento giusto genera la pressione del tasto
Praticamente un generatore di evanti basato su file

[Bonfo]

Problema che richiede consiglio.
Vi faccio notare una piccola differenza:

bigGem.canMoveDown(grid)

grid.gemCanMoveDown(gem)

I due metodi sono esattamente opposti come impostazione. Qui salta all'occhio il problema che la BigGem non è un droppable. Bisogna riuscire in questa impresa...se qualcuno sa già che è impossibile parli adesso o taccia per sempre

Ed ora guardando bene è uscito pure questo:

    public void draw(EngineInterface engine)
    {
        background.draw(engine);

        forEachGem(new DrawGemsAction(this, engine));

        for(BigGem bigGem : bigGems)
        {
            bigGem.draw(engine);
        }
    }

e questo

gem.getSprite().draw(engine);

Perchè solo BigGem implementa Drawable e i Droppable no??
Anche questo è da fare

[Ufo13]

Bonfo, BigGem può sicuramente essere resa più omogenea... Io proprio finirei di gestirla dome aggregato di Gem ma bisogna prima terminare il refactoring di Droppable che avevamo iniziato e che mi pare sia in sospeso :P

[Bonfo]

Originariamente inviato da Ufo13

Bonfo, BigGem può sicuramente essere resa più omogenea... Io proprio finirei di gestirla dome aggregato di Gem ma bisogna prima terminare il refactoring di Droppable che avevamo iniziato e che mi pare sia in sospeso :P

Sospeso
E che manca...???

Io stavo guardando ora se è lecito far si che i Droppable implemntino anche Drawable...infatti mentre BigGem gestisce internamente la Sprite, le gemme non fanno nulla, facciamo tutto noi a mano.

Questa differenza non mi piace molto.

[thebol]

Originariamente inviato da Bonfo

Sarebbe bello che il log fosse incapsulato da una classe "Player" che, costruito con un timer, al momento giusto genera la pressione del tasto
Praticamente un generatore di evanti basato su file

la mia idea è circa questa. Bisogna solo capire per bene a quale livello conviene inserirsi.

[fek]

Il playback non deve essere legato strettamente al timer del gioco e agli update dell'engine.

Quello che mi interessa (e lo spirito del task) e' arrivare a poter scrivere un test di questo tipo:

LogPlayback playback = new LogPlayback("log.txt");

int gameTurn = 100;

playback.Run(gameTurn);

Grid playerOne = playback.getPlayerOneGrid();
Grid playerTwo = playback.getPlayerOneGrid();

E da qui in poi mi interessa poter fare operazioni sulle due griglie e poter fare delle assert. Questo ci permettera', dato un log di un bug, di ricreare il bug in un test e poter testare il relativo fix.

Ovviamente l'esecuzione del singolo test non deve impiegare dei minuti, e per questo non voglio che il playback sia legato ad un timer "reale", ma solo al concetto di game turn. Se il concetto non esiste, va aggiunto.

[Bonfo]

Altra cosa che non mi piace. Ovvero che è meglio rendere molto più chiara:
in grid c'è:
move(float,float);
moveTo(float,float);

Se mi dite che la differenza è chiara sto zitto...altrimenti

[VICIUS]

Originariamente inviato da Bonfo

Problema che richiede consiglio.
Vi faccio notare una piccola differenza:

bigGem.canMoveDown(grid)

grid.gemCanMoveDown(gem)

I due metodi sono esattamente opposti come impostazione. Qui salta all'occhio il problema che la BigGem non è un droppable. Bisogna riuscire in questa impresa...se qualcuno sa già che è impossibile parli adesso o taccia per sempre

Ed ora guardando bene è uscito pure questo:

    public void draw(EngineInterface engine)
    {
        background.draw(engine);

        forEachGem(new DrawGemsAction(this, engine));

        for(BigGem bigGem : bigGems)
        {
            bigGem.draw(engine);
        }
    }

e questo

gem.getSprite().draw(engine);

Perchè solo BigGem implementa Drawable e i Droppable no??
Anche questo è da fare

Non è male come idea. Se riusciamo ad implementare Droppables in bigGem oltre a usare uno stile comune per entrambi possiamo unire i due foreach. Magari rinominado GemAction forEachGem in DroppableAction forEachDroppable.

ciao

[VICIUS]

Grid è pieno di metodi che riguardano solo le BigGem e questo mi puzza.
Ci sono funzioni come "public boolean gemCanMoveDown(Droppable gem)" che hanno nel nome Gem e poi richiedono un Droppable. Anche questa confusione non mi piace

[thebol]

Originariamente inviato da fek

Il playback non deve essere legato strettamente al timer del gioco e agli update dell'engine.

Quello che mi interessa (e lo spirito del task) e' arrivare a poter scrivere un test di questo tipo:

LogPlayback playback = new LogPlayback("log.txt");

int gameTurn = 100;

playback.Run(gameTurn);

Grid playerOne = playback.getPlayerOneGrid();
Grid playerTwo = playback.getPlayerOneGrid();

E da qui in poi mi interessa poter fare operazioni sulle due griglie e poter fare delle assert. Questo ci permettera', dato un log di un bug, di ricreare il bug in un test e poter testare il relativo fix.

Ovviamente l'esecuzione del singolo test non deve impiegare dei minuti, e per questo non voglio che il playback sia legato ad un timer "reale", ma solo al concetto di game turn. Se il concetto non esiste, va aggiunto.

il gameTurn pensavo ci fosse, ma non cè...

in teoria è facile ricavarselo dal log(cè il timeStamp per ogni azione e sapendo il rate degli update si ricava in fretta), ma in effetti sarebbe piu carino introdurlo(anche nella scrittura dei log), in modo da avere una cosa piu uniforme. E cmq perdere il timeStamp dal log in favore del gameTurn non penso sia un problema