2 ms·
Great explanation, thank you. > This comes at a cost of making adding and removing components from an entity more expensive. I think you could write a design-
by de_keyboard 5y ago
Great explanation, thank you.
> This comes at a cost of making adding and removing components from an entity more expensive.
I think you could write a design-time tool that takes a simple description file (with hints) and outputs code that stores your entities and components efficiently.
Description file:
{
"archetypes": [
{
"components": [ "A", "B", "C" ]
},
{
"components": [ "B" ]
},
{
"components": [ "B", "C" ]
}
]
}
Output:
class ArchetypeABC {
A a;
B b;
C c;
}
class ArchetypeB {
B b;
}
class ArchetypeBC {
B b;
C c;
}
class EntityStore {
ArchetypeABC[] entitiesABC;
ArchetypeB[] entitiesB;
ArchetypeBC[] entitiesB;
}
- meheleventyone 5y agoThis static analysis might not be sufficient as most of these designs allow runtime manipulation of the components on an Entity. Usually the implementation of the component storage does much the same at runtime though so archetype storages are created and removed as needed. The static analysis could be used to pre-warm that if it was particularly slow.
- codetrotter 5y agoFrom the way that the parent commenter illustrated the memory layout I thought they were talking about SoA style but your comment is using AoS style. So I would expect the code corresponding to their comment to look like this instead of what you wrote: class ArchetypeABC { A[] as; B[] bs; C[] cs; } class ArchetypeB { B[] bs; } class ArchetypeBC { B[] bs; C[] cs; } But maybe I misunderstood?
- meheleventyone 5y agoYou’re correct.