[CICLO 10] Storia 2

[cionci]

Resta comunque il fatto che vadano spediti i timestamp...di fatto è necessario un aggiustamento del timer della finestra secondaria pari al ping fra i due utenti...

[thebol]

ma se dal gioco vengono considerati solo i comandi letti nel gameLoop, non basta loggare solo quelli?(od ho capito male io come funziona?)


ps. aggiustare il timer della seconda finestra a seconda del ping, puo essere fatto come ottimizzazione, ma il ping puo essere variabile, quindi non si puo usare come regola aurea

[cionci]

Originariamente inviato da thebol

ma se dal gioco vengono considerati solo i comandi letti nel gameLoop, non basta loggare solo quelli?(od ho capito male io come funziona?)

Sicuramente può bastare, ma gli eventi vengono registrati con un proprio timer..."appiattire" tutti gli eventi al gameloop (che non avviene ogni 20 ms, ma gira di continuo, l'unica pausa che c'è è di 1 ms), e di conseguenza ad un timer costante per tutti, potrebbe significare la perdita o l'inserimento di una ripetizione che altrimenti non ci dovrebbe essere...

Nella storia è riportato erroneamente che ogni loop di Game finisce/inizia ogni 20 ms... Il loop gira continuamente...c'è solo una pausa di 1ms alla fine di ogni loop...

Originariamente inviato da thebol

ps. aggiustare il timer della seconda finestra a seconda del ping, puo essere fatto come ottimizzazione, ma il ping puo essere variabile, quindi non si puo usare come regola aurea

Certamente, ma può essere una stima anche fatta molto spesso...

[cionci]

Ho in mente di fare una modifica anche all'aggiornamento dei timestamp....

Vi spiego, ora, praticamente da ogni parte, funzina così:

if(nuovoTimeStamp > vecchioTimeStamp + X)
{
  vecchioTimeStamp = nuovoTimeStamp;
  faiAzione(); 
}

Secondo me va SEMPRE trasformato in questo modo:

if(nuovoTimeStamp >= vecchioTimeStamp + X)
{
  vecchioTimeStamp += X;
  faiAzione(); 
}

Il primo metodo va benissimo in locale, quando i ritardi sono minimi, ma il secondo, oltre ad andare bene in locale va bene anche per la griglia secondaria...che in questo modo non si perderebbe mai una "azione"...
inoltre sarebbe compatibile con l'aumento/diminuzione dello sfasamento del timer...

[Jocchan]

Cionci, penso che la storia del loop ogni 20ms dipenda da un refactoring da fare a Game.

[cionci]

Mi sembra strano che sia ogni 20 ms... Anzi, sarebbe dannoso, visto che l'UpdateRate viene fatto ogni 10 ms e lo stesso FrameRate ogni 20 ms... Di fatto si antrebbe ad aumentare queste due grandezze...

[VICIUS]

Originariamente inviato da Jocchan

Cionci, penso che la storia del loop ogni 20ms dipenda da un refactoring da fare a Game.

No il refactoring di Game serve solo a togliere la logica del gioco da Game e spostarla in GameLoop.

Quanto dice cionci mi ha fatto riflettere.
GameTurn ci serve? Per ora non è altro che un'astrazione del timestamp da scrivere su un file. Ma il timestamp lo dobbiamo scrivere quindi non vedo la necessita di averlo.

ciao

[^TiGeRShArK^]

ehm... non ho capito bene...
dovremmo inviare TUTTI gli eventi generati da un utente al diamonds dell'altro utente???
ma supponendo anke 3 ms come intervallo per leggere un evento avremo la bellezza di circa 300 eventi al secondo...
mi sembrano un pò tantini onestamente... già trasmettendo 10 byte ad evento arriveremmo a 3 KB/s ke secondo me è il limite massimo...
inoltre per le considerazioni effettuate nell'altro thread secondo me non possiamo basarci sulla ricostruzione della storia del gioco basandoci sugli eventi perchè ci troveremmo a trattare con problematiche di ritrasmissione in caso di errore che non ci possiamo permettere di utilizzare per problemi di latenza..
imho la cosa migliore è usare (tanto x fare un esempio "alla femminina") la stessa tecnica utilizzata nei satelliti artificiali.... aumentare la ridondanza per prevenire gli errori piuttosto che effettuare ritrasmissioni... in questo modo avremo un pò di ridondanza in + ma in caso di errori potremo sempre e comunque gestire l'aggiornamento del gioco senza rimanere blokkati anke per 300 ms e ritrovarci comunque un evento fuori sequenza ke non potremo piu' gestire avendo già processato gli eventi precedenti e perdendo quindi la consistenza tra le due piattaforme del gioco....
spero di essermi spiegato anke se forse sono stato un pò criptico...

[cionci]

Qui si parla solamente di scrivere gli eventi su un file...mi sembra che abbiate già parlato di questa cosa su nsn... Credo comnuque che la trasmissione sulla rete e questa storia siano relazionati strettamente...

Quello che ora c'è da capire è: questo storia è relativa alla comunicazione sulla rete e semplicente riguarda solo quel famoso "log dei tasti"...

[Bonfo]

Emulando il nostro coach, fek, mi viene da dire YANGI.
La storia riguarda un log degli eventi locale.
La rete....ci si pensa quandò sarà il momento. Non è compresa nella storia. Stiamo rischiando una confusione infinita!!!

L'obbiettivo è ottenere un file con il log degli eventi dell'utente locale per poi avere la possibilità di debuggare...per adesso.
Il punto è....come lo facciamo sto file. Non ci dovrebbe interessare la rete.
Il gameturn è una astrazione utile o no?? Il timestamp è obbligatorio da spedire??
Come fa il log a tenere conto delgi avvenimenti ripetuti com e doppia pressione o mantenimento della pressione per più tempo??

Queste sopno le cose alle quali dobbiamo rispondere...il resto YANGI

Ora dico la mia.
Il gameTurn semplifica il file rispetto un timestamp: quindi ci vuole

[cionci]

IMHO il GameTurn toglie informazioni...e potrebbe portare ad una intepretazione errata del log...
Poi ancora...il GameTurn non è definito come tale... Cosa si intende per GameTurn ?

1) il tempo fra un update dello stato delle gemme in grid e il successivo
2) il tempo fra un rendering e il successivo
3) il tempo fra un'elaborazione degli ingressi e la successiva
4) il tempo fra l'inizio e la fine di un gameloop (ricordo che in questo caso non ci sono temporizzazioni a regolare tale intervallo)

In ogni caso potremmo fare direttamente un log degli eventi nel momento in cui vengono gestiti (quindi da dentro l'event handler)... In tal caso sì, potremmo riprodurre esattamente le mosse (e le ripetizioni) ed in questo caso proprio in base al gameturn che però definirei come il punto 3 sopra...

[Jocchan]

Ne ho discusso con Fek, ed abbiamo definito meglio a cosa vogliamo arrivare con questa storia: un sistema di logging degli eventi facilmente intellegibile.
I gameturn servono solo per semplificarci la vita. Avranno applicazioni anche più avanti, ma (YAGNI) per ora li implementiamo solo per il logging.
Cambieremo però alcuni dettagli, ed ora insieme a Vicius vedremo di riorganizzare anche i task, in modo da rendere il tutto ad un livello di astrazione ancora superiore: invece dei codici dei tasti e del loro stato, loggheremo direttamente delle stringhe che descrivano l'azione che è effettivamente avvenuta su schermo, saltando ovviamente i gameturn in cui non è successo nulla, ed ordinando gli eventi di ogni gameturn in base ai timestamp (non loggati).
La forma finale sarà qualcosa del tipo:

01
ruby-topaz pair created

02
move left

05
move right
rotate clockwise

11
move right
mirroring

17
pair dropped
diamond-emerald pair created

...

I gameturn li usiamo insomma per separare questi "blocchi" di eventi, e per avere un'idea del tempo trascorso tra l'uno e l'altro (20ms significa 1/50 di secondo).

[^TiGeRShArK^]

Originariamente inviato da Jocchan

Ne ho discusso con Fek, ed abbiamo definito meglio a cosa vogliamo arrivare con questa storia: un sistema di logging degli eventi facilmente intellegibile.

ah ecco... perfetto..
essendomi perso la discussione su nsn pensavo fosse collegato alla trasmissione in rete.... non avevo capito ke era per debug

[cionci]

Originariamente inviato da Jocchan

I gameturn li usiamo insomma per separare questi "blocchi" di eventi, e per avere un'idea del tempo trascorso tra l'uno e l'altro (20ms significa 1/50 di secondo).

Ok...allora ci si può sincronizzare direttamente con il lancio degli eventi (un turno ogni InputRate ms).... In questo modo, come ho scritto sopra, ogni volta che viene chiamata GridController.reactToInput vengono loggati tutti gli eventi che vengono svolti i quel turno...di fatto è molto più semplice e lineare...

[cionci]

Perchè non si salva il random seed invece di scrivere i nomi delle gemme generate ?

[Ufo13]

Originariamente inviato da cionci

Perchè non si salva il random seed invece di scrivere i nomi delle gemme generate ?

eh ma poi come ricrei la sequenza?

[cionci]

Se salvi il random seed e reinizializzi il random generator con lo stesso seed, la sequenza è automaticamente identica alla precedente...
Dopo il log sarà così:

423422543 <- random seed

01
pair created

02
move left

05
move right
rotate clockwise

11
move right
mirroring

17
pair dropped
pair created

[thebol]

Originariamente inviato da cionci

Se salvi il random seed e reinizializzi il random generator con lo stesso seed, la sequenza è automaticamente identica alla precedente...
Dopo il log sarà così:

423422543 <- random seed

01
pair created

02
move left

05
move right
rotate clockwise

11
move right
mirroring

17
pair dropped
pair created

dipende se si vuol dare leggibilità al log oppure no(secondo me sarebbe opportuno fosse leggibile)

[cionci]

Ma a cosa servirebbe farlo leggibile ?!?!? Secondo me dovrebbe solamente essere riprodubile...la leggibilità credo che sia secondaria...

[Bonfo]

Mi sembra che l'ultima proposta fattaci sia mooolto più orientata alla leggibilità che alla riproducibilità...
...anche se io sono d'accordo con te, cionci.