librelist archives

« back to archive

receive non-const event?

receive non-const event?

From:
Jeremy Huffman
Date:
2014-06-26 @ 01:38
Hi, I've been dabbling a bit with EntityX in a Cocos2d-x project. I may not
be approaching this correctly, but I was thinking of using events to sync
properties across different components in an Entity. For example I have a
Movement component that just has const members next_position and vector.
I've wired an Event receiver SpriteMover to receive the
ComponentAddedEvent<Movement>; it would then check and see if the entity
has a Sprite component, and set a new position on the Sprite if found. The
rest of the game logic concerned with managing motion can ignore the
sprites this way.

It seems like this approach is discouraged by the fact that the Event
received is a const. I can't assign or destroy components through the
handle I get in the receive, or call non-const methods (like component<>)
on any members there-in. Is this a hint that receive isn't the right place
to mutate game state? I can work around this by storing a reference to the
EntityManager when I construct my SpriteMover and then doing a get by
ID...but thought I should at least ask in case I'm missing something here.

Thanks,

Jeremy

Re: [entityx] receive non-const event?

From:
Asmodehn Shade
Date:
2014-06-26 @ 02:12
Hi,

I am working on a coco2dx project with entityx as well.

The way I see it is :

Systems and Components work together from the basic original design of
entity systems.
The pace of change is made to be fast as it happens during the update cycle.
Therefore a system can add a component to an entity and another system can
get it from that entity and do the appropriate action. This is the proper
way to communicate between systems imho.

Events and Managers have been added over the basic entity system design.
They add another layer to be able to divide and manage the complexity
better.
Events are triggered by systems or managers and can be caught by them too.
But i see this communication as more sparse. Meaning one event will happen
unexpectedly sometime, and has nothing todo with an entity ( otherwise,
shouldnt the same information be in a component ? )

So for me Managers communicate with systems and themselves via events,
independently of entities. Another level of abstraction that can help with
complex design.
For exemple think of a GUI on top of a 3d view... you could have a manager
for the 3d world. A manager for the ui. And they exchange info with events.
But each entities managed by each system do not interact directly. So there
are two "worlds" that are separate : the GUI world and the 3d world.

I hope this helps.
--
AlexV
On Jun 26, 2014 10:38 AM, "Jeremy Huffman" <jeremy@jeremyhuffman.com> wrote:

> Hi, I've been dabbling a bit with EntityX in a Cocos2d-x project. I may
> not be approaching this correctly, but I was thinking of using events to
> sync properties across different components in an Entity. For example I
> have a Movement component that just has const members next_position and
> vector. I've wired an Event receiver SpriteMover to receive the
> ComponentAddedEvent<Movement>; it would then check and see if the entity
> has a Sprite component, and set a new position on the Sprite if found. The
> rest of the game logic concerned with managing motion can ignore the
> sprites this way.
>
> It seems like this approach is discouraged by the fact that the Event
> received is a const. I can't assign or destroy components through the
> handle I get in the receive, or call non-const methods (like component<>)
> on any members there-in. Is this a hint that receive isn't the right place
> to mutate game state? I can work around this by storing a reference to the
> EntityManager when I construct my SpriteMover and then doing a get by
> ID...but thought I should at least ask in case I'm missing something here.
>
> Thanks,
>
> Jeremy
>

Re: [entityx] receive non-const event?

From:
Alec Thomas
Date:
2014-06-26 @ 03:27
Hi Jeremy,  

Alex’s assessment is pretty much dead on.

For your example, I would typically do something like this 
(https://gist.github.com/alecthomas/d6240ccfca9ff307970e). Note that the 
order in which the systems are applied is fundamental.

The MovementSystem only deals with updating movement. Other systems can 
then utilise the updated data. The SpriteSystem implicitly relies on the 
fact that MovementSystem is executed first. This is not as clean from a 
design perspective as triggering events would be, but it is much, much 
faster.

Hope that helps.

Alec

PS. A recent commit added a const component<T>() 
(https://github.com/alecthomas/entityx/commit/5b8e0ae73b4a5c9e19050ceb2b045dd0f5f8b54e)
method.  


On Thursday, 26 June 2014 at 12:12 pm, Asmodehn Shade wrote:

> Hi,
> I am working on a coco2dx project with entityx as well.
> The way I see it is :
> Systems and Components work together from the basic original design of 
entity systems.
> The pace of change is made to be fast as it happens during the update cycle.
> Therefore a system can add a component to an entity and another system 
can get it from that entity and do the appropriate action. This is the 
proper way to communicate between systems imho.  
> Events and Managers have been added over the basic entity system design.
They add another layer to be able to divide and manage the complexity 
better.
> Events are triggered by systems or managers and can be caught by them too.
> But i see this communication as more sparse. Meaning one event will 
happen unexpectedly sometime, and has nothing todo with an entity ( 
otherwise, shouldnt the same information be in a component ? )  
> So for me Managers communicate with systems and themselves via events, 
independently of entities. Another level of abstraction that can help with
complex design.
> For exemple think of a GUI on top of a 3d view... you could have a 
manager for the 3d world. A manager for the ui. And they exchange info 
with events. But each entities managed by each system do not interact 
directly. So there are two "worlds" that are separate : the GUI world and 
the 3d world.  
> I hope this helps.
> --
> AlexV  
> On Jun 26, 2014 10:38 AM, "Jeremy Huffman" <jeremy@jeremyhuffman.com 
(mailto:jeremy@jeremyhuffman.com)> wrote:
> > Hi, I've been dabbling a bit with EntityX in a Cocos2d-x project. I 
may not be approaching this correctly, but I was thinking of using events 
to sync properties across different components in an Entity. For example I
have a Movement component that just has const members next_position and 
vector. I've wired an Event receiver SpriteMover to receive the 
ComponentAddedEvent<Movement>; it would then check and see if the entity 
has a Sprite component, and set a new position on the Sprite if found. The
rest of the game logic concerned with managing motion can ignore the 
sprites this way.  
> >  
> > It seems like this approach is discouraged by the fact that the Event 
received is a const. I can't assign or destroy components through the 
handle I get in the receive, or call non-const methods (like component<>) 
on any members there-in. Is this a hint that receive isn't the right place
to mutate game state? I can work around this by storing a reference to the
EntityManager when I construct my SpriteMover and then doing a get by 
ID...but thought I should at least ask in case I'm missing something here.
> >  
> > Thanks,
> >  
> > Jeremy

Re: [entityx] receive non-const event?

From:
Jeremy Huffman
Date:
2014-06-26 @ 10:58
Hi, thank you both, this really helps me understand the proper role for the
event system. I can see how it will be much faster to do it as you've
suggested Alec since we're handling all the components in a single
iteration for each system. Probably the code will be simpler to understand
as well - having lots of events wired up creating implicit behavior can
become confusing down the road.


On Wed, Jun 25, 2014 at 11:27 PM, Alec Thomas <alec@swapoff.org> wrote:

>  Hi Jeremy,
>
> Alex’s assessment is pretty much dead on.
>
> For your example, I would typically do something like this
> <https://gist.github.com/alecthomas/d6240ccfca9ff307970e>. Note that the
> order in which the systems are applied is fundamental.
>
> The MovementSystem *only* deals with updating movement. Other systems can
> then utilise the updated data. The SpriteSystem implicitly relies on the
> fact that MovementSystem is executed first. This is not as clean from a
> design perspective as triggering events would be, but it is much, *much*
>  faster.
>
> Hope that helps.
>
> Alec
>
> PS. A recent commit added a const component<T>()
> 
<https://github.com/alecthomas/entityx/commit/5b8e0ae73b4a5c9e19050ceb2b045dd0f5f8b54e>
>  method.
>
> On Thursday, 26 June 2014 at 12:12 pm, Asmodehn Shade wrote:
>
> Hi,
>
> I am working on a coco2dx project with entityx as well.
>
> The way I see it is :
>
> Systems and Components work together from the basic original design of
> entity systems.
> The pace of change is made to be fast as it happens during the update
> cycle.
> Therefore a system can add a component to an entity and another system can
> get it from that entity and do the appropriate action. This is the proper
> way to communicate between systems imho.
>
> Events and Managers have been added over the basic entity system design.
> They add another layer to be able to divide and manage the complexity
> better.
> Events are triggered by systems or managers and can be caught by them too.
> But i see this communication as more sparse. Meaning one event will happen
> unexpectedly sometime, and has nothing todo with an entity ( otherwise,
> shouldnt the same information be in a component ? )
>
> So for me Managers communicate with systems and themselves via events,
> independently of entities. Another level of abstraction that can help with
> complex design.
> For exemple think of a GUI on top of a 3d view... you could have a manager
> for the 3d world. A manager for the ui. And they exchange info with events.
> But each entities managed by each system do not interact directly. So there
> are two "worlds" that are separate : the GUI world and the 3d world.
>
> I hope this helps.
> --
> AlexV
> On Jun 26, 2014 10:38 AM, "Jeremy Huffman" <jeremy@jeremyhuffman.com>
> wrote:
>
> Hi, I've been dabbling a bit with EntityX in a Cocos2d-x project. I may
> not be approaching this correctly, but I was thinking of using events to
> sync properties across different components in an Entity. For example I
> have a Movement component that just has const members next_position and
> vector. I've wired an Event receiver SpriteMover to receive the
> ComponentAddedEvent<Movement>; it would then check and see if the entity
> has a Sprite component, and set a new position on the Sprite if found. The
> rest of the game logic concerned with managing motion can ignore the
> sprites this way.
>
> It seems like this approach is discouraged by the fact that the Event
> received is a const. I can't assign or destroy components through the
> handle I get in the receive, or call non-const methods (like component<>)
> on any members there-in. Is this a hint that receive isn't the right place
> to mutate game state? I can work around this by storing a reference to the
> EntityManager when I construct my SpriteMover and then doing a get by
> ID...but thought I should at least ask in case I'm missing something here.
>
> Thanks,
>
> Jeremy
>
>
>

Re: [entityx] receive non-const event?

From:
Asmodehn Shade
Date:
2014-07-03 @ 07:11
Actually if you are interested my project is there :

https://github.com/asmodehn/WkCocos

I recently added a Download system that uses entityx to manage the multiple
files download...

Quite early stage though, so feel free to contact me if you want more info.

Cheers,
--
AlexV
On Jun 26, 2014 7:59 PM, "Jeremy Huffman" <jeremy@jeremyhuffman.com> wrote:

> Hi, thank you both, this really helps me understand the proper role for
> the event system. I can see how it will be much faster to do it as you've
> suggested Alec since we're handling all the components in a single
> iteration for each system. Probably the code will be simpler to understand
> as well - having lots of events wired up creating implicit behavior can
> become confusing down the road.
>
>
> On Wed, Jun 25, 2014 at 11:27 PM, Alec Thomas <alec@swapoff.org> wrote:
>
>>  Hi Jeremy,
>>
>> Alex’s assessment is pretty much dead on.
>>
>> For your example, I would typically do something like this
>> <https://gist.github.com/alecthomas/d6240ccfca9ff307970e>. Note that the
>> order in which the systems are applied is fundamental.
>>
>> The MovementSystem *only* deals with updating movement. Other systems
>> can then utilise the updated data. The SpriteSystem implicitly relies on
>> the fact that MovementSystem is executed first. This is not as clean from a
>> design perspective as triggering events would be, but it is much, *much*
>>  faster.
>>
>> Hope that helps.
>>
>> Alec
>>
>> PS. A recent commit added a const component<T>()
>> 
<https://github.com/alecthomas/entityx/commit/5b8e0ae73b4a5c9e19050ceb2b045dd0f5f8b54e>
>>  method.
>>
>> On Thursday, 26 June 2014 at 12:12 pm, Asmodehn Shade wrote:
>>
>> Hi,
>>
>> I am working on a coco2dx project with entityx as well.
>>
>> The way I see it is :
>>
>> Systems and Components work together from the basic original design of
>> entity systems.
>> The pace of change is made to be fast as it happens during the update
>> cycle.
>> Therefore a system can add a component to an entity and another system
>> can get it from that entity and do the appropriate action. This is the
>> proper way to communicate between systems imho.
>>
>> Events and Managers have been added over the basic entity system design.
>> They add another layer to be able to divide and manage the complexity
>> better.
>> Events are triggered by systems or managers and can be caught by them too.
>> But i see this communication as more sparse. Meaning one event will
>> happen unexpectedly sometime, and has nothing todo with an entity (
>> otherwise, shouldnt the same information be in a component ? )
>>
>> So for me Managers communicate with systems and themselves via events,
>> independently of entities. Another level of abstraction that can help with
>> complex design.
>> For exemple think of a GUI on top of a 3d view... you could have a
>> manager for the 3d world. A manager for the ui. And they exchange info with
>> events. But each entities managed by each system do not interact directly.
>> So there are two "worlds" that are separate : the GUI world and the 3d
>> world.
>>
>> I hope this helps.
>> --
>> AlexV
>> On Jun 26, 2014 10:38 AM, "Jeremy Huffman" <jeremy@jeremyhuffman.com>
>> wrote:
>>
>> Hi, I've been dabbling a bit with EntityX in a Cocos2d-x project. I may
>> not be approaching this correctly, but I was thinking of using events to
>> sync properties across different components in an Entity. For example I
>> have a Movement component that just has const members next_position and
>> vector. I've wired an Event receiver SpriteMover to receive the
>> ComponentAddedEvent<Movement>; it would then check and see if the entity
>> has a Sprite component, and set a new position on the Sprite if found. The
>> rest of the game logic concerned with managing motion can ignore the
>> sprites this way.
>>
>> It seems like this approach is discouraged by the fact that the Event
>> received is a const. I can't assign or destroy components through the
>> handle I get in the receive, or call non-const methods (like component<>)
>> on any members there-in. Is this a hint that receive isn't the right place
>> to mutate game state? I can work around this by storing a reference to the
>> EntityManager when I construct my SpriteMover and then doing a get by
>> ID...but thought I should at least ask in case I'm missing something here.
>>
>> Thanks,
>>
>> Jeremy
>>
>>
>>
>