ECS and Towards More Normalized Code

The Case Against ECS

ECS is a powerful pattern, but it's not a silver bullet. It can be overkill for small projects or projects where the complexity doesn't justify the overhead.

Here are some reasons you might not want to use ECS:

1. Ramp Up: ECS can feel at first like too much overhead when you just want to get something up and running. It guarantees you'll need at least 2 files per game system, which can really add up. As a solo dev, sometimes you just want a simple game loop, and fair enough.
2. Knowledge: Every example on Babylon playground, et al, is not ECS. It's hard to find babylon ECS examples anywhere, so you'll have to convert a lot of the examples you find to the Component, System pattern.
3. Verbose: ECS can feel verbose. You have to create a lot of classes and interfaces to get it working. It's not as simple as just adding a function to your game loop with an object full of data. It's understandable all the other tutorials don't really use it. They're truing to teach something orthogonal to ECS.

The Case For ECS

That said I prefer it even though I'm a solo dev. I found my first dozen attempts at making games were inevitably bottlenecked by having to make choices about where the data would live and how systems would access the data. I'd end up with a lot of spaghetti code and a lot of bugs. ECS has helped me avoid that because it prescribes a way to organize code so the project can scale linerarly as the game gets larger.

ECS is a powerful pattern that can help you build more modular, maintainable, and scalable code. Here are some reasons you might want to use ECS:

1. Modularity: ECS encourages you to break your game logic into small, reusable components that can be added and removed from entities at runtime and serialized into data for saving your games.
2. Scalability: ECS can help you manage complexity as your game grows. By separating data from behavior in a common interface, you can more easily add new features and systems without having to rewrite large parts of your codebase.
3. Flexibility: ECS allows you to create systems that operate on entities based on the components they have, rather than their type. This can make it easier to create new types of entities and systems without having to modify existing code.

This can make your code easier to understand and maintain, especially among a team of developers. As a solo dev, returning to a project after a few months, I find it easier to understand what tge code is supposed to do when I use ECS.

The Reason this Course Exists is ECS

I saw a giant gap in the Babylon.js community's knowledge and decided to gear everything towards getting ECS in your intuition. Unity has a built in ECS system and much of it's examples are in the ECS pattern. Babylon.js has no such thing. I'm trying to fill that gap.

My hope is it will lead to more complex babylon.js projects. I've seen a lot of simple games and demos, but not a lot of complex games. I think ECS is one way to get there.

In Sum

In short, every project defines some interfaces or interfaces for the code to work in a maintainable way. You can either define it at the start of the project or let it emerge as you go. ECS is a way to define those interfaces at the start of the project. If every dev on the team has a different idea of how to organize the data and the code, you'll end up with a mess. Call it whatever you want. Components are data and Systems are code.