Lessons

flecs, from the storage up

These lessons follow the flecs documentation, but with a debugger alongside. Every example runs real flecs, compiled to WebAssembly from the current master branch, with a trace hooked into its internals. Step through it and you see what the docs describe: rows moving between tables, the last row swapped into the hole, commands waiting for a sync point, caches being told about new tables, and observers firing in order. Later lessons add playgrounds and benchmarks you can run on the same build.

Open the sandbox →A live world to play with: create entities, add and remove components (including Sparse and DontFragment ones), add observers and systems, and watch archetypes and observer calls update as you go.

Storage and identity

  1. 1Entities, ids and namesWhat an entity id actually is, why ids get reused, and why "components are entities too" matters more than it sounds.
  2. 2Archetypes, and entities moving between themWhere flecs actually keeps your components, what happens to that storage when you add or remove one, and why row numbers can't be trusted.
  3. 3Holding on to component referencesA reference to a component is a pointer into a table column. Here is everything that silently moves it, what reading or writing through it then does, and the patterns that stay safe.
  4. 4RelationshipsPairs, wildcards and Exclusive relationships, what they do to storage, and when an entity id in a plain component is the better choice.
  5. 5Prefabs and inheritanceHow a prefab gives an entity its whole type in one move, the difference between copied and inherited components, and what overriding does to storage.

Queries

  1. 6The query languageOperators, wildcards, variables, traversal and fixed sources, tried live on a small world, plus what each one costs.
  2. 7Queries and what they cacheWhat a cached query actually stores, when that cache is updated, and what an uncached query does instead.

Systems, commands and reactions

  1. 8Systems and the pipelineA system is a query, a function and a phase. What order systems run in, why the function is called once per table rather than once per entity, and what writing through a field does and doesn't do.
  2. 9Commands and sync pointsWhy operations inside a system don't happen straight away, what the command queue does with them, and where they finally land.
  3. 10What the command queue merges awayWhen a system queues several operations for one entity, flecs applies them as a batch. Which of those operations observers get to see, and how that changed on master in October 2026.
  4. 11Hooks and observers, in orderExactly when component hooks and observers run relative to the storage changes they react to, and what each one can see at that moment.
  5. 12Deleting thingsWhat flecs does to everything that refers to an entity when you delete it, how cleanup policies change that, and why deletes can be bulk table operations.

Designing your data

  1. 13FragmentationHow relationships and hierarchies can spread a handful of entities over dozens of tables, what that costs, and what DontFragment and Parent do about it.
  2. 14Choosing storage: column, Sparse, DontFragment, CanToggleFour ways to store or switch a component, what each does to moves, pointers, queries and systems, and how to choose.
  3. 15Spatial data and lookupsWhich entities are near this point? That is not a question archetypes answer well. Three ways to store a spatial index next to flecs, what each costs, and a benchmark you can run.

Engine integration

  1. 16Reflection, scripts and engine resourcesflecs only knows the size of your components until you tell it what is inside them. What needs that, what scripts really do when they assign values, and how to tie engine resources (physics bodies, meshes) to components so every path that creates them works.
  2. 17Networking patternsTwo worlds that must agree on what an entity id means. Making ids match with make_alive, keeping local ids out of the way with entity ranges, choosing what to send with a Replicated tag, and sending frequent and rare data differently.

Wrapping up

  1. 18Thinking in flecsEverything so far, as a way of designing. A worked redesign of a typical game character, the questions to ask before adding a component, tag or relationship, and how to check your choices instead of guessing.
  2. 19Where to learn moreThe official manuals, the examples worth reading first, real projects built on flecs, and where people ask questions.

Lessons assume you've written some code against an ECS before. Examples are shown in C++; the same operations exist in C, C# and Rust. Not affiliated with the flecs project.