[CICLO 10] Storia 2

[Jocchan]

Meglio andare sulla leggibilità

[cionci]

Vabbè...in ogni caso niente vieta di salvare anche il random seed ed usare quello per riprodurre la sequenza... Scrivere le gemme generate ci può anche stare, ma sicuramente leggerle da lì per poi riprodurre la sequenza è diversi ordini più complicato che usare il random seed

[thebol]

Originariamente inviato da cionci

Vabbè...in ogni caso niente vieta di salvare anche il random seed ed usare quello per riprodurre la sequenza... Scrivere le gemme generate ci può anche stare, ma sicuramente leggerle da lì per poi riprodurre la sequenza è diversi ordini più complicato che usare il random seed

in genere il compito di un log, è illustrare cosa sta facendo l'applicazione(in caso di errore/eventi particolari), e il dare in pasto il log a un programma per vedere cosa fa è "complicato".

Certo nulla vieta di mettere anche il seed all'inizio(cosa che si puo aggiungere in caso si voglia fare riprodurre il log a Diamonds)

[Jocchan]

Allora, se questo ci dà dei vantaggi in termini di riproducibilità, nella prima riga salveremo il seed.

[VICIUS]

Potrebbe servirci per controllare se la lista delle gemme è corretta. Se vogliamo un po' di leggibilità in più basta fare cosi:

seed 234518458724

ciao

[cionci]

Originariamente inviato da thebol

in genere il compito di un log, è illustrare cosa sta facendo l'applicazione(in caso di errore/eventi particolari), e il dare in pasto il log a un programma per vedere cosa fa è "complicato".

Secondo me il log non serve a niente se non può essere riprodotto dall'interno di diamond... A leggere il log non capiremmo mai niente

[Ufo13]

Basterebbe poter inserire manualmente il seed in modalita` debug... Con la lista dei comandi si riproduce...

[fek]

Originariamente inviato da cionci

Secondo me il log non serve a niente se non può essere riprodotto dall'interno di diamond... A leggere il log non capiremmo mai niente

Bingo. Il log e il record interno ci devono servire per poter riprodurre come un replay cio' che e' accaduto dall'interno del gioco. Ci servira' anche per fare regression testing: in pratica avremo tutta una batteria di test che leggono dei log e testano che qualche particolare proprieta' sia valida. Quando qualcuno ci manda un log con un bug, ad esempio, questo verra' inserito nella batteria di test, e poi ci sara' il fix.

[VICIUS]

Originariamente inviato da fek

Bingo. Il log e il record interno ci devono servire per poter riprodurre come un replay cio' che e' accaduto dall'interno del gioco. Ci servira' anche per fare regression testing: in pratica avremo tutta una batteria di test che leggono dei log e testano che qualche particolare proprieta' sia valida. Quando qualcuno ci manda un log con un bug, ad esempio, questo verra' inserito nella batteria di test, e poi ci sara' il fix.

Allora il gameturn e la legibilità ci servono veramente a poco. Ci serve sapere il momento esatto in cui avviene un evento quindi dobbiamo per forza di cose stampare il timestamp del timer.

ciao

[fek]

Originariamente inviato da VICIUS

Allora il gameturn e la legibilità ci servono veramente a poco. Ci serve sapere il momento esatto in cui avviene un evento quindi dobbiamo per forza di cose stampare il timestamp del timer.

ciao

Dove ci serve sapere il momento esatto di preciso? Si puo' modificare il codice di modo che non serva piu'? Oppure spostare il capture degli eventi a valle rispetto a quel codice?

[VICIUS]

Originariamente inviato da fek

Dove ci serve sapere il momento esatto di preciso? Si puo' modificare il codice di modo che non serva piu'? Oppure spostare il capture degli eventi a valle rispetto a quel codice?

Se vogliamo riprodurre esattamente l'input del utente mi pare sia l'unico modo.

IL gameturn non lo trovo una semplificazione ma una informazione superflua visto che abbiamo il timer. Con soli 20 millisecondi tra un gameturn e l'altro l'unico modo per far avvenire due eventi nello stesso è riuscire a premere più di 50 tasti nello stesso istante che è semplicemente inumano. In sostanza il file sarebbe composto da:

gameturn
evento

gameturn
evento

Inoltre venendo incrementato ogni 20 millisecondi il numero del gameturn aumenta molto velocemente e perde ogni significato per un osservatore umano.

Anche le stringhe leggibili sono superflue. Lo sviluppatore non andrà mai a leggere direttamente il file di log per confermare la presenza del bug o fare del debugging. Come hai detto tu stesso sarà dato in pasto ai test o ad una versione per il debug del gioco quindi preferisco avere una versione più scarna ma facile da leggere.

In pratica qualcosa di simile a questo:

4532184645513

00021232 left
00021245 up
00021325 mirror
00032099 clockwise

Se fosse per me scriverei direttamente tutto in binario e userei i codici dei tasti al posto delle stringhe ma forse è un po troppo.

ciao

[cionci]

No...VICIUS...a questo punto sono contrario al timestamp... Seguite il mio discorso:

Teniamo un contatore che conta le volte che viene chiamata InputReactor.reactToInput (quindi viene incrementato una volta ogni 60ms circa)...

Ora sappiamo che verrà fatta la gestione degli eventi (e qui è di fatto come se gli eventi avvenissiro tutti al momento della chiamata di reactToInput)...quindi memorizzando il contatore e gli eventi (anche le ripetizioni) riusciremo a riprodurre la sequenza esatta degli eventi...

Manca solo una cosa...la GridController.update e la GridController.reactToInput non sono sincronizzate fra loro o meglio lo sono ma non strettamente... Questo potrebbe provocare sfasamenti nell'applicazione della gravità fra la sequenza riprodotta e quella originale...

Basta sincronizzare strettamente GridController.update e GridController.reactToInput (ad esempio eseguendo la seconda ogni 6 volte che viene eseguita la prima)... Ecco ora abbiamo la garanzia che sia la caduta verticale che i movimenti saranno sincronizzati esattamente e la sequenza potrà essere riprodotta senza problemi...

[thebol]

e spostare il gameturn nell processInput()?
è qua che viene controller.reactToInput(timer)(viene fatto un update sulla keyboard è ne viene preso lo stato e in base a questo stato vengono sparati gli handler dei vari tasti); è qua che avviene effettivamente l'azione utente, percui il timestamp (imho) non serve. Serve sapere l'ennesimo ciclo di lettura degli input in cui abbiamo trovato il tasto z premuto.

come ottimizzazione del traffico, si potrebbe stabilire la regola che logga il gameturn di quando il tasto viene premuto e il gameturn in cui viene rilasciato.(anche se sarebbe meglio l'evento...)

per cui la struttura sarebbe

[code<gameturn>
<evento1 stato='i'>
<evento2 stato='e'>
</gameturn>
[/code]

ho usatlo l'xml per chiarezza

[thebol]

chiamate contatore che conta le volte che viene chiamata InputReactor.reactToInput come gameturn, e io e cionci diciamo piu o meno la stessa cosa

[cionci]

thebol: sì, ho fatto una modifica...boh...

Originariamente inviato da thebol

viene fatto un update sulla keyboard è ne viene preso lo stato e in base a questo stato vengono sparati gli handler dei vari tasti

L'update dei tasti viene fatto in Input.update()...
Direi comunque che quello che dobbiamo memorizzare siano gli eventi eseguiti (AbstractKeyEventHandler.execute)...

[thebol]

Originariamente inviato da cionci

thebol: sì, ho fatto una modifica...boh...


L'update dei tasti viene fatto in Input.update()...
Direi comunque che quello che dobbiamo memorizzare siano gli eventi eseguiti (AbstractKeyEventHandler.execute)...

    public void update()
    {
        keyboard.update();
    }

l'update di Input

ho solo saltato un passaggio

in teoria si potrebbe modificare la reactToInput di gridController per ritornare un lista degli eventi processati a quel giro

[cionci]

Come dicevo, basterebbe andare a scrivere gli eventi al momento dell'esecuzione, sarebbe la cosa più semplice...

[cionci]

Ho spostato qualche post nella discussione sul netcode...

[VICIUS]

Originariamente inviato da cionci

Manca solo una cosa...la GridController.update e la GridController.reactToInput non sono sincronizzate fra loro o meglio lo sono ma non strettamente... Questo potrebbe provocare sfasamenti nell'applicazione della gravità fra la sequenza riprodotta e quella originale...

Era proprio di questi sfasamenti e perdite di sincronia. Scrivere direttamente i timestamp mi sembrava l'unica maniera per ora di realizzare qualcosa di affidabile, pero se mi dici che con qualche modifica possiamo ottenere lo stesso risultato allora sono perfettamente favorevole alla soluzione del gameturn.

ciao

[cionci]

Sicuramente... Come dicevo basta eseguire una reactToInput ogni TOT (pari al rapporto fra InputRate e UpdateRate) update... Di fatto la reactToInput avverrà sempre prima (o dopo) dello stesso (se si contasse) update che ha generato l'input...

Faccio un esempio:

int numeroDiUpdateFraDueReactToInput = 6;

if(timeStampUltimoUpdate + UpdateRate <= timeStamp)
{
   timeStampUltimoUpdate += UpdateRate;
   if(timeStampUltimoReactToInput + UpdateRate * 6 <= timeStamp)   
   {
      timeStampUltimoReactToInput += UpdateRate * 6;
      controller.reactToInput();
   }
   controller.update();
}

In questo modo la sequenza che ha generato il log verrà sempre riprodotta...

Ad esempio questa è la sequenza delle chiamate:
Update1
Update2
Update3
Update4
Update5
ReactToInput1 -> eseguo MOVE_LEFT e scrivo nel log #1 MOVE_LEFT
Update6
Update7
Update8
Update9
Update10
Update11
ReactToInput2 -> eseguo ROTATE_CCW e scrivo nel log #2 ROTATE_CCW
Update12


Nella riproduezione:
Update1
Update2
Update3
Update4
Update5
ReactToInput1 -> nel turno #1 devo eseguire MOVE_LEFT
Update6
Update7
Update8
Update9
Update10
Update11
ReactToInput2 -> nel turno #2 devo eseguire ROTATE_CCW
Update12