Question on when to use SharedComponentData

[bold venture]

Say for example I am making an rts, I have a component to represent a player data which I can assign to units, buildings etc to mark that they are owned by this player so I can iterate over only things owned by this player, Would a SharedComponentData be a good way to model such data? The entities would be ghost refabs and the owner of these entities would not change often but structural changes still might happen. Or would it be more performant to ignore shared component data alltogether and use IComponentData instead? Would I just do my foreach query as normal but then do a value check to see if it's the player I want and continue if its not?

[next axle]

anything about shared components locks you to main thread always

if your game does not utilize threads - should be fine

otherwise, it's awful way to make game logic

[undone urchin]

I used a shared component for the concept of a 'team'

and use this for some heavy optimization of ownership

[undone urchin]

not sure what you mean? you can use shared components in jobs

[next axle]

but not change them

[undone urchin]

obviously you can't change them but for the concept of ownership you would very rarely change them

[next axle]

and then say goodbyte to capture mechanics 😅

besides

having to assign query filter in main thread

[undone urchin]

yeah mindcontrol etc that's the rare part

[next axle]

is also awful

[undone urchin]

that's hardly a requirement for shared components to be useful

but as for doing setshared filter, a) it's really not that bad for small numbers b) you'd likely only do this in a single system anyway

but knowing all your objects in a single chunk on same team can lead to some amazing optimizations

i have this concept of shared memory

            public void Execute(in ArchetypeChunk chunk, int unfilteredChunkIndex, bool useEnabledMask, in v128 chunkEnabledMask)
            {
                var observations = chunk.GetBufferAccessor(ref this.SharedMemoryHandle);
                var teamIndex = chunk.GetSharedComponent(this.TeamHandle);

                for (var i = 0; i < observations.Length; i++)
                {
                    this.AddObservations(observations[i].AsSet(), teamIndex);
                }
            }```

and knowing all entities with memory in the same chunk are the same team

i can merge this data to a single source magnitudes faster

(and no need for set shared filter etc)

[next axle]

I mostly use it to postprocess subscenes, but even then I don't use shared filters. I just manually check component chunk value 😅

this way I can have many filters at the same time

in a key-value pair list

[undone urchin]

Team is the only shared component i have in my entire project, but i think it's the most useful
(at least for a team based game!)

[next axle]

how many total teams supported?

[undone urchin]

32 technically

though in reality probably like 4-8

[next axle]

can team mutate mid game?

[undone urchin]

you couldn't change team except for a mind control

which would not be common

but yes

[bold venture]

this would be the usecase I was thinking, allowing for easy iteration over any kind of entity that is bound to a team

[next axle]

and also forcing to have N amount of jobs for each team if you run per team logic of some sort

[bold venture]

is iterating over every team and doing a check for everything that needs to check teams better?

[next axle]

it is something that can be done fully on jobs, without involving main thread logic

as well as mutate team over frame easily

without sync points

since changing shared comp = structural change