Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

To be honest, I'd consider a "cutscene" to be mostly an AI routine, not a game state. When the cutscene starts, you push a very thin gamestate on top that does little more than add a visual effect you want (letterboxing is traditional) and prevent the player's controls from going through. Then you just override the AI of the entities and start dancing them around as needed. I'd leave all the entities owned by the gameplay state itself - the cutscene really isn't taking over ownership, and complex ownership semantics are begging for subtle bugs.

share|improve this answer
There are other cutscenes like the intro scenes with text, music, and animation; are you saying this is a totally different type of cutscene and they should be considered separate? – Tesserex May 12 '12 at 15:28
Yeah, I think it would be reasonable to make a distinction between "ingame cutscene" and "out-of-game cutscene". Even if the two aren't distinct, I think there's a clear distinction between a cutscene that moves ingame entities around, rendered with the ingame renderer, and a cutscene that plays a canned image/animation/music sequence. At the closest, those are two quite different parts of a "cutscene" - the ingame stuff could be handled via AI as I'm suggesting, the out-of-game stuff could be rendered via your existing game state system. – ZorbaTHut May 13 '12 at 11:14

Would it not be possible to establish a communication system between your handlers, where one handler can query for another handlers entity? Be sure to keep it as simple as possible so it does not turn into an over-complicated-mess. You could have handlers query for entity types(if any) or Ids or move entities around between handlers? But on another note: When you say "states" I assume, that one state transitions to another? I.e. there are never two different states at the same time? Couldn't you make some kind of hand-over? i.e. During state-transition one state hands over all entities under it's control to the next state.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.