Checkpoint — entity scenes, prefabs & blobs

01why

Baked output could have been serialized as a recipe — a list of 'create entity with these components' instructions. Why serialize chunk memory instead?

1. aRecipes take more disk space
2. bReplaying a recipe means running the full structural-change machinery per entity at load time; a chunk image is already in final layout, so loading is a byte copy with no archetype computation or component writes at all
3. cRecipes can't represent component values
4. dChunk memory compresses better

02how

Why does streaming a baked section of 10,000 static props beat instantiating the same 10,000 entities?

1. aStreaming uses the GPU
2. bStreaming cost scales with bytes and I/O bandwidth and can happen off the main thread; instantiation pays per-entity structural change on the main thread, scaling with entity count and archetype complexity
3. cInstantiation is not supported for static objects
4. dThey cost the same; streaming is just more convenient

03why

Why must Entity references inside a baked scene be remapped when it loads?

1. aBecause entity data is encrypted on disk
2. bAn Entity is an index-plus-version into a specific world, not a pointer — the loading world already has entities at low indices, so a stored index means something different or nothing at all
3. cBecause references become null during serialization
4. dThey don't need remapping; they're absolute

04why

You store an entity's index as a plain int in a component, then read it after a scene load. What happens?

1. aIt works — indices are stable across loads
2. bNothing patches it, because remapping only covers Entity fields the serializer recognizes; you get a value that resolves to a real live entity that is the wrong one
3. cThe build fails at bake time
4. dIt throws a null reference exception

05why

A baked prefab entity has to satisfy two conflicting requirements at once. What are they, and what resolves the conflict?

1. aBe small and be fast; solved by compression
2. bBe a fully baked entity with correct archetype and values (so instantiation has a source to copy), yet be invisible to gameplay queries (so it isn't rendered, moved or damaged) — resolved by a zero-size Prefab tag that queries exclude by default
3. cBe managed and unmanaged; solved by a wrapper
4. dBe serialized and streamed; solved by sections

06how

A component holding 4 KB of navigation data, on 10,000 entities. Price it.

1. aFine — 40 MB is affordable on modern hardware
2. bChunk capacity collapses to about three entities per 16 KB chunk before any other component, destroying density and prefetch benefit, while storing 10,000 identical copies of 4 KB to represent 4 KB of information
3. cIt's efficient because the data is contiguous
4. dThe compiler deduplicates identical component values automatically

07why

Why can't shared immutable data just be a raw pointer in a component?

1. aPointers are illegal in C#
2. bThree independent failures: managed references can't live in unmanaged components or be touched by Burst; a raw address is meaningless after serialization, so a baked scene of pointers is garbage on load; and a pointer gives the job safety system nothing to reason about
3. cPointers are too slow to dereference
4. dOnly one entity may hold a pointer at a time

08why

Why are internal links inside a blob stored as relative offsets rather than absolute addresses?

1. aOffsets are smaller than pointers
2. bIt makes the blob position-independent — every reference means 'so many bytes from here', so the blob is valid wherever it lands in memory, which is what lets it survive serialization and be loaded to any address
3. cThe CPU can only address relatively
4. dIt allows the blob to be mutable

09why

Why is blob immutability what makes the sharing safe, rather than merely a restriction?

1. aImmutable data is faster to read
2. bIf a blob could be written, 10,000 entities referencing it across parallel jobs would be a data race by construction — read-only shared data has no write to overlap, so every reader parallelizes freely
3. cImmutability saves memory
4. dIt prevents accidental typos in the data