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.
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.