1
\$\begingroup\$

My game is very GUI based, the way how it works is that I have a GUI class, which contains the basic GUI elements, a parent GUI object, and a copy of the main game's class object. The game starts out with the main GUI, which is the main menu, then when it wants to it takes something like the in game GUI, creates a object with the main menu's copy of the game and then the main menu object itself using this as the parent GUI. So when the in game GUI wants to, it can call back for the parent GUI to be used again.

Here is where the issue lays, the in game GUI needs to be a GUI, but also needs to contain this such as the level it's playing, the player, and all those things. How is this done?

Should I have approached my GUI based system differently? Because I can't somehow figure out of I would implement such a GUI without errors. How do you approach this? Or how would you approach this?

\$\endgroup\$
1
  • \$\begingroup\$ As others have said the GUI just displays information. It's not the holder of that information. That information should be stored somewhere else (the model) and sent to the GUI (the view) when needed. \$\endgroup\$
    – user441521
    Commented May 29, 2015 at 19:32

2 Answers 2

Reset to default
6
\$\begingroup\$

You should clearly separate GUI (view) from the actual game state (model). GUI just shows the model to the player (in one way or another) and lets the player control it, but the model itself is solid enough to know everything it needs (level, player, etc). The GUI should know only things GUI needs, which model does not care about (e.g. controls positions).

\$\endgroup\$
1
  • \$\begingroup\$ Yes, this is very important. Parking information in the GUI is just about the worst thing you can do in any app that can be represented by some roughly MVC model. \$\endgroup\$
    – bobobobo
    Commented Jun 10, 2013 at 15:55
1
\$\begingroup\$

The answer to your specific question, how does the GUI know about the level being played, is: it doesn't.

The GUI displays everything it's being told to display, but it doesn't have any information about what that data actually is.

A common approach is to use a message system to pass messages from one component to another. When the LevelLoader has finished loading a level, it creates a message:

<MessageEnvelope type="LevelLoaded">
    <Identifier>1</Identifier>
    <Name>Big spooky forest</Name>
    <Attempt>33</Attempt>
</MessageEnvelope>

I'm using XML here, but you can use whatever you like. Personally, I prefer Protobuf.

The message system approaches all of its listeners with this message until the GUI says: yup, that one's for me. The GUI then extracts the Name element from the XML and uses it to display the level's name.

There are two things to keep in mind here: the GUI doesn't know the LevelLoader class exists (decoupling), only that it can receive messages from the MessageSystem. And the LevelLoader doesn't know that the GUI exists, only that it has to send a message to the MessageSystem when the level is done loading.

Because both are oblivious to each other, it's very easy to swap out implementations.

\$\endgroup\$
1
  • \$\begingroup\$ -1 Just because there is a message system in between, doesnt mean its decoupled. The GUI must know whether the game has teams or not, whether it has XP, how many skill points, which skill trees for which character, all this information must be hard wired in the GUI, messages in between or not. So the whole decoupling idea renders pointless once you put it into practice. \$\endgroup\$
    – Maik Semder
    Commented May 22, 2013 at 20:10

You must log in to answer this question.

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