All this hype around ECS started when Minecraft, Factorio and They Are Billions proved that the paradigm works, though that is just a small percentage of games that can benefit from ECS. The rest should use the classic OOP model. I really don't see how a game like Dota, CSGO or your average Battle Royale will be better with ECS. I agree with the article.
There are libraries enabling ECS for you if you are not looking for an engine like Unity:
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.
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).
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.
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.
Total Annihilation (1997), Thief (1998), Dungeon Siege (2002), and many others used ECS and their developers wrote about it long, long before Minecraft and others.
I believe ECS is in fact quite a bit older than that. As far as I can tell, ECS first started being talked about by AAA developers who were trying to find efficient ways to deal with the memory hierarchy in modern computing platforms (it got quite big specifically with the PS3, which had a very hard to deal with memory layout that could totally kill game performance). ECS allows data to be processed in a very cache-effective manner.
Kind of providing an ECS-based game pre-2016, before Factorio, Minecraft Non-Java, They Are Billions and Overwatch (as I was told in a comment) got released?
Dungeon Siege, although the slides where this was revealed seem to no longer be online. Additionally, here is the blog post from 2007 that largely introduced the concept in the form we know now, based on the Dungeon Siege talk and others: http://t-machine.org/index.php/2007/09/03/entity-systems-are...
Although, arguably, Dungeon Siege's component architecture is different from what we call ECS today.
Thanks, I will check them out. I'm out of the loop when it comes to older games since for me game development is only a recent hobby. I'm developing Big Data stuff mostly with Java and Scala, but I have been playing with data-oriented stuff in Clojure, hence my interest.
Funnily enough, I came to it in reverse: I learned about ECS years ago (from the tmachine series of posts, posts about Dungeon Siege, and others I can't remember) and became interested in Clojure's data-oriented stuff because of my interest in ECS. Although, I became interested in and used Clojure already, due to its focus on immutability and functional programming, before people really started pushing the data-oriented aspects, so it was an easy evolution for me.
There are libraries enabling ECS for you if you are not looking for an engine like Unity:
C++: https://github.com/skypjack/entt (Non-Java Minecraft uses this)
Java: https://github.com/libgdx/ashley
Rust: https://github.com/bevyengine/bevy (it's still work in progress, not battle-tested and a moving target)