Maybe CO should just straight up hire Mr. Huhtala if they lack the in-house acumen to produce the insights he provides in this outstanding article. That said, they might already know everything he describes in his blog post and might simply have run out of time to implement the improvements. In that case, the likely culprit would be pressures from management and/or the publisher to release now, ahead of the important Christmas season. Whatever the case may be, delaying the game would have been the right call. I remain cautiously optimistic but will keep waiting to purchase the game.
The devs knows, but management decided to push it. It’s always like that.
To be fair, the game is playable if you turn off certain settings, and they did warn about performance issues before launch. But still, I think the current steam reviews of Mixed is very fair. They shouldn’t have launched it in this shape.
They took a gamble on a new tech and it didn’t pay off as well as they thought.
It will probably be an amazing game in 2024 though.
I am guessing ypu never worked in software development?
they most likely know the issue is and even have a ticket sitting in their backlog about it, but it’s probably not a quick fix or it was simply deprioritized by management.
Man, now I even feel a bit bad for them. C:S2 needed that CPU issue fixed, else people would’ve never been happy, it was the biggest issue of the first game and they were right on prioritizing that.
Now with these issues, they simply should’ve got more time and fix them before release, because most consumer probably don’t care how much devs struggled. Their team isn’t that big, so it’s totally understandable that they didn’t switch engine.
A lot of features that would have helped, from say the recent Unreal Engine feature list, are also very new, people shouldn’t forgot that game development starts many years earlier. And you also don’t know if another engine could’ve handled the CPU issue side any better and then C:S2 would’ve been dead from the start.
At least now I’m looking forward to them fixing the LOD issues and this would show them they gambled correctly, although released too early.
There’s a lot of detailing what the author did to try to investigate the issues. That’s interesting, but if one just wants what he found, one can skip to the end, which summarizes the results:
So why is Cities: Skylines 2 so incredibly heavy on the GPU? The short answer is that the game is throwing so much unnecessary geometry at the graphics card that the game manages to be largely limited by the available rasterization performance. The cause for unnecessary geometry is both the lack of simplified LOD variants for many of the game’s meshes, as well as the simplistic and seemingly untuned culling implementation. And the reason why the game has its own culling implementation instead of using Unity’s built in solution (which should at least in theory be much more advanced) is because Colossal Order had to implement quite a lot of the graphics side themselves because Unity’s integration between DOTS and HDRP is still very much a work in progress and arguably unsuitable for most actual games. Similarly Unity’s virtual texturing solution remains eternally in beta, so CO had to implement their own solution for that too, which still has some teething issues.
Here’s what I think that happened (a.k.a this is speculation): Colossal Order took a gamble on Unity’s new and shiny tech, and in some ways it paid off massively and in others it caused them a lot of headache. This is not a rare situation in software development and is something I’ve experienced myself as well in my dayjob as a web-leaning developer. They chose DOTS as the architecture to fix the CPU bottlenecks their previous game suffered from and to increase the scale & depth of the simulation, and largely succeeded on that front. CO started the game when DOTS was still experimental, and it probably came as a surprise how much they had to implement themselves even when DOTS was officially considered production ready. I wouldn’t be surprised if they started the game with Entities Graphics but then had to pivot to custom solutions for culling, skeletal animation, texture streaming and so on when they realized Unity’s official solution was not going to cut it. Ultimately the game had to be released too early when these systems were still unpolished, likely due to financial and / or publisher pressure. None of these technical issues were news for the developers on release day, and I don’t believe their claim that the game was intended to target 30 FPS from the beginning — no purebred PC game has done that since the early 2000s, and the graphical fidelity doesn’t justify it.
In even shorter form:
Highly-detailed models coupled with a lack of lower-level-of-detail models for viewing at a distance.
Limited culling (avoiding drawing things that aren’t actually visible onscreen).
Some gambles made on external work-in-progress software that turned out not to be ready at release time, forcing the developer to implement their own solutions.
I haven’t been following the issue or played the game, but to me, it sounds like they could probably put in short-term fixes for some of that – if imperfectly – without a lot of trouble.
I don’t know how much time the typical player spends zoomed in in the game, but if it’s like C:S1, I imagine that the answer might be “not very much”. Frankly, I have a number of games where the developers have spent time modeling and building rendering for stuff that I never look at, because I’m spending time looking at the high-level overview. Cold Waters, a submarine sim, could completely eliminate the 3D rendering portion of the game, all of the 3d models, and it’d have little to no impact on how I play the game, because the only thing that particularly matters for playing the game is a 2d sensor plot and some insets showing numerical data. This is what I’m virtually always seeing when playing the game, whereas the promo screenshots and video mostly show the 3D views. I don’t know what the situation is for C:S2, but frankly, I didn’t really ever pay attention to individual characters in C:S1; I’ll only click on a person to get an idea of what many people in the city might be experiencing with travel difficulties. I don’t really care what they look like. It’s vaguely-nice to have little specks crawling around, makes the city look a little more realistic and maybe gives some idea of where congestion might be, but it honestly doesn’t matter that much, because I’m looking at the city from high altitude. I suspect that C:S2 would be completely playable if they at least had the option to render every drawn character as an untextured rectangular solid, maybe drawing the closest one or two if zoomed in.
I don’t care much about three effects (depth-of-field, motion blur, and volumetric effects) that he cited as having poor performance (on his system, things which he said disabling caused rendering the main menu to go from under 10 FPS to about 90 FPS). Frankly, the depth-of-field blur in C:S1 I turned off because I didn’t like the look of it. Just turning those off by default, at least on lower-end systems, probably makes sense and shouldn’t be hard.
Putting in lower definition models is a technically-straightforward approach, though it’s going to cost modeler time. But if you are having your system run at 10FPS, that’s unplayable. I’d rather have a game that has buildings that are just untextured, opaque, flat polygonal boxes in the distance – especially if they intend to keep working on the game, since “ugly but playable” is preferable to “unplayable but pretty”. That’s one LOD level, and I imagine that the engine shouldn’t have any problem with that.
As a stopgap fix, I’d personally rather have that and then have patches go in over time to prettify things than to be running sluggishly and waiting for patches to improve performance. Plus, benefit is that you at least have the option to run the game on a very low-end system. Maybe someone wants to run the thing on a laptop without a discrete GPU or something.
Now, is that acceptable to other players? I don’t know. Maybe some people are really upset if they get a game that has pretty screenshots and on their system, it instead has stuff on par with placeholder assets. But I can say that for a city simulator, I’d definitely rather have something that runs smoothly than something flashy. For me, the interesting bit of a city simulator isn’t sitting there admiring the view down a street, but in figuring out how various mechanics interact with each other.
When I look at screenshots of the game, they seem to usually be at street level, looking down the thing. And yeah, it’s all highly-detailed and such, but that’s not how I’ve ever played a city simulator.
First up, meshes and textures are two different things. The former, what this is about, is the 3d model, the latter is the the paint on them. The resolution of the texture usually has no impact on performance as long as you don’t run out of VRAM.
On to the actual question: To a certain degree, yes, there’s usually a settings that changes how aggressive the LOD system is at reducing and what’s the max level of detail is. However, even on ultra most* modern games will still employ some sort of LOD, because rendering everything at max is just so ridiculously for almost no benefit, that it’s just wasteful.
*: Some games can get away without a LOD system, for example a top-down game with a fixed camera distance. There you can directly optimize the meshes based on how far they appear from the camera.
This tracks with my experience using Unity in the past. They like to add a bunch of half-baked new features while simultaneously deprecating old ones that worked fine. Which means you have to choose between using a “worse” feature you know will no longer be supported or using a “better” feature that’s not fully finished yet. When your release window is 2+ years out it is really hard to make that decision.
And they do it directly in their stable builds and label individual features as “beta” rather than keeping them in a separate beta branch which is remarkably stupid. It makes them seem like the features are ready for production when they’re clearly not.
Yup. I’m just a hobbyist gamedev, but the way they handled these new features made me wary of Unity as a whole, even before their recent licensing fiasco, although that one was the last straw for me.
Every time I checked out a new feature it was barely working and badly documented. Worse yet, these things often didn’t change even after they’ve moved on to the next shiny new thing, leaving the old thing in development hell.
So yeah, in hindsight it’s shouldn’t be surprising at all that even one of the biggest Unity devs have fallen into that trap and botched one of their releases at least partly due to Unitys behaviour.
Really wish this level of sloppiness was more well known before the unity debacle. Feels like people didnt want to shit talk the unreal competition before they blew their own foot off.
As if an unfinished release wasn't bad enough, the whole 30 FPS justification just left a really bad taste in my mouth. Given their prices for their games + DLCs this should have not been necessary.
Tldr: “Colossal Order took a gamble on Unity’s new and shiny tech, and in some ways it paid off massively and in others it caused them a lot of headache.”
Said new tech made the game much lighter on the CPU and able to simulate things with much more detail, but Unity never integrated it properly with everything else in the engine, so Cities’ devs had to basically fill in a lot of gaps, with a lot less expertise in engine making. It turned out understandably inefficient.
Add comment