librelist archives

« back to archive

Eventless entityx

Eventless entityx

From:
Asmodehn Shade
Date:
2014-11-19 @ 06:45
Hello,

I am wondering what is the benefit of having Event concept in entityx.

Background : While developing a game with entityx for the last 6 months, me
and two other devs were learning Entity System concept. We already knew
about signal/Events concept though.

The result after 6 month of uses is that whenever we wanted to do something
, we intuitively used Events, as it is a glorified callback, and callback
concept is simple to grasp. However many times, we could have used a
component that could have been created at one point by one system, assigned
to one entity, and picked up by another system later, for the same result.

Now with the game almost finished, we have events everywhere, so much that
we can sometimes loose track of what is called when. the main point is that
Events can easily complexify the imperative code flow. And we have very
limited use of Entity System design, even if wherever we applied that
design the code is cleaner, easier to understand, and more maintainable.
As a result, we might soon starts replacing many of our events with
components.

So while this is because of our inexperience, I feel that having events in
entityx can be confusing, and I am wondering if it wouldn't be interesting
to have a simpler entityx without events.

Events still are very useful, but we should probably use them at a higher
level. More complex interactions between complex object, when we cant
really apply entity system design. However we should have less interactions
so the event code will still remain manageable...

What do you think ?
Is it doable ?
Is this something that entityx is aiming at ?
Or should I start working on a entityx-eventless fork ?

Thanks a lot !
--
AlexV

Re: [entityx] Eventless entityx

From:
Alec Thomas
Date:
2014-11-19 @ 23:16
It’s definitely possible to abuse events. Although some kind of system is 
necessary to notify when components and entities are added and removed, 
it’s possible this could become encoded in components or moved to simple 
callbacks.

I’m not opposed to removing events for EntityX 2.0, if an elegant 
alternative presents itself. In fact, the new system could be introduced 
while the event system is still in place… something like this 
(https://gist.github.com/alecthomas/500791d204531f6a6284) 
NotificationSystem could be a start, though it could be made more elegant 
if it were builtin to the core.

std::shared_ptr<NotificationSystem> notifications(new 
NotificationSystem<Position, Direction, …>());
systems.add(notifications);

…

Notification::Handle notification;
for (auto _ : entities.entities_with_components(notification)) {
  // Do something with notification.components_added, .components_removed,
or .created.
}
// Do something with NotificationSystem->destroyed...

The downside with this approach is that ordering of systems becomes 
critical. If system Z adds a component that system A is monitoring, A will
not be aware of the change. This could lead to subtle, hard to find bugs.

If you could create a ticket on GitHub, basically with your concerns and 
thoughts, it would be useful for tracking it for 2.0.

PS. I’ve just created milestone 2.0 
(https://github.com/alecthomas/entityx/milestones/2.0) for tracking these 
issues. I’ll try and backfill a bunch of ideas that have been discussed on
the mailing list.

> On Nov 19, 2014, at 5:45 PM, Asmodehn Shade <asmodehn@gmail.com 
(mailto:asmodehn@gmail.com)> wrote:
>  
> Hello,
>  
> I am wondering what is the benefit of having Event concept in entityx.
>  
> Background : While developing a game with entityx for the last 6 months,
me and two other devs were learning Entity System concept. We already knew
about signal/Events concept though.
>  
> The result after 6 month of uses is that whenever we wanted to do 
something , we intuitively used Events, as it is a glorified callback, and
callback concept is simple to grasp. However many times, we could have 
used a component that could have been created at one point by one system, 
assigned to one entity, and picked up by another system later, for the 
same result.
>  
> Now with the game almost finished, we have events everywhere, so much 
that we can sometimes loose track of what is called when. the main point 
is that Events can easily complexify the imperative code flow. And we have
very limited use of Entity System de sign, even if wherever we applied 
that design the code is cleaner, easier to understand, and more 
maintainable.
> As a result, we might soon starts replacing many of our events with components.
>  
> So while this is because of our inexperience, I feel that having events 
in entityx can be confusing, and I am wondering if it wouldn't be 
interesting to have a simpler entityx without events.
>  
> Events still are very useful, but we should probably use them at a 
higher level. More complex interactions between complex object, when we 
cant really apply entity system design. However we should have less 
interactions so the event code will still remain manageable...
>  
> What do you think ?
> Is it doable ?
> Is this something that entityx is aiming at ?
> Or should I start working on a entityx-eventless fork ?
>  
> Thanks a lot !
> --
> AlexV
>  

Re: [entityx] Eventless entityx

From:
Asmodehn Shade
Date:
2014-11-21 @ 03:32
Hi,

I just created https://github.com/alecthomas/entityx/issues/64. I let you
put the link to your gist and related ideas...

I also noticed https://github.com/alecthomas/entityx/issues/63 and I think
it is related. Let me explain in more details...
sorry in advance for the broad generalizations and the very simplistic
assumptions required to explain the idea in a few lines.

Entity System is a design pattern born from these facts :
- We naturally think with our language structure : "Subject Action Object".
When we design a game, we do the same : "I shoot the cat".
- Most well known computer languages are ( were ? ) imperative and to give
the illusion of multiple things happening at once, we have no choice but to
have a big fat loop.
- Entities are the Subject and the Object. Actions are done by Systems.
Entities hold data, System hold behavior. They can be split and called in a
nice loop that doesn't look so big after all.

So Entity System is for me one possible answer to the problem.
Another possible answer would be a completely concurrent one ( with our
current and future hardware and languages ) :

- I have many actors running in parallel
- They send messages to each other
=> The Actor model, which usually needs specifically designed languages or
frameworks to be easy enough to use.

For me an "Event" is a first step of the implementation of a messaging
system, going away from the imperative coding that entityx is there to
alleviate, towards the Actor model...
That is why it doesn't really belong to Entity system per say in my mind...

However we can, and we probably should for better efficiency, in the end,
mix these two designs...
As In : If I have 8 actors in my conceptual model and 2 CPUs when i run the
code, it will run 2 actors with each having a loop with 4 entities.

But I strongly feel that if we want to keep entityx easy enough to use and
to maintain, we should keep it minimal : only an entity system
implementation.

For concurrency, we could use entityx as a library in a new project (actorx
;) ?) , but I would prefer to keep entityx simple.

Cheers,

--
AlexV

2014-11-20 8:16 GMT+09:00 Alec Thomas <alec@swapoff.org>:

> It’s definitely possible to abuse events. Although some kind of system is
> necessary to notify when components and entities are added and removed,
> it’s possible this could become encoded in components or moved to simple
> callbacks.
>
> I’m not opposed to removing events for EntityX 2.0, if an elegant
> alternative presents itself. In fact, the new system could be introduced
> while the event system is still in place… something like this
> <https://gist.github.com/alecthomas/500791d204531f6a6284> NotificationSystem
> could be a start, though it could be made more elegant if it were builtin
> to the core.
>
> std::shared_ptr<NotificationSystem> notifications(new
> NotificationSystem<Position, Direction, …>());
> systems.add(notifications);
>
> …
>
> Notification::Handle notification;
> for (auto _ : entities.entities_with_components(notification)) {
>   // Do something with notification.components_added, .components_removed,
> or .created.
> }
> // Do something with NotificationSystem->destroyed...
>
> The downside with this approach is that ordering of systems becomes
> critical. If system Z adds a component that system A is monitoring, A will
> not be aware of the change. This could lead to subtle, hard to find bugs.
>
> If you could create a ticket on GitHub, basically with your concerns and
> thoughts, it would be useful for tracking it for 2.0.
>
> PS. I’ve just created milestone 2.0
> <https://github.com/alecthomas/entityx/milestones/2.0> for track ing
> these issues. I’ll try and backfill a bunch of ideas that have been
> discussed on the mailing list.
>
> On Nov 19, 2014, at 5:45 PM, Asmodehn Shade <asmodehn@gmail.com> wrote:
>
> Hello,
>
> I am wondering what is the benefit of having Event concept in entityx.
>
> Background : While developing a game with entityx for the last 6 months,
> me and two other devs were learning Entity System concept. We already knew
> about signal/Events concept though.
>
> The result after 6 month of uses is that whenever we wanted to do
> something , we intuitively used Events, as it is a glorified callback, and
> callback concept is simple to grasp. However many times, we could have used
> a component that could have been created at one point by one system,
> assigned to one entity, and picked up by another system later, for the s
> ame result.
>
> Now with the game almost finished, we have events everywhere, so much that
> we can sometimes loose track of what is called when. the main point is that
> Events can easily complexify the imperative code flow. And we have very
> limited use of Entity System de sign, even if wherever we applied that
> design the code is cleaner, easier to understand, and more maintainable.
> As a result, we might soon starts replacing many of our events with
> components.
>
> So while this is because of our inexperience, I feel that having events in
> entityx can be confusing, and I am wondering if it wouldn't be interesting
> to have a simpler entityx without events.
>
> Events still are very useful, but we should probably use them at a higher
> level. More complex interactions between complex object, when we cant
> really apply entity system design. However we should have less interactions
> so the event code will still remain manag eable...
>
> What do you think ?
> Is it doable ?
> Is this something that entityx is aiming at ?
> Or should I start working on a entityx-eventless fork ?
>
> Thanks a lot !
> --
> AlexV
>
>

Re: [entityx] Eventless entityx

From:
Alec Thomas
Date:
2014-11-22 @ 05:58

On Friday, 21 November 2014 at 2:32 pm, Asmodehn Shade wrote:

> Hi,
>  
> I just created https://github.com/alecthomas/entityx/issues/64. I let 
you put the link to your gist and related ideas...
>  
> I also noticed https://github.com/alecthomas/entityx/issues/63 and I 
think it is related. Let me explain in more details...  
> sorry in advance for the broad generalizations and the very simplistic 
assumptions required to explain the idea in a few lines.
>  
> Entity System is a design pattern born from these facts :
> - We naturally think with our language structure : "Subject Action 
Object". When we design a game, we do the same : "I shoot the cat".
> - Most well known computer languages are ( were ? ) imperative and to 
give the illusion of multiple things happening at once, we have no choice 
but to h ave a big fat loop.
> - Entities are the Subject and the Object. Actions are done by Systems. 
Entities hold data, System hold behavior. They can be split and called in 
a nice loop that doesn't look so big after all.
>  
> So Entity System is for me one possible answer to the problem.
> Another possible answer would be a completely concurrent one ( with our 
current and future hardware and languages ) :  
>  
> - I have many actors running in parallel
> - They send messages to each other
> => The Actor model, which usually needs specifically designed languages 
or frameworks to be easy enough to use.
>  
> For me an "Event" is a first step of the implementation of a messaging 
system, going away from the imperative coding that entityx is there to 
alleviate, towards the Actor model...
> That is why it doesn't really belong to Entity system per say in my mind...

Events are a tool. Over use of them can cause complexity, yes, but it’s 
really not any indication of some theoretical progression towards a 
general purpose actor model. I can’t comprehend why you would think that 
would be the case?
>  
> However we can, and we pr obably should for better efficiency, in the 
end, mix these two designs...
> As In : If I have 8 actors in my conceptual model and 2 CPUs when i run 
the code, it will run 2 actors with each having a loop with 4 entities.
>  
> But I strongly feel that if we want to keep entityx easy enough to use 
and to maintain, we should keep it minimal : only an entity system 
implementation.
>  
> For concurrency, we could use entityx as a library in a new project 
(actorx ;) ?) , but I would prefer to keep entityx simple.

From this discussion, it seems like perhaps you’re imagining EntityX 
moving to a much more complex design? That is not the case. The 
investigation of concurrency is to see if there’s an elegant solution to 
facilitate concurrency within the current design, not to change EntityX 
into a general purpose concurrency solution. I’m not even sure why actor 
models came up?

>  
> Cheers,
>  
> --
> AlexV  
> 2014-11-20 8:16 GMT+09:00 Alec Thomas <alec@swapoff.org 
(mailto:alec@swapoff.org)>:
> > It’s definitely possible to abuse events. Although some kind of system
is necessary to notify when components and entities are added and removed,
it’s possible this could become encoded in components or moved to simple 
callbacks.
> >  
> > I’m not opposed to removing events for EntityX 2.0, if an elegant 
alternative presents itself. In fact, the new system could be introduced 
while the event system is still in place… something like this 
(https://gist.github.com/alecthomas/500791d204531f6a6284) 
NotificationSystem could be a start, though it could be made more elegant 
if it were builtin to the core.
> >  
> > std::shared _ptr<NotificationSystem> notifications(new 
NotificationSystem<Position, Direction, …>());
> > systems.add(notifications);
> >  
> > …
> >  
> > Notification::Handle notification;
> > for (auto _ : entities.entities_with_components(notification)) {
> >   // Do something with notification.components_added, 
.components_removed, or .created.
> > }
> > // Do something with NotificationSystem->destroyed...
> >  
> > The downside with this approach is that ordering of systems becomes 
critical. If system Z adds a component that system A is monitoring, A will
not be aware of the change. This could lead to subtle, hard to find bugs.
> If you could create a ticket on GitHub, basically with your concerns and
thoughts, it would be useful for tracking it for 2.0.
>  
> PS. I’ve just created milestone 2.0 
(https://github.com/alecthomas/entityx/milestones/2.0) for track ing these
issues. I’ll try and backfill a bunch of ideas that have been discussed on
the mailing list.
>  
> > On Nov 19, 2014, at 5:45 PM, Asmodehn Shade <asmodehn@gmail.com 
(mailto:asmodehn@gmail.com)> wrote:
> >  
> > Hello,
> >  
> > I am wondering what is the benefit of having Event concept in entityx.
> >  
> > Background : While developing a game with entityx for the last 6 
months, me and two other devs were learning Entity System concept. We 
already knew about signal/Events concept though.
> >  
> > The result after 6 month of uses is that whenever we wanted to do 
something , we intuitively used Events, as it is a glorified callback, and
callback concept is simple to grasp. However many times, we could have 
used a component that could have been created at one point by one system, 
assigned to one entity, and picked up by another system later, for the s 
ame result.
> >  
> > Now with the game almost finished, we have events everywhere, so much 
that we can sometimes loose track of what is called when. the main point 
is that Events can easily complexify the imperative code flow. And we have
very limited use of Entity System de sign, even if wherever we applied 
that design the code is cleaner, easier to understand, and more 
maintainable.
> > As a result, we might soon starts replacing many of our events with 
components.
> >  
> > So while this is because of our inexperience, I feel that having 
events in entityx can be confusing, and I am wondering if it wouldn't be 
interesting to have a simpler entityx without events.
> >  
> > Events still are very useful, but we should probably use them at a 
higher level. More complex interactions between complex object, when we 
cant really apply entity system design. However we should have less 
interactions so the event code will still remain manag eable...
> >  
> > What do you think ?
> > Is it doable ?
> > Is this something that entityx is aiming at ?
> > Or should I start working on a entityx-eventless fork ?
> >  
> > Thanks a lot !
> > --
> > AlexV
> >  
>  
>  
>  

Re: [entityx] Eventless entityx

From:
Asmodehn Shade
Date:
2014-11-23 @ 00:10
Ok, I understand.

I started mentioning actors, because after abusing events, i need another
concept to harness the complexity of the code...

The control flow is inverted since now many of my objects are waiting for
events before they do something...

I use entity design at a low level. They trigger events. And at a higher
level, entities are not useful/usable and i m left with a lot of different
events that can happen at anytime...

A possible design solution for me is to have entities ( without using
events to keep the simplicity ) at the low level and actors at a higher
level ( maybe not the general purpose actor model, but some light version
of it ). But I'll see what I can come up with...

Anyway, thanks for the precision.

Cheers.
On Nov 22, 2014 2:58 PM, "Alec Thomas" <alec@swapoff.org> wrote:

>
>  On Friday, 21 November 2014 at 2:32 pm, Asmodehn Shade wrote:
>
> Hi,
>
> I just created https://github.com/alecthomas/entityx/issues/64. I let you
> put the link to your gist and related ideas...
>
> I also noticed https://github.com/alecthomas/entityx/issues/63 and I
> think it is related. Let me explain in more details...
> sorry in advance for the broad generalizations and the very simplistic
> assumptions required to explain the idea in a few lines.
>
> Entity System is a design pattern born from these facts :
> - We naturally think with our language structure : "Subject Action
> Object". When we design a game, we do the same : "I shoot the cat".
> - Most well known computer languages are ( were ? ) imperative and to give
> the illusion of multiple things happening at once, we have no choice but to
> h ave a big fat loop.
> - Entities are the Subject and the Object. Actions are done by Systems.
> Entities hold data, System hold behavior. They can be split and called in a
> nice loop that doesn't look so big after all.
>
> So Entity System is for me one possible answer to the problem.
> Another possible answer would be a completely concurrent one ( with our
> current and future hardware and languages ) :
>
> - I have many actors running in parallel
> - They send messages to each other
> => The Actor model, which usually needs specifically designed languages or
> frameworks to be easy enough to use.
>
> For me an "Event" is a first step of the implementation of a messaging
> system, going away from the imperative coding that entityx is there to
> alleviate, towards the Actor model...
> That is why it doesn't really belong to Entity system per say in my mind...
>
>
> Events are a tool. Over use of them can cause complexity, yes, but it’s
> really not any indication of some theoretical progression towards a general
> purpose actor model. I can’t comprehend why you would think that would be
> the case?
>
>
> However we can, and we pr obably should for better efficiency, in the end,
> mix these two designs...
> As In : If I have 8 actors in my conceptual model and 2 CPUs when i run
> the code, it will run 2 actors with each having a loop with 4 entities.
>
> But I strongly feel that if we want to keep entityx easy enough to use and
> to maintain, we should keep it minimal : only an entity system
> implementation.
>
> For concurrency, we could use entityx as a library in a new project
> (actorx ;) ?) , but I would prefer to keep entityx simple.
>
>
> From this discussion, it seems like perhaps you’re imagining EntityX
> moving to a much more complex design? That is not the case. The
> investigation of concurrency is to see if there’s an elegant solution to
> facilitate concurrency within the current design, not to change EntityX
> into a general purpose concurrency solution. I’m not even sure why actor
> models came up?
>
>
> Cheers,
>
> --
> AlexV
>
> 2014-11-20 8:16 GMT+09:00 Alec Thomas <alec@swapoff.org>:
>
> It’s definitely possible to abuse events. Although some kind of system is
> necessary to notify when components and entities are added and removed,
> it’s possible this could become encoded in components or moved to simple
> callbacks.
>
> I’m not opposed to removing events for EntityX 2.0, if an elegant
> alternative presents itself. In fact, the new system could be introduced
> while the event system is still in place… something like this
> <https://gist.github.com/alecthomas/500791d204531f6a6284> NotificationSystem
> could be a start, though it could be made more elegant if it were builtin
> to the core.
>
> std::shared _ptr<NotificationSystem> notifications(new
> NotificationSystem<Position, Direction, …>());
> systems.add(notifications);
>
> …
>
> Notification::Handle notification;
> for (auto _ : entities.entities_with_components(notification)) {
>   // Do something with notification.components_added, .components_removed,
> or .created.
> }
> // Do something with NotificationSystem->destroyed...
>
> The downside with this approach is that ordering of systems becomes
> critical. If system Z adds a component that system A is monitoring, A will
> not be aware of the change. This could lead to subtle, hard to find bugs.
>
> If you could create a ticket on GitHub, basically with your concerns and
> thoughts, it would be useful for tracking it for 2.0.
>
> PS. I’ve just created milestone 2.0
> <https://github.com/alecthomas/entityx/milestones/2.0> for track ing
> these issues. I’ll try and backfill a bunch of ideas that have been
> discussed on the mailing list.
>
> On Nov 19, 2014, at 5:45 PM, Asmodehn Shade <asmodehn@gmail.com> wrote:
>
> Hello,
>
> I am wondering what is the benefit of having Event concept in entityx.
>
> Background : While developing a game with entityx for the last 6 months,
> me and two other devs were learning Entity System concept. We already knew
> about signal/Events concept though.
>
> The result after 6 month of uses is that whenever we wanted to do
> something , we intuitively used Events, as it is a glorified callback, and
> callback concept is simple to grasp. However many times, we could have used
> a component that could have been created at one point by one system,
> assigned to one entity, and picked up by another system later, for the s
> ame result.
>
> Now with the game almost finished, we have events everywhere, so much that
> we can sometimes loose track of what is called when. the main point is that
> Events can easily complexify the imperative code flow. And we have very
> limited use of Entity System de sign, even if wherever we applied that
> design the code is cleaner, easier to understand, and more maintainable.
> As a result, we might soon starts replacing many of our events with
> components.
>
> So while this is because of our inexperience, I feel that having events in
> entityx can be confusing, and I am wondering if it wouldn't be interesting
> to have a simpler entityx without events.
>
> Events still are very useful, but we should probably use them at a higher
> level. More complex interactions between complex object, when we cant
> really apply entity system design. However we should have less interactions
> so the event code will still remain manag eable...
>
> What do you think ?
> Is it doable ?
> Is this something that entityx is aiming at ?
> Or should I start working on a entityx-eventless fork ?
>
> Thanks a lot !
> --
> AlexV
>
>
>
>