Why Cities: Skylines 2 performs poorly

Analysis showed that most frame time was lost due to lack of LOD levels and culling - causing the engine to render insanely high amounts of polygons that weren't even visible on screen.

In conclusion it seems that using the brand new engine feature DOTS (which is a perfect match for this game), successfully solved the CPU bottlenecks the first game had.

But because of Unity's DOTS HDPR integration still being WIP (with several key features being experimental/missing) - they had to implement a lot of stuff on their own (including, but not limited to culling), which cost development time and caused the game to be not quite ready at release (explains missing LODs/optimization).

It was expected, yes. It does not mean they weren't trying to fix it in the 11th hour. I woildnt be surprised if some core tech was unfinished or inadequate that lead to this.

>instead of going into valve time, they released it anyway, which means that you skipped the entire polish and optimisation part not only for the game itself but for half the engine as well.

Yup, welcome to game development when you have deadlines and no benevolent (or at least, apathetic) dictator paying your bills. It's unfortunate that we can trace this back to the 80's with ET, but this is simply the business realities. Game code isn't mission critical (and until recently, does not care about maintainability), and also isn't what sells the product.

So it never gets the time to be cultivated like other indistries. And people still buy anyway. It's a two way street of apathy and every publisher hopes it can slip under the cracks and not become the next Superman 64. Most manage to slip.

There's not much you can do about it with the current publishing structure, where most funders don't work in nor care about games. And the ones that do still see their money draining whenever the talk of delays come up. That won't be solved except with time as more industry trailblazers retire and shift to management (remember, Todd Howard is only in his 50's. Gabe and Kojima are 60. So many pioneers are still well under retirement age). Or for more truly indie teams to arise and learn how to scale up projects while staying lean. The latter is what I hope to do.

Every project managed by a dedicated servant-leader Six Sigma Kanban certified Scrum ninja-coach project has been a bureaucratic shitshow, with constant cargo culting to agile priniciples and forced ceremonies.

For example, Godot isn't really build around ECS, but the idea of servers which are mostly autonomous game subsystems that can process their area of expertise (rendering, physics etc.) mostly independently, and are loosely coupled to the general game logic.

ECS architectures originate in the PS2/PS3 era, when CPUs were awful. Tiny caches, horrible branch mispredict penalties, slow memory, fragmented memory spaces and lack of a random access storage forced developers to build their games around predictable memory access patterns, that in general resulted in streaming architectures, where data necessary for the game data to be streamed in tiny chunks to be processed.

While generally this is good practice even nowadays, with the advent of superfast CPUs with amazing speculative execution, great branch predictors, and tens of megabytes of cache, this is no longer strictly necessary, especially considering that most modern games haven't really increased that much in terms of stuff going on on the screen compared to say, a decade or two ago. It's still uncommon for the player to fight more than a dozen dudes in an action game.

And in games with thousands of things on screen at the same time, often specialist logic and handling is necessary.