> (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.

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 it needs and in theory allows for better code cache efficiency (since the loops are tighter and more focused than they would be if they were all in one).

> 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

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.

Splitting things this way is also handy because you can avoid branches, rather than one big loop with lots of conditional branching you have many loops one for each set of elements represented by a branch. Except rather than having to untangle and manage that yourself the granular systems approach make it a more natural way to implement things.

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.

One of the main benefits of doing things with an ECS is composition though so you'd expect more granularity than you'd get in other modular approaches which is of course a tradeoff in some respects.

> I bet the current design passes and queries data all over the place, very redundantly

That's not how ECS works. A system has one or more queries that provide it direct access to the data. There's no passing around of queries or data.

I agree, surely some sparse, distributed representation (that also factors in level of detail) is what will be needed for simulations with truely mind boggling numbers of agents. You’re hitting into a hard physics problem that’s also hitting against the limits of our current models.

> 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.

This graph is also showing system-system dependencies as well as system-component dependencies. I'm assuming that the system-system dependencies are ordering related which implies the dependent systems depend on the results of the previous system either explicitly or more annoyingly implicitly. That's not a bad thing or necessarily avoidable because a lot of things are dependent in games/simulations. If you look at the big graph there are a couple of core systems that must execute first that are probably setting things up for the next tick and then very quickly many fewer dependencies except for core functionality like triggers and pathfinding.

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.

On the flip side, look at all the systems with no dependencies on the left!

> Seeing this 700 nodes graph with all the dependencies screams technical debt and domino effect

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.

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?

From my experience (both writing games and reading released/leak code) it is usually 70000 objects of well intentioned code and then one hundred thousand lines file player.cpp with all the spaghetti logic added just before deadline.

I've experimented with ECS before and it allows for much nicer decoupling.

> 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'm pretty sure Colossal Order (the developers of the game) purposefully makes the game easier to decompile (or at least doesn't employ methods to make it harder) as modding is a large part of the game's community. They want it to be easy to mod.

This is ECS Done Wrong to be fair, one imagines it'd run even worse with another design.

> This is ECS Done Wrong to be fair

How so? Not sure I love the approach of saying something is "Done Wrong" without pointing to something specific that gives you that impression.

Judging by the system & component names this looks to be pretty well designed tbh. There are a lot of systems for sure, but considering this is a city simulator that's kind of expected.