It's aggravating that parents are purposefully written in a language that makes it harder to read.
What I could gather from it is that this is just an implementation of archetype-based ECS. Which just means that entities with the same set of components (that is, the same "archetype") are allocated together.
But I don't know whether they are patenting archetypes in general or just a narrow usage.
Now I have a question: is it possible that things published before the date of the patent (24 march 2020) are infringing on the patent? Or, on the contrary, things published before this date can actually be prior art?
Because, there are Rust ECS libraries that use archetypes, like for example legion https://crates.io/crates/legion/0.1.0 - that had its first release on 9 march 2019. And even at this date, the concept of using archetypes to optimize the memory layout of ECS applications is not novel. More about this here
I would say that the google v8's Javascript optimization, where they create a new struct layout for each possible combination of object fields, might as well count as prior art. It doesn't use ECS though: but I don't think that prior art needs to check all technology boxes. I argue that, in light of v8's trick to turn objects with dynamic fields (traditionally stored as a hash table) into objects with statically known fields, then ECS archetypes are not novel enough for a patent.
(And I don't even know if the v8 optimization is itself novel)
> Now I have a question: is it possible that things published before the date of the patent (24 march 2020) are infringing on the patent? Or, on the contrary, things published before this date can actually be prior art?
You have to look at the date of filing, not date of publication. The date of filing is June 12, 2018 (patents take a few years to issue these days). So March 9, 2019 cannot be prior art.
This is very very concerning. Not only Amethyst's legion is archetype based, but also Bevy's ECS. So the Rust gamedev ecosystem is somewhat tainted (depending on the specifics on the patent and the source code of those frameworks, but I think that even reading the patent is risky - or at least I was told that, because if you know about the contents of the patent, infringing it is worse)
If someone online talked about archetypes earlier than June 12, 2018 that can be prior art.
You don't need to have working code to take on a patent. If someone posted a medium article, or even some kind of proof of concept or cobbled together POC that'd be enough.
(I think really any kind of proof that you had the idea before that date is good enough -- a personal diary would work in principle, but you'd need to somehow prove that you wrote your thoughts down on the date and didn't forge it after the fact)
> "a personal diary would work in principle, but you'd need to somehow prove that you wrote your thoughts down on the date and didn't forge it after the fact"
Patent agent here, not patent lawyer. (that means I passed the patent bar exam and could write your patent, but could not sue anyone over it.)
Wrong, wrong, wrong. Prior art has to be "published" (and there is a whole body of case law about what that means). Maybe you are thinking of the old "first to invent" rule?
This is correct, although published is pretty broad it doesn't include everything under the sun.
The real problem is that the patent examiners are not in general required to look at the whole breadth of what is published, just what is in the patent databases.
As a result there can be clear prior art, but unless it gets fed in during the review process, the practical way to resolve that is likely to end up in court, and likely to be expensive.
Of course often "clear prior art" isn't too. Hence the process to sort it out.
Interesting side note about non-patent prior art (by the way, the examiners do, most of the time, look for it):
I was told that a proposal to require the examiners to use Google was rejected by the union: if you're going to require us to do more work, then you have to pay us more.
This was back in 2012 or so. I have no idea if now they have to use Google, but they only get about a day and a half on each patent (again, this is old data).
> (by the way, the examiners do, most of the time, look for it)
Sure, but usually superficially (and not, I think, required); which is fair - you can't practically require the patent examiners to have the kind of breadth and depth necessary to have a good feel for this.
One more point about this: the date on the publication isn't necessary the effective date. If it's a journal that says "May 1999" that doesn't mean the date is May 1. It would be the date that it became available to persons in the art.
Getting a librarian to say "yes, we cataloged it and made it available on May 5" would be pretty strong. Or a Wayback Machine archive from May 2.
Still I think I've been deposed (I got grilled by an actual hostile patent lawyer) before over an old Usenet post I made in the late-90s (that was really more of a "showerthought" in the middle of an flamewar) that was being used to attack a patent.
It's specifically archetype based ECS that's been patented. Like (seemingly) everyone else in gamedev, I've implemented ECS multiple times over the past 10 years. The last time I did it was in Rust, trying to be the first to use Rust's awesome parallel processing constructs to make an automatically parallel ECS, I got distracted halfway through and then specs beat me to it.
I'd never seen or heard of archetype based ECS before I first saw Legion and I was very impressed with it. I don't know where they got the idea but it's very worrying if Unity legit came up with this first. I'm not super up to date on what's happening inside AAA studios, but what I've seen in production is that game studios usually manually group components to optimise performance. The automatic grouping in archetypes is definitely not mentioned in any tutorial or game engine architecture I've ever seen before Legion.
Ignoring the specific claims in the patent (automatic memory optimization or whatever), if we're just going by entity component system articles, we can do a lot better. Here's one from 2007:
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.
It's not relevant. Unity is claiming an automated system for determining an optimal memory layout as entities with new combinations of components are generated (at runtime). Such a layout defined in advance would not infringe.
I was wondering when this would come up. Everything people are inventing in the "ECS" space, including the very concept of "ECS" itself is just concepts from databases being adapted to storing small amounts of ephemeral data that needs to be manipulated very quickly in-memory rather than large amounts of data that need to be persisted reliably on disk.
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.
Can you name a database that performs such a function? There might very well be one, but I'm not aware.
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).
> I'm most familiar with relational databases and the way in which their data is stored is generally dictated by the schema.
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.
"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."
Now I expect someone to develop an AI-based translation system to convert legalese into layperson's expressions. It could be easier than translating two natural languages.
You might not even need AI if the copied phrases are precise enough (which they’re incentivized to be). Just a regular string search, with annotations and/or a mapping to phrases used by human beings.
> It's aggravating that parents are purposefully written in a language that makes it harder to read.
Legalese is a discovered language. Various phrases are reused because their meaning has been found in previous court cases. Using novel language to express an idea with an existing, court-tested alternative is begging for trouble.
Lawyers are not very expensive compared to the consequences of trying to read it yourself. This would still be true even with a less-legal-ly legalease.
What I could gather from it is that this is just an implementation of archetype-based ECS. Which just means that entities with the same set of components (that is, the same "archetype") are allocated together.
But I don't know whether they are patenting archetypes in general or just a narrow usage.
Now I have a question: is it possible that things published before the date of the patent (24 march 2020) are infringing on the patent? Or, on the contrary, things published before this date can actually be prior art?
Because, there are Rust ECS libraries that use archetypes, like for example legion https://crates.io/crates/legion/0.1.0 - that had its first release on 9 march 2019. And even at this date, the concept of using archetypes to optimize the memory layout of ECS applications is not novel. More about this here
https://csherratt.github.io/blog/posts/specs-and-legion/
I would say that the google v8's Javascript optimization, where they create a new struct layout for each possible combination of object fields, might as well count as prior art. It doesn't use ECS though: but I don't think that prior art needs to check all technology boxes. I argue that, in light of v8's trick to turn objects with dynamic fields (traditionally stored as a hash table) into objects with statically known fields, then ECS archetypes are not novel enough for a patent.
(And I don't even know if the v8 optimization is itself novel)