Implementing IFamily

[Bryan Bozzi]

Hey there,

I'm trying to implement IFamily but it's pretty difficult since the add and remove on NodeList are internal. What am I missing here?

Thanks,

Bryan

[Michael Cann]

Families are managed by the engine, you shouldnt have to add or remove nodes external from the engne. You add or remove nodes to a family by adding or removing components from an entity and thus altering whether it matches that family or not.

You shouldnt have to ever implement IFamily. What is your use case?

Mike

--
You received this message because you are subscribed to the Google Groups "Ash Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ash-framework+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/ash-framework.
For more options, visit https://groups.google.com/d/optout.

--

Mike Cann
http://www.mikecann.co.uk/

@mikeysee

[Bryan Bozzi]

I guess I was trying to think of a way that a Family could support inheritance. Like if you have some AbstractComponent that you'd like to extend into a dozen classes but still iterate them all in the same System.

For a really simplified example. Maybe you have an AbstractNumberGeneratorComponent and you implement RandomNumberGeneratorComponent and PrimeNumberGeneratorComponent. You want to use these within a single System so you want a NodeList of Entities that have an implementation of AbstractNumberGeneratorComponent.

I know there are ways to do the example above without implementing an IFamily but it might be easier.

On Sunday, January 22, 2017 at 7:00:41 PM UTC-5, Michael Cann wrote:

Families are managed by the engine, you shouldnt have to add or remove nodes external from the engne. You add or remove nodes to a family by adding or removing components from an entity and thus altering whether it matches that family or not.

You shouldnt have to ever implement IFamily. What is your use case?

Mike

On 22 January 2017 at 11:32, Bryan Bozzi <bryan...@gmail.com> wrote:

Hey there,

I'm trying to implement IFamily but it's pretty difficult since the add and remove on NodeList are internal. What am I missing here?

Thanks,

Bryan

--
You received this message because you are subscribed to the Google Groups "Ash Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ash-framewor...@googlegroups.com.

Visit this group at https://groups.google.com/group/ash-framework.
For more options, visit https://groups.google.com/d/optout.

[Bryan Bozzi]

I guess another example I can think of off hand is if you have an AbstractParticleComponent then you make twenty implementations. If you want one ParticleSystem that draws all of these types of particles how would you do that? Especially if you want an entity to be able to have multiple ParticleComponent implementations added to it.

Currently, wouldn't you need to make a Node and System per particle Component? Or a System with a NodeList reference per particle Component type?

If the Families dictionary on engine was public you could create and add a ParticleNodeFamily which creates a NodeList containing all entities that have an implementation of AbstractParticleComponent. Now your entities could contain multiple particle components and all be rendered by the same system.

Again, this is just one example I'm thinking of. Maybe there is a better way to do this.

On Sunday, January 22, 2017 at 7:00:41 PM UTC-5, Michael Cann wrote:

Families are managed by the engine, you shouldnt have to add or remove nodes external from the engne. You add or remove nodes to a family by adding or removing components from an entity and thus altering whether it matches that family or not.

You shouldnt have to ever implement IFamily. What is your use case?

Mike

On 22 January 2017 at 11:32, Bryan Bozzi <bryan...@gmail.com> wrote:

Hey there,

I'm trying to implement IFamily but it's pretty difficult since the add and remove on NodeList are internal. What am I missing here?

Thanks,

Bryan

--
You received this message because you are subscribed to the Google Groups "Ash Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ash-framewor...@googlegroups.com.

Visit this group at https://groups.google.com/group/ash-framework.
For more options, visit https://groups.google.com/d/optout.

[Michael Cann]

Hi Bryan,

I think you arent thinking small enough. You should be breaking down your particle into bits that can be used by a single system.

For your Particle example. Rather than having many different implementations of an abstract base component you instead broke it up so you had a "RenderingSystem" which operates on an entity that has a "Position"" and "Sprite" components then you had a "MovementSystem" which operates on a "Position" and "Velocity" and perhaps a "SpawningSystem" which operates on a "Spawner" and "Position" components you wouldnt need to have a bunch of implementations of a base class.

Another way of thinking about it. Perhaps in your random number example. Say you had a "RandomNumberGeneratorComponent" then inside there you had a property that was of type "IRandomGenerator" that could also work. Then you would just set it up at the start to contain whatever type of random generator you wanted. Then any system that wanted a random number generator would just look for a "RandomNumberGeneratorComponent" and then access the "IRandomGenerator" property on it.

Does that help? 

Mike

To unsubscribe from this group and stop receiving emails from it, send an email to ash-framework+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/ash-framework.
For more options, visit https://groups.google.com/d/optout.

[Bryan Bozzi]

Those do sound like pretty good solutions. For ease of use I would prefer that a specific entity have a component which indicates that the entity is emitting particles of a certain type. It seems easier to manage that way. So I guess a ParticleSystem would look for an entity with a PositionComponent and a ParticleEmitterComponent which has a list of ParticleDescriptors for the kinds of particles the entity is emitting? Then the ParticleSystem could make particle Entities (PositionComponent, SpriteComponent) and those would be rendered by the RenderSystem. This approach would work of course, but I will need to add functionality to easily add and remove particles from the ParticleEmitterComponent. This functionality is the kind of thing that I was hoping to leverage Ash for.

The same thing implemented with a Family would have a variety of ParticleComponents which a ParticleSystem would iterate, spawn particle Entities. So if your player is on fire you can leverage Ash to add/remove FireParticleComponent plus a number of other types if you wanted. I do see how this doesn't exactly fit how the framework was intended to be used. Perhaps I'm still thinking a little to object oriented.

[Michael Cann]

Perhaps I'm still thinking a little to object oriented.

Precisely. You have to change the way you think about things when dealing with ECS.

 So if your player is on fire you can leverage Ash to add/remove FireParticleComponent plus a number of other types if you wanted. 

To do this what I would do would be to have a static helper class call it something like "ParticlesAttacher" and then have function like "static void AttachFireParticicleEmitter(Entity entity)" which would then attach the necessary components to make it emit. Another way would be that "AttachFireParticicleEmitter" would create a whole new entity, with the required components, then have a "Follow" component which would follow a target Entity, in effect making it a hierarchical structure.

This approach would work of course, but I will need to add functionality to easily add and remove particles from the ParticleEmitterComponent. This functionality is the kind of thing that I was hoping to leverage Ash for.

You would have a "ParticleDieingComponent" that would have an accompanying system. You just add that component whenever you want to remove the entity.

Mike

 

To unsubscribe from this group and stop receiving emails from it, send an email to ash-framework+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/ash-framework.
For more options, visit https://groups.google.com/d/optout.