Jason Frame: Entity Systems

Orde Saunders' avatarPublished: by Orde Saunders

Jason Frame (@jaz303) was speaking about Entity Systems at Glasgow.js, these are my notes from his talk.

What are entity systems

  • Origin in MMORPG
  • Collection of architecture patterns used to organise a game "world" - not the UI
  • No fixed definition
  • Decrease coupling
  • Increase runtime flexibility - don't impose structure on objects.
  • Separate data from behaviour - increase parallism.

Flaws in traditional OO

As the structure gets extended features bubble to the top - everything can be an instance of the same thing which breaks OO principles.

We can overcome this by compostion or mixins but this still isn't transparent - we're basically back to where we started.

Autopoietic (social) systems

Borrowed from biology.  Systems operate on the environment and extract information from it.


  • Implement one single game task
  • Maintains a collection of components
  • Acceptance check - is there anything about this object that I'm interested in.


An entity is a bag of components

  • Represents a single facet of a single entity - e.g mass, velocity, position
  • Usually a map of key:value pairs
  • Max of one component of each type per entity
  • Data only - no logic!


The world is a container with a bunch of query methods that acts as a message system


  • Flexible component composition
  • Tooling is simplified - can add and remove components at runtime.
  • Can just trawl each component and dump them
  • Lends itself to running in parallel

Pick up an item:  remove position component and add carried item component.

Inter-system communication

Systems neither know nor care about other systems - communication is handled by events.

Attribute/Behaviour Systems

  • No systems or components
  • Instead we have attributes and behaviours

Attributes are just values.  Behaviour responds to two methods - onUpdate and onMessage.

Managing Determinism

  • Synchronisation point - rather than acting immediately we queue it up until a known point.
  • Queues - event can happen at a known time in the future, waits until it's its time to process.
  • Asynchronous or synchronous - need to decide which is need for a given situation, code for both.


  • Overhead - they can be more complex
  • Hierarchical data problem - entity might be a child of another entity and we need code to handle it.
  • "Framework" required - high startup cost, need to build the entity system first.

Beyond games

  • Chris Granger's Light Table project uses component-entity systems
  • Useful where custom objects must be composed dynamically at runtime

Comments, suggestions, corrections? Contact me via this website