Unit — Systems

01why

Systems are stateless and data lives in components. What does that separation make possible that an OOP 'entity owns its update' design cannot?

1. aFewer files to maintain
2. bData can be laid out contiguously for cache and vectorization while a system sweeps those arrays, and stateless transforms are safe to parallelize across chunks
3. cEntities can inherit behaviour from base classes
4. dThe garbage collector runs less often

02how

You have systems that compute velocity, integrate position from velocity, and cull off-screen entities from position. How should their order be established?

1. aName the files 1_, 2_, 3_ so they sort correctly
2. bDeclare UpdateAfter/UpdateBefore reflecting the real data dependencies — integrate after velocity exists, cull after position is final — and let the runtime topologically sort
3. cCreate them in the right order in code; creation order is execution order
4. dOrder doesn't matter because each runs once per frame

03why

Why can't a structural change be performed in the middle of iterating a query — stated as a memory-safety argument?

1. aThe EntityManager is locked during OnUpdate by policy
2. bA structural change relocates entity data and can move the entities being iterated, invalidating the chunk pointers the loop is streaming — and in parallel, pointers other threads are reading concurrently
3. cStructural changes require the main thread, which is busy iterating
4. dIt would exceed the chunk's 16 KB size

04how

A sync point (ECB playback) is expensive for two compounding reasons. Which pair?

1. aIt allocates memory and triggers garbage collection
2. bIt applies all recorded structural changes at once, and it's a hard barrier that must drain outstanding jobs before those changes can safely apply
3. cIt recompiles Burst code and reloads the scene
4. dIt sorts every chunk and rebuilds every archetype

05why

Framerate-sensitive physics integration placed in the ordinary SimulationSystemGroup produces what bug?

1. aA compile error about missing timestep
2. bThe simulation behaves differently at different framerates (dt varies), so a 144 Hz machine diverges from a 60 Hz one and replays desync; it belongs in the FixedStepSimulationSystemGroup
3. cPhysics runs twice as fast on faster hardware, which is fine
4. dNothing; SimulationSystemGroup already fixes the timestep

06why

Recording structural changes from a parallel job with a constant sortKey breaks what, and why?

1. aNothing — sortKey only affects performance
2. bDeterminism: worker threads finish in unpredictable order, so without a distinct per-command ordering key (e.g. chunk index in query), playback order varies run to run and the sim can diverge
3. cThread safety — the buffer corrupts
4. dMemory usage — commands are duplicated

07howmeasure

Build the churn lab: 5,000 destroys/frame via immediate EntityManager calls vs a single ECB playback. Enter frame_time_immediate / frame_time_ecb.