I have used EnTT for a few half finished projects. I like it because, as a more intermediate programmer, it forced me into the pattern. Sort of like coding on rails a bit in a good way.

Part of my feels that it is too much of a bother for most projects. Another part of me feels like that the ECS pattern is only going to get more common and that I should be concerned about data locality and speed no matter what (otherwise why am I even writing in C++?). I've honestly never had a project which needed the extra performance boost that an ECS library would give me. Usually my bottleneck is inefficient collision detection and noob rendering. 

Two parts of my mind are conflicting: one tells me that using a library is great because it lets me how things are supposed to be done, and that I should use a library of every type before I try to roll my own. Another part of my mind tells me that I will never fully learn this stuff without rolling my own and that I am wasting my time using a library when I can't even roll my own and don't know completely how it all works.

Anyhow, let me know your thoughts and experiences with ECS libraries.

Regarding this part:

Quote

...otherwise why am I even writing in C++?...

Another possible reason besides performance would be portability. For example, C++ might be a reasonable choice for a common code base shared between e.g. iOS and Android versions of a game or framework.

Further, it seems like whether performance would be a concern at all would depend on e.g. what platforms you're targeting and what types of projects you're working on. Depending on the answers to those questions, other languages might be perfectly suitable.

Quote

I've honestly never had a project which needed the extra performance boost that an ECS library would give me.

I could be wrong about this, but I've always been under the impression that the motivators behind ECSs are mostly architectural and not as much related to performance. Obviously an ECS implementation can be performant, but such a system could certainly be implemented in a non-performant way as well. So if your primary motivation for using an ESC is performance and not, say, convenience or architecture, it seems like that might be worth taking another look at.

2 hours ago, Zakwayda said:

Quote

I've honestly never had a project which needed the extra performance boost that an ECS library would give me.

I could be wrong about this, but I've always been under the impression that the motivators behind ECSs are mostly architectural and not as much related to performance. Obviously an ECS implementation can be performant, but such a system could certainly be implemented in a non-performant way as well. So if your primary motivation for using an ESC is performance and not, say, convenience or architecture, it seems like that might be worth taking another look at.

ECS should in theory help scale to very large object numbers by having a better memory layout and possibly being more amenable to SIMD etc., which could help with say your collision detection, depending on tour current implementation. Compared to having an "Entity" base class with say "virtual update()", "virtual canCollideWith(other)", etc. where the argument is that calling a virtual method on a "soup" of different things hurts CPU prediction (different actual implementations) and memory caching (jumping around in memory between objects).

But it is by no means the only way. e.g. Factorio, where I believe the devs have openly said they see no advantage to ECS, and I believe do even have an OOP "Entity" structure (the Prototype / data gives an idea) but optimised the important cases (e.g. items on belts, pipes, inserters, etc.).

A common example in various games that may be specifically optimised would be projectiles, particles, and "static" things like trees, rocks, etc.

Quote

ECS should in theory help scale to very large object numbers by having a better memory layout and possibly being more amenable to SIMD etc., which could help with say your collision detection, depending on tour current implementation.

Agreed. I made a mistake in terminology in my previous post, so I'll retract the second part of it. I'd still be interested in knowing more about the OP's goals though (target platforms, types of projects, etc.), since that could have a bearing on what languages and/or idioms might be worth pursuing.

If you decide for driving ECS and that was not the question here, you should for serious projects drive your own system (an Entity Component System System ? ... however) because of a simple reason: Those libraries don't know your usecase. It is the same thing why people write their own game engines, using feature complete (hopefully) full tested libraries/game engines give some kind of safety that you won't waste time debugging that code (but you will always do in large projects, too bad) but are designed as general as possible to target the most common market they can get. A custom solution is made just for your special use case or engine and so could be optimized in a way a general library couldn't.

As an example, I talked to a coullege of the industry that is working at an AAA studio. His ECS implementation was drilled to performance, use a continous memory block for all objects for all components on a limitted ammount of components. So every object always had memory allocated for every component where components were placed in their own array for each type of component. Entitites just carried a bit mask and an array index.

So you see: it depends ?

Hey, OP here.

I've been using EnTT library coding in C++ for a GUI library. So far so good. I like the library and the pattern because it helps me with decoupling and inheritance confuses me a lot.

The way the library works is each entity is an integer and they are all held in a registry. The systems you create traverse the registry and pick out all the entities which have the necessary components. Then the systems carry out their transformations on the components. For me this is easier than OOP at least it is does not seem any more difficult and provides a cool way to look at things.

My next problem with my GUI library is bringing focused windows to the front of the render order. It seems I need another registry for render order. I thought about rearranging the main registry however, then I would have to store another unique ID as a component for each entity. I don't know really what is best  I guess there are multiple ways to skin this feline.

@Shaarigan. I'm pretty basic I don't have a complicated or unusual use case yet, but hopefully someday I will be sophisticated enough to. I like the idea of working with libraries and reusing others code. Usually the general solution is much better than any one I could come up with at this point in my development in CS.

14 hours ago, LorenzoGatti said:

Can you clarify the impact of maintaining information about focused windows in the GUI on entities in the game state? Intuitively, there should be no impact: you can use straightforward references from GUI controls to the game entities that constitute their respective models and a data structure for "render order" and focus that has nothing to do with the entities and components.
If you have a problem you must be doing something more complicated.

Well the solution I have now is this:

There is a 0th guiEntity which is a sort of none thing which just serves as the root of the gui tree and which has a global position of 0,0. 

I created a component called Node which has a reference to the parent entity and a vector which has references to the children entities.

During rendering I traverse this tree from the 0th entity to all the children.

When I want to cycle up a window to the top of the render I find the entity I've clicked on and move it to be the first of the 0th entities children.

Right now I am only having 0th entities children as "windows". I don't see a need to have other entities recognized as "windows". I define a window as an independent entity which is usual draggable.