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. And on unpatentable subject matter (i.e., being an abstract idea), there is a pretty good argument that this improves the functionality of the computer, not just uses a computer to do something known, which recent cases have started using as the de facto dividing line.
1. A system comprising:
one or more computer processors;
one or more computer memories;
a set of instructions incorporated into the one or more computer memories, the set of instructions configuring the one or more computer processors to perform operations for automatically managing a set of memory chunks within the one or more computer memories at runtime for a computer application, the operations comprising:
receiving a set of entities from the computer application, each of the set of entities including a set of components, wherein each component of the set of components has one type of a set of types;
classifying the set of entities into a set of archetypes, each archetype representing a different count of the set of components or a different combination of types of the set of components relative to other archetypes of the set of archetypes;
based on a determination that one of the set of archetypes corresponds to a new archetype, building a new memory chunk, adding the new memory chunk to the set of memory chunks, and populating the new memory chunk, wherein the populating of the new memory chunk includes adding data from the set of components included in one or more entities of the set of entities that are classified under the new archetype, the adding of the data including contiguously adding the data to ends of a set of component data arrays included in the new memory chunk, each of the set of data arrays included in the new memory chunk corresponding to a respective component of the set of components included in the one or more entities that are classified under the new archetype.
Not a patent lawyer here. But I'm unfortunate enough to have several patents to my name, owned by past employers.
My impression of everyone that I have ever heard from, or dealt with, involved with patents is that you all are so firmly in regulatory capture that your heads are captured up your collective asses, and the tech industry is being hampered by the resulting legal quagmires.
In a sane world, the entire description that you gave falls squarely under "generic computers doing generic computer things". And therefore by Alice v. CLS Bank as decided by the Supreme Court, it should not be patentable. Period.
Unfortunately the United States Court of Appeals for the Federal Circuit has gone rogue, and you're almost certainly correct that they will happily grant use of the patent to any patent troll lucky enough to get it. And the Patent Office is so firmly in the land of regulatory capture that bad patents like this have no trouble being issued.
And the result is that people whose work ACTUALLY achieves "Progress of Science and useful Arts" is hampered by this crazy system. And our patent system continues to undermine its stated Constitutional purpose.
It's unfortunate that any criticism of the patent ecosystem gets immediately shot down by 'You are not a lawyer', The impact of the flawed patent system affects everyone and so anyone can point it out.
I strongly believe that actual innovators are now left to 'innovate' within the boundaries set by the mega corporations with the help of their patent-pipeline and the patent trolls with the help of flawed legal systems.
To be fair the lawyers are mad at us engineers for automating away many of their jobs. I think they’re jealous their profession isn’t top tier anymore.
The entire patent system needs to be dismantled. It's simply hampers competition and prevents free trade. All of us in the technology industry know that the simple facts are that building a business is 99% perspiration and 1% innovation. Further, any new idea is based on a mountain of previous human innovations. Even the largest leap in human history was a miniscule percentage of the entire knowledge base it rested on. For someone to claim ownership over even a small bit of something that is based on all the sweat blood and tears in human history is nightmarishly wrong.
I was not naming courts in general. I was naming the specific appeals court that takes on all patent cases, and has essentially constructed most of current patent law unsupervised.
> In a sane world, the entire description that you gave falls squarely under "generic computers doing generic computer things".
That archetype stuff is so out of the norm that it took me a long time to grok how to work with it in Unity. It's most certainly not "generic computers doing generic computer things" and I've never seen it elsewhere, so I'd guess it would be quite defensible in court especially now that they have a patent.
Not sure what you're on about, but if it's a valid concern I'd pick a better example than this specific piece of tech (granted that one tiny snippet from the patent might not portray what the tech is or how it's unique).
Edit: seems like there is some confusion here about ECS and how archetypes are implemented in DOTS. ECS and archetypes are not synonymous, so I’m not sure what to tell you when you claim they are.
But I’m also not sure how downvoting me is helping here. I guess community consensus is that archetypes and ECS are the same thing, in which case Unity will have an uphill battle ahead.
ECS is bog standard in a lot of smaller game engines. It’s not new, I first worked with it ~2010 while hacking some Flash stuff together, and I use it frequently when I hack together games in other engines. I’m really baffled by how Unity would be able to patent this.
Archetypes are a conceptually simple implementation optimization (group similarly-populated objects) not unique to ECSes - e.g. v8 organizes javascript objects based on their "shape" (again, grouping similarly-populated objects, based on their "properties" instead of their "components") (2017 article: https://v8.dev/blog/fast-properties .)
You can add all kinds of automagic parallelizing and filtering libraries (which I imagine have some overlap with database query optimization and scheduling in their fundamentals), but the basics are incredibly trivial - to the point where you might re-invent it by accident without knowing it has a name.
Yeah I had never heard of ECS until about a year ago, yet if you could look at the whiteboard on my wall from 2 years ago you'd find a diagram for a primitive version of an ECS I came up with as a hypothetical. Idk understand how tf that could be patentable if its something a former 2.7 gpa CS student could come up with on a whiteboard.
I thought archetype-based ECS was the standard way to implement an ECS. Typically using bitsets or something to define an archetype.
But I may just not be understanding what an archetype represents exactly. My only real experience with ECS, besides implementing a crude one around 2011 for fun, is EnTT, which specifically advertises itself as not being archetype-based as one of its key differentiators.
Its likely I just don't quite understand archetypes though.
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.
Wait just one second... they managed to actually get a completely generic description of ECS into the claims?
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.
Not really. To me the novelty in the first claim is that they have a system which automatically determines an optimal memory layout, even in the face of new combinations of components within a newly created entity. A typical hand-crafted ECS system wouldn't likely infringe -- it's more likely that the memory layout was defined in advance.
I guess this will be a major roadblock to Unreal Engine offering such an automated ECS system, which is a real shame. There are certain types of games which do need ECS to make viable use of computing resources (simulations, etc). You don't see many of those on Unreal now and I guess you won't for the foreseeable future if this patent holds.
What exactly is their system for determining optimal layout? It must be disclosed in detail. They can't just claim that any approach like that is theirs.
Unfortunately your second sentence is not correct; patents do this overclaiming game all the time.
(not a lawyer, co-inventor on three patents so I've been through this, unfortunately as I didn't want to participate in that system, consult a lawyer before doing anything rash).
The claim matters, not their detailed description. The most harmful patents work that way: describe in detail a specific implementation, but write the claims to cover every alternative implementation you can think of.
Several already existing unreal games already use ecs. I saw a tech talk about Conan exiles for example. It’s just not part of the engine. Can’t find the talk, it was an epic event, but they advertise it in job postings
> they managed to actually get a completely generic description of ECS into the claims?
From looking at the claims, it seems they are patenting archetype-based based ECS. In other words, not just vanilla "array of components" but "array of sets of components".
Except that it might be, because if people knew how to do it, they would have for the past 20 years that ECS have been implemented in the games industry that is notoriously focused on memory locality optimisation.
(not that I'm advocating for the patentability of software in general, I just think that if software should be patentable, this sure seems like something that could be)
> And on unpatentable subject matter (i.e., being an abstract idea), there is a pretty good argument that this improves the functionality of the computer, not just uses a computer to do something known
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").
> 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.
Where does the patentability filter fail? By "clearing the bar of novelty beyond prior art" I am referring to both novelty and non-obviousness.
You seem to be implying, by referencing what I can only assume is the Alice Corp case, is that the patent is too abstract. I don't think that's the case. The patent describes a very specific technique for memory management and archetype based inheritance.
I think the technique would be patentable were it an inventive step above the prior art, but it's not novel enough, IMHO, IANAL, BBQ.
>> 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.
I think it's more specific than a combination of ECS and memory allocation strategy. Since ECS allows dynamic building of "types" or "classes" of objects, this seems to be automatically detecting new types and allocating memory for them separately. Maybe? So go ahead and ECS all you want, and go ahead and use spiffy memory management all you want, but don't tie type inference into your memory allocator. IANAL but that seems to be the ostensibly unique part.
Setting aside whether or not this patent is silly or abstract or obvious or anything else, I have one important question: what does Unity plan to do with this?
Most big tech companies have a constant stream of patent applications, many of which are granted. But they rarely sue over 99% of them. Sure, Amazon had one-click for however many years and they cared about it. But the other tens of thousands of patents Amazon owns (a couple of which have my name on them as 'inventor') are never going to see a court room.
Why do they patent everything? So that patent trolls can't patent it first and then sue them for patent violations. It's a defensive patent.
Is ECS going to be Unity's "This is ours, no one else can use it without paying us" lawsuit-generating patent? I doubt it. They know they'd lose in court eventually, and along the way the entire industry would stop doing business with them. It would be a complete lose-lose move.
On the other hand, now that Unity owns this patent, no patent troll can go and patent ECS then start suing small-studio Unity customers, like parasites leaching off the success of Unity.
Last year unity retroactively changed the license on assets from its asset store. Since then, you can no longer let freelancers or contractors use your assets while they do work for you, you end up having to buy them each a copy of everything in practice unless their work is really decoupled from the project.
It’s a real killer for indies who are trying to collaborate who have not formed a company yet. This seems to apply to items you purchased before they changed the terms. They even promised they freelancers could use your assets in support forums days before the change
I stopped using unity after that. They don’t act in good faith towards their users
Godot isn't quite as robust or mature as Unity yet, but it is open source and it has had the benefit of learning from Unity's mistakes when designing its own workflows.
I think most Unity developers find the switch incredibly easy because most of the principles and many of the idioms are the same (and Godot is also more intuitive and has better documentation imo).
Godot 4 looks like it should remove most of the last few pain points too.
I'd say Godot is the superior prototyping/game jam tool, the superior 2d game engine, superior for building UI, and you don't have to deal with any licensing bullshit. It's also like 300 mb as a base install compared to Unity's 7 gb clusterfuck of spandrels.
I'd say the only situation where I'd recommend Unity over Godot is if you already have a ton of Unity experience and want to build something quickly without learning new stuff, or if there is something critical in the asset store you can't find in Godot's (definitely less content and tutorials because of the smaller userbase)
But the flip side is that this gives corporations a great tool to handicap competition.
If a competitor emerges, they can threaten legal action. And with a huge patent portfolio the big players can usually find a way to attack pretty much anyone.
Many companies will easily get scared and cave, and so either lose competitive advantage by dropping the technology, or feel forced into agreeing to an aqui-hire by the corporation . Which further cements the corporations dominating position.
This happens often enough, but rarely goes public.
Ironically, Unity's ECS development effort has gone radio-silent in the last few months. Their latest versions of the Unity Editor (2021.1+) are no longer compatible with ECS, and Unity's forum reps have not responded to the many game devs left in limbo and begging for info or an update.
Something with ECS development is clearly going haywire, and the silence from the Unity people is troubling.
I know what ECS is and why it's needed for some games. But for a large group of game developers that transition was simply too overwhelming I think.
Not just the nomenclature: ECS, DOTS, Burst Compiler, SRP/HDRP/LWRP/URP.... It's an endless list of confusing terms... But moreover those concepts are not so easy to grasp and to use in code by just looking at a few examples.
After doing lots of small 'experiments' in Unity (the old way without ECS) I started to realize, that more and more I was fighting the engine, trying to use or build upon features which were half-baked, buggy or simply not developer friendly. And instead of first fixing those things Unity decided to go all in on ECS.
There came Godot, a breath of fresh air without all the cruft and without all those confusing terms. I think Unity will have a hard time in the future: On one hand there's Unreal which caters the AAA market and there are smaller engines like Godot for the indie crowd. Unity is the odd one in between.
The only problem with Godot is the 3D engine is nowhere near as good as Unity or Unreal . Godot 4 is a lot closer but given Godot’s history , it will take years to arrive . With all of this said , I am rooting for Godot . Long term , an open source game engine will be better .
Caveat that this is second hand info based entirely on GameFromScratch (I've avoided playing with it because of his updates) -- he's recorded a new review on afaics every recent Lumberyard release, and currently seems answer is "yes, ish, the actual engine seems reasonable, but the process of actually getting that engine up and running is staggeringly bad, albeit 100× better than it was six months ago"
I can't imagine them to just continue DOTS like normal after going silent for so long. If they don't axe it, then they may choose to do something drastically different than before, like automatic ECS conversion under the hood.
ECS is really good for things that scale. Architecturally, it has both pros and cons to OOP. After working with ECS for a few years, I came to the conclusion that OOP is still the best for behavioral richness.
The current state of DOTS is just sad as it's affecting a lot of developments such as Tiny, unity.physics, dots audio, dots animation, etc...
Burst and Jobs are probably the best things that came out of Unity's initial push for DOTS.
I never understood why they didn't take this approach -- converting under-the-hood "automatically" to their ECS paradigm. The existing data-structures were/are already very similar to their ECS counterparts (though with substantially less boilerplate code); the main "issue" in trying to do an 'automatic conversion', at least that I could foresee, was related to references & non-blittable types. Even then, it seems like you could automatically convert all the data that is a blittable type, and then let the rest work "the old way" (read: sub-optimally, at least insofar as memory access goes -- and ideally/likely with some developer feedback via profiler improvements to demonstrate where [and by roughly how much] any non-blittable type access was actually costing you in performance).
Just my 2c.
I do concur with the above poster, though -- their ECS/DOTS has been basically ignored. At this point there's so, so, so much of the Unity ecosystem that just flat out fails to work beyond some very, very, very small scale that it's just mind-blowing. Want to use their physics, or nav-mesh agents, or even their sprite-rendering systems? Once you get 500-1k of any of those objects into a scene (ie, sprites!!), you've already blown way past your CPU/framerate budget. It's mind-boggling; especially when you can, for example with sprite rendering, run your own mesh with a bunch of quads and absolutely obliterate the performance you get from SpriteRenderers.
Very frustrating & somewhat mind boggling TBH. I'd personally guess the vast majority of indie devs that use Unity are simply using it as a [mesh] rendering pipeline & practicing a "roll our own" approach for almost everything else.
> I never understood why they didn't take this approach -- converting under-the-hood "automatically" to their ECS paradigm
I completely agree. I've done compile-time code transformation/generation in C# using Reflection in the past, and while it's not really trivial, it's entirely feasible. I knew some people who did this independently because of things like INotifyPropertyChanged in WPF. They're already doing things that are way more advanced than that with the usage of the [BurstCompile] attribute.
If anything, they could just restrict the usage of fields that don't work with it.
> At this point there's so, so, so much of the Unity ecosystem that just flat out fails to work beyond some very, very, very small scale that it's just mind-blowing.
Someone in here said that everything in Unity is either unmaintained or unfinished. I share this sentiment. :(
It could be that they were anticipating filing this patent and they didn't want to publicly disclose the "new" methods they were working on. My understanding is that public disclosure prevents you from being able to patent something. (I am not a lawyer and this is not legal advice).
Unity's ECS source code -- including the archetype-based entity-component model described in the patent -- has been completely public for several years now, so I don't think that's it.
Because its such a different way of working I had assumed they would fork the engine and start pitching a different kind of engine with big changes to the work flow and editor. Call it Super Unity and charge twice as much.
I wouldn't be surprised if this is what they end up doing. Trying to shoehorn ECS into an already existing object-oriented engine has probably been an engineering nightmare for them.
The tinfoil hat interpretation would be that this is Unity's Embrace/Extend/Extinguish. First hire Mike Acton to build an ECS feature for Unity. patent it, and ensure that neither him nor anybody else can use this design pattern to beat their engine.
When reading a patent basically the only part that matters legally is the claims section. This is always at the end of the patent filing, at least in modern practice. This is on page 28 and 29 of the filing. It starts with "The invention claimed is". Google Patents has a better format than the USPTO website and makes the claims easy to see: https://patents.google.com/patent/US10599560B2/en?oq=10%2c59...
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.
On software patents, something I've devoted a hell of a lot of time to:
The commenters who mentioned "regulatory capture" and patent trolls are 100% right. But it's much worse than you think: the professional societies (ACM, IEEE) and tech industry management are solidly not in your corner, either. They've invested too much money in the current system.
Let's imagine that GitHub or StackOverflow or some other large developer forum ran a poll: "Are you in favor of abolishing software patents?" What do you think the results would be?
Why don't they ask the question? Unfortunately, they don't want to hear the answer. It might move Congress to actually do something, which they always prefer not to do.
And indeed, I have a quote from Joel in my paper [1].
However, the law is full of the phrase "practitioners in the art." A poll showing that a vast majority of practitioners of the art feel one way would have some effect. Whether it would be enough, or how long that would take, is an open question.
Patent agent here. At Google we investigated patents and their possible invalidity almost every day.
Claim language is obtuse because it's for lawyers, not laymen. An engineer can write the description, but only the lawyer can write the claims.
It's immensely complicated, but if Unity does someday assert this patent against someone else, then you all are helping the defendant when they have to defend themselves. At least, I hope the defendants find this discussion.
The defendant's standard tactic is usually to file for IPR, or PTAB reexamination of the patent, which is like a trial without a courtroom. The cost figure I recall is $500,000; maybe it's different now.
If the IPR succeeds, then Unity is SOL. There was a Supreme Court case recently where some plaintiffs tried to get the whole IPR system thrown out. They failed, as far as I know.
Lastly, the whole back-and-forth with the PTO is in the public record, if you know how to find it (and if you think reading claims is difficult, wait 'til you try reading a prosecution history!)
> The cost figure I recall is $500,000; maybe it's different now.
That's the standard tactical defence fee? I would guess that kind of money is very far above the means of most open-source developer defendants.
And wouldn't a larger, closed-source business rationally choose to pay Unity (say) $400,000 extortion fee instead of taking it to court with the associated uncertainty?
To the defendant who doesn't have $500,000 or $400,000 (maybe $1-10k is available), whether it's court or IPR seems like splitting hairs. It doesn't matter what kind of legal proceeding, because they can't afford to participate in any legal proceedings at this level anyway. They also can't afford to pay for more than superficial advice.
What I'm getting at is: $500k is more than most people's entire assets, and more than the assets in many small businesses and organisations. With software patents like this one, most infringements are likely done by the "little guy", who can end up threatened when they publish code, or have to operate in fear of that happening, if they know about it. They simply cannot challenge the patent through any legal method that has a fee like $500k.
If the rational closed-source company will pay Unity's hypothetical fee because it's less than the IPR fee, and the open-source defendant doesn't have any choice because they can't afford any of the options... who is left that is both motivated and capable to use the IPR procedure?
In the case of this particular patent by Unity, the techniques are things people thought of decades ago, but like most "inventions" of this kind, it's only when you have a specific project (typically paid) where they'd come in useful that you typically get around to using it. Nobody has time to document and explain every little "invention of the day" every time they think of a new technique just to feed the prior art corpus. I tried that once. When you've come to see how low the threshold is for patentability in software (and to be honest, in some digital hardware too), it's seems literally impossible to write down every patentable insight as fast as they come once you're on a roll; you'd need a support team just to do the documenting.
It's upsetting to think up a technique, flesh it out, not have a use for it for 10 years (you're busy, right?), then find one day when you want to use the fruits of your own figuring out 10 years prior on a project, it cannot be used any more. Even more so when it follows naturally from techniques dev communities have been discussing for years in the field.
(A number of us also have stories of publishing a sketch of a technique on some forum, only to find it patented later. It happened to me with a texture-mapping graphics technique in the 90s, where I found a later patent actually cited my Usenet post; in practice that meant I couldn't develop it further because the obvious next steps were blocked.)
jlokier, if you're assuming I'm in favor of software patents, you haven't been paying attention.
Developers have been writing screeds like this for almost 40 years, but nothing changes. That's because the people in power don't want them to change. Do you want to just keep complaining, or do you want to do something?
> if you're assuming I'm in favor of software patents, you haven't been paying attention
I wasn't assuming that, but I was assuming from the way you wrote it, that you think $500k is an ok price for people to continue practicing the software engineering they were already doing. It might just be a language interpretation thing from the way you wrote about that. And because of this:
>> That's not court; that's an IPR [1].
I consider almost all the interesting defendents to be people who will not be able to afford the IPR procedure, and the above seems a mere technicality from that perspective. For those people, it might as well be a court case in spirit. I.e. something they can't afford, that involves a panel judging something and corporate lawyers making arguments that determine someone's future.
So it seems only relevant to people who might be serious about doing the IPR. That's what gave me the impression you consider it feasible for typical defendants. But then:
>> As for defense strategy: you're right, but Unity might want a quick hit. They don't want a lengthy proceeding where they might lose.
You wrote "but", yet seem to agree with what I wrote on each point here, which amounts to nobody having the combination of motivation and capability to use the IPR procedure.
> Do you want to just keep complaining,
If you're assuming I'm complaining, you haven't been paying attention. I'm saying that when it appears to be suggested (possibly by way it's written) that it's an ordinary and reasonable $500k fee for a defendant to overturn a patent via IPR, that suggests to me (and probably others) that the author thinks of defendants as the kinds of companies or individuals with that level of funding capability.
I probably didn't state my case well, but the gist is two things: 1. I think the the vast majority of interesting defendents (infringers and potential infringers) don't have that kind of funding capability. 2. A genuine question (which hasn't been answered): Who would pay for the IPR, when neither the small-time defendant or the company who can pay the patent holder's fee has both motivation and capability to do the IPR?
> or do you want to do something?
You appear to be suggesting an alternative course of action than writing on HN, something to do with people in power, but I can't guess what "something" you have mind. Do you have something concrete in mind, or is that just a generic complaint on HN that there's too much complaining? :-)
You seem to think that explaining the system is the same as justifying it. For example, saying "it costs $500K" constitutes minimizing that sum or calling it ordinary and reasonable. Neither is true. I don't need to pile on the condemnations in every sentence.
As for what "something" is: I happen to be retired while you probably will be living with the patent system for a few years yet. So don't just say "someone should do something." Whatever that "something" is, you'll be more motivated if you think of it.
> The defendant's standard tactic is usually to file for IPR, or PTAB reexamination of the patent, which is like a trial without a courtroom.
For it to be the standard tactic, that implies a worldview in which defendants have that tactic as an option, and that's where the impression you think most defendants have access to that level of assets comes from.
But once you've explained the fees, it becomes clear that the typical defendant's standard tactic isn't to "file for IPR, or PTAB reexamination".
I'm not sure what the standard tactic is, but it isn't the one they can't afford.
When I've spoken with other patent lawyers, they've been skeptical that working engineers/devs regularly "reinvent" things covered in patents by accident. They have said they don't believe such people exist. Yet in my line of work, it's a near daily occurrence; it wouldn't even be possible to write them all down some days, and often it's things that were figured out years or decades prior. I know this with confidence because occasionally I look up techniques I've developed before that I want to use in some project that warrants it, and then I'm dismayed to find them recently patented, sometimes more recently than when I first developed the techniques.
So hopefully you can understand why I might have the impression patent lawyers (some at least) imagine that most "defendants" (people pursued for infringement or under threat of such) are the type of people they have as paying clients, and that other defendants (who I think are the majority) don't exist.
> So don't just say "someone should do something".
But I haven't said that. You came close, though, thus asking what you had in mind.
My argument here is not that someone should do something. It's that most defendants won't pursue IPR/PTAB reexamination because it's not an option for them, and companies with sufficient assets to pursue the reexamination are better off paying licence fees, so who is it that's both motivated and capable to pursue the IPR/PTAB reexamination? If there isn't anyone, it's not going to be overturned, is it, and most infringers (accidental or not) are just stuck with it even it would be overturned on reexamination, aren't they?
The answer to that is a missing piece in your explanation of the system, which without it seems to say that it's "standard" to end up reexamining these sorts of patents and overturning them if appropriate. I would be very surprised if that really is what happens, but also genuinely interested if that's the typical outcome.
OK, you're offended by the word "standard." I get that. If I said that criminal defendants' "standard" tactic is to stall and hope the witnesses forget about it (I don't know if that's true, actually), you would be offended because really poor ones can't get out on bail? I wouldn't say "too bad for them." The legal system is well-known to be stacked against poor people on almost every level, and even Charles Dickens was not the first to write about it.
This is Hacker News, not Patent Law 101. I'm not obligated to explain every aspect of the system in a comment.
I gather you think there's something new or unique in your comments about poor defendants. There is not. People have been saying it since the 90s. You are preaching to the already-converted.
Finally, if you read my paper on SSRN (which I've cited here many times), you'd see that "programmers' standard toolbox of techniques" is what I called out as something missing from the law.
That paper got cited in the Checkpoint amicus brief to SCOTUS in the CLS Bank case. That's an example of doing "something" but I will admit it's not much.
If you really wanted to do more, you'd start or join a political movement to "abolish software patents." There already are such organizations.
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?
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.
My read (and from what I know of ECS) is that it's basically claiming a system which automatically organizes the memory layouts of instances of different types of "entities" (i.e. "type" meaning which "components" it includes) in an efficient manner.
Here, an "entity" is just an object identifier (integer, or whatever). A "component" is a specific set of data relevant to some function (e.g. position component would have x, y, z floats, while damage level component might be a single float to represent amount of damage).
ECS generally means laying out all memory for all instances of a given component contiguously, so in the example I gave you'd have one array for all position components in your game world, and one array for all damage level components. The "entities" are just collections of these components from these different arrays. So the "player" entity for example is logically composed of one particular element of the position array and one particular element of the damage array. This is more cache friendly when you have a "system" (say, the physics subsystem) which generally only operates on one or a limited set of types of components across many entities.
There is no way ECS in general is patentable but their system which intelligently and automatically performs the memory layouting for their form of ECS (which also includes the notion of chunking these arrays into finite sized blocks) very well might be.
Splitting up objects attributes into separate arrays is required if you plan to work with those data on the GPU. I did it when working with Java and OpenCL, and wanted to efficiently access the same data trough Java objects and also in OpenCL kernels. OpenCL does not know about objects, like Java, but it can access data in arrays, so practically every Java object holds an index into the arrays of the different attributes.
Per my knowledge Unity ECS does not currently process data on the GPU, but uses ECS to split work to multiple threads on the CPU. If the threads work on data that only they need to touch, then there is no need to synchronise them. It is also more cache efficient to read and write data from a couple of arrays sequentially, than to pull objects and their attributes from all over the heap.
The idea of storing objects by attributes, instead of object instances is not new. Some clever allocator indeed might be new.
I suspect they want to make it harder for Unreal to make the same system. Unreal might have nice visuals, but scaling was not their strength before.
Yeah I think it's a huge roadblock for Unreal. Though, I'm not sure that the patent would preclude a system which organizes memory layouts at build-time rather than runtime (though I could be wrong about that). Could be a good opening for Unreal, though to this point I think they've (disappointingly) shown little interest in any kind of ECS system.
I don't know the details of slab allocators. Though if you are describing an allocator that does not have knowledge of what the memory is being used for (e.g. the difference between asking the allocator for memory for a position component defined as three floats and also a color component also coincidentally defined as three floats, versus asking the allocator for two sets of three floats without regard to their intended usage), then it is not the same.
> it's basically claiming a system which automatically organizes the memory layouts of instances of different types of "entities" (i.e. "type" meaning which "components" it includes) in an efficient manner.
V8 was already automatically creating virtual classes for Javascript objects like thirteen years ago.
I should have been somewhat more precise with my wording. The document is generally irrelevant for the purposes of deciding whether or not your product potentially infringes the patent. It's not until after processing the claims, or perhaps during if you're unclear about terminology or meaning, that you start considering the rest of the document.
> 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.
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.
> So if you have a widget and it matches claim 1-8 but does not match claim 9, it does not match.
This is not correct. If you infringe claim 1 then you infringe claim 1. Whether or not you also infringe claim 9 doesn't matter.
Assuming Claim 9 is dependent on claim 1, claim 9 includes all the limitations of claim 1. So claim 1 is A+B+C.... Claim 9 is 1 + D = A+B+C+D. So if you infringe 9 because you have A+B+C+D then you also, by definition, infringe claim 1 because you have A+B+C.
Also, you can write a claim that has ORs applied. But the drafter has to be really careful with how it is done and it is not the norm.
I may have explained it incorrectly, I'm a bit rusty.
I did a lot of work in pharmaceutical route development, where some patent does "ABCD123" and we'd do "ABCD456". My point is more that, patents are usually laid out like:
1. A method for crystallization of a pharmaceutical in an organic solvent with some counterion.
2. (1), where the solvent is ethanol, or methanol
3. (1), where the counterion is Cl, SO4, or NO3
4. (1), where the pharmaceutical is a COX2 inhibitor
So that patent doesn't allow you to claim any crystallization route with ethanol. If I crystalize from ethanol but use mesylate as the counterion, I'm not infringing.
Considering the doctrine of claim differentiation, your hypothetical could still be infringing Claim 1. You’d have to consider the spec, among other things, to persuasively argue one way or the other.
It appears to describe a data-oriented component entity system in which all data types within a component are assigned to chunks (batches) in such a way that they can be optimally grouped with data from components of other entities for optimal memory access.
The other disclosure establishes prior art for other people and sets you up for more patents in the future with the same prior art date (continuations).
The patent system is just not fit for purpose. Even for pharmaceuticals and other long-development-cycle products in the real world it has been corrupted beyond reason; I worked on battery materials for a while and even though there was plenty of prior art, a couple of players had basically patented every metal oxide possible under the guise of a cathode material, even though most of them would be utterly useless. Until there is some penalty for such time-wasting chancers, nothing will change. The software world makes it even worse by removing the already low bar for a proof of existence or actual benefit.
I don't see anything new even when considering the entire context. I have worked on similar data-oriented entity component systems for over 10 years. Unity was actually very late to the game and Sony had to push them to give it more priority.
Edit: Some examples, including the use of chunks, or what I call batches:
Not sure about Archetype specifically, but discussions on twitter about this have pointed out talks from GDC going back to at least 2002 when it comes to ECS.
Yes, but their claim is specifically about (quoting my other comment):
> It appears to describe a data-oriented component entity system in which all data types within a component are assigned to chunks (batches) in such a way that they can be optimally grouped with data from components of other entities for optimal memory access.
This is not new either. I and others have done this for years. The term "archetype" is something they made up to describe something that has been done many time before.
Edit: It appears that the term "archetype" was introduced somewhere in the last few years. Not sure then if it is specifically coming from Unity.
Without commenting on whether this patent should be granted or not, I really don't think it is about ECS in general. The patent has to do with an automated system for organizing component data into arrays and chunks. The key word being "automated". You give it definitions for component data, start creating entities with combinations of those components, and it does all the rest (at runtime).
There might very well be prior art for that as well but any ECS system where the layout scheme has been defined in advance would not be relevant one way or the other. At least that is my read of all of this.
Then doesn't a patent have to more precisely describe the "scheduler" mechanism or can they leave that out? If so. How can I know that I am not infringing the patent? My entity component system which is > 4 years old already does automatic scheduling with batches (what Unity calls chunks) to optimize the memory layout.
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 GDC. This runs counter to that openness, and is particularly corrosive given the trend towards game engines becoming more and more aligned with trying to lift all boats (such as the efforts by Epic and more recently Amazon's Open 3D engine.)
> Either way, how the hell do you get a patent for some abstract diagrams that represent a design pattern.
You don't.
Patents are unfortunately very obtuse to read and hard to parse, and it's especially easy for a lay person to give up very quickly and as a result misinterpret the patent. This is especially true when you're pointed to the patent by a rando on the internet telling you what (they think) is patented, even if it's not accurate.
Another contributing factor is that, even when you read the claims, a lot of the actual description may be functionally irrelevant to the actual thing being claimed. Suppose, for a moment, that you were patenting a new kind of bike pedal. Then your actual claim would look like an overly verbose and vague description of a bike that includes your new kind of pedal. And since most of the paragraph is describing a bike, it's easy to assume that what is being patented is the bike and not the pedal of that bike.
For people looking for how far back prior art goes, Looking Glass developed an ECS for the Dark Engine on the Thief games (& Irrational used for System Shock 2) in the late 90s.
The version Unity's been building with DOTS was, I believe, being headed by Mike Acton, who's been advocating for years for everyone in the industry to abandon OOP and switch to data-oriented systems. I wonder what he thinks about this.
IMO, this is too broad a patent to be enforceable. I have built many systems that look exactly like this over the years. The terminology I use is simply "data-driven". Nothing so fancy as "Entity Component System", which is just an opinionated take on the more fundamental idea of arrays of structs (aka "data").
My take is that this patent is part of a defense-in-aggregate strategy which leverages a larger portfolio. I don't think a legal team would stand on this one alone in a AAA vs AAA studio fight.
I usually visualize large corporations pointing patent piles at each other as if they are locked in some sort of cold war. I have zero fears that this patent would be used against me or any of my work.
I haven't read the patent but Unity's long march to ECS included figuring out mapping their previous GameObject + Behavior paradigm to the ECS paradigm. At a glance, part of this appears to be trying to patent that. This isn't a Unity specific problem though, many gaming studios have existing code on the old paradigm and are looking for good ways to migrate or bridge to ECS.
Patenting such technology runs counter to the reality that this track of game engine innovation in particular has been one particularly notable for the open sharing of techniques and technology, in the interest of everyone benefitting from a better approach in core architecture that improves performance and reduces incidental complexity. At some point, it became a cultural norm that people were not going to hold their cards close to their chest on this core part of the game loop. There are a lot of areas where I'd be inclined to accept the idea of IP protections for game engine companies on an ethical basis: this isn't one of them.
So I started playing with Godot in early 2020 and remembered reading an article on ECS and why they don’t do it. I just found it again and they say this pattern has been around in the game industry since the 2010s feels like 1) it’s good Godot doesn’t implement this, just to not deal with any potential Unity BS 2)this patent would fail if you’ve got deep enough pockets and time. Here’s the article: https://godotengine.org/article/why-isnt-godot-ecs-based-gam...
Who are the examiners who are reading and granting patents like this? Are they experts in their field? IE, could they program a game in C? Do they keep up with state of the art techniques?
I suspect the meat of the patent will be very specific about the types of optimizations they do in Unity DOTS, rather than the concept of an ECS. There's plenty of public prior art about ECS, but the concrete set of choices they made to implement and optimize theirs is a concrete thing. (ftr I don't think it should be patentable either way)
Apple's GameplayKit also includes an ECS system. Not a patent lawyer, so not sure how broad or not this particular claim is. But that was introduced back in 2015 or 2016, so there's prior art there.
EPO has destroyed the law with "as such" or "technical effect", and they are lobbying hard to get the UPC in place, so that software patents are fully "valid" accross Europe.
That doesn't stop them, Benoît Battistelli has been actively pushing for software patents and ignored the EPC.
With staff being quoted previously:
“We are far too often put in front of the dilemma of either working according to the European Patent Convention and respecting the examiner’s guidelines, or issuing ‘products’ as our hierarchy demands"
It's indeed really surprising to see them _patenting ECS_. Unity's ECS is a lot about cache-friendliness, not just simple entity-compoenent-system, though.
The whole point of ECS is cache-friendliness, so it's kind of the same. Besides there is nothing novel in their implementation. Putting frequently accessed component together is quite an old technique.
ECS has been around since like 2007 and there's plenty of public prior art on this, but suuuuuuuuuure Epic Games yep you guys totally invented the concept and deserve a monopoly on use of the technology. This might directly affect several projects I have if they choose to use this patent offensively. This further cements my disgust with IP law, honestly I'd rather we just have information anarchy when it comes to abstract computer stuff at this point.
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. And on unpatentable subject matter (i.e., being an abstract idea), there is a pretty good argument that this improves the functionality of the computer, not just uses a computer to do something known, which recent cases have started using as the de facto dividing line.
1. A system comprising: one or more computer processors; one or more computer memories; a set of instructions incorporated into the one or more computer memories, the set of instructions configuring the one or more computer processors to perform operations for automatically managing a set of memory chunks within the one or more computer memories at runtime for a computer application, the operations comprising: receiving a set of entities from the computer application, each of the set of entities including a set of components, wherein each component of the set of components has one type of a set of types; classifying the set of entities into a set of archetypes, each archetype representing a different count of the set of components or a different combination of types of the set of components relative to other archetypes of the set of archetypes; based on a determination that one of the set of archetypes corresponds to a new archetype, building a new memory chunk, adding the new memory chunk to the set of memory chunks, and populating the new memory chunk, wherein the populating of the new memory chunk includes adding data from the set of components included in one or more entities of the set of entities that are classified under the new archetype, the adding of the data including contiguously adding the data to ends of a set of component data arrays included in the new memory chunk, each of the set of data arrays included in the new memory chunk corresponding to a respective component of the set of components included in the one or more entities that are classified under the new archetype.