Because it is one of the 1,000,000 things to pay attention to in game development. Someone or some software probably just made a mistake in setting up its LOD. Or some dynamic LODding code didn't properly cull the LOD0 mesh. Or that code couldn't be finished in time. Or it was something else.
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.
> It's completely normal in AAA games to have a few imperfect and in-optimal things.
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.
you're missing the forest for the badly rendered tree in some E3 showcase that everyone nitpicked to death. Can we not treat this discussion like a Reddit rant, please?
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.
While I tend to agree that there are a few people bashing it just because everyone else seems to be doing it I would also like to ask you to consider that not all the complaints are invalid.
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.
The most common GPU on steam stats is a 3060. The AMD 7800/7700 do 90% and 70% better on benchmarks. So if you have either of those, you're getting nearly twice the FPS that the most common steam user would see.
I have a 1660Ti. I get 40+ fps on 1080p. It's functional. Now, whether it is really any better than the previous generation is the more relevant question in my opinion. There are a few things improved, and a whole lot missing. The performance issues are only a small fragment of the game's issues.
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.
What trade off would you choose between fixing a performance issue which is somewhat avoidable and fixing a game breaking crash bug? Because the latter gets priority and there’s never enough time to fix all of those before launch, let alone work your way up to closing out every last frame rate drop.
I think if you get 100k poly models in your (city builder) game in the first place (for any but the most amazing wonders) your process has failed spectacularly at some point.
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).
It’s speculation based on these mesh sizes being so arbitrary in the game development process and what’s broken being unnecessarily window dressing for gameplay. It’s the kind of thing that could be delayed to the last minute with some simple placeholder.
“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.
> Because it is one of the 1,000,000 things to pay attention to in game development.
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".
This is on par with: “Sure, there’s a raging fire in that corner of the office, but it’s just one of a million things I had to deal with that day. That’s why I didn’t call the fire department, okay!?”
Staying on top of poly count budgets is like game dev 101.
Happen more than you think, despite the absurd metaphor. Maybe there was an inferno in the neighbohood and no time to worry about the fire in the corner of the apartment. Maybe your publisher doesn't care if your house burns down but wants to make money now for their own earnings.
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.
But gamedev usually means, all new faces teams, as the old one quits in lockstep. So it's very likely a bunch of youngsters running around yelling "premature optimization" is the death of all good things. Mistaking that with needing no optimization plan at all until game is almost done.
You're right that this kind of stuff is sort of par for the course. As in other cases, it's indicative of (IMO) a bad development process that they didn't budget the time to polish before shipping. I save my games budget for stuff that is "done when it's done", not rushed out, mostly out of principle.
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.
I get that you can leave a bunch of things unoptimized, as long as it works fine.
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?
So you know the saying “premature optimization is the root of all evil?” Producers love that statement because it removes half of the complaints around work being rushed.
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.
Except there really isn’t a better product to back up these issues. There were some important improvements made to the gameplay, traffic system, certain things were reworked, nicer graphics etc. It feels like an iteration and not a ground-breaking game rhat would justify the performance issues we’re seeing.
The design was iterated, but the game assets are redone almost completely, and the systems appear largely reworked, too. This is evident when you play the game.
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 :)
you call it incompetence, devs call it "publishers told us to ship now". You'd think a technical community like this would sympathize with such mandates given across the industry.
> 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.
So I assume you have a better explanation of the excessively slow G-buffer and shadowmap passes?
Nope. 15 years game industry veteran here. Good game engine engineers focus on performance from day one and will analyse everything top to bottom all the time to make sure the game runs smoothly. This is an example of a company that doesn't have competent engine devs working for them.
What if we’re more charitable and consider that maybe the modelers assumed that they were doing the most detailed models and someone else would be processing them to produce derivatives for lower zoom levels? It’s rare that something like this happens because nobody knew it was a problem but rather that there is a management dysfunction around priorities and resources.
That sounds like a failure to set the right culture in the company, though? I’m not saying that nobody else is to blame in that situation but in general responsibility starts at the top where people are paid enormous sums precisely to handle problems like that.
I mean, you shouldn't be charitable. Those clothes drying aren't 20 subdivision wide because they're detailed. The logs have five sides they don't have all those segments along their length because they're detailed. At absolute best, they didn't go back and fix the topology. At worst those were development assets that were thrown together in 5 minutes and then never replaced.
This doesn't fly with a one man team and not with a 1000. It's just badly done, there's no sugarcoating. Those meshes should never end up in the game files.
>This doesn't fly with a one man team and not with a 1000
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.
random quirks do. this is not random quirks. it's a systematic and expected issue of underoptimisation caused by releasing a product before it was even slated to be ready. one bad mesh is not the issue, it's never the issue. we're talking of thousands of terrible meshes and a near-total lack of basic optimisations applied at the last stage of development to most games. the manpower was not enough to release within the deadline, likely due to running into a lot of technical difficulties working with unity. 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. poor performance was not only expected, i'm certain that every member of the team saw it as the only possible outcome.
I'd call 4 examples of "this needed LODs" random quirks in the grand scheme of things. It's not like every single mesh is 100k vertices. Grossly underoptimized, yes. But the devs pre-empting their announcement with "we're not satisfied" tells me they were too busy slaying dragons to worry about the annoying barking Chihuahua in the room.
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.
It's pretty clear that with the performance that the game has it's a lot more than four models with bad LODs. They would probably have identified that issue within days. There's likely a more fundamental issue, not only with the technology but also with LODs for most detail models. These are only examples since you can't list every model out of hundreds being rendered.
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.
Sure, more than 4, less than however many assets there are in the game. I mostly want to emphasize that a systematic issue implies that this was an acceptable development pipeline, which I doubt any engineer on the team would say.
>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).
The systematic issue refers to the fact that it is both prevalent and a result of the early release, more a systematic issue of modern AAA development studio organisation than a development practice by developers.
I'm solodeveloping a game, and there's no fucking way a 100,000 vert mesh is getting in the game without a LOD. My game is running on the Quest 2 at 72 fps stable
sure, it's easy to catch major hiccups when one person has 100% knowledge base. Not so much when 30 devs each have different responsibilities and the optimizer guy is drowining in other fires.
But… why?