Sigh… You conveniently deleted important parts of my comment, such as “at least with low-graphics settings” and “adjust for a few years of hardware inflation”, and completely ignored the fact that I am talking about cases of abnormally bad performance compared to entire categories of games. The straw man you’re arguing against is not what I wrote.
Given that they’ve developed a faithful and fairly wide-ranging representation of D&D 5e, I’m willing to bet that ended up being a lot more involved than their own proprietary system.
That game was just one example, but since you seem interested in singling it out:
Turn-based game rules cannot explain the awful graphics performance that game has, even at idle, on some systems. (Not even D&D 5e, which I happen to know in detail.)
Graphics engine enhancements might explain it, but in that case, the developers should have included options to disable those enhancements.
I haven’t reverse engineered the code, but some of the behaviors I’ve seen in that game smell strongly of decisions/mistakes that I would expect from a game that was rushed, such as lack of occlusion culling. Others smell like mistakes that are common among programmers who haven’t yet learned how to use the graphics APIs efficiently, such as rapid-fire operations that should instead be batched. Still others could be explained by poor texture and/or model scaling techniques. As a software engineer, the bad performance in this particular game looks like it could come from a combination of several different factors. None of them are new in this field. All of them can usually be avoided or mitigated.
In any case, the point is that none of that analysis matters for the sake of this discussion, because a community with experience using products doesn’t have to be experienced in building them in order to notice when something is wrong. It’s not fair to categorically dismiss their criticism.
(Thankfully, the Baldur’s Gate 3 developers haven’t dismissed it. Instead, they are working on improving it. Better late than never.)
I think it is. Note that I wrote 30km/h, not 200km/h. (In case you’re American, 30km/h is about 18mph.)
The Last of Us Part 1 is another example. We know it should run better on our hardware (at least with low-graphics settings) because we have already seen the original game run far better on less capable hardware. Yet this one fails to do so even at the lowest possible settings.
Even Baldur’s Gate 3, despite being otherwise wonderful, has some glaring hit-and-miss performance issues (think 8 fps at 1080p) that show up on hardware that can handle similar games easily. You don’t need to be a software engineer to compare it to Divinity: Original Sin 2, adjust for a few years of hardware inflation, and have a rough idea of how it should perform at moderate-to-low settings.
I see people upset because the car isn’t a masarati,
I don’t doubt that those people exist, but I believe they are outliers. Most of the complaints I see about underperforming games in the past year or so are from people with very reasonable expectations. If most of the gripes you’ve seen are from teeth-blaming Masarati-entitled loudmouths, I suspect it has more to do with the forums you frequent than anything else.
To be fair, one doesn’t have to be an automotive engineer to deduce something is wrong with a new car that struggles to reach 30km/h while most of the others exceed 100km/h with ease.
(This is the first I’ve heard of anyone blaming teeth, though. That’s a bit strange.)
Yes, exactly. Or if a loud noise outside keeps you from hearing something important. Or if the voice actor mumbles. Or any number of other things that happen in real life.
If you can store player decisions long enough to assemble a cut scene once, you can store them long enough do it again. The decision tree is already there. It’s not difficult or expensive.