2 ms·

My experience here is very limited, but at least in the Rust world, some ECSs seem to make component dependencies explicit, partially to support scheduling para

My experience here is very limited, but at least in the Rust world, some ECSs seem to make component dependencies explicit, partially to support scheduling parallel systems execution. That is, if there are two systems where neither system writes any component that the other accesses, they can run in parallel. Is that not common in general? Godot usually gets a lot of praise of HN and elsewhere, probably rightly so. But I got the same weirdly defensive vibes from reading the article. Performance is the strawman used throughout: claiming you don't need that many objects anyway, claiming that there design is "higher level" -- without ever really explaining what that means. I know from other contexts that the real problem with deep inheritance hierarchies often is code duplication, you simply can't solve the diamond problem. Good job pointing out examples of that.

Athos_vk 6y ago
It's indeed a common approach that they list their dependencies so you can build runtime DAGs for multithreading, but my main point is that within one system dependencies can be selected at will (I believe Unity allows to just change these at runtime as well). In the end they just get the entire gameworld fed in and then select what they need. If you take something like writing unit tests, you basically have to mock the entire gameworld because these dependencies could change, even if only theoretically. I struggle to find a good way a generic approach of DOD can prevent that. In general it's also very hard to get dependencies done right. I think Unity does it well, but from what I saw some years ago it's one of few (for implentations that are public). Also not surprising considering Mike Acton seems to play a significant role in that. Yeah their arguments on performance are an even worse aspect of the article. It's clear that no game or simulation of significant scale has been built with Godot.

Athos_vk 6y ago

It's indeed a common approach that they list their dependencies so you can build runtime DAGs for multithreading, but my main point is that within one system dependencies can be selected at will (I believe Unity allows to just change these at runtime as well). In the end they just get the entire gameworld fed in and then select what they need. If you take something like writing unit tests, you basically have to mock the entire gameworld because these dependencies could change, even if only theoretically. I struggle to find a good way a generic approach of DOD can prevent that. In general it's also very hard to get dependencies done right. I think Unity does it well, but from what I saw some years ago it's one of few (for implentations that are public). Also not surprising considering Mike Acton seems to play a significant role in that. Yeah their arguments on performance are an even worse aspect of the article. It's clear that no game or simulation of significant scale has been built with Godot.