Suggestion: Allow multiple components of the same type about entitas HOT 11 CLOSED

It's a good and valid question and something you will likely encounter when starting with ECS. Lets focus on developing and sharing solutions, please.

from entitas.

I was thinking a little bit about it now. I'm not sure if it's a good idea to allow multiple components. It will add quite some complexity I think. For instance, what does entity.RemovePosition(); mean when you have multiple positions? You'd have to also manage indices like entity.RemovePosition(3);

I think with the given example of the health regenerators it's better to sth like I just mentioned before.

e.AddHealthRegenerations(new List<HealthRegeneration>());

The good thing is, when you do sth like

var list = e.healthRegenerations.list;
list.Add(new HealthRegeneration(...));
e.ReplaceHealthRegenerations(list);

Entitas is smart enough not to change any data structures under the hood. You'll reuse the some instance of the list over and over again, so there will be no overhead. e.ReplaceHealthRegenerations(list); will also not change groups but only dispatch event, so it's efficient, too.

from entitas.

I don't see how it would make the API that much more confusing just by allowing more of the same component type. It would give a lot more possibilities and opens up more elaborate game design.

Having to manage Lists of "components" in a component kind of defeats the point of an Entity System and only data being in components. What's in the Lists would be the components, not the components themselves and those wouldn't play along well with any of the rest of the system.
You'd also end up with old list contents unless you clear them every time you remove and cache a component else you end up with a whole lot. And if you want to cache those actual embedded components in the list you'd have to build your own cache and your own reactive system.
What's important is the single components in the list, not the whole list of them. For adding you only want those actually added etc.
One-to-many relationships (which are pretty common) are just not feasible that way.

Oh well, guess I'll have to go back to my own implementations. Thanks for considering it anyway.

from entitas.

The discussion here neatly sums up the difference between the people making tools for theoretical games in a theoretical world of ideal philosophies vs the people actually trying to make physical games in the real world with physical teams of real people.

from entitas.

Haha ;) Entitas came to live because of real games and real problems. Nothing theoretical about it.

from entitas.

The discussion here neatly sums up the difference between the people making tools for theoretical games in a theoretical world of ideal philosophies vs the people actually trying to make physical games in the real world with physical teams of real people.

Bullshit.
I have been working with Entitas for years on professional projects with different team sizes. I can assure you that Entitas was created through practical work with ECS. Creating a list of components with a 1..* relation is incredibly easy in the ECS universe:
(pseudo)

EntityA
    IdComponent(for example Int = 3) with [PrimaryEntityIndex]
EntityB
    ParentComponent (with Int = 3 pointing to EntityA) with [EntityIndex]
    SomeValueComponent
EntityC
    ParentComponent (with Int = 3 pointing to EntityA) with [EntityIndex]
    SomeValueComponent

SomeSystem
    Execute()
    var entities = context.GetEntitiesWithParent(entityA.id);
    foreach(entities) DoSomething(entity.someValue)

This procedure also applies in other ECS environments. Not only Entitas and is one of the fundamental principles of understanding ECS. Necromantic and some others here in the issue have not, in my opinion, understood the basics.

from entitas.

You are right, entities can only have one component per type. At the moment this behaviour is intended. I'll think about your suggestion next week if it might make sense to add sth like [AllowMultipleComponents].

For now, in order that you can continue, I'd suggest having a HealthRegeneration class which contains all needed information about start/end time/interval etc. Then create a HealthRegenerationsComponent(plural) which has a List.

e.AddHealthRegenerations(new List<HealthRegeneration>());

// later somewhere else in the code
var list = e.healthRegenerations.list;
list.Add(new HealthRegeneration(...));
e.ReplaceHealthRegenerations(list);

Hope that helps. I'll keep you updated

from entitas.

Thanks for the response. I thought about multiple solutions and that was one of them, but to be honest that one kind of defeats the point of the entity system and would basically be a system in itself. You also couldn't use any of the group callbacks etc. when adding new components, you'd have to replace the whole component(with the list) just for changing one of its sub-components, which just doesn't feel right.

What I've done so far is make a [MultipleInstance] Attribute and basically duplicated the components array and all it's utility variables and methods like:

        readonly IComponent[] _components;
        readonly List<IComponent>[] _componentLists;

I even went so far to check for that attribute on code generation.
But because everything is kind of duplicated with list behaviours you'd also have to separate component index, type and name lists etc. in order to not clutter the different arrays with empty references that would only ever be filled in the other.
So at some point it feels like the only good and clean solution would be to build it into the system from the ground off.

I'm not really working on a specific project right now so it's nothing I need urgently, it's just something I noticed when trying to implement an old attribute/skill system based on a (really simplistic) entity system of my own with Entitas.
I just thought it would be an interesting feature for more applications and that it might be interesting to have it as part of Entitas.
If I find a good solution myself I'll let you know.or possibly create a fork.

from entitas.

I've also given this idea some thought and come to the same conclusion, it'll make the API more confusing while only giving you a bit more granular notifications. And you can wrap the code sschmid wrote in an extension so that you'd only have to write

e.AddHealthGeneration(index, new HealthGeneration(...))
e.ReplaceHealthGeneration(index, new HealthGeneration(...))
e.RemoveHealthGeneration(index)

If you absolutely had to only update a single HealthGeneration then you're still stuck with writing some more code to compare the previous and new list but I'd say this is more an exception rather than a rule.

from entitas.

Wasn't meant to be offensive. I understand that this question comes up frequently, but to call the design theoretical without any proof is a bit provocative and degrading 😬

from entitas.

I've never had the need to give an entity multiple instances of the same component. I guess if I decided that was the best option, I'd either give said component a collection or I'd just split it into multiple smaller entities as @StormRene suggested.

I do have a prefab with two instances of the same MonoBehaviour, but that's to simplify integrating parts of my game's UI with a particular library. Not really pertinent to Entitas, though.

from entitas.