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.

Systems

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

Entities

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!

World

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

Benefits

• 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.

Drawbacks

• 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