0

My application right now has a Game class, which contains other classes that receive a Game pointer. Also these classes passes the Game* pointer to their subclasses. I do this to keep communication between objects. Is this a bad way to keep all communicated? This looks like a "god object" antipattern.

The only alternative I've found to avoid this is simply instanciate my objects globally, inside namespaces, like they did int his project https://github.com/thelaui/M.A.R.S. . But this also looks as an antipattern, where almost everything is global.

What is then the correct way to design a program where the objects keep communicated?

Or the objects shouldn't keep communicated? Which looks hard to make a game.

freesoul
  • 393
  • 4
  • 11

1 Answers1

1

I personally have found it difficult at best to write clean code for a game without at least one singleton/static object that holds references to frequently required information. Passing around references and keeping local copies of references to things you may only need once or twice in a given class just wastes memory and gives you headaches doing all the boilerplate for each class

You are thinking about god objects incorrectly -- a god object knows too much about what is going on outside of its context... an object that you need access to a single instance from many places is not a god object, and can be a good thing :)

Our Game object is such an object, and it contains a list of service objects that get updated/rendered as part of the main game loop to handle things that need to occur outside the normal scene graph rendering process.. examples of services might be input management, HUD/GUI , and physics ... things that need to happen at specific points in the rendering lifecycle and that persist through the lifespan of the game no matter what scene is being rendered. The game object manages activating these services at the right time before or after scene graph processing, but knows nothing beyond the fact that is activating a service, or rendering a scene... thus it is not a god object :) services and scene graphs are handled in completely separate classes that the Game object just makes calls on without knowing how they work internally. If you piled input management, scene graph management, etc, etc all into the Game class -- THAT would be a god object :)

Ascendion
  • 434
  • 2
  • 7