4 ms·

Godot is sort of its own thing, not a strict "object hierarchy everything" so much as "favor composition; everything is a node in the scene tree."

pphysch 5y ago
Godot's head developer admits that if you want to do anything performance-intensive (e.g. thousands of interacting entities, AAA stuff) with Godot, you will likely end up hacking the low-level engine code or even using a separate ECS/DoD implementation. At that point, why not use a proper ECS engine? https://godotengine.org/article/why-isnt-godot-ecs-based-game-engine https://godotengine.org/article/why-isnt-godot-ecs-based-gam... (see "Optimization" section and below)
- flohofwoe 5y ago
  Hardly any game needs "thousands of interacting entities" though (outside of special subsystems like particle systems). Arguably, (DOTS-style) ECS makes it harder to incrementally build a game by adding features, because you need to put more effort into designing the data layout upfront. And if there's just a few dozen instances of each thing that's definitely overkill, moving to ECS won't make a noticeable performance difference in that case.
  - pphysch 5y ago
    > Hardly any game needs "thousands of interacting entities" though (outside of special subsystems like particle systems). This is an example of survivorship bias. How many ambitious game concepts have collapsed under performance/architecture issues that lead to productivity-killing refactoring? Impossible to say, but no doubt many. > Arguably, ECS makes it harder to incrementally build a game by adding features, because you need to put more effort into designing the data layout upfront. OOP bakes these decisions into the inheritance hierarchy, which ends up being more thorny than adding a component, or migrating an existing component's schema. ECS will make it straightforward to determine which Systems will be affected when a particular Component's schema is altered.
    - Twisol 5y ago
      > This is an example of survivorship bias. How many ambitious game concepts have collapsed under performance/architecture issues that lead to productivity-killing refactoring? Impossible to say, but no doubt many. I'm reminded a bit of Minecraft, whose infinite and completely mutable voxel world was really novel at the time -- and which was (and maybe still is) the source of a lot of performance woes.
    - meheleventyone 5y ago
      > This is an example of survivorship bias. How many ambitious game concepts have collapsed under performance/architecture issues that lead to productivity-killing refactoring? Impossible to say, but no doubt many. Probably less than you think. The games industry knows how to wring performance out of hardware. Data oriented design is common in most game engines where it matters. It’s just it’s not usually the gameplay code that is particularly a bottleneck. There are also plenty of examples of games where the gameplay layer is a perf concern that not only have been released but were big sellers. For example Factorio and City Skylines. It’s just I’m those examples it makes more sense to worry about data model and access patterns for the actual problem at hand rather than try to generalise it with all the attendant problems that causes. Not least slowing down workflows when you don’t actually need it. Most game engines are also composition based rather than using much inheritance these days.
    - SeanBoocock 5y ago
      Speaking from experience, the hardest part about game development isn’t figuring out how to (efficiently) build something, it’s deciding what to build in the first place. The second hardest problem is getting everyone on board with the answer to that. The third is figuring out how to build the content 1000x to support that. Way, way down the list is the runtime performance for a gameplay system. True ECS systems - and not frameworks that just have things called “entities” which own things called “components” - are hard to work with, almost by definition (ie you have to be very explicit about data layout and dependencies). They add a lot of friction upfront to solving the important and hard problem(s) while purporting to solve something that isn’t actually an issue in most cases (guess what, your N is likely < 10, modern cpus go brrr, etc). If you are working in a domain where you already know something about the performance and input size characteristics - particle systems are the go to example - then maybe ECS makes sense as a framework. Otherwise, I’d advocate for simpler oop approaches with heavy composition.
  - mkishi 5y ago
    I've been wondering something, though: wouldn't it be possible to implement regular EC-style components on top of an ECS system? You can't implement ECS on top of EC, but if it's possible the other way around, Godot's argument that most people won't need it would seem a bit weak — just let them use fat components on top of an ECS core, and if/when they need the performance there's still room to push it without side-stepping the whole engine.
    - jbluepolarbear 5y ago
      You can implement ECS on top of EC. Entitas is and example of a really good ECS on top of Unity’s default EC. I’m currently writing and designing a serialization/networking library that I’m using to build an ECS framework on top of regular Unity EC. Why not use dots? Well, I hate the restriction of using only blittables for component data, I want to have access to the already existing ecosystem of Unity packages, and the biggest is that I am designing it for networking first. It’s slow going (I’m a dad and I have a full time game dev job), but I’m making good steady progress. My serialization library currently features composition, quantization, no reflection, and no garbage collection. I plan on releasing the first version under the MIT license hopefully in the next couple months. I have a prototype that I’ve been building to test my stuff. Check it out it’s only 30s. https://youtu.be/p4v3ZnS2KBM https://youtu.be/p4v3ZnS2KBM
      - prox 5y ago
        Your demo reminds me of a problem that M&B 2 Bannerlord had, they created a destructable castle, but couldn’t get performance network enough to sync the destruction (bricks and stone walls) to all players.
        jbluepolarbear 5y ago
        Networking games is hard. It’s what I do for work and it’s an iterative process. If you’re interested in the subject of physics and netcode I’d recommend: https://gafferongames.com/post/introduction_to_networked_physics/ https://gafferongames.com/post/introduction_to_networked_phy... If your want a very deep dive and very technical, I’d recommend: https://fabiensanglard.net/doom3_documentation/The-DOOM-III-Network-Architecture.pdf https://fabiensanglard.net/doom3_documentation/The-DOOM-III-... A lot of good resources at the bottom of the pdf too.
- EamonnMR 5y ago
  I've played maybe one game with entities in that count range (Planetary Annihilation) and I think you'd need a lot of low level engine work for something like that anyway (since it's doing all sorts of neat stuff with interpolation, weird coordinate systems, networking, etc.)

pphysch 5y ago

Godot's head developer admits that if you want to do anything performance-intensive (e.g. thousands of interacting entities, AAA stuff) with Godot, you will likely end up hacking the low-level engine code or even using a separate ECS/DoD implementation. At that point, why not use a proper ECS engine? https://godotengine.org/article/why-isnt-godot-ecs-based-game-engine https://godotengine.org/article/why-isnt-godot-ecs-based-gam... (see "Optimization" section and below)

flohofwoe 5y ago
Hardly any game needs "thousands of interacting entities" though (outside of special subsystems like particle systems). Arguably, (DOTS-style) ECS makes it harder to incrementally build a game by adding features, because you need to put more effort into designing the data layout upfront. And if there's just a few dozen instances of each thing that's definitely overkill, moving to ECS won't make a noticeable performance difference in that case.
- pphysch 5y ago
  > Hardly any game needs "thousands of interacting entities" though (outside of special subsystems like particle systems). This is an example of survivorship bias. How many ambitious game concepts have collapsed under performance/architecture issues that lead to productivity-killing refactoring? Impossible to say, but no doubt many. > Arguably, ECS makes it harder to incrementally build a game by adding features, because you need to put more effort into designing the data layout upfront. OOP bakes these decisions into the inheritance hierarchy, which ends up being more thorny than adding a component, or migrating an existing component's schema. ECS will make it straightforward to determine which Systems will be affected when a particular Component's schema is altered.
  - Twisol 5y ago
    > This is an example of survivorship bias. How many ambitious game concepts have collapsed under performance/architecture issues that lead to productivity-killing refactoring? Impossible to say, but no doubt many. I'm reminded a bit of Minecraft, whose infinite and completely mutable voxel world was really novel at the time -- and which was (and maybe still is) the source of a lot of performance woes.
  - meheleventyone 5y ago
    > This is an example of survivorship bias. How many ambitious game concepts have collapsed under performance/architecture issues that lead to productivity-killing refactoring? Impossible to say, but no doubt many. Probably less than you think. The games industry knows how to wring performance out of hardware. Data oriented design is common in most game engines where it matters. It’s just it’s not usually the gameplay code that is particularly a bottleneck. There are also plenty of examples of games where the gameplay layer is a perf concern that not only have been released but were big sellers. For example Factorio and City Skylines. It’s just I’m those examples it makes more sense to worry about data model and access patterns for the actual problem at hand rather than try to generalise it with all the attendant problems that causes. Not least slowing down workflows when you don’t actually need it. Most game engines are also composition based rather than using much inheritance these days.
  - SeanBoocock 5y ago
    Speaking from experience, the hardest part about game development isn’t figuring out how to (efficiently) build something, it’s deciding what to build in the first place. The second hardest problem is getting everyone on board with the answer to that. The third is figuring out how to build the content 1000x to support that. Way, way down the list is the runtime performance for a gameplay system. True ECS systems - and not frameworks that just have things called “entities” which own things called “components” - are hard to work with, almost by definition (ie you have to be very explicit about data layout and dependencies). They add a lot of friction upfront to solving the important and hard problem(s) while purporting to solve something that isn’t actually an issue in most cases (guess what, your N is likely < 10, modern cpus go brrr, etc). If you are working in a domain where you already know something about the performance and input size characteristics - particle systems are the go to example - then maybe ECS makes sense as a framework. Otherwise, I’d advocate for simpler oop approaches with heavy composition.
- mkishi 5y ago
  I've been wondering something, though: wouldn't it be possible to implement regular EC-style components on top of an ECS system? You can't implement ECS on top of EC, but if it's possible the other way around, Godot's argument that most people won't need it would seem a bit weak — just let them use fat components on top of an ECS core, and if/when they need the performance there's still room to push it without side-stepping the whole engine.
  - jbluepolarbear 5y ago
    You can implement ECS on top of EC. Entitas is and example of a really good ECS on top of Unity’s default EC. I’m currently writing and designing a serialization/networking library that I’m using to build an ECS framework on top of regular Unity EC. Why not use dots? Well, I hate the restriction of using only blittables for component data, I want to have access to the already existing ecosystem of Unity packages, and the biggest is that I am designing it for networking first. It’s slow going (I’m a dad and I have a full time game dev job), but I’m making good steady progress. My serialization library currently features composition, quantization, no reflection, and no garbage collection. I plan on releasing the first version under the MIT license hopefully in the next couple months. I have a prototype that I’ve been building to test my stuff. Check it out it’s only 30s. https://youtu.be/p4v3ZnS2KBM https://youtu.be/p4v3ZnS2KBM
    - prox 5y ago
      Your demo reminds me of a problem that M&B 2 Bannerlord had, they created a destructable castle, but couldn’t get performance network enough to sync the destruction (bricks and stone walls) to all players.
      - jbluepolarbear 5y ago
        Networking games is hard. It’s what I do for work and it’s an iterative process. If you’re interested in the subject of physics and netcode I’d recommend: https://gafferongames.com/post/introduction_to_networked_physics/ https://gafferongames.com/post/introduction_to_networked_phy... If your want a very deep dive and very technical, I’d recommend: https://fabiensanglard.net/doom3_documentation/The-DOOM-III-Network-Architecture.pdf https://fabiensanglard.net/doom3_documentation/The-DOOM-III-... A lot of good resources at the bottom of the pdf too.
EamonnMR 5y ago
I've played maybe one game with entities in that count range (Planetary Annihilation) and I think you'd need a lot of low level engine work for something like that anyway (since it's doing all sorts of neat stuff with interpolation, weird coordinate systems, networking, etc.)