Checkpoint — components & queries

01why

A tag component (IComponentData with no fields) stores zero bytes per entity. Why is adding one to an entity still a structural change?

1. aTags are secretly stored as a hidden byte
2. bIt changes the entity's component set, and the set determines the archetype and therefore the physical chunk — so the entity is relocated
3. cThe tag must be initialized, which requires a copy
4. dIt isn't a structural change; tags are exempt

02why

You use a shared component to store each entity's world position as a float3, giving ~5,000 entities ~5,000 distinct values. What happens?

1. aPositions are deduplicated, saving memory
2. bEntities fragment into ~5,000 chunks of ~1 entity each — 16 KB of mostly empty space per entity, and queries crawl thousands of chunk boundaries
3. cThe shared component silently converts to an ordinary component
4. dNothing unusual; shared components handle any cardinality efficiently

03why

A query with WithAll<A>() runs while millions of entities exist, only thousands of which have A. Why is matching cheap regardless of total entity count?

1. aThe runtime samples a subset of entities to estimate matches
2. bThe match decision is made per-archetype (tens to hundreds exist), not per-entity — only chunks of matching archetypes are ever visited
3. cEntities without A are stored in a slower tier and skipped by the OS
4. dWithAll caches a list of every matching entity ID

04why

You call SetComponent<LocalTransform> on every entity every frame, then wonder why your change filter on LocalTransform never skips any chunks. Why?

1. aChange filters don't work with LocalTransform specifically
2. bWriting the component — even the same value — bumps the chunk's change version, so every chunk looks changed every frame and nothing is ever skipped
3. cThe filter needs to be reset manually each frame
4. dChange filters only skip chunks that were never written to at all, ever

05how

Change versions are stamped at what granularity?

1. aPer entity, per component
2. bPer chunk, per component type — writing one entity's component bumps the version for the whole chunk
3. cPer archetype, globally
4. dPer frame, for the entire world

06why

Why does the ECS runtime refuse to guarantee the order in which a query yields entities?

1. aIt's a bug that will be fixed in a later Entities version
2. bOrder-independence lets the runtime store entities in the fastest-to-iterate layout and hand independent chunks to independent threads without reconciling a global order — it's a precondition for the parallelism
3. cOrdering would require sorting every frame, which is too slow to implement
4. dThe order actually is guaranteed to be entity-ID ascending

07how

You have a property that flips on and off many times per second per entity (e.g. 'currently stunned'). Purely from cost, which representation is worst?

1. aAn enableable component
2. bA tag you add and remove each time it flips
3. cA boolean field in an ordinary component
4. dThey all cost exactly the same