Entity component systems and you: They're not just for game developers

While the rest of the software architecture world is admiring their containers, edge computing, and cloud-native architecture, game developers are off in the corner creating entity component system (ECS)-based architectures and pushing the boundaries with this flexible, compatible, composable approach. It's not just for games. Paris Buttfield-Addison, Mars Geldard, and Tim Nugent explain why.

The hot new1 thing in software architecture for games is entity component systems (ECS). While the rest of the software architecture world is admiring their shiny containers, edge computing, and cloud-native architecture, game developers are off in the corner creating new ECS-based architectures and pushing the boundaries of architecture with this runtime-flexible, highly compatible, safe, and easily composable approach to software. An entity-component-system involves three components: an entity (a general purpose object); a component (the parameters for one facet of the object); and the system (something that runs continuously and performs actions on every entity that has a component of the same facet the system manages). ECS makes for the safe management of dependencies; the system can check entities for the components and perform logic as needed. Nothing is dependent on anything else in a strongly coupled way. ECS also makes for easily “composable” software. There’s no complex inheritance tree, since every entity has little more than an ID and a list of the components—its facets. Any object necessary can be created by composing an entity with the needed facets. Features from one type of entity can be added to another by including the necessary components. In game design, the use is obvious: a physics engine in a game can iterate through all the physics simulation components present, performing any necessary calculations without caring how the entity is drawn. Or health point components can be attached to a play entity but not to other entities in the game world, and the health management system would know how to deduct health from entities that have health point components when a collision that would cause a loss of health occurs. Intersystem and intercomponent communication can be a problem in this architecture, but there are a number of solutions, including use of the observer pattern. This architecture is not just for games. Paris Buttfield-Addison, Mars Geldard, and Tim Nugent explain why. You’ll learn how to apply the lessons from decades of ECS use in game development to the wider software development and software architecture world and see how ECS is related to existing similar architectures. (ECS is kind of microservices, combined with functional programming, on some levels, but isn’t quite the same.) ECS isn’t for every software problem, but you can learn a lot from it even if you don’t use it.

1. ECS debuted in 1998.