![\"Entities\"](\"http://blog.lmorchard.com/wp-content/uploads/2013/11/pp-entities.jpg\")
\n Entities: OOP & ECS\n
\n\n Contents\n
\n \nThe Entity, Component, & System design pattern is old hat for many game developers. But, keep in mind that I’m a web developer, and mostly on the server side of things for the past decade or so. One of my last big revelations was discovering the Model, View, & Controller way of doing things. Apropos of that, this ECS thing seems to be a Big Deal of similar proportions.
\n\n\n\n\nWhen I first started working on Parsec Patrol, I started sketching out a plain vanilla class hierarchy. You know, the kind I saw when I first started learning about Object Oriented Programming.
\nI started with an Entity, which begat a RenderableEntity, which begat things like a SpaceShipWithThrustersRenderableEntity. I built a game loop that iterated through all the objects in the universe, calling a tick() method on each in turn. Simple, just like things I’d seen in textbooks.
As I started trying to pile things in, though, I flirted with multiple inheritance and primitive composite patterns and everything just got messy and slow. Performance sucked, and garbage collection went wild. So, I figured I must be Doing It Wrong, and started on a Google quest into game engine design to maybe absorb some modern thinking on these matters. Eventually, I stubbed my brain on the notion of an “entity/component system”.
\nPlenty of other blog posts & articles out there have done a great job of describing how an ECS design works:
\nI don’t want to totally reinvent the wheel here. But, let’s see if I can’t break it down a little, if only to convey my excitement with discovering this design pattern and the fun I’ve had with it.
\nFirst, you’ve got the Entity: Everything in the game universe is an Entity – ships, rocks, missiles, the works. In my naive OOP world, Entities were instances of classes from my tangly, thorny hierarchy.
\nBut, in this ECS world, an Entity is a database ID – just a string, really.
\n\n Entities: OOP & ECS\n
\nWait, what? Yeah, that was the first thing that bruised my lobes. This design pattern turns everything inside out. An ECS framework is better understood as a data-oriented system than an object-oriented system. In fact, a blog post describing an ECS system in relational database terms really drove it home for me.
\nSo, given that an Entity is an ID in a system that looks like a SQL database from a certain angle, what’s in the database?
\nComponents are in the database. Specifically, Component types correspond to tables and Component instances correspond to rows. Structurally, a Component is a collection of properties – not unlike the columns in a row in a table in a database.
\n![\"Parsec](\"http://blog.lmorchard.com/wp-content/uploads/2013/11/2013-11-27-10.14.50.jpg\")
\n Components: OOP & ECS\n
\nIn case it doesn’t quite make sense yet, here are some sample Components:
\nImagine each of those as schema for database tables, each with the Entity ID as primary key. Given an Entity ID, you can query across all the tables and assemble a set of Components that completely describe an Entity in the game universe.
\nNote that any given Entity can be composed of any combination of these Components: A spaceship might be described by Shape, Position, Motion, Thruster, Health, and BeamWeapon. Meanwhile, an asteroid drifting in space might only offer Shape, Position, and Motion.
\n(Also, just to be pedantic: This doesn’t really have to live in a SQL database. In fact, I currently just use an ad-hoc in-memory key-value store – i.e. a set of heavily-abused JavaScript objects.)
\nSo, where’s the stuff that makes things go? In an OOP design, this would live in the methods of the objects, bundled by classes to go alongside the data. In the ECS design, Entities are just IDs and Components are just data – neither methods nor code implementing game logic live in either of those artifacts.
\nThis is where Systems come in: Systems are modular mini-game loops. The “master” game loop holds a list of available systems and runs a tick() method on each of those in turn. Each System performs a query against the Component database – usually for all instances of a particular type – and crunches through updating the properties for each.
![\"Systems:](\"http://blog.lmorchard.com/wp-content/uploads/2013/11/2013-11-27-10.47.11.jpg\")
\n Systems: Most confusing diagram ever?\n
\nConsider a MotionSystem:
\nx, y, and rotation properties of the Position using the Motion properties.Consider a SeekerSystem:
\ntarget_entity_id.Notice that each system deals only with data directly relevant to the job at hand. Rather than loading up a full representation of an Entity, each System only touches the specific Components needed. For instance, MotionSystem and SeekerSystem touch Motion and Position - but never Shape Components.
\nThis adds some efficiencies for data stored entirely in memory. But, I expect this will have huge implications for data that might someday come from a database or over a network. I’m also thinking that this pattern lends well to shuffling certain systems off onto background threads or Web Workers – the need for data coordination is limited to just the relevant Components when needed.
\n![\"Parsec](\"http://blog.lmorchard.com/wp-content/uploads/2013/11/Screenshot-2013-11-27-11.16.42-1024x714.png\")
\n Parade! Of! Sprites!\n
\nThese Systems feel a lot like particle systems: Tight, focused code working close to the metal with data, skipping a lot of overhead and object juggling. Components get modified in place and are rarely discarded – that seems to save me from a lot of garbage collection issues. And, if a particular Component is not actually used by any existing Entity, the System looking for it just won’t perform any work.
\nFor the most part, Systems act independently & are very loosely coupled. They can cooperate through shared Component data – consider how the SeekerSystem modifies the Motion Component, and the MotionSystem uses that data to move the Position Component. I’m also playing with a crude pub/sub messaging system for things like transmitting damage from one Entity to another, but I suspect that might be the wrong approach.
\nAnd, once I was freed from my tangled class hierarchy, things started to get fun. The mental cost for adding a new layer to the system dropped fast: Add a new Component or two, add a new System – and suddenly Entities can do new things!
\nAnd, the most fun part? I get to describe things in the game world like a five-year-old and not give a crap about serious programming stuff:
\n![\"Spaceship](\"http://blog.lmorchard.com/wp-content/uploads/2013/11/2013-11-27-11.06.12.jpg\")
\n Spaceship doodles\n
\nI’ve got a bad guy space ship! And it’s shaped like an arrow! And it’s got rocket thrusters! And it chases the good guy! And it has missile launchers! And it blows up when the hero shoots it a lot!
\nOh, and I’ve got a good guy ship! And it’s shaped like a cool thing different than an arrow! And it’s also got rocket thrusters! And it goes where you click! And it has lots of laser beam guns!
\nOh, and there are rocks! They kind of spin a bit and drift around! They bounce when they run into things! Sometimes they blow up!
\nThat’s almost exactly the running dialog in my head when I write the code. It’s pretty cool.
\n", "body": "\n Contents\n
\n \n\n Entities: OOP & ECS\n
\n\n Components: OOP & ECS\n
\n\n Systems: Most confusing diagram ever?\n
\n\n Parade! Of! Sprites!\n
\n\n Spaceship doodles\n
\n