[CICLO 15] Storia 2

[cionci]

Originariamente inviato da fek

Ma no, voglio loggare a valle, solo il risultato degli eventi, non voglio loggare la pressione dei tasti. Proprio perche' voglio loggare meno e concetti piu' astratti. Cosi' non dobbiamo portarci dietro concetti come il timer ed e' piu' facile da mantenere.

Nessuno ha detto di loggare i tasti...ora vengono loggate le azioni... Ed il log che si fa adesso basta ed avanza per riprodurre interamente gli eventi... Ovviamente con l'aiuto del MockTimer...

[fek]

cionci, e' un hack grosso come una casa. Un Timer non e' un qualcosa che tiene traccia dei timestamp. Un Timer conta il tempo e basta, gli stai dando un'altra responsabilita' e questo porta a grossi disastri.

Ora, se e' una soluzione temporanea mi sta bene, se e' la tua soluzione finale no. Va rifattorizzata subito.

[fek]

Originariamente inviato da cionci

Nessuno ha detto di loggare i tasti...ora vengono loggate le azioni... Ed il log che si fa adesso basta ed avanza per riprodurre interamente gli eventi... Ovviamente con l'aiuto del MockTimer...

Ok, i requisiti del task ti chiedono di farlo senza aiuto del MockTimer. Il task e' concluso quando posso scrivere quel test che ho richiesto senza un MockTimer di mezzo.

[cionci]

Originariamente inviato da fek

Ora, se e' una soluzione temporanea mi sta bene, se e' la tua soluzione finale no. Va rifattorizzata subito.

Chiamiamolo TimeStamp allora...dopo tutto è giusto che si chiami così...e ripeto... Questo è IMHO un refactoring da fare indipendentemente se useremo o meno questa possibilità per riprodurre il log...

[thebol]

Originariamente inviato da fek

doSomething() deve generare l'evento che viene messo in ordine con gl'altri eventi. Come scrivevo, la generazione e l'ordinamento degli eventi deve essere fatto a monte, e poi scritto il risultato nel log assieme al suo game turn.

Quindi un evento crush viene scritto come tale e il tempo di attesa processato a monte. C'e' solo da fare un attimo di refactoring per introdurre questo concetto di generazione degli eventi.

In questa maniera(lavorando su eventi) si sposterebbe il livello di intervento su inputReactor, sostituendolo con una classe che chiami gli eventHandler opportuni.

[cionci]

Originariamente inviato da fek

Ok, i requisiti del task ti chiedono di farlo senza aiuto del MockTimer. Il task e' concluso quando posso scrivere quel test che ho richiesto senza un MockTimer di mezzo.

Ok, ma valutiamo anche il traffico... Aumentando gli eventi aumenta il traffico e diminuisce la possibilità di utilizzare il gioco su un modem 56K...

[fek]

Originariamente inviato da cionci

Chiamiamolo TimeStamp allora...dopo tutto è giusto che si chiami così...e ripeto... Questo è IMHO un refactoring da fare indipendentemente se useremo o meno questa possibilità per riprodurre il log...

Sono pedante oggi, scusami

Vuoi creare una classe TimeStamp per che cosa di preciso? Non mi e' chiaro. (Sono pedante e lento oggi).

Una piccola nota su quello che e' accaduto in questa discussione. Lo scambio di opinioni ha portato ad una migliore definizione da parte mia dei requisiti del task, che prima della discussione erano molti laschi.

Questo dimostra che discutere un task e' una cosa sempre molto buona.

Ora, quello che ti chiedo sembra una violazione di YAGNI, perche' tu mi proponi una soluzione che richiede meno codice e io te ne chiedo una con piu' codice. Sembra che io sia in violazione, ma non lo sono perche' sono il Coach

A parte gli scherzi, dopo la discussione sono cambiati i requisiti quindi la tua soluzione non e' piu' la soluzione giusta al problema di soddisfare i (nuovi) requisiti del task "Riprodurre il log senza ausilio di MockTimer", ma e' soluzione dei requisiti vecchi.

YAGNI si applica quando tutti i requisiti sono soddisfatti e impone che lo siano con meno codice possibile.

[cionci]

Ripeto ragazzi...provate il gioco con quell'hack o come lo volete chiamare... Abbassate InputRate a 50 e vedrete aumentare la precisione del gioco... Ad esempio negli spostamenti laterali...

IMHO è da introdurre poi fate come volete...indipendentemente dal fatto di usare il mocktimer nel log...

[fek]

Originariamente inviato da cionci

Ok, ma valutiamo anche il traffico... Aumentando gli eventi aumenta il traffico e diminuisce la possibilità di utilizzare il gioco su un modem 56K...

Stai discutendo il design del codice in base a valutazioni di carattere prestazionale che non appaiono nei requisiti?

I requisiti del networking (per ora), non parlano di model 56k quindi questo E' YAGNI. Se i requisiti lo richiederanno e se la banda che consumiamo sara' eccessiva una volta fatto il profiling, allora valuteremo le soluzioni a quel problema. Ora non le valutiamo e ci atteniamo strettamente ai requisiti.

[fek]

Originariamente inviato da cionci

Ripeto ragazzi...provate il gioco con quell'hack o come lo volete chiamare... Abbassate InputRate a 50 e vedrete aumentare la precisione del gioco... Ad esempio negli spostamenti laterali...

IMHO è da introdurre poi fate come volete...indipendentemente dal fatto di usare il mocktimer nel log...

Joc, puoi valutare una build con questo fix per favore? La decisione qui diventa tua.

[cionci]

Aspettate che vi metto su un test (fatto a mano, non JUnit) che vi dimostra la maggiore precisione...

[cionci]

Ok...allora avviate il gioco premete da subito i tasti sinistra e basso (se rischiate di riempire la colonna centrale, prima dell'inserimento di una nuova gemspair lasciate il tasto sinistra e premete destra contemporaneamente) di entrambi i giocatori...vedrete che i campi gioco dopo un po' si evolveranno in maniera diversa...

[thebol]

Originariamente inviato da fek

Ok, i requisiti del task ti chiedono di farlo senza aiuto del MockTimer. Il task e' concluso quando posso scrivere quel test che ho richiesto senza un MockTimer di mezzo.

non penso sia possibile, a meno che tu nn voglia aspettare il tempo della partita prima di vedere finire il test.

[thebol]

Originariamente inviato da cionci

Ok...allora avviate il gioco premete da subito i tasti sinistra e basso (se rischiate di riempire la colonna centrale, prima dell'inserimento di una nuova gemspair lasciate il tasto sinistra e premete destra contemporaneamente) di entrambi i giocatori...vedrete che i campi gioco dopo un po' si evolveranno in maniera diversa...

era il non determinismo di cui parlavo qualche post fa

[fek]

Originariamente inviato da thebol

non penso sia possibile, a meno che tu nn voglia aspettare il tempo della partita prima di vedere finire il test.

Nei requisiti c'e' di non dover aspettare il tempo della partita

Tutto e' possibile. E spesso e' possibile anche in maniera piu' semplice.

[fek]

Originariamente inviato da cionci

Ok...allora avviate il gioco premete da subito i tasti sinistra e basso (se rischiate di riempire la colonna centrale, prima dell'inserimento di una nuova gemspair lasciate il tasto sinistra e premete destra contemporaneamente) di entrambi i giocatori...vedrete che i campi gioco dopo un po' si evolveranno in maniera diversa...

Appena Joc lo conferma, questo diventa un bug e va risolto. Approposito, dobbiamo tenere aggiornato l'elenco dei bug e Joc deve produrre ogni tanto una storia per correggerli.

[thebol]

Originariamente inviato da fek

Nei requisiti c'e' di non dover aspettare il tempo della partita

Tutto e' possibile. E spesso e' possibile anche in maniera piu' semplice.

Quando entro nello stato waitStateBeforeNewGemPair, come faccio a dirgli che sono passati n ms e che puo passare allo stato successivo?

Si potrebbero saltare tutte queste attese creando un mockTimer settato a 9999999999999999, ma sempre mockTimer è.

[cionci]

Originariamente inviato da thebol

Quando entro nello stato waitStateBeforeNewGemPair, come faccio a dirgli che sono passati n ms e che puo passare allo stato successivo?

Semplicemente non ci entri... Riproduci gli eventi...quindi sai che al turno N verrà generata una nuova gemspair...

Comunque a questo punto inputServed deve cambiare... Ora vengono contati i turni di input... Per loggare questi eventi deve contare gli update...

[thebol]

Originariamente inviato da cionci

Semplicemente non ci entri... Riproduci gli eventi...quindi sai che al turno N verrà generata una nuova gemspair...

Comunque a questo punto inputServed deve cambiare... Ora vengono contati i turni di input... Per loggare questi eventi deve contare gli update...

mmm

percui generiamo anche gli eventi tipo Crush(possono essere a catena) nel log?

[Jocchan]

Cionci, ho provato a settare InputRate a 50 (ma anche a 5, pensando ci fosse un errore di battitura nel post, visto che hai detto di "ridurlo" ed il suo valore iniziale è 10).
Non mi pare ci sia una maggiore precisione, cambia solo la rapidità con cui le stesse cose vengono eseguite, ma le imprecisioni rimangono uguali, e credo si presentino più o meno dopo lo stesso numero di drop.