[Vaskivo]

While ECS means you're using a "data driven" approach, you can have a "data driven" approach without having to use ECS.

It's all about having configuration data separate to the logic. And use this data to setup and build the game elements.

Here's a couple of videos I created:

How to start with Data Driven Development in Godot: https://www.youtube.com/watch?v=ZG__fXSp74c

What I can do with it in my game, One Way Dungeon: https://www.youtube.com/watch?v=PqZwKahZ3cU

[Jasper_]

ECS is commonly described as "data-oriented", not "data-driven". It's confusing, yes, but the have separate and unrelated meanings in the game development space.

The former is a methodology for building engine systems that are cache-friendly, the latter talks about workflows that are more flexible to artists and developers.

You can use ECS without "being data-driven", and you can use data-driven workflows without ECS.

[Vaskivo]

> You can use ECS without "being data-driven", and you can use data-driven workflows without ECS.

True, I've read about ECS being used for one or both of those purposes.

My first contact was ECS was as a composability pattern. So, in a "high level" purpose, as an alternative to inheritance. It was also described as "Game Object - Game component" pattern.

See http://gameprogrammingpatterns.com/component.html, specially the sidenote in http://gameprogrammingpatterns.com/component.html#no-bj%C3%B....

There's the "performance" ECS, where it tackles data locality.

And the "game element definition and configuration" ECS, where it solves a high level problem of building game elements. On the "game developer" level, Unity works like this.