21–30 of 175 posts
Ridiculous, and corrosive. I understand this isn't "patenting ECS" but patenting optimizations to ECS that are heavily inspired from existing work like, for example, JIT javascript runtimes, is shameful behavior. I hope Epic or someone else produces prior art and the requisite shaming. The reason ECS is even a thing is because of the endless amount of sharing and openness from game engine studios at conferences like…
How does such an abstract idea get approval? Like Figure 4B. It's a diagram that basically says, if something happens and we need a new entity we create one... Figure 4A is literally talking about adding to an array. Figure 1 is just a diagram of a computer? The abstract is just garbage collection...
That said, I've reread claim 1 a couple of times and I have no clue what it is actually claiming.
Patent lawyer here. There is a lot of dubious stuff already in this thread, so be careful with legal opinions from people on the internet. Some relevant claim language is below. Of course a lot of this stuff has been known for a while, but you have to have everything together--or an evidenced argument that combining things in this way would have been obvious--before you can conclude anything about the validity of the…
That's not really what is getting folks riled up with respect to patentability. The techniques mentioned (as interpreted by some) are considered not at all novel, being widely known in the prior art.
That's my take. I haven't dug too deep.
Update after briefly reading the patent. I like to read claims backwards, because they almost always build upon each other, with Claim 1 basically claiming the broad domain, and each subsequent claim narrowing the scope. Claims are "subtractive" - each has to match, unless you specifically call out sub-claims (e.g. "8. claim 7, but also ABC; 9. claim 7, but also DEF").
Here's a plaintext link for those following along: https://patents.justia.com/patent/10599560
Claims 17 and 20 are the real kickers.
> The method of claim 10, the operations further comprising:
> determining that an entity of the set of entities within a first archetype has been modified;
> based on a determination that the modified entity corresponds to an additional new archetype, adding the additional new archetype to the set of archetypes, building an additional new memory chunk for the additional new archetype, populating the additional new memory chunk with data from the set of components included in the modified entity, and deleting data corresponding to the modified entity from the first archetype;
> based on a determination that the modified entity corresponds to an existing second archetype in an existing memory chunk, populating the existing memory chunk with data from the set of components included in the modified entity, and deleting data corresponding to the modified entity from the first archetype.
Woof. That's really dense, but it sounds like it's basically describing inheritance based on composition. To update an archetype and all entities of that archetype, create a new archetype in memory, move some pointers, and you're done. No reallocation beyond that updated archetype node.
> 20.20. The non-transitory machine-readable medium of claim 19, wherein each component data array of the set of component data arrays is contiguous with a next component data array of the set of component data arrays.
So this isn't just about ECS, this isn't about archetype ECS, or even OOP-based archetype ECS. This is specifically about an OOP-based archetype ECS using some fancy memory layout method, which lays out contiguous chunks in such a way that modifying archetypes doesn't result in large reallocations. I think. It's super dense.
Even with all that added specificity, I still think it falls short of clearing the bar of novelty beyond prior art. This is such a performance-relevant part of game engines that leverage ECS, that somebody out there has to have already thought of ways to improve the memory management of entities.
Edit: Some examples, including the use of chunks, or what I call batches:
https://stackoverflow.com/a/15414523
https://old.reddit.com/r/C_Programming/comments/6nxfzp/going...
Patent lawyer here. There is a lot of dubious stuff already in this thread, so be careful with legal opinions from people on the internet. Some relevant claim language is below. Of course a lot of this stuff has been known for a while, but you have to have everything together--or an evidenced argument that combining things in this way would have been obvious--before you can conclude anything about the validity of the…
EDIT: yes, yes they did. What you see above is in fact clam 1, in it's entirety.
This is worse than usual. Usually "X patents (common thing)" headlines actually mean "X patents (common thing with weird twist)," which is a great deal less severe. This really looks like Unity got an actual patent on the actual ECS design pattern, the one that every game has used for the past 40 years.
They will be able to extort an awful lot of money with this patent before it gets overturned.
How does such an abstract idea get approval? Like Figure 4B. It's a diagram that basically says, if something happens and we need a new entity we create one... Figure 4A is literally talking about adding to an array. Figure 1 is just a diagram of a computer? The abstract is just garbage collection...
What the patent actually covers is governed by the claims at the very end of the patent, and most of the rest of the document is generally irrelevant, per my very limited understanding of how patents work. That said, I've reread claim 1 a couple of times and I have no clue what it is actually claiming.
INAL but this is incorrect. The rest of the document is mostly the disclosure and - critically - claims cannot rely on anything not disclosed.
Importantly during the review process you can edit or amend your claims, but you can't update the disclosure without changing precedent date.
If it is not claimed in the claims it is not subject to the patent. Any analysis of this patent (or any other patent) that doesn't focus on the claims is not a real analysis. Part of why companies spend so much money on patent lawyers is because good ones know how to write the claims in as broad a way as possible that won't get thrown out by a court. This way the patent applies to a maximal set of implementations. The claims are typically hard to read, the ones in this patent are no exception.
There are essentially 3 main claims this patent is making (numbers 1, 10, and 19). These are all separate claims. So if any one holds up in court then the defendant is violating the patent. I briefly read them, but it takes a lot of effort to understand them and my knowledge of ECS is shaky. However, none of them seem to be claiming anything all that novel, so I would be surprised if they held up in court.
But to use an expression I've heard somewhere, patents aren't read, they're counted. Lone inventors almost never successfully defend a patent. They were intended to spur innovation but in modern practice patents are used as legal weapons by large corporations. That's why most major companies incentivize having employees produce patents. The companies don't really care what's in the patents, they just want a lot of them so they can successfully threaten other corporations with lawsuits. This allows everyone to infringe on each others patents, since it would be too expensive to actually have a trial. So big corporations are largely protected from patent lawsuits since their competitors are probably infringing on at least some of their patents and vice-versa. The real losers under this system are small companies and individual inventors.
How does such an abstract idea get approval? Like Figure 4B. It's a diagram that basically says, if something happens and we need a new entity we create one... Figure 4A is literally talking about adding to an array. Figure 1 is just a diagram of a computer? The abstract is just garbage collection...
What the patent actually covers is governed by the claims at the very end of the patent, and most of the rest of the document is generally irrelevant, per my very limited understanding of how patents work. That said, I've reread claim 1 a couple of times and I have no clue what it is actually claiming.
Correct. Only the contents of the Claims system matters to what is actually patented. Also, claims are subtractive/intersection, like all bullets have an AND function applied. So if you have a widget and it matches claim 1-8 but does not match claim 9, it does not match. That is, unless you specifically call out your "unions" - this usually looks like "the method of claim 8, but abc", "the method of claim 8, but def". That's how you do "unions." Kinda.
This is a gross simplification.
Patent lawyer here. There is a lot of dubious stuff already in this thread, so be careful with legal opinions from people on the internet. Some relevant claim language is below. Of course a lot of this stuff has been known for a while, but you have to have everything together--or an evidenced argument that combining things in this way would have been obvious--before you can conclude anything about the validity of the…
Patent lawyer here. There is a lot of dubious stuff already in this thread, so be careful with legal opinions from people on the internet. Some relevant claim language is below. Of course a lot of this stuff has been known for a while, but you have to have everything together--or an evidenced argument that combining things in this way would have been obvious--before you can conclude anything about the validity of the…
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)