Skip to content

Motore di gioco

drblallo edited this page Apr 12, 2018 · 3 revisions

Al fine di poter essere mantenuto sincronizzato attraverso la rete, esso deve soddisfare le seguenti caratteristiche

schema a comandi

Il gioco non deve offrire setter pubblici, solo getter e callback. Tutte le modifiche al gioco devono avvenire tramite azioni. Tali azioni devono poter essere serializabili, poiché sono esse a venire trasferite attraverso la rete.

costruttore vuoto

Una volta costruito, lo stato del gioco dovrebbe essere equivalente a quello del gioco da tavola ancora non preparato. È tramite comandi che si seleziona il numero di giocatori, si imposta il seed e si caricano le schede customizate

nessun float

Non dovrebbe essere necessario utilizzare numeri reali. L'uso esclusivo di interi garantisce l'assenza di problemi platform dependant.

reimplementare hashcode()

Poiché è necessario controllare che lo stato del gioco sia corretto, è necessario reimplementare la funzione hashcode, in modo che o campi che non devono essere condivisi, quali le callback e i puntatori, non vengano inclusi nel calcolo.

nessuna operazione randomica

Tutte le operazioni casuali, come il lancio dei dadi, deve essere eseguito tramite operazioni pseudo randomiche platform independent. Il seed del generatore deve poter essere impostato da un azione, tale azione deve essere la prima azione ricevuta dal gioco.

tutti i componenti istanziati durante la costruzione, nessun componente rimosso

Al fine di semplificare il bidind della View al gioco, tutti i componenti di gioco devono esistere per tutta la durata del gioco. Ad esempio i dadi devono già tutti esistere nel sacchetto e da la essere trasferiti

divisione dell'azione di selezione del dado e del piazzamento

Alcune carte indicano che possono essere selezionate dopo aver selezionato un dado, ma prima di averlo piazzato. Per questo motivo è utile dividere in due l'azione di piazzamento. Ciò semplifica enormemente l'implementazione del delle carte.

Clone this wiki locally