Hi everyone,

So, I've been working on my own (relatively) simple Entity-Component engine to make Pong! :-) (More advanced games coming soon I'm sure). So far, it's going pretty well and most of the internals do things as planned. I started with a flat array of entities/components that each system would loop over to compute its own internal state changes. However, now I've been getting myself slightly stuck thinking about how to implement hierarchies of entities into my engine via scene graphs.

Originally, I implemented the scene graph hierarchy in the entity objects themselves. In fact, the entity objects exist almost solely as containers of the scene graph data (components use entity ids to know which entity they are part of). After a few hiccups, I got a nice simple approach working where each entity can have an arbitrary amount of children, can get detached easily and deleted, etc..

However, now the problem is how does this help with each individual system? For example, the rendering system could in principle use the scene graph to efficiently cull unobservable geometry, except all the scene graph data is part of the entity data structure. This could then equally apply to the collision system, or even the audio system (when dealing with huge numbers of audio sources). This seems to leave 3 solutions :

1) Each system could perhaps have knowledge of the entity data, but then this destroys the data-driven cache efficiency that the ECS approach brings.

2) I can duplicate the entity scene graph hierarchy in each of the components, effectively creating multiple scene graphs, one per system. The system then loops over nice local, cache friendly data but there's duplicated data and the extra overhead of updating all the scene graphs over all systems when something changes.

3) Ignore scene graphs completely in the systems and have each system create its own efficient structure, most likely some kind of tree structure containing data for each component type. The tree only uses local data so again is nice and cache-friendly, both to build and to traverse.

I was hoping the obvious solution would present itself as I coded but alas just more confusion. The only thing that seems clear is the scene graph should be used to update transforms, but the rest is not clear at all to me. Any ideas? Thanks in advance, even if you just point out how stupid my own ideas are :-)

@HappyCoder : Yes, I like to keep things as simple as possible too, at least for the first iteration and leave the complexity for the future when necessary. I tried implementing the simplest possible entity scene graph, but even that got more complicated than I originally intended.

Yes, I feel no. 3 is the long-term choice. I originally felt a scene graph approach would be simpler for now, but as I explained, it's more complicated than that and creates its own problems. Maybe what I should do for now is use the scene graph for the transform updates (which are relatively cheap) and just keep a flat hierarchy in the other systems before implementing something better when the time is right? However, that means I'll have to put LOD on-hold until later!

its not uncommon to have multiple representations of the same data in different formats for different uses. such as a list of renderables in a terrain chunk as well as a 2d collision map for the terrain chunk. the collision info could be calculated from the render info. but a 2d array lookup is much faster than iterating thru a list of renderables.

Yes, like I said, I can see it being the way to go for the long term. I was kind of hoping there'd be some intermediate simple (although not optimal) data structure I could use for all systems which would be easy to implement, other than of course iterating through the entire list of components. But alas, I guess there aren't too many options here so I guess I'll continue with the simpler case and implement something more sophisticated per system in the future as and when I need it!