librelist archives

« back to archive

Actors vs Entities

Actors vs Entities

From:
Asmodehn Shade
Date:
2014-10-22 @ 04:22
Hello,

Regarding concurrent programming with entityx, i usually encapsulate one
thread in one component.

And when i want callback some other functions from that thread things can
quickly become complicated.

Luckily entity systems design is based on an update loop, so i can always
queue up callbacks to be done on next update.
Something that many developers also end up doing when they have too many
events to know what is actually happening.

One could also parallelize the looping on the entity list that has to be
done in each system... but the problem remain the same : when calling
callbacks, one has to be careful of the context, and specifically the
lifetime of the instances accessed by the callback.

So complexity can be somehow managed when dealing with entity systems, but
async progamming is still hard to use.

In that aspect, i wonder how it could be used with other design concept, or
programming paradigm...

For example could we use actor programming along with entity system ( CAF
and entityx ) to improve our ability to manage complex concurrent
programming ?

How should one go about doing something like this ? Have an actor being a
holder of eventManager along with systemManager and entityManager ( similar
to the old Manager helper ) ?

I m interested at finding a simple abstract model ( layers ? ) that would
help us structure highly concurrent software... not only concurrent as in "
with multiple threads" but with events that can come up any time, needing
some context to be able to execute some code ( so not in a purely
functional language )

Somehow i feel the answer could be an alternance of concurrent threads and
imperative update/event handling loop.

Anyone else has some idea about this topic ?

Ultimately it relates to "how to use entityx into your game code ?" In the
case where there are many async events around ( user click, http answer
that you waited for 10 seconds, multithread computing ai, etc. )

That is what i m doing at the moment, and i feel i am in need of another
concept to add to entity system to manage code complexity...

Thanks a lot !

Re: [entityx] Actors vs Entities

From:
Alec Thomas
Date:
2014-10-22 @ 23:51

On Wednesday, 22 October 2014 at 3:22 pm, Asmodehn Shade wrote:

> Hello,
> Regarding concurrent programming with entityx, i usually encapsulate one
thread in one component.
> And when i want callback some other functions from that thread things 
can quickly become complicated.
> Luckily entity systems design is based on an update loop, so i can 
always queue up callbacks to be done on next update.
> Something that many developers also end up doing when they have too many
events to know what is actually happening.  
> One could also parallelize the looping on the entity list that has to be
done in each system... but the problem remain the same : when calling 
callbacks, one has to be careful of the context, and specifically the 
lifetime of the instances accessed by the callback.
> So complexity can be somehow managed when dealing with entity systems, 
but async progamming is still hard to use.
> In that aspect, i wonder how it could be used with other design concept,
or programming paradigm...
> For example could we use actor programming along with entity system ( 
CAF and entityx ) to improve our ability to manage complex concurrent 
programming ?
> How should one go about doing something like this ? Have an actor being 
a holder of eventManager along with systemManager and entityManager ( 
similar to the old Manager helper ) ?
> I m interested at finding a simple abstract model ( layers ? ) that 
would help us structure highly concurrent software... not only concurrent 
as in " with multiple threads" but with events that can come up any time, 
needing some context to be able to execute some code ( so not in a purely 
functional language )
> Somehow i feel the answer could be an alternance of concurrent threads 
and imperative update/event handling loop.
> Anyone else has some idea about this topic ?
>  
>  


There are two solutions that I think are viable:

If you have a physics system (for example) in your game, running the 
physics simulation in a thread and synchronising with the entities every 
frame seems like it would work quite well.  This is really a case-by-case 
solution.

The second proposal is more difficult to implement in an efficient manner,
but is more general purpose. Each system that can be run in parallel 
receives an immutable copy of the entities at the beginning of the frame. 
Mutations are queued and merged together at the end of the frame. This is 
obviously easy to describe and quite difficult to implement, and the 
details would be tricky. Here’s a talk 
(http://michaelshaw.github.io/game_talk/game.html#/23) describing one 
possible implementation in Scala. I think this is a pretty interesting 
approach, but it might be better to be a separate project as one of the 
appeals of EntityX (IMO) is its relative simplicity.

> Ultimately it relates to "how to use entityx into your game code ?" In 
the case where there are many async events around ( user click, http 
answer that you waited for 10 seconds, multithread computing ai, etc. )  
> That is what i m doing at the moment, and i feel i am in need of another
concept to add to entity system to manage code complexity...
> Thanks a lot !
>  
>  

Re: [entityx] Actors vs Entities

From:
Asmodehn Shade
Date:
2014-10-23 @ 00:25
Thank you for the link, interesting indeed...

I hope i ll can make some time to look more into this...

I ll let you know if i get an interesting example running.
On Oct 23, 2014 8:52 AM, "Alec Thomas" <alec@swapoff.org> wrote:

>
>  On Wednesday, 22 October 2014 at 3:22 pm, Asmodehn Shade wrote:
>
> Hello,
>
> Regarding concurrent programming with entityx, i usually encapsulate one
> thread in one component.
>
> And when i want callback some other functions from that thread things can
> quickly become complicated.
>
> Luckily entity systems design is based on an update loop, so i can always
> queue up callbacks to be done on next update.
> Something that many developers also end up doing when they have too many
> events to know what is actually happening.
>
> One could also parallelize the looping on the entity list that has to be
> done in each system... but the problem remain the same : when calling
> callbacks, one has to be careful of the context, and specifically the
> lifetime of the instances accessed by the callback.
>
> So complexity can be somehow managed when dealing with entity systems, but
> async progamming is still hard to use.
>
> In that aspect, i wonder how it could be used with other design concept,
> or programming paradigm...
>
> For example could we use actor programming along with entity system ( CAF
> and entityx ) to improve our ability to manage complex concurrent
> programming ?
>
> How should one go about doing something like this ? Have an actor being a
> holder of eventManager along with systemManager and entityManager ( similar
> to the old Manager helper ) ?
>
> I m interested at finding a simple abstract model ( layers ? ) that would
> help us structure highly concurrent software... not only concurrent as in "
> with multiple threads" but with events that can come up any time, needing
> some context to be able to execute some code ( so not in a purely
> functional language )
>
> Somehow i feel the answer could be an alternance of concurrent threads and
> imperative update/event handling loop.
>
> Anyone else has some idea about this topic ?
>
>
> There are two solutions that I think are viable:
>
> If you have a physics system (for example) in your game, running the
> physics simulation in a thread and synchronising with the entities every
> frame seems like it would work quite well.  This is really a case-by-case
> solution.
>
> The second proposal is more difficult to implement in an efficient manner,
> but is more general purpose. Each system that can be run in parallel
> receives an immutable copy of the entities at the beginning of the frame.
> Mutations are queued and merged together at the end of the frame. This is
> obviously easy to describe and quite difficult to implement, and the
> details would be tricky. Here’s a talk
> <http://michaelshaw.github.io/game_talk/game.html#/23> describing one
> possible implementation in Scala. I think this is a pretty interesting
> approach, but it might be better to be a separate project as one of the
> appeals of EntityX (IMO) is its relative simplicity.
>
> Ultimately it relates to "how to use entityx into your game code ?" In the
> case where there are many async events around ( user click, http answer
> that you waited for 10 seconds, multithread computing ai, etc. )
>
> That is what i m doing at the moment, and i feel i am in need of another
> concept to add to entity system to manage code complexity...
>
> Thanks a lot !
>
>
>