Checkpoint — enableable state & determinism

01why

Module 1 left you with a dilemma between a tag and a bool field for volatile state. Restate why both fail.

1. aTags are deprecated and bools waste memory
2. bA tag makes flipping a structural change — the entity's archetype changes so it physically moves chunks, thousands of times per second; a bool avoids that but queries can't filter on it, so every system iterates all entities and branches per entity
3. cBoth work fine; the choice is stylistic
4. dTags can't be queried and bools can't be written in jobs

02why

Three requirements force the design of enableable components. What are they, and where do they point?

1. aSmall, fast and safe — pointing at a compressed component
2. bFlipping must not be structural (so not in the archetype), queries must still filter on it (so the query system must see it), and filtering must be cheap in bulk — which together point at a bitmask in the chunk header, one bit per entity per type
3. cSerializable, mutable and Burst-compatible — pointing at a blob
4. dThey point at a separate lookup table outside the chunk

03why

Why can a disabled enableable component not reclaim its bytes?

1. aIt could, but Unity hasn't optimized it yet
2. bThe whole point was that the entity doesn't move and the archetype doesn't change — but archetype determines chunk layout, so if layout is unchanged the space stays allocated. The space is the price of the stability
3. cThe bytes are needed for the bitmask
4. dDisabled components are moved to a separate chunk

04how

Why is flipping an enableable bit safe inside a parallel job when adding a tag is not?

1. aBits are atomic and components are not
2. bWhat makes structural changes require a command buffer is that they invalidate chunk layout mid-iteration; a bit write to the chunk header changes no layout, so nothing is invalidated
3. cJobs can't add components at all, for unrelated reasons
4. dThe safety system special-cases enableable components

05why

A colleague makes every component enableable 'for flexibility'. What have they done?

1. aImproved the design at no cost
2. bReintroduced the cold-data density tax — full component size in every chunk for properties that never flip — through a feature designed to save cost elsewhere. A property fixed at bake time should be a tag: zero bytes, and the structural cost is never paid because it never flips
3. cBroken determinism
4. dMade queries impossible

06how

Do enableable components restore full chunk-skipping?

1. aYes, identical to archetype matching
2. bNo — an all-disabled chunk is skipped cheaply, but a partially-disabled chunk is still visited and the loop steps over disabled entities. It's entity-level filtering with cheap bulk tests, better than a per-entity bool branch but weaker than an archetype that simply doesn't match
3. cNo, they provide no filtering at all
4. dOnly when combined with shared components

07what

Define determinism as this module uses it, and name what it enables.

1. aCode that never crashes; it enables stability
2. bSame starting state plus same inputs produces byte-identical results every frame — enabling replay from inputs alone, rollback that re-simulates correctly, and lockstep networking where bandwidth is independent of world size
3. cSingle-threaded execution; it enables debugging
4. dFixed frame rate; it enables smooth rendering

08why

Why is parallel accumulation the classic determinism killer?

1. aParallel code has race conditions by nature
2. bFloating-point addition isn't associative — (a+b)+c differs from a+(b+c) by rounding — and across cores the combination order depends on which finished first, so two runs give sums differing in the last bit, which the simulation feeds forward until the divergence is visible
3. cAccumulators overflow unpredictably
4. dThe job system randomizes work distribution deliberately

09why

What is the relationship between order-independence, parallelism, and determinism?

1. aThey are three unrelated properties
2. bThe same property does both jobs — if each entity's result depends only on its own data, processing order can't affect the outcome, so the work parallelizes safely AND stays deterministic regardless of how the scheduler distributes it
3. cDeterminism requires giving up parallelism
4. dParallelism guarantees determinism automatically

10why

NativeList.ParallelWriter is thread-safe and the safety system reports no error. Why might it still break your simulation?

1. aIt has a hidden race the safety system misses
2. bThread-safe and deterministic are different properties — the safety system only checks the first. The order of appended elements depends on thread timing, so anything downstream that accumulates floats over that list produces different results per run, with no error anywhere
3. cParallelWriter is not Burst-compatible
4. dIt allocates, causing frame spikes

11how

Why does a deterministic simulation need a fixed timestep?

1. aFixed timesteps are faster to compute
2. bVariable delta time makes the simulation a function of frame rate, so two machines running at different speeds compute different results — simulation runs on a fixed step and rendering interpolates for smoothness
3. cThe job system requires it
4. dIt reduces floating-point error