[CICLO 15] Storia 2

[thebol]

Originariamente inviato da thebol

avevo pensato a un sistema per risolvere un po la cosa...
mettere un metodo isUpdatable e setUpdatable.

nell'update di gridController ce un

while (state.isupdatable())
{
      state = state.update;
}
state.setUpdatable();

gli stati quando restituiscono uno stato settano se deve essere eseguito subito o no.

Centralizzi la chiamata della state.update, ma non so se sia vantaggioso farlo.

fra l'altro in questa maniera, potrei gestire i log degli state come i log del inputReactor.

Adesso invece ho messo uno stringBuffer in gridController, a cui gli state appenderanno la loro stringa.

[Bonfo]

Originariamente inviato da thebol

avevo pensato a un sistema per risolvere un po la cosa...
mettere un metodo isUpdatable e setUpdatable.

Secondo me non è quello il probelma.
In realtà basta decidere se il return degli state deve essere:
return new state();
oppure
return new state().update();

Il funzionamento rimane il medesimo. Per le temporizazzioni non so, ma anche quelle dovrebbero essere mantenute.
Il problema è modificare i test di conseguenza, che non sempre è molto ovvio.

PS: in realtà non capisco perchè alcuni state non dovrebbero essere updatable ??

[thebol]

Originariamente inviato da Bonfo

Secondo me non è quello il probelma.
In realtà basta decidere se il return degli state deve essere:
return new state();
oppure
return new state().update();

Il funzionamento rimane il medesimo. Per le temporizazzioni non so, ma anche quelle dovrebbero essere mantenute.
Il problema è modificare i test di conseguenza, che non sempre è molto ovvio.

PS: in realtà non capisco perchè alcuni state non dovrebbero essere updatable ??

la mia soluzione serviva per centralizzare il luogo di chiamata della update degli state.
Dove ora (negli state) viene fatto

return new stateXXX();

diverrebbe

State state = new stateXXX();
state.setNotUpdatable();
return state

mentre

return new stateXXX().update();

diverrebbe

State state = new stateXXX();
state.setUpdatable();
return state;

il codice aumenta, pero si centralizza per certi versi la gestione degli state.

Non so se sia conveniente, aspetto consigli dall'alto

[fek]

Originariamente inviato da thebol

il codice aumenta, pero si centralizza per certi versi la gestione degli state.

Non so se sia conveniente, aspetto consigli dall'alto

Se il codice aumenta, si sceglie la soluzione piu' semplice che risolve il problema.

Quel setUpdatable mi sa' tanto di getType mascherato. Provate a risolvere il problema con il polimorfismo, non settando dei flag.

[Jocchan]

Ho aggiunto la lista di refactoring postata nell'altro topic all'inizio di questo, in modo da potervi fare sempre riferimento. Ci sono altri refactoring svolti o in corso, così aggiorno l'elenco? Aggiornatemi, plz

[cisc]

secondo me le BigGem non sono completamente assimilabili a dei Droppable, sono delle entità che non cadono come tutti gli altri pezzi, ma che si formano dopo, e in qualche modo sono degli oggetti attivi quanto i bauli...nel senso che hanno il potere di modificare lo stato di Grid di più di una cella..quindi secondo me va cercata una qualche soluzione alternativa a quella attuale, ma non bisogna assimilare le bigGem direttamente ai droppable..

[Bonfo]

Originariamente inviato da cisc

secondo me le BigGem non sono completamente assimilabili a dei Droppable, sono delle entità che non cadono come tutti gli altri pezzi, ma che si formano dopo, e in qualche modo sono degli oggetti attivi quanto i bauli...nel senso che hanno il potere di modificare lo stato di Grid di più di una cella..quindi secondo me va cercata una qualche soluzione alternativa a quella attuale, ma non bisogna assimilare le bigGem direttamente ai droppable..

Non sono d'accordo...comunque la cosa mi sembra molto interessante
Mi farebbe piacere che ci esponessi approfonditamente questo pensiero e cosa ti frulla per la testa. Mi sa che ne escono fuori un sacco di belle cosine!!!

RACCONTACI!!!

[cisc]

questa sera non ho avuto modo di approfondire lo studio del codice in questione, cmq, le bigGem non le vedo tanto droppable magari creare un'interfaccia gridElement (un nome a caso, non badateci troppo adesso), che generalizza il più possibile una Droppable, e che magari si basi non più sul concetto di cella, ma di gruppo di celle...in questo modo si naturalizza la formazione di una bigGem, semplicemente sostituendo ad un gridElement di cella unitaria, una gridElement che occupa più celle...bisognerebbe ovviamente verificare quale sia la soluzione più opportuna con la matrice che al momento memorizza la griglia di gemme, cmq la via penso sia quella di considerare le bigGem non come un agglomerato di gemme, ma come una gemma + grande..che non cade, ma che nasce già bloccata, può solo scendere da "bloccata", dopo una crush... come vedete ancora le idee non sono molto chiare, sto vagliando una serie di soluzioni...domani sera cerco di concretizzare tutte queste idee che mi girano per la testa in una soluzione più chiara e definita, intanto le butto così, chissà che possano essere sviluppate o ampliate da qualcun altro nel frattempo...

[cdimauro]

Originariamente inviato da thebol

ci sto lavorando su, e ho notato che il gemspair.update, era nell'update di gridcontroller. Per evitare di doverla loggare, l'ho spostata in gemsundercontrollState. Qua fallivano dei test, ma è bastato togliere un update in waitstateBeforenewgemspair quando ritorna gemsundercontrollState.

Solo che ora mi fallisce il famigerato testAllTexutresLoadBeforeStartPlaying!
mi restituisce 46 invece che 45

ps. mi pare di aver capito che è quel problema sull'ordine dei test eseguiti...
ho fatto revert per nulla

Sì, perché vuol dire che è stata aggiunta qualche altra nuova texture che viene utilizzata dal gioco e che non è stata inserita nell'elenco di quelle da precaricare (aggiornando anche il numerino).

Sto lavorando a questo problema.

[fek]

Originariamente inviato da cdimauro

Sì, perché vuol dire che è stata aggiunta qualche altra nuova texture che viene utilizzata dal gioco e che non è stata inserita nell'elenco di quelle da precaricare (aggiornando anche il numerino).

Sto lavorando a questo problema.

Questo problema ha assoluta priorita'. Questo test deve essere reso autonomo il prima possibile.

[cdimauro]

OK. Appena finisco alcune rifattorizzazioni su Environment (che mi renderebbero la vita più facile) è la prima cosa a cui metterò mano.

[fek]

Mi aggiornate sullo stato del task playback?

E' possibile dati i refactoring concluderlo entro la fine del Ciclo o va posticipato? Abbiamo bisogno di piu' visibilita' sul suo stato.

[thebol]

Originariamente inviato da fek

Mi aggiornate sullo stato del task playback?

E' possibile dati i refactoring concluderlo entro la fine del Ciclo o va posticipato? Abbiamo bisogno di piu' visibilita' sul suo stato.

per stasera dovrei finire di completare il log.

poi cè da fare il reader del log, e un oggetto che dopo aver letto il log esegua in serie i vari eventi/stati.

fino al reader entro fine ciclo ci si arriva(si potrebbe incominciare gia a farlo adesso, per i log degli eventi dei tasti) per l'esecutore invece non penso...

[fek]

Originariamente inviato da thebol

per stasera dovrei finire di completare il log.

poi cè da fare il reader del log, e un oggetto che dopo aver letto il log esegua in serie i vari eventi/stati.

Ottimo, mi fai un break down di questi task, per favore? Abbiamo decisamente sottovalutato il task e serve che sia spezzato in sotto task, cosi' lo possiamo schedulare meglio nella prossima Storia se necessario.

[thebol]

Originariamente inviato da fek

Ottimo, mi fai un break down di questi task, per favore? Abbiamo decisamente sottovalutato il task e serve che sia spezzato in sotto task, cosi' lo possiamo schedulare meglio nella prossima Storia se necessario.

cavolo, piu veloce del mio edit

fra l'altro il legame fra il reader e l'esecutore non è banalissimo...

[thebol]

devo fare qualche test a livello di playField e fare il log per il stoneFallState e poi la prima parte è spero finita.

curiosità...
mi dimenticavo di resettare il log degli stati, ed ero arrivato a 200MB di log per field in meno di un minuto

[thebol]

mi appresto a committare...

il log ora è molto verboso, sopratutto per i molti gemspairOnControllState loggati...

si potrebbe risolvere questa cosa, facendolo loggare solo quando esce con il numero di volte che è stato eseguito.

altra cosa, il codice che scrive il log è sempre uguale(tranne che per stoneFallState), si potrebbe creare una classe abstract di gridControllerState e fare un metodo abstract li dentro(poi chi ha esigenze particolari lo reimplementa).

[fek]

Originariamente inviato da thebol

altra cosa, il codice che scrive il log è sempre uguale(tranne che per stoneFallState), si potrebbe creare una classe abstract di gridControllerState e fare un metodo abstract li dentro(poi chi ha esigenze particolari lo reimplementa).

YAGNI. Andiamo dritti alla soluzione del problema ora.

[thebol]

Originariamente inviato da fek

YAGNI. Andiamo dritti alla soluzione del problema ora.

ora cè da fare il reader del log, da pensare se eseguire il log mano a mano che lo si legge, oppure tutto in una volta e memorizzare quello che ci serve in una struttura ad hoc.

Poi scelta la soluzione, fare l'esecutore.

[fek]

Originariamente inviato da thebol

ora cè da fare il reader del log, da pensare se eseguire il log mano a mano che lo si legge, oppure tutto in una volta e memorizzare quello che ci serve in una struttura ad hoc.

Poi scelta la soluzione, fare l'esecutore.

Qual e' la piu' semplice a tuo avviso?