Entity Component Systems

Entity-Component-System (ECS) is a distributed and compositional architectural design pattern that is mostly used in game development. Elixir is a dynamic, functional language built on top of the Erlang VM designed for building scalable and maintainable applications. In this talk, discover how we can use both ECS and Elixir in a novel approach to structure our programs beyond the traditional OO/inheritance paradigm.

https://goo.gl/ECeFOI

Transcript

1. Entity Component Systems Yos Riady yos.io goo.gl/ECeFOI
2. 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
3. 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
4. Animal hop() Bunny swim() Whale GameObject kill() Killer Whale
5. Animal hop() Bunny swim() Whale hop() kill() Killer Bunny GameObject kill() Killer Whale
6. 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
7. 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
8. 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
9. Entity Component Systems
10. 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
11. What qualities might a bunny have?
12. 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
13. 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
14. The bunny entity
15. 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
16. The carrot entity Placeable - int x - int y - int z Consumable - float calories Physical - int height - int width - int length
17. The ghost entity Placeable - int x - int y - int z Spooky - int spookiness Seeing - int sight_radius - boolean night_vision?
18. 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
19. 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”
20. 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
21. 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
22. 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
23. The spreadsheet analogy for ECS
24. The spreadsheet analogy for ECS
25. • 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
26. • 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
27. 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
28. ECS in the Real World
30. 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
31. Entity Component Systems in Elixir
32. 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
33. 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
34. 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
35. Demo
36. 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
37. 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.
39. “ 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
40. Thanks Yos Riady yos.io