[CICLO 6/bis] Xmas Carol Story 2

[thebol]

Originariamente inviato da fek

Secondo me non serve neppure derivare PivotGem. Esci dal loop in cui ti sei infilato, questo task e' molto piu' semplice di quanto pensi. Fallo in PP con Ufo e fatelo sulla linea di guida di non derivare nulla. Non serve.

io che faccio rilascio parte del task, loro fanno il task poi io adatto il mio?

[fek]

Originariamente inviato da thebol

io che faccio rilascio parte del task, loro fanno il task poi io adatto il mio?

Finisci il tuo task, loro partono col refactoring del tuo task e poi implementano il loro.

[Jocchan]

Originariamente inviato da Ufo13

hmmm mi va benissimo farlo in pair con cionci ed inizierei anche subito, ma non è meglio se aspettiamo che vicius confermi il task?

Dopo un veloce consulto con fek, direi che potete iniziare anche subito
I limiti del task sono chiari?

[Ufo13]

A sto punto credo che io e cionci dovremmo semplicemente implementare la classe GemsPair e thebol i controlli su di essa (collisioni e movimenti, ovviamente rotazioni escluse)

[Ufo13]

cionci se confermi iniziamo

[thebol]

Allora ridefinisco i limiti del mio task
-inserimento di 2 gemme(DO)
-gravità su entrambe le gemme(DO)(in configurazione pivot[1,4] slave[0,4])
-funzionamento downkey(venuto gratis dal sottotask precedente)(DO)
-Movimento di entrambe le gemme a sx e dx (in configurazione pivot[1,4] slave[0,4])(DO)
-Collisione a sx a dx e in basso (in configurazione pivot[1,4] slave[0,4])(TODO)
-init del gioco con 2 gemme e creazione di 2 gemme quando raggiungono il fondo(TODO)

Se volete ovviamente gestisco tutte le collisioni e i movimenti , ma dopo il refactoring del gempair magari è meglio

[Ufo13]

hmmm aspetto qualcuno che si confermi per il pair e parto subito

nessuno?

[cionci]

Non posso farlo in pair programming, sono occupato in questi giorni...

[thebol]

E ora le collisioni...

    public void testMoveTwoGemLeftWithCollisionOfEach()
    {
        grid.insertGemUnderControl(1, 0, gem1);
        grid.insertGemAsSlave(2,0,gem2);

        input.generateKey(KeyCode.vk_Left, timer.getTime());
        inputReactor.reactToInput();

        assertEquals("Gem pivot must not move to the left", grid.getGemAt(1, 0), gem1);
        assertEquals("Gem slave must not move to the left", grid.getGemAt(2, 0), gem2);

    }

e relativo per desta.

    public void testMoveTwoGemRightWithCollisionOfEach()
    {
        grid.insertGemUnderControl(1, GRID_COLUMNS - 1, gem1);
        grid.insertGemAsSlave(2, GRID_COLUMNS - 1, gem2);

        input.generateKey(KeyCode.vk_Right, timer.getTime());
        inputReactor.reactToInput();

        assertEquals("Gem pivot must not move to the right", grid.getGemAt(1, GRID_COLUMNS - 1), gem1);
        assertEquals("Gem slave must not move to the right", grid.getGemAt(2, GRID_COLUMNS - 1), gem2);

    }

I test passano senza modifiche, dato il fatto che le gemme sono incolonnate(in altre configurazioni probabilmente non sara cosi).


e ora la collisione in basso (aka bloccare le gemme dalla caduta per gravita)

    public void testTwoGemIsNotFalling()
    {      
        grid.insertGemUnderControl(GRID_ROWS - 1, 0, gem1);
        grid.insertGemAsSlave(GRID_ROWS - 2, 0, gem2);
        grid.update();

        assertTrue(gem1.isNotFalling());
        assertTrue(gem2.isNotFalling());
    }

questo fallisce \o/ ma modificando la update di grid

        if(gemCantMoveDown(getGemUnderControl()))
        {
	[...]
            if (getGemSlave() != null){
               getGemSlave().dropGem();

            }
        }

[NB manca l'align e il bright, lo faccio io o famo in un altro task?]


build verde ora si passa all'inserimento all'inizio delle 2 gemme, e durante il gioco

[Ufo13]

beh appena si offre qualcuno parto (fek? )... Sennò posso anche farlo non in pair

[thebol]

a questo punto, si potrebbe incominciare a metter insertTwoNewGem(); al posto di insertNewGem nel costruttore di grid.

    public void testTwoGemInsertion()
    {
        assertNotNull("no gem Pivot inserted in grid after creation",
            grid.getGemUnderControl());
        assertNotNull("no gem Slave inserted in grid after creation",
            grid.getGemSlave());    
    }

e implementazione

   public Grid(Rectangle bounds, Config config, GemGenerator gemGenerator)
    {
	     [...]

	//insertNewGem();
	insertTwoNewGem();
    }

Ma questo rompe assai la build, ma basta cambiare il createForTesting di grid in maniera che rimuova anche la gemma slave da grid e torna ad andare tutto

    public static Grid createForTesting(GemGenerator gemGenerator)
    {
        Grid grid = new Grid(new Rectangle(40, 40, 295, 487), Config
            .createForTesting(), gemGenerator);

        grid.removeGemFromGrid(grid.getGemUnderControl());
        grid.removeGemFromGrid(grid.getGemSlave());
        grid.gemUnderControl = null;
        grid.gemSlave = null;
        grid.empty = true;

        return grid;
    }

ora manca che a quando le gemme raggiungono il fondo, vengano create 2 gemme invece che 1

   public void testTwoNewGemInsertion()
    {
        grid.insertGemUnderControl(13, 4, gem1);
        grid.insertGemAsSlave(12,4,gem2);
        controller.update(timer);
        assertNotNull(grid.getGemUnderControl());
        assertTrue(gem1 != grid.getGemUnderControl());
        assertNotNull(grid.getGemSlave());
        assertTrue(gem2 != grid.getGemSlave());

    }

e implementazione

    private void handleWaitState(AbstractTimer timer)
    {
        if(timer.getTime() - timeBase >= delay)
        {
            if(isGameOver())
            {
                return;
            }

            //grid.insertNewGem();
            grid.insertTwoNewGem();
            waitState = false;
        }
    }

questo rompe da problemi a testAfterSecondDelay, ma basta spostare il piazzamento della gemma in 12,4(quello previsto dall'init) e tutto ridiventa verde

	controller.setDelay(300);
	grid.insertGemUnderControl(12, 4, gem1);
	controller.update(timer);
	[...]

[fek]

Secondo me Grid non deve sapere dell'esistenza di due gemme sotto controllo. Questo concetto deve essere esclusiva di GridControl. In altre parole vi avevo chiesto di non mettere nulla in Grid che non fosse strettamente necessario e questo non mi sembra il caso. Voglio essere molto draconiano su questo punto.

[thebol]

Originariamente inviato da fek

Secondo me Grid non deve sapere dell'esistenza di due gemme sotto controllo. Questo concetto deve essere esclusiva di GridControl. In altre parole vi avevo chiesto di non mettere nulla in Grid che non fosse strettamente necessario e questo non mi sembra il caso. Voglio essere molto draconiano su questo punto.

ti giuro che avevo fatto lo stesso pensiero.

solo che essendo la gemundercontrol in grid, ho preferito mantenere per ora il fatto delle 2 gemme in grid, aspettando(e proponendo) di spostare le gemme controllate in gridcontroll per il refactoring di gemPairs

grid deve essere solo una griglia dove inserire gemme, e che dia responsi se una gemma e spostabile o no, etc.


ora aggiungo un test per verificare che anche la seconda gemma contribuisca al brighten, poi faccio merg e committo il tutto.

[fek]

Prima di fare il commit puoi togliere il concetto di coppia di gemme da Grid?

[Ufo13]

A proposito di Grid e Gem... Secondo me la classe Cell non dovrebbe stare dentro Gem...

[thebol]

Originariamente inviato da fek

Prima di fare il commit puoi togliere il concetto di coppia di gemme da Grid?

ok, tolgo proprio gemundercontrol e gemslave e le sposto(con relative logiche) in gridcontroll.

speriamo sia abbastanza indolore

[cionci]

Originariamente inviato da Ufo13

A proposito di Grid e Gem... Secondo me la classe Cell non dovrebbe stare dentro Gem...

Secondo me sì... Prima era in Grid ed in pratica mettendola dentro Gem abbiamo eliminato una grande quantità di codice (ad esempio un funzione chiamata findGemCell che trovava la posizione di una Gem all'interno di grid scorrendo tutta la matrice)...
Inoltre il fatto che stia dentro Gem è logicamente corretto: una Gem sta in una data posizione e Cell (magari il nome non è il massimo) ne indica la posizione...

[Ufo13]

Sono d'accordissimo che la gemma ha una posizione dentro la griglia però, a parer mio, il concetto di Cell (vista come elemento di Grid) ed il concetto di Gemma sono abbastanza separati da giustificare l'indipendenza della classe Cell (e non un oggetto Cell) da Gem...

Se proprio non vi piace la classe Cell separata... Perchè non spostarne la dichiarazione dentro Grid invece che dentro Gem?

[cionci]

Originariamente inviato da Ufo13

Se proprio non vi piace la classe Cell separata... Perchè non spostarne la dichiarazione dentro Grid invece che dentro Gem?

Era già dentro Grid...spostarla in Gem ha semplificato notevolmente il design... Magari come dicevo si potrebbe rinominare...

[Ufo13]

Secondo me il design ne è compromesso... Anche rinominandola continui ad avere dentro la classe Gem una classe che non c'entra con Gem...

Puoi benissimo tenere Cell in Grid e lasciare tutto com'è

cambia una sola riga in Gem.java:

private Cell cell;

diventa:

private Grid.Cell cell;