If I had given this question any other title it would have immediately looked like a dupe of this one. Although that has some nice ideas none of the answers actually address what I need.
I'm refactoring my game state system a bit. I already have a stack system, not to share data, but so you can leave a pause menu and return to gameplay as it was. There is also a transition type that clears the stack completely, so you can go from the title, to a menu, to in game, and those aren't stacked on each other.
I have three big state types (handlers) right now: gameplay, menus, and cutscenes. The latter two have a lot in common so they share a base class. I'm stuck right now because of how they handle entities (gameplay objects), which all three can use.
Many games have cutscenes that don't leave gameplay, they just take control and start puppeteering the characters currently on the screen. My handlers currently have their entities separate from each other, and there's no data sharing. The only affect they can have on each other is deciding whether the previous one should keep updating / drawing or not. I need to refactor things so that I can support that kind of cutscene when it's pushed on top of the gameplay state.
How should I organize my states so that they can share entities? I'm considering splitting my handlers in half, one side to hold objects, the other for logic to manipulate those. Then I could mix and match them, or just swap one logic for another without changing out the data. Will this work? Maybe another approach is better.
Again, I know this sounds a lot like the other question but those answers were either things I'm already doing or didn't match my situation.
No comments:
Post a Comment