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.
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)
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?
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.
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).
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.
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.
I remember reading about them in my CS studies, and that was pre 2011.
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.
Edit: creator of bevy has a great initial reaction to this on Reddit: https://www.reddit.com/r/rust/comments/pjtpkj/comment/hbzaz6...
How about 2013:
https://www.gamedev.net/tutorials/programming/general-and-ga...
I use a heavily updated version of this for my own projects
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.
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.
You didn't patent that did you?
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.
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.
"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)