Class communication

State managers are used for what their name indicates, managing which state the application is in. Eeg. an IntroState does whatever is supposed to be your game's intro and when it's finished or the used presses a key, it puts another state into the state manager which is then activate - this might be a MainMenuState or something.

Some state managers have a stack of states instead of just the current state so they can be used eg. for that fancy weapon selection screen which needs its own state. It is simply pushed onto the state stack and when the user closes the weapon selection, it removes itself again, without needing to know whever it was called from a MultiPlayerGameState or SinglePlayerGameState.

-Markus-

Regarding inter-object communication, that's not so easy to say as there is no general solution on how it's done. I hope this is what you were asking for at all :D


Of course, an object should have pointers to other objects it is supposed to talk to. The tricky part is organizing your architecture in an elegant fashion, so that not every object needs to know every other object in the system.

Often, starting out with a hierarchical approach works best, eg. begin with writing something like a "Game" class that manages all the elements game, like the Player, Map/Level, items in it and so on. Then you "Player" object can just be given a pointer to the Game instance and will be able to access the Map/Level for collision detection or anything else. The player might have an inventory, which would become an object to which only the Player instance has a pointer. Go on like that and you will be able to build a simple object model for a small game.

Of course, as the tree grows larger, signals or callbacks, abstraction through polymorphism and so on start to play a role in decoupling your objects, but that's something which comes over time (and by reading books on OOP, OOA)

-Markus-