[CICLO 5] Storia 2

[Jocchan]

Storia 2: Creazione di una nuova gemma quando la precedente tocca il fondo o una gemma sottostante (emissione del bip in entrambi i casi), con rilevamento delle collisioni tra le gemme presenti nell’area di gioco (non sarà possibile spostare la gemma in una casella già occupata da un'altra). Introduzione di un contatore per il punteggio del giocatore, inizializzato a zero, capace di assumere valori validi di 8 cifre e mostrato su schermo mediante una png contenente le cifre nelle 10 caselle che la compongono.
Ogni volta che un diamante collide con il fondo (o con una gemma al di sotto di esso) il contatore del punteggio viene incrementato di 1.

Punti cardine da tenere a mente durante i lavori:

• Mai fare a gara a chi finisce il task per primo, meglio procedere con calma, altrimenti perderemo molto più tempo in seguito
• Evitiamo di complicarci la vita, esiste di certo una soluzione più semplice di quella che abbiamo pensato di implementare
• MAI aggiungere elementi non richiesti esplicitamente dai task: se mai serviranno, se ne parlerà nelle prossime storie
• Comunichiamo il più possibile, se qualcosa non è chiaro discutiamone tutti i dettagli fino ad eliminare ogni dubbio, anche il più insignificante

[VICIUS]

Task:
5.2.1: Cionci: completato
Quando la gemma collide con il bordo inferiore dell'area di gioco ne deve essere creata una nuova nella parte superiore che diventa quella gestita tramite input da tastiera.
5.2.2: Cover + TigerShark: completato
Modificare Grid in modo che lo spostamento verticale della gemma sia fermato se la casella della riga sottostante è gia occupata. (solo pair programming)
5.2.3: DanieleC88: completato
Impedire lo spostamento laterale della gemma se la casella nella colonna di destinazione è occupata. (solo pair programming)
5.2.4: 71104: completato
Aggiungere la possibilità di disegnare un numero intero di massimo 8 cifre usando la clase Sprite e come base una texture.
5.2.5: Vifani: completato
Visualizzare nella casella dello score presente alle coordinate 219x421 il numero di diamanti presenti all'interno della griglia. Ogni cifra deve essere distanziata dall'altra 11 pixel.

ciao

[fek]

5.2.2 va svolto in Pair Programming.

[cover]

Io sarei tentato per il 5.2.2 per provare pair programming...se c'è qualcuno disposto, e con tanta pazienza
chi si offre volontario ? fek ?

Sperando di non aver scelto il task più difficile / con più complicazioni ^^

[fek]

La mia prossima vittima programmata sara' cionci

Ora preferisco che proviata a fare Pair Programming fra di voi.

[^TiGeRShArK^]

ci proviamo insieme cover???
x me andrebbe bene domani e dopodomani dopo le 19.00.....
certo ke se magari ci seguono gli altri mentre scriviamo è pure meglio!

EDIT: ma non dovremmo aspettare che il task 1 sia implementato prima???

[cionci]

Originariamente inviato da fek

La mia prossima vittima programmata sara' cionci

Purtroppo nemmeno questa settimana lo posso fare... Sono occupato praticamente tutte le sere

Avrei una domanda sul 5.2.3: supponendo che la gemma si trovi nella cella [Y, X]...e la cella [Y+1, X+1] contenga una gemma... La gemma in [Y,X] si trova all'inizio della cella (ricordiamoci che l'hot spot è in alto a destra)... Vengono svolti diversi update in cui al gemma si sposta verso il basso, ma rimane ancora in [Y, X]... Viene premuto il tasto sx, la gemma in questo caso non si deve spostare nella casella [Y, X+1] perchè andrebbe a collidere lateralmente, ma solo dal punto di vista grafico, non dal punto di vista della cella, con la gemma in [Y+1, X+1]...
E' giusto questo comportamento ? Quindi non solo bisogna controllare che non ci siano collisioni con le gemme nelle caselle adiacenti lateralmente, ma che non ci siano anche nelle diagonali inferiori se la gemma non si trova all'inzio della cella...

Direi che se si aggiunge anche questo punto di vista il task 5.2.3 diventa più complesso del 5.2.2...e quindi direi che sarebbe meglio fare questo in pair programming...

Quindi per motivi di tempo io prenderei quello dei due che non si svolge in pair programming...
Quali sono le priorità fra i task ?

[cionci]

Originariamente inviato da ^TiGeRShArK^

ci proviamo insieme cover???
x me andrebbe bene domani e dopodomani dopo le 19.00.....
certo ke se magari ci seguono gli altri mentre scriviamo è pure meglio!

EDIT: ma non dovremmo aspettare che il task 1 sia implementato prima???

Non importa perchè le gemme le potete inserire voi a mano (insertGemAt)

[fek]

Originariamente inviato da cionci

Purtroppo nemmeno questa settimana lo posso fare... Sono occupato praticamente tutte le sere

Avrei una domanda sul 5.2.3: supponendo che la gemma si trovi nella cella [Y, X]...e la cella [Y+1, X+1] contenga una gemma... La gemma in [Y,X] si trova all'inizio della cella (ricordiamoci che l'hot spot è in alto a destra)... Vengono svolti diversi update in cui al gemma si sposta verso il basso, ma rimane ancora in [Y, X]... Viene premuto il tasto sx, la gemma in questo caso non si deve spostare nella casella [Y, X+1] perchè andrebbe a collidere lateralmente, ma solo dal punto di vista grafico, non dal punto di vista della cella, con la gemma in [Y+1, X+1]...
E' giusto questo comportamento ? Quindi non solo bisogna controllare che non ci siano collisioni con le gemme nelle caselle adiacenti lateralmente, ma che non ci siano anche nelle diagonali inferiori se la gemma non si trova all'inzio della cella...

Direi che per ora ignoriamo il problema e vediamo come si comporta il gioco. Poi Jocchan ci dira' esattamente come comportarci in questa situazione, quando potra' provarla direttamente.

Quindi per motivi di tempo io prenderei quello dei due che non si svolge in pair programming...
Quali sono le priorità fra i task ?

Le priorita' sono in ordine di numerazione dei task.

[cionci]

Allora mi prenoto per il 5.2.3, potrei fare anche il 5.2.1, ma fino a mercoledì pomeriggio/giovedì non ho un briciolo di tempo Quindi se nessuno se lo accolla entro domani sera magari ci posso pensare io, lasciando il 5.2.3 ovviamente...

[fek]

Originariamente inviato da cionci

Allora mi prenoto per il 5.2.3, potrei fare anche il 5.2.1, ma fino a mercoledì pomeriggio/giovedì non ho un briciolo di tempo Quindi se nessuno se lo accolla entro domani sera magari ci posso pensare io, lasciando il 5.2.3 ovviamente...

Ottimo

[71104]

il 5.2.4 sembra carino, mi prenoto
dubbi: va disegnato uno sprite per ogni cifra o tutto il numero va in un unico sprite? (propongo la prima...)
stima, be', bu, boh, facciamo 1 giorno a partire dal termine del task per cui mi sono prenotato alla Storia 1.

PS: per non scrivere valori costanti nel codice direi di inserire il valore degli 11 pixel in config come "digitSpacing".

[VICIUS]

Originariamente inviato da 71104

il 5.2.4 sembra carino, mi prenoto
dubbi: va disegnato uno sprite per ogni cifra o tutto il numero va in un unico sprite? (propongo la prima...)
stima, be', bu, boh, facciamo 1 giorno a partire dal termine del task per cui mi sono prenotato alla Storia 1.

PS: per non scrivere valori costanti nel codice direi di inserire il valore degli 11 pixel in config come "digitSpacing".

Tutto tuo.

ciao

[fek]

Originariamente inviato da 71104

il 5.2.4 sembra carino, mi prenoto
dubbi: va disegnato uno sprite per ogni cifra o tutto il numero va in un unico sprite? (propongo la prima...)
stima, be', bu, boh, facciamo 1 giorno a partire dal termine del task per cui mi sono prenotato alla Storia 1.

L'idea e' che le cifre da 0 a 9 sono conservate in una texture in posizioni che Jocchan ti comunichera'. Tu crei 10 sprite (uno per ogni cifra) che prendono le informazioni dalla texture e disegni gli sprite corretti a seconda del numero da visualizzare nella posizione corretta.

Tutto testato ovviamente. Mi raccomando la test list prima di iniziare.

PS: per non scrivere valori costanti nel codice direi di inserire il valore degli 11 pixel in config come "digitSpacing".

Per ora attieniti al task

[cionci]

Per il 5.2.1, caso mai lo facessi io: dal punto di vista della metodologia di sviluppo, è più coerente sviluppare una nuova classe che gestisce l'inseriemnto e l'arrivo in fondo della gemma controllata oppure ampliare Grid ?

[fek]

Originariamente inviato da cionci

Per il 5.2.1, caso mai lo facessi io: dal punto di vista della metodologia di sviluppo, è più coerente sviluppare una nuova classe che gestisce l'inseriemnto e l'arrivo in fondo della gemma controllata oppure ampliare Grid ?

E' una decisione tua questa e dipende dalla tua sensibilita'.

Ti posso dire quello che farei io. Io scriverei la cosa piu' semplice che mi viene in mente, quindi scriverei subito dentro Grid. Una volta finito il task guarderei Grid e e come il codice si e' evoluto e cercherei di capire come vuole essere strutturato meglio. Quindi cercherei possibilita' di refactoring ed un refactoring possibile e' quello di estrarre comportamenti comuni in una nuova classe.

Grid sta crescendo e prima o poi dovremo prenderne atto e alzare il suo livello di astrazione, quindi estrarre delle classi e definire il comportamento di Grid in termini di composizione di queste classi.

Da fare subito? Dopo? Non saprei dirtelo, anche qui sta alla vostra sensibilita'.

Tutto sto discorso per dirti: decidi tu

[Jocchan]

In realtà noi dobbiamo considerare ogni gemma come un quadrato 32x32, indipendentemente dalla forma che poi avrà.
Questo significa che, se è nota la coordinata (x, y) dello spigolo in alto a sinistra, possiamo ricavare quelle degli altri tre semplicemente aggiungendo il valore 32 alle coordinate:
- spigolo in alto a destra -> (x+32, y)
- spigolo in basso a sinistra -> (x, y+32)
- spigolo in basso a destra -> (x+32, y+32)
Sia chiaro che mi riferisco ad uno schema con l'origine degli assi in alto a sinistra, che dovrebbe essere unico per tutto il nostro progetto (così come il posizionamento dell'hot spot che, per quanto ne so, si trova anch'esso in alto a sinistra di ogni oggetto).

Il rilevamento delle collisioni implica che questi quadrati in movimento non vengano mai sovrapposti, nemmeno di un pixel. Avendo a disposizione le coordinate di tutti e quattro gli spigoli, comunque, non dovrebbe essere troppo complesso.

[fek]

Originariamente inviato da Jocchan

Il rilevamento delle collisioni implica che questi quadrati in movimento non vengano mai sovrapposti, nemmeno di un pixel. Avendo a disposizione le coordinate di tutti e quattro gli spigoli, comunque, non dovrebbe essere troppo complesso.

In realta' per ora il discorso e' ancora piu' semplice perche' abbiamo una rappresentazione ad alto livello che e' la Griglia. Non abbiamo bisogno di controllare la sovrapposizione degli sprite, ci basta controllare che la cella sotto o al nostro lato non sia gia' occupata e impedire il movimento o bloccare la caduta.

[cionci]

Originariamente inviato da Jocchan

Sia chiaro che mi riferisco ad uno schema con l'origine degli assi in alto a sinistra, che dovrebbe essere unico per tutto il nostro progetto (così come il posizionamento dell'hot spot che, per quanto ne so, si trova anch'esso in alto a sinistra di ogni oggetto).

Sì...ho scritto male.. Intendevo in alto a sinistra

[Jocchan]

Originariamente inviato da fek

In realta' per ora il discorso e' ancora piu' semplice perche' abbiamo una rappresentazione ad alto livello che e' la Griglia. Non abbiamo bisogno di controllare la sovrapposizione degli sprite, ci basta controllare che la cella sotto o al nostro lato non sia gia' occupata e impedire il movimento o bloccare la caduta.

Benissimo, meglio ancora
Ovviamente se abbiamo una gemma in (x, y) ed una casella (x+1, y+1) occupata, potremo liberamente muoverci in (x+1, y) nella sua interezza: la collisione verticale verrà valutata solo quando fisicamente le due gemme andranno a toccarsi (cioè sarò ancora in grado di spostare la gemma un istante prima del contatto, per incastrarla da qualche altra parte).
Per le collisioni orizzontali, visto che si salta istantaneamente da una casella all'altra, e non bisogna considerare caselle riempite solo parzialmente dalla gemma in caduta, il concetto è ancora più semplice