31–40 of 50 posts
As a game dev, I'm starting to feel like ECS isn't the right paradigm. Seeing this 700 nodes graph with all the dependencies screams technical debt and domino effect (changing one small system would impact a lot of other ones). Not sure if there's anything better right now, but seeing everyone copy what Unity did feels like there isn't a ton of innovation in how to build gameplay systems. Lots of engines are being ma…
As a game dev, I'm starting to feel like ECS isn't the right paradigm. Seeing this 700 nodes graph with all the dependencies screams technical debt and domino effect (changing one small system would impact a lot of other ones). Not sure if there's anything better right now, but seeing everyone copy what Unity did feels like there isn't a ton of innovation in how to build gameplay systems. Lots of engines are being ma…
> changing one small system would impact a lot of other ones This is a misunderstanding. _Components_ don't depend on each other, nor do they (or should they) access each other, because they don't contain any logic. _Systems_ access components.
One of the nice things about being able to graph this dependency tree at all is that it means execution can be parallelized easily as long as there aren't too many undiscovered implicit dependencies.
Similarly components don't depend on one another but many systems depend on components so changing those often isn't free either.
Earlier quoted context omitted.
> (changing one small system would impact a lot of other ones) Would you not expect that in a sim game though? I mean, why would you have a nice tree when everything interacts with almost everything?
Of course, but their use of the ECS seems excessive. I'd have expected a few big systems for each area of the game, clicking on Game.Simulation.AdjustElectricityConsumptionSystem for example reveals quite a lot of things that could be within one system. I bet the current design passes and queries data all over the place, very redundantly.
Earlier quoted context omitted.
Of course, but their use of the ECS seems excessive. I'd have expected a few big systems for each area of the game, clicking on Game.Simulation.AdjustElectricityConsumptionSystem for example reveals quite a lot of things that could be within one system. I bet the current design passes and queries data all over the place, very redundantly.
I assume they've split it out so much to better allow smaller systems over larger ones. In theory this should allow better access patterns, for instance for the electricity, the AdjustElectricityConsumptionSystem has to consider each building and the information about it, but the ElectricityFlowSystem only has to consider the edges for electricity flow. This means the ElectricityFlowSystem can be access only the data…
Although probably once you're at that stage of optimizing gameplay code it's also probably time to write something specific for the problem rather than trying to fit it into a general purpose framework.
> it's one of the first games that is using ECS what do you mean by this?
> > it's one of the first games that is using ECS and that I also have a deep interest into
> Both, at the same time :)
> ECS probably been around since at least early 2000s if not even in the 90s.
https://news.ycombinator.com/item?id=38703926
I guess if at least two people asked this question, my initial description wasn't clear enough that it was supposed to be a AND statement.
As a game dev, I'm starting to feel like ECS isn't the right paradigm. Seeing this 700 nodes graph with all the dependencies screams technical debt and domino effect (changing one small system would impact a lot of other ones). Not sure if there's anything better right now, but seeing everyone copy what Unity did feels like there isn't a ton of innovation in how to build gameplay systems. Lots of engines are being ma…
Imagine all the various features of the game, it's a city simulation game that currently scales up to a population about 1 million before even 32-core CPUs start to suffer.
You'd have a large code base creating this, no matter the approach.
The game also relies a lot on modding to add additional content from the community. This used to be a big hassle when the first game relied a lot on inheritance. Mods broke each other frequently.
With ECS and this (relatively) decoupled design, modding becomes a lot easier as it almost provides hooks out-of-the-box for you to add your own functionality.
> Not sure if there's anything better right now, but seeing everyone copy what Unity did feels like there isn't a ton of innovation in how to build gameplay systems
ECS isn't really a Unity innovation at all, it has existed for longer than Unity Engine.
Personally, even if ECS had similar performance as the more traditional approaches, I'd still use ECS for my own games as it's just easier to write and reason about a decoupled ECS design, compared to the alternatives.
But then I've mostly used ECS via Bevy, rather than Unity ECS, maybe Unity ECS is a bit more verbose and gets in your way, compared to Bevy ECS.
Earlier quoted context omitted.
Of course, but their use of the ECS seems excessive. I'd have expected a few big systems for each area of the game, clicking on Game.Simulation.AdjustElectricityConsumptionSystem for example reveals quite a lot of things that could be within one system. I bet the current design passes and queries data all over the place, very redundantly.
I assume they've split it out so much to better allow smaller systems over larger ones. In theory this should allow better access patterns, for instance for the electricity, the AdjustElectricityConsumptionSystem has to consider each building and the information about it, but the ElectricityFlowSystem only has to consider the edges for electricity flow. This means the ElectricityFlowSystem can be access only the data…
Not only that, but modding becomes easier as well, and modding is a big part of the game.
If all the electricity stuff was jammed into just one System, it would be harder to modify just some parts of it while remaining compatible with other mods modifying other parts.
Instead, Systems are broken down into relevant parts so modders can add easier to it or replace whole Systems, without replacing ALL electricity code.
Anyone know if mods in general work when running CS2 inside Steam on Linux? It's kinda hard to search for since there are a lot of Cities: Skyline results mixed in.
As a game dev, I'm starting to feel like ECS isn't the right paradigm. Seeing this 700 nodes graph with all the dependencies screams technical debt and domino effect (changing one small system would impact a lot of other ones). Not sure if there's anything better right now, but seeing everyone copy what Unity did feels like there isn't a ton of innovation in how to build gameplay systems. Lots of engines are being ma…
PS: I'm kinda surprised that a shipped Unity game contains that much human-readable information for reverse engineering. Is there no symbol stripping in .NET?
As a game dev, I'm starting to feel like ECS isn't the right paradigm. Seeing this 700 nodes graph with all the dependencies screams technical debt and domino effect (changing one small system would impact a lot of other ones). Not sure if there's anything better right now, but seeing everyone copy what Unity did feels like there isn't a ton of innovation in how to build gameplay systems. Lots of engines are being ma…
700 nodes with random interdependencies is better than 700000 objects with random interdependencies though ;) PS: I'm kinda surprised that a shipped Unity game contains that much human-readable information for reverse engineering. Is there no symbol stripping in .NET?
I've experimented with ECS before and it allows for much nicer decoupling.