As counterintuitive as it sounds, it turns out video game consumers don't care much about the actual computation either. Most games are riddled with bugs, and it has next to no impact on sales. Rather, having weird, even embarrassing bugs can make players look at the game more fondly. Skyrim is one of the best selling games ever. Ostensibly it's about fighting dragons. But "Skyrim moment" does not mean an epic battle with a dragon. It means said dragon flying through a goddamn castle, then getting stuck on a single tree and disappearing into the ground, and still hitting you with fire breath somehow.
Buggy games have destroyed franchises. Gothic 3 being a prime example. Contrary to the memes skyrim is not even close to the worst offenders in terms of bugs. Besides bad code does not only lead to bugs. It can lead to bad gameplay, bad performance, missing features, slipped deadlines. A things users care a lot about.
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 disappeared leaving just eyeballs behind, which still sold crazy numbers. Or the famously bad Cyberpunk 2077 launch, where bad means millions of copies sold in first 2 weeks, not even counting preorders. Or countless other examples.
Most players care about performance even less than they care about bugs. Basically every AAA game nowadays is criticized for piss poor performance and not having the looks to justify it. They're still massive successes.
Usually, it's good code that leads to missed deadlines, not bad code. It literally takes more time and effort to write good code. Gamedev lives on 3-year cycle, that's not enough time for code debt to start causing problems.
Bad gameplay... yes, that can be actual problem. But it's rarely due to a single bad line of code, or even ten thousand bad lines of code. In most games, gameplay is bad because it was designed to be bad. As in, they had a certain way of playing in mind, and they made the game exactly how they wanted, it's just most players don't find that way of playing fun. No amount of code quality can fix that.
> 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 precisely because the base underneath the bugginess was good. You don't have a good community after 20 years if you have bad bodybuilding and uninteresting story.
> Most players care about performance even less than they care about bugs. Basically every AAA game nowadays is criticized for piss poor performance and not having the looks to justify it. They're still massive successes.
You equal success meaning that players don't get care about bad things in a game. That's just a way to reductive view. You can literally read everywhere how people complain about the bad performance of games. Performance is a standard staple in game reviews.
> Usually, it's good code that leads to missed deadlines, not bad code. It literally takes more time and effort to write good code. Gamedev lives on 3-year cycle, that's not enough time for code debt to start causing problems.
Nice trying to put words in my mouth. This is about good and bad developers. Good developers write better code in the same or less time it would take bad developers. that's literally why they are good developers. Bad developers compound on bad code making progress exponentially slower compared to if you had good developers from the start. The question was never the same developer writing good vs bad code.
> Bad gameplay... yes, that can be actual problem. But it's rarely due to a single bad line of code, or even ten thousand bad lines of code. In most games, gameplay is bad because it was designed to be bad. As in, they had a certain way of playing in mind, and they made the game exactly how they wanted, it's just most players don't find that way of playing fun. No amount of code quality can fix that.
I think you really underestimate how much a gameplay programmer can influence the gameplay. Not every millisecond of latency is specified in game design docs. Most of gameplay is designed by feeling. If your developer is not capable of producing good gameplay your game designers can do nothing.
> This is just not true. Gothic 3 is still pretty alive in terms of modding and improvement precisely because the base underneath the bugginess was good. You don't have a good community after 20 years if you have bad bodybuilding and uninteresting story.
You do realize that Bethesda's excuses for worldbuilding are some of the most modded turds out there, right?
> Gothic 3 is still pretty alive in terms of modding
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.
