headers
Nick Trout | 7 Jan 2010 22:57

Re: Entity Communication & Use of Reflection

1) Components have a container. A pointer to this is basically your entity id. Components have an initialise(ComponentContainer&) method. Here they can cache pointers to other components they require. Runtime dynamic lookup is baad. This implies some dependency order in initialisation. Static downcast using type system gets you from IComponent to the type your require.


2) Entities are objects made by composition. A component registers itself with a "system" (not its owner, the container is that). If you want to find another component of the same type (which is basically 2 different entities which your just sliced up) you ask the same system that you are registered with. E.g. a physics solid body component might want to find another near it. The component gets the system reference from its factory.

3) When two different component types want to talk to each other in different entities, as 2) but you need references to different systems.

Reflection (introspection) could be used to check the types of the components. Avoid string comparisons. RTTI typeid or homebrew type system via static id preferable. 

Nick


2009/12/18 Ashkan Aliabadi <ashkan.aliabadi <at> gmail.com>
David (Black), could you please elaborate how you handle communications between different components? More specifically, how do you handle these:

1) How do two (different) components, both of which belong to the same entity, communicate?
2) How do two identical components, each of which belongs to a different entity, communicate?
3) How do two different components, each of which belongs to a different entity, communicate?

I suppose the most  general way is to have a universal message dispatcher. This way, message handling can also be done in separate threads.

Besides, could you also describe how reflection can be put to good use in a component-based entity system?

Thanks!

On Thu, Dec 17, 2009 at 10:38 PM, <sweng-gamedev-request <at> lists.midnightryder.com> wrote:
sweng-gamedev <at> midnightryder.com



--

Mike Ditka  - "If God had wanted man to play soccer, he wouldn't have given us arms."

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com


_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 91 comments |
headers
Emil Dotchevski | 8 Jan 2010 04:36

Re: Entity Communication & Use of Reflection

On Thu, Jan 7, 2010 at 1:57 PM, Nick Trout
<chinbillybilbo <at> googlemail.com> wrote:
> 2) Entities are objects made by composition. A component registers itself
> with a "system" (not its owner, the container is that).

Isn't it better to have a separate (factory?) function register the
components in whatever systems they have to be registered? That way
the components themselves aren't coupled with systems that manage
them.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 90 comments |
headers
Nick Trout | 10 Jan 2010 21:19

Re: Entity Communication & Use of Reflection

Possibly, but I think thats restrictive and assumes the components are mainly plain data containers, when the commonly they offer functionality to other components or the systems they are registered with, and the components tend to want to call manager classes.

E.g. if you had a looping audio component and wanted to change the sample each loop, you might have a callback in the component that the manager calls when the loop ends, and then the component might want to call the manager to start another sample.

Also, what if the component doesn't want to act straight away? A component might activated by another component using it. E.g. say a particle system component is started by a collision component, but then unregisters when the effect finishes.

It might also be easier to handle error conditions if the component can unregister itself when it become unusable.

In the end it just offers a lot more flexibility and simplifies things. Otherwise I think you'd have to get the factory involved in the component's management, which seems like a confusion of responsibility between the component and its creator.

Another angle, where you might have the factory register the component, is if the manager class implements IComponentFactory for the given component type. This would probably less flexible though as the manager and client code are blurring together.

Nick


2010/1/8 Emil Dotchevski <emil <at> revergestudios.com>
On Thu, Jan 7, 2010 at 1:57 PM, Nick Trout
<chinbillybilbo <at> googlemail.com> wrote:
> 2) Entities are objects made by composition. A component registers itself
> with a "system" (not its owner, the container is that).

Isn't it better to have a separate (factory?) function register the
components in whatever systems they have to be registered? That way
the components themselves aren't coupled with systems that manage
them.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 89 comments |
headers
Richard Fabian | 11 Jan 2010 00:33
Picon
Gravatar

Re: Entity Communication & Use of Reflection

I'd agree with this. Most component work I do leads to having clever code inside the managers (such as spatial partitions and recent use caches), so having the component decoupled from the component manager seems really pointless and costly.
Also, if your components are actually data objects, then you're missing one of the great savings of component approaches: the simplicity of vectorising your systems and making your "tick" cache friendly.

2010/1/10 Nick Trout <chinbillybilbo <at> googlemail.com>
Possibly, but I think thats restrictive and assumes the components are mainly plain data containers, when the commonly they offer functionality to other components or the systems they are registered with, and the components tend to want to call manager classes.

E.g. if you had a looping audio component and wanted to change the sample each loop, you might have a callback in the component that the manager calls when the loop ends, and then the component might want to call the manager to start another sample.

Also, what if the component doesn't want to act straight away? A component might activated by another component using it. E.g. say a particle system component is started by a collision component, but then unregisters when the effect finishes.

It might also be easier to handle error conditions if the component can unregister itself when it become unusable.

In the end it just offers a lot more flexibility and simplifies things. Otherwise I think you'd have to get the factory involved in the component's management, which seems like a confusion of responsibility between the component and its creator.

Another angle, where you might have the factory register the component, is if the manager class implements IComponentFactory for the given component type. This would probably less flexible though as the manager and client code are blurring together.

Nick


2010/1/8 Emil Dotchevski <emil <at> revergestudios.com>

On Thu, Jan 7, 2010 at 1:57 PM, Nick Trout
<chinbillybilbo <at> googlemail.com> wrote:
> 2) Entities are objects made by composition. A component registers itself
> with a "system" (not its owner, the container is that).

Isn't it better to have a separate (factory?) function register the
components in whatever systems they have to be registered? That way
the components themselves aren't coupled with systems that manage
them.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode


_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com




--
fabs();
Just because the world is full of people that think just like you, doesn't mean the other ones can't be right.
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 87 comments |
headers
Emil Dotchevski | 11 Jan 2010 06:43

Re: Entity Communication & Use of Reflection

On Sun, Jan 10, 2010 at 3:33 PM, Richard Fabian <raspo1 <at> gmail.com> wrote:
> I'd agree with this. Most component work I do leads to having clever code
> inside the managers (such as spatial partitions and recent use caches), so
> having the component decoupled from the component manager seems really
> pointless and costly.

The manager would be coupled with the components, I meant avoiding
coupling the other way around. Being able to use components without
"the" manager means you can write simple component unit tests without
having to link to the universe.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 86 comments |
headers
Emil Dotchevski | 11 Jan 2010 06:59

Re: Entity Communication & Use of Reflection

On Sun, Jan 10, 2010 at 12:19 PM, Nick Trout
<chinbillybilbo <at> googlemail.com> wrote:
> Possibly, but I think thats restrictive and assumes the components are
> mainly plain data containers, when the commonly they offer functionality to
> other components or the systems they are registered with, and the components
> tend to want to call manager classes.

The components can still have logic and behaviors. Decoupling them
from the manager only removes the higher level logic, the code that
knows how various components interact with each other (in this
particular game.)

> Also, what if the component doesn't want to act straight away? A component
> might activated by another component using it. E.g. say a particle system
> component is started by a collision component, but then unregisters when the
> effect finishes.

You could have the collision component signal the collision and leave
it up to the caller to start a particle effect if that's desirable.
Then the particle effect would signal it's done and leave it up to the
caller to delete it.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 0 comments |
headers
Richard Fabian | 11 Jan 2010 10:14
Picon
Gravatar

Re: Entity Communication & Use of Reflection

Coupling by definition is two way. If you don't want to link in the universe, may i suggest you do what I do and don't make the manager require the universe. it's not always that difficult, and lets you have what you want for unit testing and lets you maintain full cache friendliness, thread safety, and vectorisability.


2010/1/11 Emil Dotchevski <emil <at> revergestudios.com>
On Sun, Jan 10, 2010 at 3:33 PM, Richard Fabian <raspo1 <at> gmail.com> wrote:
> I'd agree with this. Most component work I do leads to having clever code
> inside the managers (such as spatial partitions and recent use caches), so
> having the component decoupled from the component manager seems really
> pointless and costly.

The manager would be coupled with the components, I meant avoiding
coupling the other way around. Being able to use components without
"the" manager means you can write simple component unit tests without
having to link to the universe.



--
fabs();
Just because the world is full of people that think just like you, doesn't mean the other ones can't be right.
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 85 comments |
headers
Jon Watte | 11 Jan 2010 20:01
Picon
Gravatar

Re: Entity Communication & Use of Reflection

To unit test, apply dependency injection. If the manager is an interface, rather than concrete, then you can use a MockManager. If the dependencies are "found" using some abstraction like an execution environment or configurable singletons, then you can unit test components on their own easily.


Btw: I see three pieces here:
- Low-level functionality, like rigid bodies, scene graph, playing sounds, etc
- Components (integrate with the low-level functionality to provide a high-level abstraction)
- Entities (collections of components)

It sounds like some people put smarts in the entities. I've found that to end up being a bad idea, because you then have tighter coupling, and can't treat entities as generic entities as easily. I've found that putting all of the "smarts" of the integration layer in the components is best, and Entity ends up being nothing more than a convenient way to address entities (for networking, or whatnot), putting a name on something, and being a bag of components.

Is there something I'm missing here? What's the benefit of putting smarts in the component container itself?

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.



On Mon, Jan 11, 2010 at 1:14 AM, Richard Fabian <raspo1 <at> gmail.com> wrote:
Coupling by definition is two way. If you don't want to link in the universe, may i suggest you do what I do and don't make the manager require the universe. it's not always that difficult, and lets you have what you want for unit testing and lets you maintain full cache friendliness, thread safety, and vectorisability.


2010/1/11 Emil Dotchevski <emil <at> revergestudios.com>

On Sun, Jan 10, 2010 at 3:33 PM, Richard Fabian <raspo1 <at> gmail.com> wrote:
> I'd agree with this. Most component work I do leads to having clever code
> inside the managers (such as spatial partitions and recent use caches), so
> having the component decoupled from the component manager seems really
> pointless and costly.

The manager would be coupled with the components, I meant avoiding
coupling the other way around. Being able to use components without
"the" manager means you can write simple component unit tests without
having to link to the universe.



--
fabs();
Just because the world is full of people that think just like you, doesn't mean the other ones can't be right.

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com


_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 83 comments |
headers
Emil Dotchevski | 11 Jan 2010 20:10

Re: Entity Communication & Use of Reflection

On Mon, Jan 11, 2010 at 1:14 AM, Richard Fabian <raspo1 <at> gmail.com> wrote:
>> The manager would be coupled with the components, I meant avoiding
>> coupling the other way around. Being able to use components without
>> "the" manager means you can write simple component unit tests without
>> having to link to the universe.
> Coupling by definition is two way.

I guess I should have said dependency, not coupling.

> If you don't want to link in the
> universe, may i suggest you do what I do and don't make the manager require
> the universe.

Make the entire game not require the universe then, why stop with the
manager. :)

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 0 comments |
headers
Emil Dotchevski | 11 Jan 2010 20:30

Re: Entity Communication & Use of Reflection

On Mon, Jan 11, 2010 at 11:01 AM, Jon Watte <jwatte <at> gmail.com> wrote:
> To unit test, apply dependency injection. If the manager is an interface,
> rather than concrete, then you can use a MockManager.

This would decouple you from the manager implementation but not from
the manager interface. Depending of how complex this manager interface
is, this makes testing individual components or entities harder.

> Btw: I see three pieces here:
> - Low-level functionality, like rigid bodies, scene graph, playing sounds,
> etc
> - Components (integrate with the low-level functionality to provide a
> high-level abstraction)
> - Entities (collections of components)
> It sounds like some people put smarts in the entities. I've found that to
> end up being a bad idea, because you then have tighter coupling, and can't
> treat entities as generic entities as easily. I've found that putting all of
> the "smarts" of the integration layer in the components is best, and Entity
> ends up being nothing more than a convenient way to address entities (for
> networking, or whatnot), putting a name on something, and being a bag of
> components.
> Is there something I'm missing here? What's the benefit of putting smarts in
> the component container itself?

If you call it a component container, then there are no benefits,
you'll just confuse everyone. :)

Let's say you have a piece A and a piece B. In your game, A and B
interact in some non-trivial way, for example as was indicated
earlier, A is a collision detector which spawns B when it detects a
collision.

You could put this logic into A itself: "I detect a collision, so I'll
spawn a B". That means that A needs a "manager" for spawning stuff,
and it also needs B. This makes it harder to write a simple test for
A.

Alternatively, you can separate this interaction logic outside of A:
"A tells me it has detected a collision, so I'll spawn a B". This
makes it easier to test A by itself.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 81 comments |

Gmane