|
|||||||
|
|
|
![]() |
|
|
Strumenti |
|
|
#1 |
|
Senior Member
Iscritto dal: Nov 2005
Messaggi: 1545
|
Grid e GridController
Arrivati a questo punto noto che Grid fa davvero molte cose...
Secondo me sarebbe una buona idea cominciare a separare i comportamenti strettamenti legati al concetto di "Griglia contentente delle gemme" dai vari concetti di "crush, creazioneBigGem, scoring, Stone etc...". Parlando di GridController, invece, il codice mi sembra parecchio complicato... Cosa ne dite di organizzare una sessione di refactoring? Potrei offrirmi per un pair nei prossimi giorni |
|
|
|
|
|
#2 |
|
Senior Member
Iscritto dal: Dec 2000
Città: bologna
Messaggi: 1309
|
beh in grid di logica per le crush ce ne è ormai ben poco(sta in abstractCrushAction and soon), cmq secondo me in grid sarebbe da togliere l'opponentGrid(che ora non fanno nulla, l'ho tolta e non ha dato errori), i restanti metodi me sembrano metodi di utilita e accesso alla griglia. Forse si potrebbero riorganizzare alcuni metodi per evitare ripetizioni di codice, ma non sono sicuro ce ne sia bisogno)
per gridController la gestione dell'update è abbastanza incasinata e si potrebbe cercare un modo per semplificarla(anche se al volo non me ne viene in mente nessuno). |
|
|
|
|
|
#3 | |
|
Senior Member
Iscritto dal: Nov 2005
Messaggi: 1545
|
Quote:
|
|
|
|
|
|
|
#4 | |
|
Senior Member
Iscritto dal: Jul 2005
Città: Silent Hill
Messaggi: 1471
|
Quote:
Poi, con qualche refactoring, la cosa un pò si è sistemata. Se la situazione è tornata come prima, allora urge un bel refactoring.
__________________
DIAMOND CRUSH - Aut viam inveniam, aut faciam. |
|
|
|
|
|
|
#5 |
|
Senior Member
Iscritto dal: Oct 2001
Messaggi: 11471
|
Me ne ero accorto anche io infatti volevo proporlo come storia di servizio ma visto che abbiamo ancora dei task da finire nella storia precedente dovremo rimandare.
Grid deve delegare in qualche modo tutta la gestione della logica ad altri. Si può pensare di usare observer per lanciare qualche evento che poi verrà gestito da queste classi. ciao |
|
|
|
|
|
#6 |
|
Senior Member
Iscritto dal: Nov 2005
Città: Bologna
Messaggi: 1303
|
Infatti...
...non so perchè ma nel nostro bel progetto di eventi se ne vedono proprio pochi. Eppure in un game a me sembra quasi ovvio pensare che la maggior parte delle azioni sia dovuta a determinati eventi. Forse dovremmo ristrutturare un po' il codice in questa ottica. Non so se sembra anche a voi, ma le varie sottoclassi di GemAction ricordano un po' dei gestori di eventi |
|
|
|
|
|
#7 | |
|
Senior Member
Iscritto dal: Oct 2001
Messaggi: 11471
|
Quote:
ciao |
|
|
|
|
|
|
#8 |
|
Senior Member
Iscritto dal: Nov 2005
Messaggi: 1545
|
Ha ragione VICIUS. Non esageriamo con le idee.
Ci serve solo rendere il codice più leggibile e rendere più facile lo svolgimento dei task. Inoltre il refactoring è reso difficile dalla discreta quantità di codice non testato presente in molte parti del codice. Questo è un problema molto più grande che avere un'architettura Event-Driven |
|
|
|
|
|
#9 |
|
Senior Member
Iscritto dal: Nov 2005
Città: Bologna
Messaggi: 1303
|
Verissimo Ufo...
...prima avremo la copertura la 100% prima potremmo fare dei refactoring anche stravolgenti !!! |
|
|
|
|
|
#10 |
|
Senior Member
Iscritto dal: Nov 2005
Messaggi: 1545
|
Allora iniziamo ad aggiungere qualche test?
Se guardi in Thread dei Problemi manca un test per la condizione di GameOver in GameLoop |
|
|
|
|
|
#11 |
|
Senior Member
Iscritto dal: Nov 2005
Città: Bologna
Messaggi: 1303
|
Volentieri...se potessi mettere le mani sul codice.
L'obiettivo delle prossime settimane è collaborare aggiungendo ogni volta che posso un piccolo test |
|
|
|
|
| Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 02:32.



















