Thoughts on ECS | Hacker News Reader

Thoughts on ECS

blog.voxagon.se

23 pointsindy13 comments

I see a lot of parallels between these ECS discussions and those had by DBAs working on SQL databases.

Why not use a RDBMS engine, perhaps specially tuned, to handle your game's data? Joining arbitrary tuples together at runtime as fast as possible has been the fitness function of every commercial RDBMS vendor since inception. Latency incurred by the network hop and disk IO is probably helping to maintain an illusion that these engines are somehow fundamentally incompatible with gaming use cases.

I've been working on my own ECS system and can say that you're not wrong, most of it is indeed a data problem (and going past DB into just memory allocation and management). Games in truth don't even have that much data, for example you might have 1-2k entities, obstacles etc.

However unfortunately I haven't found any existing DB type solutions that work for the gaming use case, even when looking at in-memory only solutions. Real world business solutions have two major constraints, a) Do a bit of work as fast as possible and b) Do a lot of those bits as fast as possible. They have additional 'pros' where you can always potentially add more hardware to any problem to achieve that throughput.

Gaming uses both of those as well but for the second case it comes at it from c) Always obey the framerate. For 60fps you have 16ms to do everything and of that you might have only 8ms available for code. Even so that might seem a lot, you could for example do 10 billion adds in that time. But throw in a few loops, conditionals and suddenly it means that for a few thousand entities you can do almost no data transformation, copying etc. Everything needs to be in place and ready to access as is.

Existing DB's are about storing data and delivering it, what we need instead is a dynamic memory manager that can move your data around in memory as needed so that elements that are currently being processed together have some advantageous layout and/or are grouped correctly for some process.

That's because ECS is a database. I'm not exaggerating. "[ECS] is a database" appears in Scott Bilias's seminal talk on ECS. As Bilas put it, ECS is a data-driven, in-memory columnar store optimized for hot-path queries over components.

The reason OOP-based games have the problems they do is because they're essentially solving an ontological problem taxonomically. This mismatch over-complicates the solution.

1. Slide 12 https://www.gamedevs.org/uploads/data-driven-game-object-sys...

> The reason OOP-based games have the problems they do is because they're essentially solving an ontological problem taxonomically.

I think this issue is not constrained to OOP-based games. Many business models are not possible to express directly (cleanly) using a heirarchy of OOP types due to concerns around circular dependencies and serialization.

ECS engines (well, the entity storage and query parts) are essentially purpose-built (usually, column-oriented, I believe) in-memory, embedded RDBMS engines, already.

I know databases cache which could potentially solve at least some of the disk IO latency but I'd be curious to see if a network hop on a local host would add too much overhead

I know you can actually use SQL lite in file mode which would eliminate both of these issues.

His "Sensible ECS" is basically what I did on my (simple 2D) game, just simple structs with components, and functions that operates on these components.

That works well, although it does not features parallelism, but still managed to run on a old laptop that can at most run Windows 7.

The final paragraph has the Crux of the issue imo.

They admit their proposed solution of statically declaring functionality in an entity has a downside.

> The main limitation is of course that entity types are locked down at compile-time and cannot be changed dynamically.

ECS is used I believe mainly in highly dynamic games.

His proposed alternative to statically hard code functionality in entities is great if you don't have a dynamic functionality which a lot of games dont.

For games like RPGs or space exploration where you have a variety of different entities with a variety of different components you can't really hard code things.

ECS is a great tool in certain situations. Not a great tool in others.

Also, I think it's important to say that ECS is not the only composition option, you can just use "EC" (or also CES): while on ECS the behavior runs on systems, on "EC"/"CES" the behavior runs on components, which is the case on Unity (by default) and O3DE.

I believe the mentioned Scott Bilas famous talk about composition follows this "EC" model instead of ECS, except that he calls it Game Object instead of Entity.

Forgive me if I'm wrong about this, still trying to get my head around ECS concepts, but isn't the whole point that data and behaviours are uncoupled? Whereas Unity's Game Objects both hold data and are composed of behaviours (rather than being data-only objects that are operated on from with-out by systems)?

Yes, I made this comment because sometimes I see some devs calling Unity an ECS (although it has an ECS option, but that's not the default mode most unity games uses).

Just to say that ECS is not the only composition option: Entity with composed behaviors is also an option (and the most traditional one I believe), and it does not have the infamous complexity of "pure" ECS in my opinion.

Just as no battle plan survives contact with the enemy, no design pattern survives contact with a specific implementation. You will often have to compromise purity for the sake of efficiency, the quirks of a specific language, performance, or in the case of a framework a consistent and general purpose API.

Really didn't realize that most people think "Elastic Container Service" when they hear ECS? (I could be wrong, but it's also def not "Entity Component System", so should define the thing up-front)

Reply on news.ycombinator.com