Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Game state communication.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Musikai   Members   -  Reputation: 138

Like
0Likes
Like

Posted 05 May 2013 - 03:14 PM

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.smile.png

 



Sponsor:

#2 ppodsiadly   Members   -  Reputation: 338

Like
4Likes
Like

Posted 05 May 2013 - 04:29 PM

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.


Edited by ppodsiadly, 05 May 2013 - 04:30 PM.


#3 Khatharr   Crossbones+   -  Reputation: 3040

Like
2Likes
Like

Posted 05 May 2013 - 10:49 PM

the Model-View-Controller pattern

 

This.

 

The state is only a view/controller of the model, not the model itself. To answer the examples in your question, the player's data and position, etc is stored in a separate object. The active state works by presenting all or part of that dataset to the user and by allowing the user/game-logic to alter that dataset. So when you open the map state the position information is already available in the shared dataset. When you leave the map state the information necessary to restart the gameplay state is sill available in the same dataset. When you open the menu the player stats are all in the shared dataset. The state simply renders that data in a user-readable format and reacts to the player's controls to navigate the menu options, etc.

 

An added advantage of this is that when it comes time to save or load the game, all the persistent data is in one place and can simply be serialized and dumped or loaded and deserialized.


Edited by Khatharr, 05 May 2013 - 10:53 PM.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

#4 Musikai   Members   -  Reputation: 138

Like
0Likes
Like

Posted 06 May 2013 - 10:04 AM

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?


Edited by Musikai, 06 May 2013 - 10:09 AM.


#5 Juliean   GDNet+   -  Reputation: 2741

Like
0Likes
Like

Posted 06 May 2013 - 10:27 AM

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.



#6 Musikai   Members   -  Reputation: 138

Like
0Likes
Like

Posted 06 May 2013 - 04:52 PM

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.



#7 NightCreature83   Crossbones+   -  Reputation: 3034

Like
0Likes
Like

Posted 07 May 2013 - 01:29 AM

Read this article as it explains what a statemachine is: http://www.gamedev.net/page/resources/_/technical/game-programming/state-machines-in-games-r2982

Read: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller to brush up on the MVS pattern.

 

Generally the MVC is implemented as three separate components(classes, systems, or whatever) that take to each other in the manner outlined in the wikipedia article. I implemented one for a space invader project in which the view controlled what the player saw, so the screens and stuff, the controller handled input for the player and the collision detection and send messages to the objects to update themselves with the collision response, the model(implemented as invader, player and laser/missile).


Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS