Jason Frame: Entity Systems
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.
Systems neither know nor care about other systems - communication is handled by events.
- No systems or components
- Instead we have attributes and behaviours
Attributes are just values. Behaviour responds to two methods - onUpdate and onMessage.
- 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.
- Chris Granger's Light Table project uses component-entity systems
- Useful where custom objects must be composed dynamically at runtime