Outboard component-based entity system architecture
Members - Reputation: 186
Posted 17 December 2007 - 06:10 AM
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.
Members - Reputation: 122
Posted 19 December 2007 - 07:31 AM
This topic is really very interesting and also quite long.
There are many good suggestions and ideas collected somewere in this topic
I think it would be usefull now summarize each proposed design, with main pros and cons of each one....
A comparative approach is the optimal to identify the best component-based design architecture
Thus please fill in the following form, then I will do an interesting summary open to further comments:
USER proposer: ...
DESIGN descr: ...
MAIN point: ...
I hope that you Sneftel will be the first on fill the form..
[Edited by - tomby on December 19, 2007 1:31:42 PM]
Members - Reputation: 629
Posted 19 December 2007 - 10:28 AM
For our first pass I'm using C style messaging (SendMessage/PostMessage) using typesafe payload structures for now because our scripting system doesn't have the smarts to handle C++ template structures right now.
Components can be written in C++ or script, with the definition of the data being an external definition that can be recompiled and reloaded.
We use this meta definition to populate a series of tools, some in 3D authoring environments, and some in our pipeline.
We use 'out of order' updates, where each component type that needs updating registers itself on construction and is updated by a subsystem, much like Sneftel pointed out. This has been a real boon for multi threading and PS3 nastiness with respect to moving our character posing and such into secondary tasks.
The real downside I have seen so far is trying to get the engineers to have decent granularity of the components. We've gotten some pretty small structures where the value of components gets lost. I'm certain we will find a good match in the long term.
Good thread, interesting read.
Members - Reputation: 118
Posted 19 December 2007 - 06:02 PM
I have been playing with componentized entity design for a long time but dare not to move on to it completely, because the issues you guys have mentioned. Sometime I wonder why it has to be the component collection way to become modular. Think if this were not a game, and a class grew really big and I decided to make it a bit modular, what should I do? Surely I would split it into aggregation of smaller classes by functionality, but how would I organize them if they have dependencies?
Actually I have home-grown it to be a hybrid of shallow inheritance and aggregation of components without a component collection - that is, a component is really a fixed member of a specific entity type. It's not a great design, but it is a stupid and simple way. I remember a guy has mentioned about a similar idea in this thread.
My 2 cents :)
Members - Reputation: 186
Posted 20 December 2007 - 12:35 AM
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]
Members - Reputation: 118
Posted 20 December 2007 - 01:57 PM
One idea inspired by your post is that, the pros/cons may depend on what the design goal is. If scripting play an important role in the engine, then the complete component way provides a really good architecture to empower scripting. And the indirection access to other components is not an issue at all for scripts. The hybrid way may help for little-scripted game, because the program knows what an entity actually is, thus easy to deal with.
The big titles in recent years are mostly large scale games and scripting plays an important role IIRC. So that may be the reason that complete component design boomed.