3 ms·
You don't need it to implement it a small-scope if the goal of your game project is to implement the game at hand. If the goal of your game project is to learn
by golergka 8y ago
You don't need it to implement it a small-scope if the goal of your game project is to implement the game at hand. If the goal of your game project is to learn about tech and then use it on your main job, that's another matter.
On my job, I work on a Unity3d-based match3 mobile game. I am constantly running into game logic as a performance bottleneck – modern match3 games with "live" boards that you can play on while they flow is a combinatorial nightmare sometimes. Obviously, I can't rewrite already released project to take advantage of ECS, but I constantly toy with it in my free time so we don't run into the same problems in the future - without any desire to make a complete game with these toy projects.
- flohofwoe 8y agoI think you're talking about the new Unity ECS, which is a very specific implementation, while the OP talks about the general idea of composition via components, which is indeed overkill for many games. If you're having an area of code which has a performance problem and can be isolated into a tight loop, the new Unity ECS is probably a good choice, but only in the specific context of Unity. And not because of the idea of "entities, components, and systems", but because the Unity ECS comes with a "toolbox" that makes it simple to run parallel code over flat arrays of structs, and with a limited C# subset created for writing high-performance code. But it's important to note that outside of Unity, or other "behemoth engines" you can get close to that performance with a lot less effort, just by using a sane data layout and running your code in a simple loop (instead of running the same code in lots of tiny pieces interleaved with unrelated code, as is often the case with "traditional" entity-component systems.