Show HN: Interactive ECS Systems/Component Explorer for Cities: Skylines 2 (captain-of-coit.github.io)
Recently I've been diving into doing mods for Cities: Skylines 2, which been very interesting as it's one of the first games that is using ECS and that I also have a deep interest into. I've mainly used ECS via Bevy before, but this time it's Unity, but many things still work the same way.
In order to help myself and other modders to navigate the ECS Systems and Components from the decompiled code, I created this interactive D3 graph.
You can click on nodes to "navigate" to that system/component, and once you're zoomed in a particular System/Component, you get a sidebar with more details. Ctrl+click also removes nodes in case you want to temporarily filter something.
This is, in short, how it works:
1. A C# program extracts information from decompiled C# code: https://github.com/Captain-Of-Coit/cs2-ecs-explorer/blob/mas...
2. The program outputs that info as JSON: https://github.com/Captain-Of-Coit/cs2-ecs-explorer/blob/mas...
3. Render with D3.js: https://github.com/Captain-Of-Coit/cs2-ecs-explorer/blob/mas...
Basically it helps people to navigate the Systems and Components references for the game.
If you're feeling brave, you can also browse the full graph which has something like ~700 nodes and ~1200 links: https://captain-of-coit.github.io/cs2-ecs-explorer/ (it'll take a while to first load)
A big problem was to figure out how to make the D3 not too messy when there are large graphs, and I don't think I've succeeded very well with this, but everything I tried (link distance based on how many connections, clustering based on namespaces and so on) made it even worse.
Happy to hear what you think and what I could do better.
49 comments
[ 3.3 ms ] story [ 171 ms ] threadBoth, at the same time :)
ECS probably been around since at least early 2000s if not even in the 90s.
Edit: Wikipedia puts Thief as the "pioneer" of ECS:
> In 1998, Thief: The Dark Project pioneered an ECS. (https://dev.to/ovid/the-unknown-design-pattern-1l64) The engine was later used for its sequel, as well and System Shock 2.
[0] https://news.ycombinator.com/item?id=28447672
[1] https://patents.google.com/patent/US10599560B2/en
Cart is the creator of Bevy (ECS engine in Rust) and Sander is the creator of Flecs (ECS engine in C)
Assume they lose if they try to enforce it, but don't know of any attempts yet.
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 made but not many games come out of it...
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?
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.
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.
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.
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.
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.
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.
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.
How so? Not sure I love the approach of saying something is "Done Wrong" without pointing to something specific that gives you that impression.
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.
FWIW, I did read to the end of the line, but I parsed that as two separate assertions (with “and that” being a means to introduce the second assertion):
1) it is one of the first games using ECS
2) that you also have an interest in it
Rather than the intersection of:
1) the set of games using ECS
2) the set of games that you have an interest in
Or, expressed another way, it’s this (how I read it):
(it's one of the first games that is using ECS) and that (I also have a deep interest into)
Vs
it's one of the first games that: (is using ECS) and that (I also have a deep interest into)
I suppose I would have written this:
It’s one of the first games using ECS which I have also had an interest in.
I’m fairly certain I’ve almost always seen something like “[of] which” to introduce another qualifier, whereas “and” almost always introduces a new statement that stands on its own (the exception being in more formal contexts where there’s a sentence structured along the lines of “consider such [insert class of objects here] which are both: [this] and [that]”).
I think it’s the “and that” which threw me (and others here who misread you) off.
"The Entity Component System (ECS) is the core of the Unity Data-Oriented Tech Stack. As the name indicates, ECS has three principal parts:
Entities — the entities, or things, that populate your game or program.
Components — the data associated with your entities, but organized by the data itself rather than by entity. (This difference in organization is one of the key differences between an object-oriented and a data-oriented design.)
Systems — the logic that transforms the component data from its current state to its next state— for example, a system might update the positions of all moving entities by their velocity times the time interval since the previous frame"
From https://docs.unity3d.com/Packages/com.unity.entities@0.17/ma...