Entity–component–system (ECS) back and forth
skypjack.github.io
skypjack.github.io
I like that both this and TFA mention a focus on the data, and "row"/"column" roughly compares to (say) an SQL table. - It's an interesting way of thinking about objects/entities.
One of his points is that you still have to solve synchronization for allocations and deletions from the arrays.
Problem: Most games are built in with a game loop ticking frames through many gameobjects/actors. Many actors share some functionality like physics collision, but there is also a lot of unique functionality on the same objects.
Naive solution: Use inheritance to build out your core functionality and override functionality as needed.
-This leads to a mess of interacting parts a massive type tree with many permutations of functionality.
-The deep type hierarchies blow out cache locality as the natural way is to tick through all functionality for a single object as you loop through all objects
ECS: Break functionality apart into discrete systems. Use composition to build the permutations of functionality.
-Its easier to to manage what you intended and also easier to experiment with functionality through composition than inheritance.
-The natural way to loop through functionality is one system at a time. You loop over your entities many times but because you can run the same system code in a tight loop its really speeds things up.
-Systems provide singleton like functionality to store global state in a private way. In a heavy actor model we have to rely on static fields, which can be ok, but now you have a large cumbersome hierarchy of functionality with global access to state.
tl;dr
-Composition over inheritance is good in all walks of coding.
-Many discrete tight loops of systems is usually better than one loop of complex logic.
Do you happen to know how that's usually done?
If you want to see the (javascript) innards: https://github.com/andyhall/ent-comp
Game objects were Pascal records. There was 1 global table with all the records. There were many functions called from the game loop processing all the records in some way. Like one function updated orientation, velocity and position. Other did collision detection between objects, another did collision detection with the map. There was a function for possible reactions to collisions (if you collided with a powerup you get 100 health etc).
It was all data driven, objects had integer indices referencing tables with predefined attributes. Like your ship record had "engineNo", which referenced table of engines with power, turning radius, fuel consumption, and other parameters for each kind of engine. Same with guns, armor, power generators.
Map was 2d array of records which had tileType, tileImage, xParam, yParam. If tileType was teleport - it teleported any object it collided with it to (xParam, yParam). If tileType was switch it triggered tile on (xParam, yParam) every time something collided with it. There were also tileTypes that damaged anything that collide with it to a various degree, and tileTypes to jump to the next level. That was like 3000 lines of code in 2 files (because Turbo Pascal refused to compile it when it was in one file :) ). Everything was global. There were no classes. And it was pretty easy to understand and modify, and allowed a lot of design possibilities.
Well, it would be easy if I used proper variable names and constants. As it was you had to remember what tileType==10 means, and I had 3-screen long function that was nested if-then-else with all possible tiletype-vs-objectType interactions. Like - bullets slow down when entering water tiles and disappear when hitting walls. Napalm particles change into smoke particles which expire after X frames. Napalm particles glue to walls and slowly move down. Grenades explode when touching walls.
There were lots of such rules, but putting them in one place was the right thing now that I think about it.
I'd argue even with abysmal naming practices it was more understandable than most of modern codebases, where this logic would be separated into 20 small classes.
Then I learnt OO programming and tried to make a proper object oriented game architecture, and it was never as simple as that naive approach :)
A related low-level design choice for high-performance data structures is “Prefer structures of arrays over arrays of structures.”
That's what worries me to be honest. I'm right there with you that ECS is just the right way, but whenever I can't come up with good arguments against my choices I feel like I'm blinded by faith.
My main argument for why I wouldn't use ECS in a greenfield game project is that a lot of existing tools don't play nice with it. That's about it.
If memory accesses were as cheap as 40 years ago, inheritance vs. composition would be a lofty debate about elegance and architecture and programming language semantics and taste; now it has become a much more practical and detailed tradeoff between difficult design and bad performance.
To clarify for readers not familiar with the motivations here:
Memory access is in fact cheaper than it used to be, as you might expect. The concern is that it did not get cheaper nearly as fast as processors got faster, meaning the relative cost of accessing memory became much higher when you could be doing more calculations in that time instead.
Specially what allows for better performance is accessing memory in a pattern that can be predicted and prefetched. Linear access is best, because looking up a single byte in memory has approximately the same overhead as looking up a contiguous chunk of bytes.
Think Wiley E. Coyote picking up train tracks from behind himself and putting them down in front. If your memory access looks like that then you are less likely to suffer from memory access bottlenecks.
Without a component-based model, sure. But with OOP specifically (which usually just means object hierarchies) you're chasing a lot of pointers and usually (though not always) doing a lot of null checks and other branching inside loops.
I'm not fully on-board with the (between-the-lines) assessment in the article that this is somehow inferior to, or should just be a stepping stone towards a full-blown ECS though. At least not for a simple game where performance is not really a concern. My view is that a hybrid approach can actually be better than a 'real' ECS for those kinds of cases, taking the best of both worlds. In my case I don't use any inheritance, only composition, I don't have to fight OOP, but I can still write very clear and concise code to access and manipulate properties of my game objects. It may not be cache-efficient and whatnot, but that really is no concern for my simple game at all, having at most 20 to 40 lightweight entities active at the same time. Physics updates (which could drag down performance if too inefficient) are treated like in a traditional ECS, simply advancing the full physics sim for all entities completely separate from the game objects.
Looking forward to the next article!
If you look at Overwatch's ECS ( https://youtu.be/W3aieHjyNvw?t=326 ), there are many systems that can read from 10+ different components. For every entity in this system, at least 10 reads with no locality whatsoever are done. That seems crazy slow to me.
The other idea is that where there is one access pattern there will be more of the same. So by updating by System you keep as much as possible hot in cache by doing all the similar lookups together. So whilst the first lookup might have ten complete misses the next one probably won't.
At a gameplay level there's a lot of chaos going on and entities are not generally doing things that are easy to organize in a way that avoids cache misses anyway. On top of which you are juggling ease of change with optimization. At which point you just need to be fast enough. I'd also bet most bottlenecks for Overwatch were not in gameplay code.
Mostly though people should be thinking in a data oriented way rather than grabbing an ECS framework and expecting that to magically make things cache efficient.
Whereas if you tick each entity separately and run all the logic, each new entity tick is following on to so much unique code having run that it is probably starting all over on uncached instruction fetches.
The short version is that ECS works against creativity. I want my entities to be unique: they move differently, they react to damage differently, they die differently, etc... In a ECS world, this means having at least 5 different components and 5 different systems per... type of entities. With just 10 entities you already have 100 different classes... that are never going to be reused. Also, because I reimplemented my game to OOP I was also able to compare the performance and noticed that the ECS performed worse (although maybe my implementation was not good?).
Shouldn't it be more data data-driven than that? That is, instead of 5 components and 5 systems, you have one or two components and one or two systems and the components declarative describe the differing behaviours in a data-driven manner.
In my personal experience, if you have objects or inheritance to define every possible behaviour, the codebase becomes a huge tangle and performance will suck and actually creating the content becomes a pain. I'd personally much rather have components that define the general flavour of the behaviour and then use data to fine-tune it.
And for the edgy edge cases.. have a script component that runs Lua or whatever.
Of course, you can do that with OOP too and you can certainly write high performance OOP, I just personally find it much harder due to how it encourages distributing state across the codebase, especially when you want to do it in a multithreaded environment. But if you've had better experiences with OOP, then more power to you, use what works for you. I would, however, not write my own ECS, but use a well designed and well tuned existing one, like the article authors EnTT.
From this view of the world it's fairly obvious that other structures need to reference entities through their handle. Or in the case of middleware with its own view of the world a translation layer keeps things synchronized.
'entities' ~= object references (ids of objects)
'components' ~= properties (instance/member variables) of objects (maps of entity ids to components)
'systems' ~= algorithms that operate on lists of components
native: native to your programming language, ie no serializing / deserializing types
It's a pattern of organizing data and code that consists of:
Entities: Conceptually these are like objects, in memory they might just be an index.
Components: Conceptually these are like fields on objects, they can typically be added and removed unlike normal fields. If entities are being represented as index's, each different type of component is generally stored as some form of Map<Entity, Component>.
Systems: These are where you store your logic, they typically iterate over all entities with a given set of components and do something. For example iterate over all entities with a position and velocity components, and do position += velocity * dt.
monster = {} // create an entity
monster.hp = 10 // give it properties
monster.pos = [0,0,0]
currID = 1 // ECS init
hpData = {}
posData = {}
id = currID++ // create an entity
hpData[id] = 10 // give it properties
posData[id] = [0,0,0]
Using ECS is somewhat like treating your game state like a normalized database. It lets you perform operations on all the items of a certain type at once.
Say in my game I need to recenter my origin on a regular basis. In an open world game, you want to make sure that players don't start to see errors caused by floating point arithmetic, and the further away their position gets from 0, the worse this gets. To fix it, one option is to transform all positions by the same amount to keep the player's absolute position near (0, 0, 0).
To do this in the hierarchy style, the code might look like this: (Using JS because I was writing it today so that's where my brain is)
var gameObjects = world.getAllGameObjects();
var offset = [-1000, 0, 500]; // Pretend it's a real vector
// Iterate through every single object in the game
// (Not using foreach or filtering in either example, sue me)
for(var gameObject in gameObjects) {
// Branch on every game object just to see if it's positioned in the world
if(gameObject.position !== null) {
// Do what I really wanted to do
gameObject.position.add(offset);
}
}
// This can vary greatly based on implementation
// I'm going to go with an option that reads easily
// This should just give back the list of components, which we'll say is an array.
// Lookup time in this fictional system is the cost of a dictionary lookup.
var positions = world.getComponents('position');
var offset = [-1000, 0, 500]; // Pretend it's a real vector
// Iterate through only the things we care about
// Not using map here, sue me
for(var position in positions) {
// Do what I really wanted to do
position.add(offset);
}
Many ECS systems will allow you to filter down to the set of entities that have two or more components at the same time. Obviously more expensive, but still not as wasteful as checking every object or adding an update function to run every tick on every relevant entity.
The above code was written just before bedtime and not against a real ECS library or OO hierarchy, so please forgive any obvious errors.
If I made a living in games I'd probably try to fill that hole myself, but it's a hobby for me, and one that doesn't get much time allocated.
I was replying to someone who asked about the What.
Incidentally, FWIW I think your post about the why completely misses the point of ECS. Looping over entities with a particular property is easily done with OOP hierarchies or anything else. The benefits of ECS are elsewhere - that you can freely add or remove an entity's properties (without type issues or hot code becoming polymorphic), that the data you frequently iterate over can be stored in friendly contiguous chunks, the usual benefits of composition over inheritance, and so forth.
I meant to say that the why is to treat your data like a normalized database, which provides those properties you list at the bottom.
In fact my example demonstrates at least the following properties:
> (without type issues or hot code becoming polymorphic), that the data you frequently iterate over can be stored in friendly contiguous chunks
My example was not to show that you can loop over every entity. It was to show how easy it is to loop over only what you care about without doing extraneous work, by iterating over a contiguous chunk of exactly what you need to update.
I was going to add an example of creating a regenerating health component and system, but I didn't for a couple of reasons. One, it was already past bedtime. Two, I would have compared it against adding a tick handler and so it would need to be a larger example with more explanation of the way the imagined engine works. The post was already pretty long in the first place so I decided against it.
Your example demonstrated iterating over a filtered list instead of an unfiltered list. The "contiguous chunks of data" benefit of ECS refers to how the underlying data is stored in memory, not to which data you iterate over (and both of those are orthogonal to types/polymorphism).
> Your example demonstrated iterating over a filtered list instead of an unfiltered list. The "contiguous chunks of data" benefit of ECS refers to how the underlying data is stored in memory, not to which data you iterate over
I apologize if this came across unclearly, but that's why I started with a block of comments explaining my fictional example ECS system. I did specifically call out that I was retrieving the backing array for the positions component, implying that components were flat arrays in a dictionary where the key was the component type. I hope we can agree that an array should be expected to be a contiguous chunk of memory when giving a quick example on the internet.
The relevant part of my previous code example:
// This can vary greatly based on implementation
// I'm going to go with an option that reads easily
// This should just give back the list of components, which we'll say is an array.
// Lookup time in this fictional system is the cost of a dictionary lookup.
var positions = world.getComponents('position');
> (and both of those are orthogonal to types/polymorphism)
I probably should have given an example in a language other than Javascript, since it's not statically typed.
This makes me curious, how bad would it be to actually store game state in say, an in-memory sqlite database? I feel like this could get you some nice things, like auto-destroying all components of an entity via foreign key deletion, being able to merge/join entities with the intersection of multiple components etc. Assuming the clunkiness of interacting with sqlite is abstracted away, I wonder what the real performance differences would be.
My gut feeling is that when crossing the SQL boundary you would lose a lot of the performance you would otherwise be gaining from using an ECS to begin with. Especially when talking to the GPU.
I'd love to be proven wrong if someone has the time though.
And lets be honest, half of my performance problems in webapps are caused by the overhead of sending a query, the database is rarely bottlenecked by inserting or updating the data on the physical storage device if I do not use bulk insert or bulk update methods.
Please try it out though, I would love to see a proof of concept that took the ECS-as-database approach. Like I said earlier in the thread I expect it would not do well, but I'd be interested to see the results either way.