> This mesh of a pile of logs is similarly only used in the shadow rendering pass, and features over 100K vertices.
But… why?
But… why?
It's completely normal in AAA games to have a few imperfect and in-optimal things. Budgets are always limiting, and development times short. Plus, it's a hit-driven industry where payoff is not guaranteed. There are some things you can do (which are usually management-related and not dev-related) to make the game a success, but estimated bookings are rarely on-point. So trade-offs have to be made to de-risk - corners cut where possible, the most expensive part - development - de-prioritized. These are much bigger trade-offs than a single mesh being unoptimized. A single mesh is nothing.
It's a fun fact that this mesh is LOD0, and so is the teeth mesh. But that alone doesn't tank the performance of the game and is probably unlikely to be addressed in lieu of actual performance fixes. The fixation on these meshes in the thread is kind of excessive.
A lot of these comments are quite galvanized so I don't want to add to that - just giving more context.
No, mate, stop. The state of C:S2 is well beyond anything we should accept as "completely normal". It's a defective product that should not have been released. Stop normalising this crap.
Gamedev has many shortcuts, and some things simply fall through the cracks. Some are caught and fixed, some are caught and not fixed, some just aren't caught at all. I imagine it's the 2nd case here; There's a unfortunate large amount of bgs these days caught by QA but not given time to fix before publisher mandates.
The game runs fine and it's really fun. This "controversy" really drives home for me how detached from reality online discourse often is
Case in point: I get 6-10 fps on a 7900XT with the default settings, 17 if I use the lowest preset, all while seeing around 55-ish percent system utilization.
Something is amiss here and the game is definitely not running fine for everyone.
As someone seeing this weird performance issue I wish both sides would focus less on screaming at each other and make it easier to figure out the root cause so everyone can enjoy the game.
It should be better optimized, but calling it "defective" does nothing but make people dismiss your comment.
runs alright for me, too. just alright, but for what it is that's fine.
however it's not really much better than the predecessor, and needs to give me a reason to give up on the HUGE mod community and well documented approaches from CS1.
All this crying when they could have simply returned the product or not buy it at all. Colossal Order themselves warned about the performance before it was even released. There were plenty of reviews that said the same thing.
So to get up in arms about the performance means they are just being exceptionally stupid and entitled, and they should just grow up and stop crying over their toys.
Colossal Order can release whatever garbage they want to. And you can choose to buy it or not, or even buy it and return it (fight for better return policies if you want something positive).
Chances are a nearly complete version of C:S2 was playable and they “broke it” at the last minute by not finishing the optimization process.
“Now you might say that these are just cherry-picked examples, and that modern hardware handles models like these just fine. And you would be broadly correct in that, but the problem is that all of these relatively small costs start to add up, especially in a city builder where one unoptimized model might get rendered a few hundred times in a single frame. Rasterizing tens of thousands of polygons per instance per frame and literally not affecting a single pixel is just wasteful, whether or not the hardware can handle it. The issues are luckily quite easy to fix, both by creating more LOD variants and by improving the culling system. It will take some time though, and it remains to be seen if CO and Paradox want to invest that time, especially if it involves going through most of the game’s assets and fixing them one by one.”
IE: The the game would have looked nearly complete even if none of these meshes where in use. Meanwhile the buildings themselves are optimized.
This really smacks of late asset delivery, which probably happened because delivery dates to the rest of the dev team kept being bumped.
Then, by the time the assets were finally delivered, it was recognized they weren't optimized (as expected), but there wasn't any time to fix that.
Or the same thing with an internal asset team.
Although honestly, you'd think after seeing the performance numbers they would have implemented an "above X zoom level, people / anything smaller than this are invisible" sledgehammer fix, until LOD could be properly addressed.
Better to deal with pop-in than have everything be unexpectedly slow.
Finding objects with ridiculous triangle counts is one of the easiest things to do when you have known performance issues.
If they didn't have time to do the first, easiest chunk of the work, then something was far more dysfunctional than "it's one of a million things to deal with".
Staying on top of poly count budgets is like game dev 101.
I don't think it's uncommon even outside of gaming for modern software to have these sort of "hidden fires". Games just get a lot more conversation and a lot of niche problems as a 3D real time application.
If you aggressively min-max development cost & time vs features, there are big external costs in terms of waste (poorly performing software carries an energy and hardware cost,) end-user frustration, stress on workers, etc., which is how I justify voting with my money against such things.
What I don't understand is - how did they not notice that the performances was horrible even high end hardware? How did they not decide to take the time to investigate the performances issues and find the causes we're talking about now?
Optimization is not done throughout the process and later there’s not enough time. Assets are made with bad topology and it would take time to redo them. Or it would take time to write a tool that retopologizes them automatically.
What I’m saying is by the time it’s “time” to optimize, there’s not enough time to optimize. It happens very commonly. But the alternative is taking development slower to do things right. And you simply don’t get investment for schedules like that in most companies. Not to mention that it’s goddamn hard to do when the execs lay off people, ask them to RTO, and induce serious attrition otherwise. Sometimes the team just can’t settle into a good process as people leave it too much. So you’re between a rock and a hard place — on the one hand: attrition and low morals, on the other hand: a tight schedule. This doesn’t apply to Colossal Order from my knowledge, but it does apply to many AAAs.
There is a problem at the root of this - extremely over-ambitious production schedules as norm. Most other things are symptoms. Most of what I described is a symptom.
The scope of work done for this game was exceptionally large for a company with 40 employees, assuming it was done within the usual AAA timeframe.
They even posted on social media 1 week before launch warning people to expect lower than expected performance, and raised the system requirements.
If companies have to decide between prioritising features that they've advertised, show stopper bugs, and performance, guess which one always takes the back seat :)
This is a cop-out. This doesn't seem like an oversight but rather blatant incompetence. You don't just "not pay attention" to this.
So I assume you have a better explanation of the excessively slow G-buffer and shadowmap passes?
This is a well known property of log scaling.
Or both?
sounds like someone never worked on a 1000 dev team. random quirks either go unnoticed or are de-prioritized all the time. Most are minor, more and more moderate to major ones are getting through. That's definitely a publisher issue.
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.
I really think that the performance and scale indie developers can squeeze out puts AAA developers to shame nowadays, and I really hope that that'll continue to happen. All it takes is time, organisation, and a lot of time.
>I really think that the performance and scale indie developers can squeeze out puts AAA developers to shame nowadays, and I really hope that that'll continue to happen. All it takes is time, organisation, and a lot of time.
Yup, I agree. Indies don't tend to have money, so the budget comes from. Elsewhere. We can already utilize some amazing tools to cut down the time of scaling up environments. Not as much with actor assets. But I don't think it's too far off (more just locked off in acedemics white papers).