11 ms·

To any budding game developers, my advice would be to not rush into ECS and try to accomplish your goals with structs and loops first and understand the fundame

To any budding game developers, my advice would be to not rush into ECS and try to accomplish your goals with structs and loops first and understand the fundamentals of how a video game 'works' under the hood. Your game will get done if you work on it, not necessarily if you pick ECS!

brigadier132 3y ago
I completely disagree. How games work is simple. It's a simulation run at some frequency and the simulation can be affected by player input. Sometimes there is a synchronization step with a server and that is more complicated. ECS is a pattern that results in better performance and more maintainable code. There is no reason not to use it.
- deleted 3y ago
  [deleted]
- HelloNurse 3y ago
  Better performance and more maintainable code are never the only concerns. For example, achieving a running prototype quickly with some ported/adapted non-ECS engine from a previous project might be more effective and efficient that starting from scratch with a better ECS architecture.
whateveracct 3y ago
In imperative langs, maybe. But I _would_ recommend ECS to Haskell devs interested in making games because apecs is just that good.
pjmlp 3y ago
Indeed, golden rules of game development, finish the game, game design matters more than tech, either make an engine or a game.
- ajmmertens 3y ago
  The opposite also applies: don't reinvent the wheel if you want to get something done. Existing game engines like Unity/Unreal already have builtin solutions for entity management, but if you're (for whatever reason) using something that's more custom you can avoid having to reinvent entity management by using an ECS library. Similar to how you'd use libraries like SDL/bgfx/sokol for graphics.
  - meheleventyone 3y ago
    This is true to a point if you need a general purpose entity management framework that will scale to whatever but a lot of games in the "make a game not an engine" vein don't need that complexity. Adding a dependency can save time but can also be its own rabbit hole. One of those things where discussing theoretical stuff doesn't help because "it depends". :D
  - moahe 3y ago
    This. Some people prefer fully-featured large engines (even for small games) and some prefer a set of libraries to mix and match. I'm happy that a really cool option with a C API exists.
illiarian 3y ago
I've also seen a few game devs saying ECS are useless in quite a few situations (or, at least, a very zealous adherence to ECS). I guess it's one of those things that you don't know until you try (and hit the limits of using or not-using one). I'm also reminded of Robert Nystrom's "Is There More to Game Architecture Than ECS": https://youtu.be/JxI3Eu5DPwE https://youtu.be/JxI3Eu5DPwE (Yes, Robert Nystrom of Game Programming Patterns and Crafting Interpreters)
davedx 3y ago
Yeah fully agree, ECS is the microservices of gamedev these days. I've worked on AAA games that used it, and shipped games as a solo dev without it. If you don't know why you need it, then chances are you don't need it. Just keep it in mind as one possible architecture pattern for when your code base starts to experience growing pains is my advice.
- throwaway894345 3y ago
  I don’t have any intention of writing a game, but my lay understanding of ECS is that it sort of treats your world as an in-memory columnar database for better cache locality: if you’re updating the positions of a collection of entities, you only need to loop over a collection of contiguous `position` structs—you can get a lot more of these in a cache line than you would if the entire entity was a struct containing a position field among many other fields which are irrelevant to the updatePosition operation. How far off am I?
  - ajmmertens 3y ago
    Pretty close, but there's a bit more to it. This post goes over one way an ECS can store data: https://ajmmertens.medium.com/building-an-ecs-2-archetypes-and-vectorization-fe21690805f9 https://ajmmertens.medium.com/building-an-ecs-2-archetypes-a...
- ajmmertens 3y ago
  I'm definitely not going to argue that you need ECS to do much of anything, but ECS has come long way in the past 4 years from a tool that lets you have lots of entities in a game, to a more generic system for entity management. Things like entity relationships (https://ajmmertens.medium.com/building-games-in-ecs-with-entity-relationships-657275ba2c6c https://ajmmertens.medium.com/building-games-in-ecs-with-ent...) introduced features that were already common in existing entity management systems, such as entity hierarchies. An ECS can also come with a bunch of tools for inspecting entities, monitoring performance or changing components in realtime (https://www.flecs.dev/explorer/ https://www.flecs.dev/explorer/). Definitely not something you need to complete a game, but very handy.
oneshtein 3y ago
You can do both. Here is tutorial for Rogue-like game with ECS in Rust: https://bfnightly.bracketproductions.com/rustbook/chapter_2.html https://bfnightly.bracketproductions.com/rustbook/chapter_2....
- tourgen 3y ago
  Here's a rogue-like game written in straight C, with hard-coded arrays, structs, and defines. https://github.com/tmewett/BrogueCE https://github.com/tmewett/BrogueCE component systems are useful when you have no design doc, or a design doc written by new-hire monkeys. Or when management has no idea what the goals are.
  - ajmmertens 3y ago
    Or if you want code that's easier to extend, read and don't want to do your own memory management. Here's a bit of code from that project that generates a monster: https://github.com/tmewett/BrogueCE/blob/master/src/brogue/Monsters.c#L63 https://github.com/tmewett/BrogueCE/blob/master/src/brogue/M... It just allocates an object per monster, followed by initializing a long list of members that presumably just gets longer as more game systems get added. The same code in ECS would look a lot simpler, and probably perform better/have better cache locality.
midland_trucker 3y ago
As a programmer not part of this world: what's the go-to alternative in this situation? Does ECS not naturally arise from using OOP? Trying to think if you are creating instances of players/physics objects/items how that wouldn't turn into a kind of entity system.
- vouwfietsman 3y ago
  No actually the ECS approach is more or less the exact opposite of (naive) OOP. In (naive) OOP you design objects for your domain, like an enemy, or a bullet, or an explosion. In ECS, you define abstract entities and compose data (and potentially behavior) on top of them, so there's no single "enemy" object, there's an entity that composes AI, geometry and sound effects to make it behave as an enemy. In general, for large systems, this is a great way to achieve decoupling, where the naive OOP approach would get you stuck quickly.
- WorldMaker 3y ago
  One view on the OOP <=> ECS relationship is that ECS is an exploration of/recreation of/divergence from alternative "natural" OOP systems outside of the "dominant OOP strain" of C++ (and family) (re-)implemented on top of C++-style OOP. There are hints (and needs) in ECS systems of post-hoc/runtime Prototypical inheritance rather than pre-hoc/design time Class based construction. There are facets of ECS that resemble concepts like mixins and pattern matching and multi-dispatch and message passing rather than "pure" "C++ VTABLE" dispatch. Some of these things arise more naturally in other branches of the OOP family tree: the Common Lisp Object System can do some of these things out of the box; Smalltalk and its descendants (even Objective-C) were easier to mold to ECS-like configurations; IO had interesting things to say about this style of OOP; even much-maligned JS' "strange" branch of Prototypical OOP has a bunch of low-level tools that make ECS "less of a need" in JS because there are ways to do them more "naturally". Certainly, though, in C++ and closer-related derivatives (even Java and C#) ECS isn't as naturally a pattern, which is why it often has need for strong "frameworks" and why there are often multiple, competing ones to pick from.
  - mananaysiempre 3y ago
stephc_int13 3y ago
I've spent a few months working with ECS/DOTS with the Unity Game Engine, their implementation of this style of architecture end up being very complex in comparison to the old fashion GameObject workflow that made Unity popular in the first place. Everything is MUCH more difficult to implement, I won't go into details but from my experience the time spent to achieve a similar result is about 5x-10x what it should be. Weird APIs, poor documentation, limited collective experience, tons of restrictions and limits of the C# language are making the global experience quite nightmarish. And I have had experience with ECS-like system in different engines in the past, and I am mostly experienced with low-level engine stuff, but the induced complexity there is something I did not expect.
- capableweb 3y ago
  > GameObject workflow that made Unity popular in the first place. It's a bit much of a over-simplication that just the GameObject architecture Unity uses is what made it popular. For example, if there wasn't a UI editor for Unity and only code, you still think it would be as popular? I'm 99% sure it wouldn't be. I tried getting into DOTS as well, as ECS is an interesting architecture overall, but Unity kind of dropped the ball on it and made it way more complicated than it has to be, from every side of having to use it. On the other hand, you have Bevy, which is built with ECS as a core part of the engine, and it makes using ECS a breeze. After getting to know Bevy and ECS outside of DOTS better, I'm not sure I could back to how I wrote my games before. ECS just makes it a lot easier to structure bigger projects than the basic introduction game like flappy bird. The modularity is on a different level and it gives you a much better view of the overall architecture than anything else I've tried before. Simply put, I'm not sure I'd write the same amount of games if it wasn't ECS, because it makes it fun to make games again, for me.
- jbluepolarbear 3y ago
  As a game dev that’s been using Unity ECS in production for over 2 years, it’s a very underwhelming implementation. Sure it’s fast if you design a game with Unitys intentions, but Unity has never made a game and what they made isn’t what game devs need.

brigadier132 3y ago

I completely disagree. How games work is simple. It's a simulation run at some frequency and the simulation can be affected by player input. Sometimes there is a synchronization step with a server and that is more complicated. ECS is a pattern that results in better performance and more maintainable code. There is no reason not to use it.

deleted 3y ago
[deleted]
HelloNurse 3y ago
Better performance and more maintainable code are never the only concerns. For example, achieving a running prototype quickly with some ported/adapted non-ECS engine from a previous project might be more effective and efficient that starting from scratch with a better ECS architecture.

whateveracct 3y ago

In imperative langs, maybe. But I _would_ recommend ECS to Haskell devs interested in making games because apecs is just that good.

pjmlp 3y ago

Indeed, golden rules of game development, finish the game, game design matters more than tech, either make an engine or a game.

ajmmertens 3y ago
The opposite also applies: don't reinvent the wheel if you want to get something done. Existing game engines like Unity/Unreal already have builtin solutions for entity management, but if you're (for whatever reason) using something that's more custom you can avoid having to reinvent entity management by using an ECS library. Similar to how you'd use libraries like SDL/bgfx/sokol for graphics.
- meheleventyone 3y ago
  This is true to a point if you need a general purpose entity management framework that will scale to whatever but a lot of games in the "make a game not an engine" vein don't need that complexity. Adding a dependency can save time but can also be its own rabbit hole. One of those things where discussing theoretical stuff doesn't help because "it depends". :D
- moahe 3y ago
  This. Some people prefer fully-featured large engines (even for small games) and some prefer a set of libraries to mix and match. I'm happy that a really cool option with a C API exists.

illiarian 3y ago

I've also seen a few game devs saying ECS are useless in quite a few situations (or, at least, a very zealous adherence to ECS). I guess it's one of those things that you don't know until you try (and hit the limits of using or not-using one). I'm also reminded of Robert Nystrom's "Is There More to Game Architecture Than ECS": https://youtu.be/JxI3Eu5DPwE https://youtu.be/JxI3Eu5DPwE (Yes, Robert Nystrom of Game Programming Patterns and Crafting Interpreters)

davedx 3y ago

Yeah fully agree, ECS is the microservices of gamedev these days. I've worked on AAA games that used it, and shipped games as a solo dev without it. If you don't know why you need it, then chances are you don't need it. Just keep it in mind as one possible architecture pattern for when your code base starts to experience growing pains is my advice.

throwaway894345 3y ago
I don’t have any intention of writing a game, but my lay understanding of ECS is that it sort of treats your world as an in-memory columnar database for better cache locality: if you’re updating the positions of a collection of entities, you only need to loop over a collection of contiguous `position` structs—you can get a lot more of these in a cache line than you would if the entire entity was a struct containing a position field among many other fields which are irrelevant to the updatePosition operation. How far off am I?
- ajmmertens 3y ago
  Pretty close, but there's a bit more to it. This post goes over one way an ECS can store data: https://ajmmertens.medium.com/building-an-ecs-2-archetypes-and-vectorization-fe21690805f9 https://ajmmertens.medium.com/building-an-ecs-2-archetypes-a...
ajmmertens 3y ago
I'm definitely not going to argue that you need ECS to do much of anything, but ECS has come long way in the past 4 years from a tool that lets you have lots of entities in a game, to a more generic system for entity management. Things like entity relationships (https://ajmmertens.medium.com/building-games-in-ecs-with-entity-relationships-657275ba2c6c https://ajmmertens.medium.com/building-games-in-ecs-with-ent...) introduced features that were already common in existing entity management systems, such as entity hierarchies. An ECS can also come with a bunch of tools for inspecting entities, monitoring performance or changing components in realtime (https://www.flecs.dev/explorer/ https://www.flecs.dev/explorer/). Definitely not something you need to complete a game, but very handy.

oneshtein 3y ago

You can do both. Here is tutorial for Rogue-like game with ECS in Rust: https://bfnightly.bracketproductions.com/rustbook/chapter_2.html https://bfnightly.bracketproductions.com/rustbook/chapter_2....

tourgen 3y ago
Here's a rogue-like game written in straight C, with hard-coded arrays, structs, and defines. https://github.com/tmewett/BrogueCE https://github.com/tmewett/BrogueCE component systems are useful when you have no design doc, or a design doc written by new-hire monkeys. Or when management has no idea what the goals are.
- ajmmertens 3y ago
  Or if you want code that's easier to extend, read and don't want to do your own memory management. Here's a bit of code from that project that generates a monster: https://github.com/tmewett/BrogueCE/blob/master/src/brogue/Monsters.c#L63 https://github.com/tmewett/BrogueCE/blob/master/src/brogue/M... It just allocates an object per monster, followed by initializing a long list of members that presumably just gets longer as more game systems get added. The same code in ECS would look a lot simpler, and probably perform better/have better cache locality.

midland_trucker 3y ago

As a programmer not part of this world: what's the go-to alternative in this situation? Does ECS not naturally arise from using OOP? Trying to think if you are creating instances of players/physics objects/items how that wouldn't turn into a kind of entity system.

vouwfietsman 3y ago
No actually the ECS approach is more or less the exact opposite of (naive) OOP. In (naive) OOP you design objects for your domain, like an enemy, or a bullet, or an explosion. In ECS, you define abstract entities and compose data (and potentially behavior) on top of them, so there's no single "enemy" object, there's an entity that composes AI, geometry and sound effects to make it behave as an enemy. In general, for large systems, this is a great way to achieve decoupling, where the naive OOP approach would get you stuck quickly.
WorldMaker 3y ago
One view on the OOP <=> ECS relationship is that ECS is an exploration of/recreation of/divergence from alternative "natural" OOP systems outside of the "dominant OOP strain" of C++ (and family) (re-)implemented on top of C++-style OOP. There are hints (and needs) in ECS systems of post-hoc/runtime Prototypical inheritance rather than pre-hoc/design time Class based construction. There are facets of ECS that resemble concepts like mixins and pattern matching and multi-dispatch and message passing rather than "pure" "C++ VTABLE" dispatch. Some of these things arise more naturally in other branches of the OOP family tree: the Common Lisp Object System can do some of these things out of the box; Smalltalk and its descendants (even Objective-C) were easier to mold to ECS-like configurations; IO had interesting things to say about this style of OOP; even much-maligned JS' "strange" branch of Prototypical OOP has a bunch of low-level tools that make ECS "less of a need" in JS because there are ways to do them more "naturally". Certainly, though, in C++ and closer-related derivatives (even Java and C#) ECS isn't as naturally a pattern, which is why it often has need for strong "frameworks" and why there are often multiple, competing ones to pick from.
- mananaysiempre 3y ago

stephc_int13 3y ago

I've spent a few months working with ECS/DOTS with the Unity Game Engine, their implementation of this style of architecture end up being very complex in comparison to the old fashion GameObject workflow that made Unity popular in the first place. Everything is MUCH more difficult to implement, I won't go into details but from my experience the time spent to achieve a similar result is about 5x-10x what it should be. Weird APIs, poor documentation, limited collective experience, tons of restrictions and limits of the C# language are making the global experience quite nightmarish. And I have had experience with ECS-like system in different engines in the past, and I am mostly experienced with low-level engine stuff, but the induced complexity there is something I did not expect.

capableweb 3y ago
> GameObject workflow that made Unity popular in the first place. It's a bit much of a over-simplication that just the GameObject architecture Unity uses is what made it popular. For example, if there wasn't a UI editor for Unity and only code, you still think it would be as popular? I'm 99% sure it wouldn't be. I tried getting into DOTS as well, as ECS is an interesting architecture overall, but Unity kind of dropped the ball on it and made it way more complicated than it has to be, from every side of having to use it. On the other hand, you have Bevy, which is built with ECS as a core part of the engine, and it makes using ECS a breeze. After getting to know Bevy and ECS outside of DOTS better, I'm not sure I could back to how I wrote my games before. ECS just makes it a lot easier to structure bigger projects than the basic introduction game like flappy bird. The modularity is on a different level and it gives you a much better view of the overall architecture than anything else I've tried before. Simply put, I'm not sure I'd write the same amount of games if it wasn't ECS, because it makes it fun to make games again, for me.
jbluepolarbear 3y ago
As a game dev that’s been using Unity ECS in production for over 2 years, it’s a very underwhelming implementation. Sure it’s fast if you design a game with Unitys intentions, but Unity has never made a game and what they made isn’t what game devs need.