Original Post
I am having an interesting time - to say the least - with the structure of my game engine. Initially I modelled the engine several graphics engines (IrrLicht, Ogre...), and created a monolithic scene-graph which handled scene-hierarchy, culling, render batching, animation and physics. As most of you who have tried this probably know already, past a certain point this just doesn't work. So now I am trying a 'distributed' approach (please forgive my terminology problems). I am now using the scene-graph solely for parent-child relationships between nodes, and each node holds various 'chunks' - for lack of a better word - which give it substance in the game world. Chunks are for things such as geometry, physics, AI and sound. Ideally, each type of chunk would be managed in its own unique structure, but in fact this seems hard to do. Here is my problem: every type of chunk in the system needs to share some data, but for modularity, I wanted to keep each largely unaware of how the others are implemented. For instance, of the 4 chunks I enumerated above (geometry, physics, AI and sound), all are going to need to know object positions, the last 3 (at least) will need to know about movement/velocity, and all except possibly AI are going to need to do some sort of culling for performance purposes. And the organisation for each type of chunk has to be radically different... Geometry and sound are fairly flexible, but both need to be organised by some notion of spatial locality. AI needs to be organised by various methods - maybe by faction and unit groups, and Physics needs to be organised by joints, etc. ATM I have a class for each type of chunk, instances of which are help by nodes in the scene graph. When you add a geometry chunk, for instance, it, must also be added to the current culling manager, and for physical objects it must be added to the physics subsystem... The problem is that some shared data, namely position and motion information, is needed by all subsystems, and has thusly been placed in the node class. This means that now all of the chunks have to know about the existence of the node class, in order to get/set these variables. There is also an issue of which subsystems are allowed to write to each variable: it is documented that only the physics system can write to the position, but I want some way to enforce this. So I guess what I wanted to ask is ultimately - how do you deal with this in your own code? Some sort of pointers to how best to organise this sort of partially-related data would be good.
