Post by Admin on Jul 16, 2016 4:27:53 GMT
Maxim Zaks @mzaks Sep 06 2015 00:00
I get your point. I guess now me and @sschmid has more stuff to discuss on Monday
However it is interesting that it didn't bothered us yet. I have to think a bit deeper about it.
@gjroelofs and I will add this write up to the Wiki.
CodePoKE @gjroelofs Sep 06 2015 00:03
To be honest; this isn't my first rodeo with ECS & Code Generation
I built it around Xtend and allows the same syntax as your code in Java with Artemis.
I've seen what can go wrong in projects which is why I wanted to open up the discussion.
To be honest; the primary thing of interest in Entitas (to me) isn't the component syntax.
It's the reactive driven design that is possible
which mixes FRP with ECS well.
Maxim Zaks @mzaks Sep 06 2015 00:04
yes this is generally what distinguish us from other ECS implementations.
CodePoKE @gjroelofs Sep 06 2015 00:05
Well; funnily enough the Artemis-ODB (Java) branch seems to have caching / pooling of components (but not the reactive design, perse)
And the Artemis C# port seems to have a proper reactive design.
Maxim Zaks @mzaks Sep 06 2015 00:05
CodePoKE @gjroelofs Sep 06 2015 00:06
Ain't no happiness, nowhere
junkdog @junkdog makes a note about looking into the specifics of Entitas and the Artemis C# port.
CodePoKE @gjroelofs Sep 06 2015 00:07
@junkdog ODB is miles ahead obviously; I'm not going traitor
gjroelofs @gjroelofs hides
Adrian Papari @junkdog Sep 06 2015 00:08
i saw the presentation you guys gave at the unity conference. interesting stuff, will surely use it if i'm ever using unity again.
@gjroelofs no, don't run away!
CodePoKE @gjroelofs Sep 06 2015 00:09
I think we (as in you) should look into the reactive design
My only let down so far is that you can subscribe to a strongly-typed component event. E.g.; only to a specific type of Component.
Sadly C# isn't really familiar with multiple dispatch
@mzaks I'm also having some line-ending issues in the tests of the code generation
I solved it for now by unifying the line-endings in the check
The code seems to use CLRF / RF intermixed throughout.
Maxim Zaks @mzaks Sep 06 2015 00:20
@gjroelofs this is due to OSX / Windows I guess. @sschmid is the gate keeper of the repo and tests
@junkdog thank you for the kind words.
CodePoKE @gjroelofs Sep 06 2015 03:16
@mzaks @sschmid Is the Entity lifecycle documented somewhere?
Should I use Pool.DestroyEntity(e), e.destroy() or e.Release()?
And if I need to use Pool.DestroyEntity(e), is there a way to destroy the entity without knowing what pool it comes from?
Maxim Zaks @mzaks Sep 06 2015 05:50
@gjroelofs
You get entities through querying a pool therefor it is always clear which pool to use for destroy.
e.destroy method is internal and e.Release has something to do with automatic reference counting. Which you only need if you want to hold a reference to an entity somewhere else (group, group-observer and reactive systems already do it for you so you don't have to worry in normal case). Than you have to manually retain and when you don't need the entity you should release it. This is due to the fact that destroyed entities are should be reused at some point. We do it to reduce garbage collection execution.
This looks like another Wiki Article
CodePoKE @gjroelofs Sep 06 2015 06:17
I'm currently constructing some Unity Editor integrations around Entitas (Tying entities to GameObject and ensuring survival through scene load/reload) and I've come to quite some occasions where I do not know the Pool used to destroy the Entity.
If the Pool is required, it should at least be a reference in Entity?
The same type of issue has now happened with Components and Matchers. I'm currently constructing a Tag implementation (to keep track of the GO <-> Entity relation) which I want to re-use between projects. This implementation should be agnostic over Pools.
(E.g.: it should find the proper Entity in a Pool, regardless of the Pool it is stuck into, matching on a Tag Component.)
However, a Matcher (/ component id) is currently tied to a concrete implementation of a pool.
In short; I can't construct a Matcher given a Pool & Entity instance on a type that I know.
(I could do some tricks with statically keeping the ID, but that won't win any beauty prizes.)
In short; I think maybe the API should be extended to cope with the agnostic cases as well?
CodePoKE @gjroelofs Sep 06 2015 22:57
I added in some documentation on the lifecycle of Entity/Group/Pool to reflect the questions I asked above, and some head scratchers I found while working with Entity events :-)
I get your point. I guess now me and @sschmid has more stuff to discuss on Monday
However it is interesting that it didn't bothered us yet. I have to think a bit deeper about it.
@gjroelofs and I will add this write up to the Wiki.
CodePoKE @gjroelofs Sep 06 2015 00:03
To be honest; this isn't my first rodeo with ECS & Code Generation
I built it around Xtend and allows the same syntax as your code in Java with Artemis.
I've seen what can go wrong in projects which is why I wanted to open up the discussion.
To be honest; the primary thing of interest in Entitas (to me) isn't the component syntax.
It's the reactive driven design that is possible
which mixes FRP with ECS well.
Maxim Zaks @mzaks Sep 06 2015 00:04
yes this is generally what distinguish us from other ECS implementations.
CodePoKE @gjroelofs Sep 06 2015 00:05
Well; funnily enough the Artemis-ODB (Java) branch seems to have caching / pooling of components (but not the reactive design, perse)
And the Artemis C# port seems to have a proper reactive design.
Maxim Zaks @mzaks Sep 06 2015 00:05
CodePoKE @gjroelofs Sep 06 2015 00:06
Ain't no happiness, nowhere
junkdog @junkdog makes a note about looking into the specifics of Entitas and the Artemis C# port.
CodePoKE @gjroelofs Sep 06 2015 00:07
@junkdog ODB is miles ahead obviously; I'm not going traitor
gjroelofs @gjroelofs hides
Adrian Papari @junkdog Sep 06 2015 00:08
i saw the presentation you guys gave at the unity conference. interesting stuff, will surely use it if i'm ever using unity again.
@gjroelofs no, don't run away!
CodePoKE @gjroelofs Sep 06 2015 00:09
I think we (as in you) should look into the reactive design
My only let down so far is that you can subscribe to a strongly-typed component event. E.g.; only to a specific type of Component.
Sadly C# isn't really familiar with multiple dispatch
@mzaks I'm also having some line-ending issues in the tests of the code generation
I solved it for now by unifying the line-endings in the check
The code seems to use CLRF / RF intermixed throughout.
Maxim Zaks @mzaks Sep 06 2015 00:20
@gjroelofs this is due to OSX / Windows I guess. @sschmid is the gate keeper of the repo and tests
@junkdog thank you for the kind words.
CodePoKE @gjroelofs Sep 06 2015 03:16
@mzaks @sschmid Is the Entity lifecycle documented somewhere?
Should I use Pool.DestroyEntity(e), e.destroy() or e.Release()?
And if I need to use Pool.DestroyEntity(e), is there a way to destroy the entity without knowing what pool it comes from?
Maxim Zaks @mzaks Sep 06 2015 05:50
@gjroelofs
You get entities through querying a pool therefor it is always clear which pool to use for destroy.
e.destroy method is internal and e.Release has something to do with automatic reference counting. Which you only need if you want to hold a reference to an entity somewhere else (group, group-observer and reactive systems already do it for you so you don't have to worry in normal case). Than you have to manually retain and when you don't need the entity you should release it. This is due to the fact that destroyed entities are should be reused at some point. We do it to reduce garbage collection execution.
This looks like another Wiki Article
CodePoKE @gjroelofs Sep 06 2015 06:17
I'm currently constructing some Unity Editor integrations around Entitas (Tying entities to GameObject and ensuring survival through scene load/reload) and I've come to quite some occasions where I do not know the Pool used to destroy the Entity.
If the Pool is required, it should at least be a reference in Entity?
The same type of issue has now happened with Components and Matchers. I'm currently constructing a Tag implementation (to keep track of the GO <-> Entity relation) which I want to re-use between projects. This implementation should be agnostic over Pools.
(E.g.: it should find the proper Entity in a Pool, regardless of the Pool it is stuck into, matching on a Tag Component.)
However, a Matcher (/ component id) is currently tied to a concrete implementation of a pool.
In short; I can't construct a Matcher given a Pool & Entity instance on a type that I know.
(I could do some tricks with statically keeping the ID, but that won't win any beauty prizes.
)In short; I think maybe the API should be extended to cope with the agnostic cases as well?
CodePoKE @gjroelofs Sep 06 2015 22:57
I added in some documentation on the lifecycle of Entity/Group/Pool to reflect the questions I asked above, and some head scratchers I found while working with Entity events :-)
