So i've been trying to make a game using a state machine/state pattern and im having trouble. So I have each state in its own class being managed by a state machine class (which is inherited by any class that needs multiple states). I've read many examples and tutorials on state machines but none of them seem to explain how the states communicate and share data.

I'l give some hypothetical game situations. What if, when playing an rpg you're in the "gameplay state" and you hit "M" to change to a "map view state", the map state is giong to need to know the players position in the world. What if you're in a "menu state" and change the games difficulty, then the "gampley state" would also need to know the new difficulty setting. If you're in an "inventory state" and you equip items then the "gameplay state" would need to know so it can display these new items on the player.

I dont know where this data should be stored and how it should be shared. If anyone knows a solution i would realy appreciate it.

I would divide states into two categories: application states and game states. Application states would have access only to the “core” subsystems, like window subsystem, sound subsystem, etc. Game would be one of these application states, however this state would also have its “substates” - game states. Game states would be initialised with a pointer to a Game/GameWorld/GameLevel/etc. Object.

That's one option. You could also use the Model-View-Controller pattern. When you look at a map you're just changing the way the world is shown to the user. Model would be the shared game data and game logic. View would be responsible only for rendering correct stuff on the screen. Controller would be responsible for reading input and deciding which View to activate.

Thanks for the help guys. So if i understand, the data should be stored in, and read from, a "Model". The state then acts as the View/Controller to alter and display the data?

So going with ppodsiadly's layout, say i have an Application state "Game" which has three substates. Would the "Game" state class act as the Model and store all the data to be accessed by each substate? Or should the Model be a seperate class entirely?

So going with ppodsiadly's layout, say i have an Application state "Game" which has three substates. Would the "Game" state class act as the Model and store all the data to be accessed by each substate? Or should the Model be a seperate class entirely?

No, the game state wouldn't be that model, it is the view and, depending on your implementation, probably also the controller. For starting, choose what fits best. I'm using a seperate controller class that is based on my gui, but you should start easy, MVC is something that could be a little hard to get right the first time.

"Model" should rather not be a seperate class eigther. MVC is a pattern, there does not need to explicitely exist a "model", "view", and "controller" class. For example, in my implementation, the "model" is an entity-component system. Each game state defines which entity systems it is going to use, therefore defining the "view". The entities themselfs is the "model", and they are shared between gamestates via an entity manager, thats allocated outside of the state system, with a reference being passed on to each new state.

Thanks Juliean. Might be a stupid question but what would an entity manager look like, and how do the states interact with it?

Maybe i'm just slow but im really struggling to get this. I'm still very much a begginer, the only game i've written is a 2d game of pong. I just want to get away from the messy switch statements i've been using for game states. It feels like this is the only thing stopping me from writing more complex games, but every time i ask a question, the answer creates ten more questions. Wish i could have a programer sit next to me so i could bore them to tears with my lack of understanding.