1

My game is now getting to the point where I have alot of classes. Currently, I'm linking all those together through my MainGame Gamestate class. So in my MainGame class I have a Camera instance, a World instance, a Player instance etcetera. Now I know this is bad practise, as this is gonna get real dirty real quick.

What is the correct way of 'linking' loads and loads of classes and systems together?

For example:

In my MainGame class I have a GUI (own GUI library) defined called DebugMenu. Now in this menu I have an input field to change my FOV. When I click the button to update the FOV, the ClickButton event i called in the DebugMenu class which is inherited from the GUI class. To change the FOV I have to call camera.setFOV(40). This camera is an instance, so I need to find the instance that the system is using! That instance is declared in the MainGame class.

I'm using Java.

Basaa
  • 1,053
  • 1
  • 8
  • 23

1 Answers1

4

There's nothing wrong with declaring instances of top-level components (like the World or Player) in your Game class. After all, they have to live somewhere.

To get those instance references to other interfaces, pass them as parameters to the other interfaces. For example, since it sounds like your GUI renderer needs to have a reference to the camera object so it can call setFOV, the GUI renderer should have a constructor:

GuiRenderer (Camera camera) {
    m_camera = camera;
}

This constructor takes a camera reference and stores it for later use.

In this fashion you make the dependencies of all your other components or subsystems very explicit, which improves readability and maintainability of those systems.

  • So if I add say 20 functions that need other classes to work to my DebugMenu, I get 20 properties is my GuiRenderer class? Isn't that a little messy? – Basaa Jul 12 '13 at 14:40
  • Yes, very messy. But that's because you shouldn't need access to 20 other classes in the GUI renderer - that implies a bad, overly-coupled design of the renderer or those other 20 components. Being explicitly about dependencies also helps reveal that problem. –  Jul 12 '13 at 14:44
  • Hmm I don't quite get that. Could you clarify that a little? If I have a huge Debug menu where I can change anything during runtime and get information from classes, I need access to them right? – Basaa Jul 12 '13 at 14:48
  • 1
    You should probably ask a separate question about it, since it's a big topic. But you should be able to define a generic structure (or method of data binding using reflection) to extract the information from every class you want to display information for, that way your GuiRenderer only knows about that one class which homogenized all the data. –  Jul 12 '13 at 14:54
  • But this is what the question is about no? Why should I make another question? – Basaa Jul 12 '13 at 19:58
  • Because your original question is about referring to other class instances and your follow-up is about normalizing data representations to avoid having deep coupling between your debug class and the real interfaces and extended discussion in comments is frowned upon. –  Jul 13 '13 at 01:37