[CICLO 10] Storia 2

[fek]

Originariamente inviato da VICIUS

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

Secondo me riprodurre l'input e' esattamente quello che non vogliamo fare, noi vogliamo riprodurre gli eventi di gioco che scaturiscono dall'input, per semplificare la gestione di questa lista di eventi.

Mi spiego meglio: se Jocchan decidesse che premdere due volte il tasto a destra in un turno causa lo spostamento della gemma alla fine della colonna di destra (esempio), quello che vogliamo registrare non e' la doppia pressione, ma l'evento "gemma si sposta alla fine della colonna a destra". Altro esempio: se la pressione del tasto destro e poi sinistro nello stesso tempo causa la generazione di nessun evento, noi non vogliamo registrare la pressione dei tasti, ma per l'appunto la generazione di nessun evento.

Quindi una lista di questo tipo:

Gameturn 1:
Spostamento a destra giocatore 1
Generazione nuova pair giocatore 2

Gameturn2:
Applicazione gravita' giocatore 1
Spostamento a destra giocatore 1
Spostamento a sinistra giocatore 1

Etc...

In questo modo la validazione degl'input viene fatta in locale e poi gli eventi risultati spediti in remoto, salvati nel log, o quant'altro ci venga in mente. Sostanzialmente voglio che questi eventi siano piu' ad alto livello dell'evento "pressione di un tasto".

Il replay sara' una cosa del tipo: leggi elenco degli eventi al gameturn x, applica gli eventi in ordine. Non serve InputReactor.

[cionci]

Hai guardato quelo che ho scritto nel post precedente ? Secondo me è l'unico modo per riprodurre fedelmente gli eventi...

[cionci]

Originariamente inviato da fek

Il replay sara' una cosa del tipo: leggi elenco degli eventi al gameturn x, applica gli eventi in ordine. Non serve InputReactor.

Va bene salvare le varie azioni degli event handler ?

Da abstractKeyEventHandler:

    private void execute(InputReactor inputReactor)
    {
        if(isKeyPressed())
        {
            executeWhenPressed(inputReactor);            
        }
        else
        {
            executeWhenReleased(inputReactor);
        }
        logger.writeEvent(this);
    }

Oppure basta semplicemente andare a scrivere una stringa da ogni handler (dentro a executeWhenPressed/Released dei vari handler)...

Ad esempio pensando ad una applicazione KISS si potrebbe andare a scrivere il valore di this.getClass().getCanonicalName() sul file di log...
Per riprodurre un evento basterebbe riuscire a recuperare l'handle in base a questa stringa (con un map, o visto che gli handle sono pochi anche scorrendoli tutti e confrontando i vari nomi)...

[Jocchan]

Come siamo messi per i task di questa storia?

[VICIUS]

Originariamente inviato da Jocchan

Come siamo messi per i task di questa storia?

Finché non finiamo i task di quello precedente non possiamo cominciare a smanettare con questo.

ciao

[cionci]

Cerchiamo anche di riformulare bene il task 10.2.2...
Come abbiamo appurato non possiamo contare i gameLoop perchè non sono di durata costante... IMHO bisogna contare o i cicli di update o i cicli di reazione agli input...

Magari se vi fidate posso occuparmi del task 10.2.3 in pair... Se vi va bene contatto nihil84 come compagno di pair...

[fek]

Originariamente inviato da cionci

Oppure basta semplicemente andare a scrivere una stringa da ogni handler (dentro a executeWhenPressed/Released dei vari handler)...

Ad esempio pensando ad una applicazione KISS si potrebbe andare a scrivere il valore di this.getClass().getCanonicalName() sul file di log...
Per riprodurre un evento basterebbe riuscire a recuperare l'handle in base a questa stringa (con un map, o visto che gli handle sono pochi anche scorrendoli tutti e confrontando i vari nomi)...

Hmmm... prova. Non ho ancora chiaro il problema e il codice, perche' e' piu' di una settimana che non riesco a guardare il codice, quindi non saprei davvero dire di piu'. Ho in mente una soluzione ideale, o meglio quello che mi piacerebbe vedere, ma ha poco senso se non ho il codice davanti e se poi al codice la soluzione ideale non piace.

Per ora implementa la cosa piu' semplice che ti passa per la testa e farla funzionare. Appena torno dal tour de force faccio do' una ripassata al problema e vediamo che succede.

[VICIUS]

Dunque mi sono pigliato il primo task. Appena chiudiamo il ciclo precedente inizio.

cionci ti ho assegnato il secondo task se qualcuno si offre volontario bene altrimenti cominciamo anche da soli.

ciao

[cionci]

Ok...ma io volevo fare il 3° Anche se il secondo è legato a doppio nodo al 3°...

[VICIUS]

Originariamente inviato da cionci

Ok...ma io volevo fare il 3° Anche se il secondo è legato a doppio nodo al 3°...

Oops!
Correggo subito.

ciao

[cionci]

Al limite posso fare anche quello in pair programming con nihil84...che tra l'altro ha accettato...quindi confermo il pair...

[Jocchan]

Dopo aver parlato con Cionci su MSN, ho segnato i task 2 e 3 in pair tra lui e nihil.

[cionci]

Per il task 10.2.2, acceptance test:

ogni volta che viene eseguita la GridController.reactToInput il contatore deve essere incrementato di 1

[VICIUS]

Task 1 completato anche se c'è ancora un po di duplicazione nel codice di TestGameLoop e GameLoop. Per ora lascio cosi anche se ho in mente un giochino con le interfaccie.

ciao

[cionci]

Help...ragazzi serve un pair programmer... Io devo andare via e mi sa che non posso lavorarci per il fine settimana... C'è qualcuno che può aiutare nihil84 per completare il task ?

[Jocchan]

Fatevi sotto, che manca davvero poco.

[nihil84]

Uff...

Ho finito... almeno credo Mi hanno lasciato solo tutti

La build e' verde ma prima di fare il commit voglio farvi vedere un esempio di esecuzione, se vi va bene rilascio, altrimenti faccio le modifiche richieste.

Ecco una porzione del log salvato:

seed 1140287050143313000

1
pair boxes/topaz boxes/sapphire

106
it.diamonds.handlers.DropCommandHandler 1

109
it.diamonds.handlers.DropCommandHandler 1

111
it.diamonds.handlers.DropCommandHandler 1

112
it.diamonds.handlers.DropCommandHandler 0

114
pair boxes/topaz ruby

116
it.diamonds.handlers.MoveLeftCommandHandler 1

ah, una domanda. Come faccio a spostare LogTest da it.diamonds.tests.ignore a it.diamonds.tests? ci dovrebbe essere un qualche metodo automatico, no?

[VICIUS]

Originariamente inviato da nihil84

Uff...

Ho finito... almeno credo Mi hanno lasciato solo tutti

La build e' verde ma prima di fare il commit voglio farvi vedere un esempio di esecuzione, se vi va bene rilascio, altrimenti faccio le modifiche richieste.

Ecco una porzione del log salvato:

seed 1140287050143313000

1
pair boxes/topaz boxes/sapphire

106
it.diamonds.handlers.DropCommandHandler 1

109
it.diamonds.handlers.DropCommandHandler 1

111
it.diamonds.handlers.DropCommandHandler 1

112
it.diamonds.handlers.DropCommandHandler 0

114
pair boxes/topaz ruby

116
it.diamonds.handlers.MoveLeftCommandHandler 1

ah, una domanda. Come faccio a spostare LogTest da it.diamonds.tests.ignore a it.diamonds.tests? ci dovrebbe essere un qualche metodo automatico, no?

Basta semplicemente trascirare il file da un package all'altro usando eclipse

ciao

[VICIUS]

Da quello che ho capito il task è finito quaindi possiamo considerare anche il ciclo terminato. Confermate ?

ciao

[cionci]

Sì...stiamo correggendo qualche bug e stiamo facendo un po' di refactoring...