8

Sono uno sviluppatore esperto nello sviluppo di giochi e ho realizzato un gioco platform 3D abbastanza semplice ma funzionante e sto cercando modi per rendere l'architettura più scalabile.Quali sono le buone tecniche per gestire lo stato e il cambiamento di stato nello sviluppo del gioco?

Qual è un buon modo per gestire lo stato nello sviluppo del gioco?
Un approccio molto ingenuo è quello di avere più booleani come:

time_stopped = True 
time_slow_motion = False 
level_loaded = True 
level_paused = True 
level_completed = False 

Questo è molto poco flessibile in quanto un errore di sviluppatore potrebbe portare a time_stopped = True e time_slow_motion = True, allo stesso tempo, che avrebbe distrutto logica di gioco.

sto cercando un approccio migliore in direzione di:

class TimeState: 
    STOPPED = 0 
    SLOW_MOTION = 1 
    NORMAL = 2 
    current_state = 0 

    def isStopped(self): 
     if current_state == self.STOPPED: return True 

Ma come avrei gestire più gruppi di Stato in senso buono? Potrei creare un LevelState con stati LOADED, PAUSED e COMPLETED. Ma come faccio a gestire gruppi sovrapposti come quando LevelState e TimeStatePAUSED dovrebbero essere sempre gli stessi? Esiste un buon modello di progettazione o una buona pratica su come risolvere la gestione dello stato?

Che cos'è un buon modo per gestire il cambio di stato?
I miei pensieri sono di dare l'oggetto stato ad es. LevelState funzioni di callback da eseguire in ogni cambio di stato dato o per eseguire il polling dell'oggetto stato ogni ciclo di gioco come if level_state.changedTo() == LevelState.COMPLETED: doStuff(). Ci sono modi migliori per gestire questo? Messaggi in coda/eventi? Non voglio incorporare la logica negli oggetti di stato.
Sono interessato anche a gestire gli eventi changedFrom e changedTo e cosa succederebbe se la logica attivata da changedFrom modificasse lo stato dell'oggetto prima che venga attivata la logica changedTo - chi vince?

Non voglio implementazioni/risposte specifiche per lingua ma suggerimenti su un buon modo di pensare dal punto di vista dell'architettura.

+0

Utilizzare python set() e creare set, è possibile basare la logica su set.issubset(), ecc ... inoltre, credo che si voglia utilizzare il pattern di osservatore – pyInTheSky

+0

@pyInTheSky Grazie per aver evidenziato il pattern di osservatore! Sono a conoscenza di modi efficienti per codificare questo in python (anche se il gioco corrente è in C#), ma ho cercato di rendere gli esempi più leggibili di quelli veloci –

+2

se si desidera semplicemente una macchina a stati facile, ho postato questo su stato attivo: http: //code.activestate.com/recipes/577693-dynamically-generated-python-state-machine/ :: l'ho modificato ma non ripubblicato, puoi facilmente cambiarlo per restituire una tupla e avere una funzione run() che agisce come arbitro, quindi non costruisce un gigantesco stack di chiamate. Ci sono anche altre mod che non ho caricato, come chiedere al sm di rigenerarsi da solo se aggiungi uno stato, ecc ... ma è molto semplice e forse ti può aiutare – pyInTheSky

risposta

2

Questa è una cosa così comune che v'è anche un modello: The State Pattern

All'inizio, sembra che questo approccio ha un certo overhead, ma come la logica diventa più complicato vedrete i benefici.

+0

Grazie per aver segnalato il pattern di stato.Ovviamente l'ho trovato tramite google, ma mi chiedo se ci sono variazioni/espansioni di esso che corrispondono meglio allo sviluppo del gioco (dato che è molto generale/semplice). Sono anche interessato a come posso gestire il cambio di stato e gruppi di stati sovrapposti. –