Jump to content

  • Log In with Google      Sign In   
  • Create Account

Outboard component-based entity system architecture


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
106 replies to this topic

#101 virus-   Members   -  Reputation: 186

Like
0Likes
Like

Posted 17 December 2007 - 06:10 AM

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.

Sponsor:

#102 tomby   Members   -  Reputation: 122

Like
0Likes
Like

Posted 19 December 2007 - 07:31 AM

Greetings!
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: ...

PROS: ...

CONS: ...

---------------------------------------------


I hope that you Sneftel will be the first on fill the form..


[Edited by - tomby on December 19, 2007 1:31:42 PM]

#103 Sneftel   Senior Moderators   -  Reputation: 1781

Like
0Likes
Like

Posted 19 December 2007 - 08:14 AM

No, but feel free to. Are there any questions you have?

#104 Sphet   Members   -  Reputation: 631

Like
0Likes
Like

Posted 19 December 2007 - 10:28 AM

Just wanted to chime in that I've just finished the first pass implementation of a component system based heavily on the Dungeon Siege style, with components, and template/pattern definitions and script integration. It's for a series of commercial products.

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.

#105 qingrui   Members   -  Reputation: 118

Like
0Likes
Like

Posted 19 December 2007 - 06:02 PM

Hope I'm not too late for this thread. It took me 2 days to read through and digest this thread.

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 :)

#106 virus-   Members   -  Reputation: 186

Like
0Likes
Like

Posted 20 December 2007 - 12:35 AM

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]

#107 qingrui   Members   -  Reputation: 118

Like
0Likes
Like

Posted 20 December 2007 - 01:57 PM

Agreed. And I don't like the events way either. My feeling is that inter-operation is as important as objects for the real world, so instead of trying to remove dependency of objects, I'm more willing to let them talk freely.

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS