Should I have multiple variables in my ECS Component or only one?

Unity Engine
, , ,
1

So I’m pretty new to Unity ECS and just want to experiment a little bit. When setting up some variables like speed, friction, ratio, etc. should I have these all in one component or should there only be one each? What’s the rule of thumb for best performance?

2

There is no rule of thumb, so usually I follow the “if they are usually used together, keep them together, if you find yourself using only a few of them in many cases then split them up”.

The rule of thumb here is to keep the code simple for yourself until you find a need to optimize.

3 Likes
3

Makes sense, but at the same time, entity is not a container : if you need to do something to every entity that has a speed (for example activate bullet time) you should keep speed separated.

4

Almost any time I put more than one value in a component or buffer I inevitably end up having to go back and split it up for one reason or another. Almost all my components use implicit casting to avoid having to type .Value everywhere, or if you need to .Reinterpret your data you can’t do that if it has multiple values.

In some cases where it really only makes sense for the data to be grouped together I will stick it in a struct and put the struct in a component, for the previously mentioned reasons.

5

Pretty much what I currently do when not just prototyping, but if you are the kind of people who relies on GenerateAuthoringComponent attribute then you will find yourself needing to manage the data dependency on hand when authoring. For that same reason, I always create my own custom authoring components so this becomes easier to manage.

6

Same, 95% of our components contain a single value. We write them all like that:

[Serializable]
public struct Velocity : IComponentData
{
    public float3 Value;

    public static implicit operator float3(Velocity velocity) => velocity.Value;
    public static implicit operator Velocity(float3 velocity) => new Velocity() { Value = velocity };
}

I’d also strongly suggest avoiding GenerateAuthoringComponent (it’s banned on our project). Decoupling your authoring data model from your runtime data model is very powerful.

7 Likes