hey there, I'm currently busy designing a simple game engine for a 2D top down space shooter. The game will be coded using C++ and OpenGL and few addition libraries. Up until now I used to code my games straight away without much considerations but this time I'd like to spend some time creating a flexible and clean system. My engine is currently split into a couple of subsystems (Renderer, Scene, Input, Sound, Physics...) with the functionality of each accessible through a manager class (i.e. renderManager, sceneManager, inputManager...) to decouple the systems. The subsystems need to interact with one another (for example the Render subsystem needs to access the sceneData through the sceneManager). The problem I'm facing is that I'm not shure what's the best way to allow the various subsystems to access the other subsystems. For example in my main loop I'd like to call an update on the various subsystems like this: ... sceneManager.update(); renderManager.update(); ... To give the renderManager access to the sceneManager i could make all manager classes static but I don't think that's very wise and will get me into a lot of trouble. But on the other hand I don't like to pass an instance to every subsystem which needs to interact with another. What would be a clean solution to this problem or am I missing something obvious ? If that's completly wrong what would be a better solution? thanks, benderB

Constant pointers.

class CRenderMgr : public CMgr{// ...CSceneManager * const m_scene;public:CRenderMgr::CRenderMgr(CSceneMgr * const scene) : m_scene(scene){// ...}// ...};

If you want to make the code better you should use a constant interface as well.

class CRenderMgr : public CMgr{// ...const CSceneManager * const m_scene;public:CRenderMgr::CRenderMgr(const CSceneMgr * const scene) : m_scene(scene){// ...}// ...};

Then the only functions that your render manager can access would be those ones which you declare as const in the CSceneMgr, adds a some encapsulation and neatness.

I'm sure you could use the boost library for something like this, or some more complicated method which is more generic, but it would probably just be overkill; but then again it depends on the scope of what you are doing.

... I hope that syntax is right I haven't done any coding in C++ for half a year.

I'm having the same problem, but I am looking into using the Observer Pattern.

Let me know what you think of the idea if you do have a look at it.

Thanks everyone for the quick replies you are helping me a lot! (But keep 'em comming :))

@AsOne:

I understand your point and the consts would quite effectivly restrict the access.
(Haven't even thought about using consts before - thank you Java programming ;)).
But I'd still have to pass a pointer to every manager class which I'm trying to avoid.
Thanks anyway this gets me thinking!

@johnnyBravo:
I have read the Observer-Pattern article and as I understand it this would boil down to some callback thingy which could be quite usefull with this problem.
The problem I see is that you would still have to "wire" the subsystems together defining every observer-subject callback for all the different purposes which could get a little messy, have to think about it a little more...

@JohnBolton:
The Singleton-Pattern seems like a good and clean solution for the problem.
I think I'll try it this way.

Quote:Original post by JohnBolton
On the other hand, do the subsystems really need access to each other? That can create dependency problems. As for the relationship between Scene and Renderer, the Scene could be part of the Renderer.

I'm trying to lower the number of dependecies.
The thing is, concerning scene and renderer, that the scene subsystem is not only used by the renderer as I would like to have the physics subsystem to access the scene as well and I don't think that the scene is a logical part of the render system.

Quote:Original post by JohnBolton
And just some nitpicking... Why is everything named xxxxxManager? Wouldn't classes named Renderer, Scene, Input, Sound, Physics... be better since those are the names of the subsystems?

Good point.

Thanks again for the input and I'd be happy to hear more on the subject,
benderB

Our system uses a publish/subscription type system with a common iSubscriber interface. So we have different game events defined in a big enum for different messages. When the event/message is published our event manager iterates over all the subscribers and sends them a message.

This system has worked out for us pretty well and makes it really easy to hook new systems in. Right now the majority of the usage is in networking messages so we can easily hook in new subsystems on the client depending on what network messages they are interested in. But we are also using this type of system for things like scripting on the server so different sub systems can be informed without having to add a lot of cross dependency. Depending on how quickly/often you need to access the other systems the overhead of the pub/sub might be too much but it has worked well for us to allow different managers and systems communicate with each other.