Idiomatic way to handle component variations?

[TerranWorks]

I'll start with a specific example. I'm implementing a "needs" system and my first thought was to create a few components (HasFoodNeed, HasShowerNeed, HasSleepNeed, etc.). All needs are basically identical, with the only differences being the duration of a couple of timers. My method at the moment is to create a Need struct and to define the components like this: HasFoodNeed(Need). I then impl Default to instantiate Need with the correct values for that kind of need. This works okay, but I eventually want my game to be highly scriptable, and it will be necessary for scripts to create their own variations.

In general: I often find myself in a situation like the one described above, where I want to create a component template in my core engine and to create components in my scripts by filling in some constant values. I want to be able to query these generated components as if they were created in the normal way so I can easily use them in systems.

This seems like a fairly common problem but also seems like it would be very difficult to implement. Are there existing solutions for what I want to do? Should I change my approach? Or should I try to implement a solution myself?

[alice-i-cecile]

For compile time types: generic components can work, but I'd actually recommend bevy_trait_query. It's a really nice way to handle this sort of abstraction over related components.

For runtime types: I think we need more support for dynamic components and especially queries to make that a reality, but there has been work done in this area. Help reviewing or adopting PRs would go a long way.

[rlidwka]

So generic components won't work, because you can't create types at runtime using scripts.

No good solutions here. There are solutions (e.g. throwing all needs into a single component as HashMap).

I think we should discuss a possibility to add multiple components to the same entity. That would be better idea from ECS point of view.