Learning

Unity DOTS · Reference

DOTS Glossary

The canonical vocabulary for the Unity DOTS course — the data model, the memory layout, and the compilation machinery.

The working vocabulary for horde-scale simulation in Unity DOTS. Terms are added here once a lesson has actually used them, not in advance.

Version note: definitions track Entities 6.5. DOTS version numbers are misleading — 6.5 is newer than 1.4. See RESOURCES for the version traps.

The data model

Entity: A unique identifier with no data and no code of its own — the Entities manual calls it “a lightweight unmanaged alternative to a GameObject”. It exists only as the key that a set of components is filed under. Avoid: Object, GameObject, actor, instance

Component: A plain struct of data attached to an entity, implementing IComponentData. It holds state and nothing else — no methods that act on it, no virtual dispatch. Avoid: MonoBehaviour, script, behaviour

System: The code half of the split. A system queries for entities matching a component signature and transforms their data. Entities contain no code; systems are where all behaviour lives. Avoid: Manager, controller, update loop

World: The container holding a set of entities, their component data, and the systems that run over them. A project can have more than one; most have a single default world.

ISystem: The unmanaged, Burst-compatible way to write a system, as a partial struct. This course’s default. Distinguished from SystemBase, the managed class-based form, which can touch managed objects but cannot be Burst-compiled as a whole.

Memory layout

Archetype: The unique combination of component types an entity has — “a unique identifier for all the entities in a world that have the same unique combination of component types”. Two entities with the same components share an archetype; adding one component to an entity changes which archetype it belongs to. Avoid: Class, type, prefab, template

Chunk: A fixed 16 KiB block of memory holding entities of a single archetype. Inside it, each component type gets its own contiguous array, plus an array of the entity IDs. This is the unit that makes DOTS fast: iterating a chunk is a linear walk through packed arrays. Avoid: Page, block, batch, bucket

Chunk capacity: How many entities fit in one chunk — roughly 16 KiB divided by the total size of the archetype’s components. Fatter archetypes mean fewer entities per chunk and more memory traffic per entity processed.

Structural change: Any operation that reorganizes chunks: adding or removing a component, creating or destroying an entity, changing a shared component value. It moves the entity to a different chunk, can only run on the main thread, and is the main performance trap in ECS. Adding a component is not a cheap operation the way setting a field is. Avoid: Mutation, edit, modification

AoS / SoA (array of structs / struct of arrays): Two ways to lay out N records. AoS keeps each record’s fields together (Zombie[]); SoA keeps each field together (float3[] positions, float[] healths). A chunk is SoA per component type, which is why reading one field across many entities touches few cache lines. Same distinction already met in gpu-prog.

Compilation and execution

Burst: A compiler that turns a constrained subset of C# — no managed objects, no exceptions in the normal path, no garbage collection — into optimized native code, with vectorization. Applied with the [BurstCompile] attribute. The constraints are the price; they are why component data must be unmanaged structs.

Baking: The editor-time conversion of authoring GameObjects in a SubScene into entities and component data. It replaces the old runtime-conversion workflow from the 0.x era. Avoid: Conversion, ConvertToEntity

SystemAPI.Query: The idiomatic way to iterate matching entities inside a system, wrapping each component in RefRW<T> (read-write) or RefRO<T> (read-only) and narrowed with WithAll<T> / WithNone<T>. The read/write distinction is not decoration — it is what lets the job system know which systems can run in parallel.

Managed component: A component holding a reference to a class rather than plain data. It lives outside the chunk, breaks the packed layout, and cannot be touched from Burst-compiled code. Usable, but each one is a hole in the performance story.