Sign in to follow this  
Halsafar

Entity System - Component ordering and interactivity

Recommended Posts

I have been gathering lots of reading information lately on using an entity system for representing game objects. The approach I enjoy most compares closely with relational databases. Some good notes before I ask my question:
[url="http://entity-systems.wikidot.com/rdbms-with-code-in-systems"]http://entity-systems.wikidot.com/rdbms-with-code-in-systems[/url]
[url="http://www.gamedev.net/topic/463508-outboard-component-based-entity-system-architecture/"]http://www.gamedev.net/topic/463508-outboard-component-based-entity-system-architecture/[/url]
[url="https://github.com/adamgit/Game--Escape-from-the-Pit"]https://github.com/adamgit/Game--Escape-from-the-Pit[/url]


The biggest problem in my understanding seems quite common among others.

1.) Simply put, if I have two components which should remain separate, lets say PositionComponent and PhysicsComponent but they require knowledge of each other. What is the appropriate solution here? I can't imagine a PhysicsComponent without a PositionComponent so perhaps a bad example.

2.) Regardless of your solution to my first question it leads directly to my next concerns. The dependencies also have an implied ordering. Lets say we have a MoveableComponent which takes gamepad input and sets up some deltas for movement then our component sub systems must be run in order. You would have to update the MoveableComponent first for the PositionComponent to be correctly computer. PositionComponent needs to be updated for the PhysicsComponent which has to update for the CollisionComponent, and so on.

I see no way to avoid the extremely ugly chain of dependencies created nor a way to avoid the ordering implied on these components.

Remember the whole idea of the entity system is to avoid this type of dependency problem. Perhaps my understanding lacks but I see this as a serious problem.

Share this post


Link to post
Share on other sites
1) There's two schools of "component systems" -- ones where components magically find each other (by inspecting the entity somehow) and automatically send messages to each other, and ones where you explicitly plug components into each other.

For the former, the physics component would ask it's parent entity to give it a pointer to a child component that implements the IPositionable interface, etc, etc, and the physics component would send "position updated" messages to that target.

For the latter, the person creating the entity would plug them together, e.g.[code]e = new Entity;
c = new PhysicsComponent;
p = new PositionComponent;
c->SetOutputComponent( p );
e->Add( c );
e->Add( p );[/code]

2) Why does every component need an "Update" function? If you don't force everything to operate in terms of "IUpdatable", then you don't have this problem ([i]seriously, imagine writing any other piece of software, such as a calculator or spreadsheet or database, where every class was controlled through a generic IUpdatable interface....[/i])

[quote]Remember the whole idea of the entity system is to avoid this type of dependency problem[/quote]Not really. The idea that composition is preferable to inheritance is a good software engineering rule-of-thumb. Modern "entity/component systems" are better than traditional "inherited entity systems" due to this fact, but component systems are not supposed to suddenly remove all dependencies in your code.

Share this post


Link to post
Share on other sites
[font="arial, verdana, tahoma, sans-serif"][size="2"][quote name='Hodgman' timestamp='1318394324' post='4871726']
1) There's two schools of "component systems" -- ones where components magically find each other (by inspecting the entity somehow) and automatically send messages to each other, and ones where you explicitly plug components into each other.

For the former, the physics component would ask it's parent entity to give it a pointer to a child component that implements the IPositionable interface, etc, etc, and the physics component would send "position updated" messages to that target.

For the latter, the person creating the entity would plug them together, e.g.[code]e = new Entity;
c = new PhysicsComponent;
p = new PositionComponent;
c->SetOutputComponent( p );
e->Add( c );
e->Add( p );[/code]
[/quote]

I do believe you made a light bulb click even if your solution isn't exactly what I will end up implementing. [/size][/font]

So far all the articles I've been reading on the topic seemed to talk about an entity system as a golden hammer to avoid OOP paradigms entirely. Adding some OOP to manage dependencies is fair in my books.

[quote name='Hodgman' timestamp='1318394324' post='4871726']
2) Why does every component need an "Update" function? If you don't force everything to operate in terms of "IUpdatable", then you don't have this problem ([i]seriously, imagine writing any other piece of software, such as a calculator or spreadsheet or database, where every class was controlled through a generic IUpdatable interface....[/i])

[quote]Remember the whole idea of the entity system is to avoid this type of dependency problem[/quote]Not really. The idea that composition is preferable to inheritance is a good software engineering rule-of-thumb. Modern "entity/component systems" are better than traditional "inherited entity systems" due to this fact, but component systems are not supposed to suddenly remove all dependencies in your code.
[/quote]

Previously I am used to the game object paradigm where an "IUpdatable" is common. In the entity+component case not all components require an update but the major light bulb from this was that not all components need to update individually. There is nothing stopping me from having a PhysicsAndCollisionSubSystem that updates all entities containing one or the other keeping the logic for both in one place.


In terms of ordering I think it reasonable to just assume we update the sub systems in the order required by the game context. This is likely to change based on your game.


One thing I must say if the component sub systems can remain "atomic" then one could potentially thread the processing of components.

Share this post


Link to post
Share on other sites
A system we use here is that of 'modules' which deal with the registering, creating (via a factory) and updating of components [i]which require it. [/i]Some modules just iterate over their internal list of active components, others do nothing or just some house keeping while the components themselves react only to events and don' t have a concept of an 'update'.

Modules have an update order, which is defined in a file external to the game/engine, which allows for update dependancies to be resolved as required.

In this system modules know about other modules but components don't know, directly, about other components. This isn't a hard and fast rule but the tendancy is for messages to be passed around by components asking their parent module to do the work for them.

Threaded component update is pretty easy, you just need to either ensure that your components are thread safe if they can cross talk OR use a shadow system to ensure that data which can be written to by the component isn't publicably visable but a copy of it is, then at some point you do a 'swap' operation on all component which push their internal state to the public state for the next frame.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this