Jakie są dobre techniki radzenia sobie ze zmianami stanu i stanu w tworzeniu gier?

Question

Jestem doświadczonym programistą zajmującym się tworzeniem gier. Stworzyłem dość prostą, ale działającą grę platformową 3D i szukam sposobów na zwiększenie skalowalności architektury.

Jaki jest dobry sposób na radzenie sobie z rozwojem gier?
bardzo naiwne podejście jest mieć wiele wartości logicznych takich jak:

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

Jest to bardzo nieelastyczny gdyż błąd deweloper może doprowadzić do time_stopped = True i time_slow_motion = True w tym samym czasie, co zniszczy gra logiczna.

szukam lepszego podejścia w kierunku:

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

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

Ale jak będę obsługiwać wiele grup Stanu w dobry sposób? Mogłem utworzyć stany LevelState, które mają stany:. Ale jak obsługiwać nakładające się grupy, na przykład, gdy LevelState i TimeStatePAUSED powinny być zawsze takie same? Czy istnieje dobry wzór projektu lub dobra praktyka w zakresie rozwiązywania problemów związanych z zarządzaniem państwem?

Jaki jest dobry sposób na zmianę stanu?
Moje myśli są albo podać obiekt stanu np.. LevelState funkcje wywołania zwrotnego do wykonania przy dowolnej zmianie stanu - lub do odpytywania obiektu stanu w każdej pętli gry, np. if level_state.changedTo() == LevelState.COMPLETED: doStuff(). Czy są lepsze sposoby radzenia sobie z tym? Kolejki/zdarzenia wiadomości? Nie chcę osadzać logiki w obiektach stanu.
Interesuje mnie również, czy należy obsłużyć zarówno zdarzenia changedFrom i changedTo, jak i to, co się stanie, jeśli logika wywołana przez changedFrom zmieni stan obiektu przed wyzwoleniem logiki changedTo - kto wygra?

Nie chcę odpowiedzi na temat implementacji/języka, ale porady na temat tego, jak mądrze myśleć w kategoriach architektonicznych.

Answer 1

To jest takie coś wspólnego, że nie jest nawet wzór: The State Pattern

Na początku wydaje się, że to podejście ma pewne obciążenie, ale jako logika staje się bardziej skomplikowana, widać korzyści.