1
\$\begingroup\$

What are the possible ways of sharing different objects between game states?

Lets say a game has a couple of states (a menu state and a game state for example), at first the engine calls the menu state's load function which loads menu textures, music et cetera.

After returning from the load function the engine enters a loop which calls update and render over and over. At this point the menu state makes a TCP connection to a IP (joining a lobby for a 1v1?) which simply creates a object of a connection class and then signals the engine to switch to the game state, the menu state then unloads all the stuff it loaded up.

Now the engine calls game state's load function, the game state loads models, textures et cetera and then enters the update-render loop.

The question now is, how will the game state know about the connection class object that the menu state created? How do the states share objects between themselves? And not only connections, different object types too, even templates maybe, imagine a template class called container which can hold anything such as textures, models, integers, strings, settings under the form of strings that are shared between the menu state and game state such as what game save the player chose when in menu state, or the difficulty...

There are two questions that look like this one but neither of them answered my question:

\$\endgroup\$
3
  • 1
    \$\begingroup\$ There's no one true solution to everything, so the most elegant solution for your specific case is probably completely different from the solution to someone elses' implementation. \$\endgroup\$ Jan 8, 2013 at 11:12
  • \$\begingroup\$ @Jari Komppa I don't see how my case is different from most engines, as far as I know the game states method I described is the most widely used method of managing different states of the game. Anyhow, if there is some better method don't hesitate to let me know. I appreciate any suggestions. \$\endgroup\$
    – Edward A
    Jan 8, 2013 at 11:17
  • \$\begingroup\$ I suspect you may be trying to OOP things too far. However, I don't have an answer for you; I'll let someone else try to answer. \$\endgroup\$ Jan 8, 2013 at 11:28

2 Answers 2

6
\$\begingroup\$

You're probably overthinking it. The only things owned by the game state should be things specific to that game state alone. Everything else should exist outside the game state and persists throughout. Usually, whatever owns the game state should also own those items, but it could be any object really. If the game state needs access, pass it in as an argument.

My object hierarchy often looks somewhat like this:

Application
+- Current State
   +- World (if it's a gameplay state)
      +- Characters
      +- Objects
+- Application Settings
+- Graphics/GUI
+- Audio
+- Networking
+- Resource Managers (unless they're part of specific subsystems)

How does the Current State know about the Audio? I pass in a reference, either when I create the state or when I update the state. Same for everything else.

\$\endgroup\$
6
  • \$\begingroup\$ For the sake of completeness of your answer: if you wanted to share one of the characters, such as the player, between states, a save file could be used. \$\endgroup\$
    – Mitchell
    Jan 8, 2013 at 13:31
  • \$\begingroup\$ Why would you do that? If it's not unique to that state, then it can just go outside the state. If it belongs to several states but not all of them, you could consider hierarchical states. Or just put them all outside with everything else and be careful about initialisation and shutdown. No need to involve serialisation and persistence for it. \$\endgroup\$
    – Kylotan
    Jan 8, 2013 at 13:54
  • \$\begingroup\$ How should the items that are not specific to a game state (such as the example I gave, network connection, or the current save game file that is being used) be stored by the owner of the states (which is the engine) assuming they're not all the same type, connection can be a object of a class and current save game used and difficulty level can be a pair of strings etc and still maintain a level of modularity to the engine so it can be used for more than one specific game? \$\endgroup\$
    – Edward A
    Jan 8, 2013 at 14:32
  • \$\begingroup\$ @Kylotan if you want to carry the player over from one world to the other, you might not want to modify the engine. \$\endgroup\$
    – Mitchell
    Jan 8, 2013 at 15:21
  • \$\begingroup\$ @Edward: they're just objects, contained by their owner. If they have few dependencies they can be reused. It doesn't matter what part of the app owns them. \$\endgroup\$
    – Kylotan
    Jan 8, 2013 at 16:39
0
\$\begingroup\$

There is a book called Head first Design patterns that discusses the various scenarios and designs for the types of situations you are describing. It's worth a look, I think you will find it useful.

Head First Design Patterns on amazon.co.uk

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .