Earlier quoted context omitted.
Gothic has always been a niche franchise, and G3 was poorly received not because of bugs, but because of bad worldbuilding (orcs speaking human language, magic runes disappearing, a powerful kingdom getting wholly conquered in basically no time, pretty small open world) and uninteresting story compared to previous titles. Sure it did have bugs, but so did G1 and G2. And that one AssCreed game where people's heads dis…
> Gothic has always been a niche franchise, and G3 was poorly received not because of bugs, but because of bad worldbuilding (orcs speaking human language, magic runes disappearing, a powerful kingdom getting wholly conquered in basically no time, pretty small open world) and uninteresting story compared to previous titles. This is just not true. Gothic 3 is still pretty alive in terms of modding and improvement prec…
A fraction of G2's modding scene. And the reason is even after all the bugfixes and community patches, people still overwhelmingly prefer G2 over G3.
> You equal success meaning that players don't get care about bad things in a game. That's just a way to reductive view.
I equal success to financial success, because we're talking why game programmers are paid less, and the reason is (partly) because code quality has next to no impact on sales. If people still buy your hame despite the bad things about it, then it's a financial success, and game studios exploit this fact to the extreme.
> Nice trying to put words in my mouth. This is about good and bad developers.
I was replying to this part: "Besides bad code does not only lead to bugs. It can lead to bad gameplay, bad performance, missing features, slipped deadlines." My intention was that no, generally it's not true that bad code leads to missed deadlines. Slow coding, yes. Bad coding, no. Good programmers are valuable to game studios not because they can write good code, but because they write bad code faster. Which is reflected in lower salaries compared to other software products where writing good code actually matters and where salaries are higher.
> Not every millisecond of latency is specified in game design docs. Most of gameplay is designed by feeling.
Not every millisecond matters for the feeling (unless you're making a fighting game but that's why I said rarely, not never). Usually performance issues in gameplay can be masked by increasing timing windows or by the eternal excuse of git gud (usually, not always). In general, the gameplay of the vast majority of games is simple enough that with modern tools, any half decent programmer can implement any feeling the designer aims for, with varying amounts of noticable issues. Sure, there are exceptions, but exceptions don't shape salary trends.