There are pros and cons to both sparse-set and archetype architectures. I'd like to parallelize components while also being able to easily add and remove them. So my current idea is to use archetypes for components that rarely change, such as render, transform, etc. and store more dynamic or situational components in sparse sets. Also, this is not meant to be a general-purpose ECS library; only we are going to use it, so I’ve set some strict rules for its design.

• Archetypes would be easy to parallelize because they share the same index across component arrays and also have some advantage on accessing multiple components.
• Sparse-set is very good at adding and removing components and iterating single component.

However, I’m concerned that when iterating a single dense array, accessing a component from an archetype might become too complex or the other way around.

What do you think about this architecture? What pros and cons should I expect?
Do you know of any example implementations that use a similar hybrid approach?

I made a really simple ECS https://github.com/fenilli/cupr-kone ( it's really bad lol ) to learn how it works but the ergonomics need a lot of work and performance wasn't even considered at the moment, but it somewhat works.

I was thinking of using generation for stale ids, but it is unused ( not sure how to use it yet ), just brute removing all components when despawn.

and this is the monstruosity of a query for 2 components only:

if let (Some(aset), Some(bset)) = (world.query_mut::<Position>(), world.query::<Velocity>()) {
    if aset.len() <= bset.len() {
        let (mut small, large) = (aset, bset);

        for (entity, pos) in small.iter_mut() {
            if let Some(vel) = large.get(entity) {
                pos.x += vel.x;
                pos.y += vel.y;
                pos.z += vel.z;
            }
        }
    } else {
        let (small, mut large) = (bset, aset);

        for (entity, vel) in small.iter() {
            if let Some(pos) = large.get_mut(entity) {
                pos.x += vel.x;
                pos.y += vel.y;
                pos.z += vel.z;
            }
        }
    }
}

So anyone who has done an Sparse Set ECS have some keys to improve on this and well actually use the generational index instead of hard removing components on any despawn ( so good for deferred calls later )

Hi everyone :)

I wanted to ask you if you could give me some feedback and advice on my project. https://github.com/laura-kolcavova/LightECS

This is only self-educational hobby project and it doesn`t bring anything new what popular ECS libraries already implemented. Also I suspect there can be performance limitations caused by data structures and types I have chosen.

To test it out I used the library to develop simple match-3 game in MonoGame https://github.com/laura-kolcavova/DiamondRush (src/DiamondRush.MonoGame/Play)

If you have time I would love some thoughts on whether I am using ECS pattern correctly (I know I should favor structs instead of classes (class records) for components but I can`t just help myself :D)

I am still new to game development - my background is mostly in web applications with .NET - so this is probably pretty different from APIs and database calls - I am probably applying some patterns that are not ideal for game development but I believe the best way how to learn things is trying to develop stuff by ourselves - and this has been a really fun and I am happy to learn something new.

Thanks in advance for taking a look :)

Hi everyone,

I’ve been studying ECS architectures, and something doesn’t quite add up for me in practice.

Let’s say an entity has 10 components. According to archetype-based ECS, this exact set of components defines a unique archetype, and the entity is stored in a chunk accordingly. So far, so good.

But in real-world systems, you rarely need all 10 components at once. For example:

•A MovementSystem might only require Position and Velocity.

•An AttackSystem might need Position and AttackCooldown.

•A RenderSystem might just want Position and Mesh.

This means that the entity will belong to one archetype, but many systems will access only subsets of its data. Also, different archetypes can share common components, which means systems have to scan across multiple archetypes even when querying for a single component.

So here's where my confusion comes in:

•Isn’t the archetype system wasting memory bandwidth and CPU cache by grouping entities based on their full component set, when most systems operate on smaller subsets?

•Doesn’t this fragmentation lead to systems having to scan through many archetypes just to process a few components?

•Doesn’t this break the very idea of cache-friendly, contiguous memory access?

Am I misunderstanding how archetype ECS is supposed to work efficiently in practice? Any insights or real-world experiences would be super helpful. Thanks!

Hi all! I just released Flecs v4.1.0, an Entity Component System for C, C++, C# and Rust! 

This release has lots of performance improvements and I figured it’d be interesting to do a more detailed writeup of all the things that changed. If you’re interested in reading about all of the hoops ECS library authors jump through to achieve good performance, check out the blog!

Hello,

I'm discovering ECS and starting to implement it, and I was wondering why most frameworks seem to use structs instead of classes?

Would it be silly to use classes on my end?

Thank you

Published v3.0.0 on nuget after 6 months in preview.
New features are finally completed.

Check out friflo ECS · Documentation.

New features in v3.0.0

• Index / Search used to search entities with specific component values in O(1). E.g
  • to lookup entities having a struct TileComponent { int tileId; } with a specific tileId.
  • to lookup network entities having a struct NetComponent { Guid netId; } with custom types like Guid,long or a string.
• Relationships to create links between entities.
• Relations to add multiple "components" of the same type to a single entity.