Using ECST (or derived) as production ready

[julien1619]

Hi,

I'm a french developer and I watched your presentation at CppCon last year about an ECS using template meta-programming, it was really great! Based on what you said and presented, we've started to write a small game for iOS and Android. This game is currently in production and I'm thinking about updating our ECS to be closer to what you did here, and eventually contribute to it by forking and Pull Requesting.

So, I would have a few questions about it, and I thought it was convenient to put it here (maybe should I've split these in two issues):

• Do you think there are any major issues that could prevent it from being used in production? I'm aware it's still WIP, but as it's a small project I'm working on, it's not an issue if, for example, API have to change from time to time.
• I don't know yet if the full engine we're writing (SDL2, Bullet, ...) we'll be released as Open Source, but it's possible. As you used an AFL v3 license, that I didn't even know it existed, is there any problem using ECST or something derived from that, whether or not we're releasing it as Open Source? From what I read, it's more or less the same thing as the MIT license.

Thank you very much!

Julien

[vittorioromeo]

Hello Julien,

I'm really glad you enjoyed the presentation! It would be great to see ECST being used in a real game, and to improve its implementation and design from real-world experience.

Do you think there are any major issues that could prevent it from being used in production?

Not that I know of. ECST assumes that you always have enough threads ready for parallel system execution synchronization (e.g. if you have two forks in the systems tree, two latches in two separate threads will block until the children subtasks are executed). This is usually not a problem, and system parallelization can be manually controlled (or disabled for specific systems) if a reproducible deadlock due to an high degree of parallelization occurs.

It would be interesting to solve this issue by keeping track of the available threads/workers and fall back to non-parallel execution at runtime (this could be implemented as a "parallelism strategy" object).

The API and the design may change from time to time, but I'm very busy with work at the moment so I do not have a lot of spare time. The latest branch is trying to generalize system instances in three different types, that will allow direct manipulation of component storage without going through entities (useful for SIMD, as an example). But that branch is far from being complete.

Another possible issue is the requirement for a fully-compliant C++14 compiler. I do not know what the state of C++14 is on iOS and Android.

As you used an AFL v3 license, that I didn't even know it existed, is there any problem using ECST or something derived from that, whether or not we're releasing it as Open Source?

It's not a problem as long as you link to this repo and include ECST's copyright.

I'm excited to see if ECST will be good enough for a small game. Feel free to contact me for any question and to contribute :)

[julien1619]

I'll keep in mind this limitation about high parallelization and I'll let you know if I face it or not.

Concerning C++14, that should not be a problem. With the latest tools (Xcode and Android Studio with the latest NDK) everything works almost out-of-the-box with our current ECS that uses some advanced C++14 features too, just needs to set some flags to enable it.

I won't forget to link your repo and include ECST's copyright ;)

I'll keep you informed ;)