http://t-machine.org/index.php/2007/09/03/entity-systems-are...

IIRC this one was the one to really popularise the idea of not storing any component data in the entities. If you loosen that requirement, there were earlier ones still (eg the one from the Dungeon Siege team).

But as others have mentioned, ECS is really a special case of a relational model, so its entirely possible that Unitity's techniques have been done there already.

Also, I found it pretty difficult to understand the claims, they didn't exactly make it easy to read, so I can't quite figure out exactly what is patented. It also doesn't help that they don't clearly define their terms, eg what exactly do they mean by archetype? Maybe they describe it in the description before the claims, but I didn't find it at a cursory glance and it was too painful to try read it all. I wonder what their definition exactly entails, versus what I imagine they mean from what I know of archetype-based ECS's. For example, if they mean "a conceptual grouping of entities that have the same components" then non-archetype ECS could fit that, but if they mean their specific implementation then I don't know. EnTT, a popular non-archetype-based ECS, has had "views", which are ways to efficiently access components, since its first public commit in 2017: https://github.com/skypjack/entt/commit/b0b8ee7aea3d9f5cfe6f...).

Whether any of that is relevant to the patents validity, I have no idea. Probably not.

So they've patented a database server, basically.

The idea that there's anything patent-worthy in automatically storing like combinations of data with like combinations of data for efficiency is... patently absurd.

But that's where the patent system is, now, I suppose. It's now mostly just a tool to help incumbents raise the barrier to entry so they can fend new entrants off with lawyers rather than merit.

I'm most familiar with relational databases and the way in which their data is stored is generally dictated by the schema.

At a minimum, to be consistent with this patent we'd be talking about a database that accepts arbitrary groupings of predefined sets of fields, which then on-the-fly determines how best to pack these individual sets together with other sets belonging to other groupings. The fact that we are talking about two types of collections (one nested in the other) is key -- that is, the nesting of fields within the sets ("components" in ECS terminology), and the nesting of these sets within the groupings ("entities" in ECS terminology).

One of the major features of relational databases (and the improvement over their predecessors) was precisely the disconnect between logical and physical model. If the logical schema dictates how something is stored physically, then it's not a terribly good system. At the very least the intention with relational databases was to provide for this extra flexibility that previous models didn't have. Sure you don't have to exercise that flexibility but it's always been there.

> we'd be talking about a database that accepts arbitrary groupings of predefined sets of fields, which then on-the-fly determines how best to pack these individual sets together with other sets belonging to other groupings

So basically columnar storage with table inheritance would be enough to do the trick. I know there's databases for either of those features, and it's absolutely not a huge leap to put the two together. Fact is I wanted to implement something like this for CLOS but didn't have the time yet, sadly.

I’ve seen engines that do that and updated my own code to do so. Unfortunately git says that was added after they filed.

Their employees could have easily pulled this from community discourse.

What’s probably needed is community backlash; no more unity games. It worked with Apple.

"In this 2017 GDC session, Blizzard's Timothy Ford explains how Overwatch uses the Entity Component System (ECS) architecture to create a rich variety of layered gameplay."

(My favorite resource to explain ECS + NetCode)