Hacker News Reader

Comment by vvanders | Hacker News Reader

Sorry but we were doing ECS long time before that in the industry. I remember doing it back on the PSP with Lua(meta-table -> component mapping) and a backing in house C++ runtime.

It was pretty widely known in industry as a way to have cache locality and made it out to the broader dev community a good while after.

View on HN

As I mentioned in another thread,

"Component Software: Beyond Object-Oriented Programming", 1998

https://www.amazon.com/gp/product/0201178885

Could you elaborate the way your system worked in Lua? Was the table itself an Entity, and which meta-methods would link with component? What kind of querying capabilities did a System have?

I've seen metatables used often to implement inheritance, but not the ECS yet.

It's been over a decade now but if I remember right yeah the entity was a table, meta-table would do a lookup for the related component(ex: table.mesh would give you the mesh component) and each entity also had an optionally available coroutine for AI logic. Components were batch processed by type for the performance sensitive areas.

The coroutines there was incredibly useful, our designers could write AI that was almost literate programming(yield value was number of frames to wait to re-eval coroutine). Something like: Walk to point A, yield until at A, turn, walk to point B, yield, check for nearby entity of type, yield, etc.

Oh and it also ran the whole game state in a 400kb preallocated block in a system than only had 8mb of accessible ram(rest went to vram).

That's nice, but why all the game engines and libraries introduced it only recently? Defold, Unity ECS, etc.?

Because not every engine slaps a fancy ECS tag front and center, the pattern evolved concurrently in industry (and we all had games to ship).

If you look really carefully you'll find structured column databases have similar properties since when you optimize for speed cache misses are your number one enemy.

Yes, I understand that ECS is probably good for more low-level stuff like particle-like systems. But what about gameplay-code? Unity ECS is mostly about that, to think in a data-oriented way about your gameplay programming. The thing that bothers me is why huge commerical engine like Unreal Engine or idTech don't even lift a finger about that?

About structured column databases, the same thing could be said about Lisps like Clojure which match the RMDB data model. But people still find it hard to grok it, hence the low adoption rate.

> why huge commerical engine like Unreal Engine or idTech don't even lift a finger about that?

https://docs.unrealengine.com/en-US/ProgrammingAndScripting/...

But according to the documentation, that is just a OOP-hierarchy in which they separate the concerns, they miss the S in the ECS.

https://docs.unrealengine.com/en-US/ProgrammingAndScripting/...

The "S" in unreal is a tick. It's been about a decade since I last worked with Unreal but there was very much the concept of systems that processed batches of things in areas where performance was a concern.

Keep in mind that ECS is a design pattern and just like any design pattern applied blindly you can end up in a worse place than you started. A FactoryDispatcherQueuePatternImpl helps no one despite using many design patterns. When it comes to ECS it's much more about the spirit than the letter of the law.

Not so. The physics system works on all physics components. The renderer system works on all rendering components. The networking system work on all components that are enabled for network replication.

You mean the big commercial game engines? They took a while time to adjust because, by definition, they're big. Harder to move the entire ecosystem at once.

But that's hardly "all the game engines"

Reply on news.ycombinator.com