Very nice topic indeed, need to read it few more times to consume all the ideas.

For my framework I've been playing around with event/job based system. Some subsystems can't use multiple threads because of the underlying implementation (rendering for one, physics depends on library). Since we can't really rely on a subsystem being able to utilize multiple threads all communication to a subsystem is done via events (still need to test if this is a viable) if the subsystem can utilize multiple threads it just processes multiple events parallel.

Now I wonder which would be a better approach.
#1 Have the entity components be just data and subsystems doing all the work on them.
#2 Have the entity components process everything that can be untied from a subsystem. The subsystem would send events and the framework would utilize all the remaining threads (1 at minimum) to process the events.

#1 seems like a pretty logical solution but we might not end up utilizing all the threads and there's no central control for them.
#2 we can process events by priority, utilize pretty much any number of threads and separate some of the work from the actual subsystems (we really don't want to do anything else in the rendering thread than to be churning data to/from GPU) but have extra overhead from larger amount of events and require a lot more components for different functionality.

I had a lot more stuff but it kinda flew out of the window once I started writing, hope that made any sense. Hopefully I'll have enough time next week to write a simple test case.

Earlier I headed the same way your hybrid solution uses, that's each entity type would use a predefined set of components. Since the entity knows what components it has it can easily pass the required data between them but it's not as modular and still has the problem of creating inheritance trees since if one entity type provides most of the functionality we want why not inherit from it. Since then I've moved to designing an completely component based entities but getting around dependencies is a bit problematic. So far it seems best that components that might depend from other components scan the existing components at initialization (so far I see no reason to support dynamic component addition/deletion) and decide the flow based on whether they're available or not, or throw an exception if they're explicitly dependent on some other component.

We could use events between components to abstract the dependencies but that really doesn't solve the problem, just abstracts it a bit further, we're no longer dependent on a specific component but on an event that some component produces, in addition to that we also incur the overhead from using events to pass the data we would've accessed directly.

EDIT: Still the benefits of completely data driven entities are enough to deal with the headaches from dependencies. If I you don't need a programmers to implement a new entity "type" the programmers can do what they're meant to do, code new/better functionality.

[Edited by - virus- on December 20, 2007 7:35:04 AM]