Entity Component Systems Yos Riady yos.io goo.gl/ECeFOI 

A walkthrough of an ECS implementation in Elixir A high-level overview of Entity Component Systems Background Drawbacks of traditional OOP / inheritance style code ECS Examples Code Next Steps Real life applications and examples of ECS in action Further learning, future improvements, and conclusion 

A walkthrough of an ECS implementation in Elixir A high-level overview of Entity Component Systems Background Drawbacks of traditional OOP / inheritance style code ECS Examples Code Next Steps Real life applications and examples of ECS in action Further learning, future improvements, and conclusion 

Animal hop() Bunny swim() Whale GameObject kill() Killer Whale 

Animal hop() Bunny swim() Whale hop() kill() Killer Bunny GameObject kill() Killer Whale 

The challenges with inheritance The Blob Antipattern A huge single root class with a large amount of functionality. Subclasses become overburdened with unneeded functionality. Deep Rigid Hierarchies The Diamond Problem 

A walkthrough of an ECS implementation in Elixir A high-level overview of Entity Component Systems Background Drawbacks of traditional OOP / inheritance style code ECS Examples Code Next Steps Real life applications and examples of ECS in action Further learning, future improvements, and conclusion 

Entity Component Systems ● Originally used in game development ○ Tendency to end up with very complex / monolithic classes when using inheritance ○ Thief, Dungeon Siege, Caves of Qud, roguelikes ● Attempts to solve issues due to deep hierarchies ○ Composition over inheritance ● Based on three key abstractions ○ Entity ○ Component ○ System 

Entity Component Systems 

Component Components are minimal, reusable data objects that are plugged into entities to support some behaviour. A Component itself has no behaviour. A Components tags an entity with a single quality. Typically a struct or dictionary. The “qualities” or “aspects”of a thing 

What qualities might a bunny have? 

What components might a bunny have? Placeable - int x - int y - int z Huggable - int fluffiness Consumable - float calories Seeing - int sight_radius - boolean night_vision? Living - float health - float age Hopping - int hop_distance Physical - int height - int width - int length 

Entities are very simple. Entities are globally unique IDs. Entities has no actual data or behaviour. Entity are solely the sum of its components. A Component gives an Entity its data. Entity An aggregation of Components 

The bunny entity 

The bunny entity Placeable - int x - int y - int z Huggable - int fluffiness Consumable - float calories Seeing - int sight_radius - boolean night_vision? Living - float health - float age Hopping - int hop_distance Physical - int height - int width - int length 

The carrot entity Placeable - int x - int y - int z Consumable - float calories Physical - int height - int width - int length 

The ghost entity Placeable - int x - int y - int z Spooky - int spookiness Seeing - int sight_radius - boolean night_vision? 

Systems run continuously and iterate over all Components of its type. Systems read and write the state of Components, resulting in behaviour. By transitive property, Systems give Entities behaviour. Could be a distributed worker pool. System Brings entities and components to life 

How does a bunny behave? Placeable - x 5 - y -2 - z 10 Living - age 2.00 Placeable - x 5 - y -2 - z 0 Living - age 2.01 “Fall” “Age” 

How does a bunny behave? Placeable - x 5 - y -2 - z 10 Living - age 2.00 Placeable - x 5 - y -2 - z 0 Living - age 2.01 “Fall” “Age” Gravity System Time System 

Data flow in ECS Gravity System Placeable - x - y - z Placeable - x - y - z Placeable - x - y - z Placeable - x - y - z Placeable - x - y - z External Event Stream i.e. Time, Player Input 

Acquires behaviour through changes in component states. Reads the continuously changing state of its components. Listens to system events, updates its state. Stores data, which gets updated in response to events from systems. Listens to outside events, publishes updates to components Provides the logic that manipulates the data encapsulated in components. Data flow in ECS System Component Entity 

The spreadsheet analogy for ECS 

The spreadsheet analogy for ECS 

● Good decoupling, helps divide your monolithic classes ● Clear separation of responsibility ○ Encourages small interfaces ○ Entity.build([PlayerInputComponent]) ● Easy reuse and composability ○ Entity.build([FlyingComponent]) ○ Entity.build([FlyingComponent, SeeingComponent]) ● Straightforward unit testing and mocking ○ Substitute components with mocked components at runtime ● Separates data from functions that act on it ● Runtime object definition ● Parallelizable Advantages of ECS 

● Most people have never even heard of this pattern ● Handling interprocess communication introduces complexity ● Inter-Component communication ○ What happens when a system needs to access multiple components? ● Inter-System communication ○ What happens when two systems need to access the same component? ● Not as concretely defined as other patterns such as MVC ○ There are a multitude of ways to implement ECS ● Instantiation of entities is more involved ○ Who wires up the components? ○ Does the entity itself creates its own components? ○ Does outside code provides the components? Challenges of ECS 

A walkthrough of an ECS implementation in Elixir A high-level overview of Entity Component Systems Background Drawbacks of traditional OOP / inheritance style code ECS Examples Code Next Steps Real life applications and examples of ECS in action Further learning, future improvements, and conclusion 

ECS in the Real World 

No content

A walkthrough of an ECS implementation in Elixir A high-level overview of Entity Component Systems Background Drawbacks of traditional OOP / inheritance style code ECS Examples Code Next Steps Real life applications and examples of ECS in action Further learning, future improvements, and conclusion 

Entity Component Systems in Elixir 

What is Elixir? ● Language that compiles to Erlang ● Built on top of the famed Erlang VM (“nine 9s of reliability”) ○ Traditionally used for telecommunications by Ericsson ○ WhatsApp, Facebook Messenger, RabbitMQ, Riak ● Built-in concurrency abstractions (Actor model and OTP) ● A pleasant, modern syntax similar to Ruby ● Immutable and Functional ● Gradual types ● Pattern Matching ● Interop with Erlang ● Metaprogramming through Macros 

The Actor Model ● Actors are computational entities that can: ○ Send messages ○ Receive messages ○ Create other actors ● Elixir processes ○ The key abstraction of Elixir’s concurrency model (Demo) ● Erlang OTP ○ Battle-tested patterns for building distributed, fault-tolerance applications ○ GenServer 

Component A struct containing state attributes System A GenServer Entity A struct with string id and a collection of Component PIDs An ECS implementation in Elixir 

Demo 

A walkthrough of an ECS implementation in Elixir A high-level overview of Entity Component Systems Background Drawbacks of traditional OOP / inheritance style code ECS Examples Code Next Steps Real life applications and examples of ECS in action Further learning, future improvements, and conclusion 

Next Steps ECS is an overlooked architectural pattern that overcomes some of the drawbacks of OOP-style inheritance, and is a great fit for distributed systems. Branching out into unfamiliar domains is a fruitful source of new ideas and patterns to write better software. 

No content

“ The worst case: The next generation of programmers grows up only being shown one way of thinking about programming. So they kind of work on that way of programming—they flesh out all the details, they, you know, kind of solve that particular model of programming. They’ve figured it all out. And then they teach that to the next generation. So that second generation then grows up thinking: “Oh, it’s all been figured out. We know what programming is. We know what we’re doing.” So the most dangerous thought that you can have as a creative person is to think that you know what you’re doing. Because once you think you know what you’re doing, you stop looking around for other ways of doing things. If you want to be open or receptive to new ways of thinking, to invent new ways of thinking, I think the first step is you have to say to yourself, “I don’t know what I’m doing. We as a field don’t know what we’re doing.” ” Bret Victor, on the Future of Programming https://vimeo.com/71278954 Next Steps 

Thanks Yos Riady yos.io