> it also does not take significant resources to fix

This is where you are wrong. Even small fixes can destabilize builds. Every change needs code review, testing, a build, release (and possibly release notes). You need to schedule time to work on it, which means prioritization meetings and advocating why this bug should be fixed and not the other large pile of bugs.

Maybe you need to update some unit tests or automated feature tests. Maybe stop by the level designer's desk to make sure there weren't any baked in assumptions about player movement and space. Probably a good idea to chat with a gameplay designer as well to make sure it wasn't intentional (and also to validate that the fix doesn't actually make the game less fun.)

Wouldn't hurt to go to a playtest and mention that it's been changed, see if anyone on the team notices.

Actually, come to think of it, maybe you could put your fix behind a console command! Then you could quickly flip back and forth and see what you like better. But that also means adding a little more code and probably a little more documentation.

Sure, on the face of it you've just changed one arithmetic function. But there is a ton of hidden work and complexity that surrounds that.

As someone who made games for a living, there's a huge amount of unseen work that goes into even small changes. Players consistently underestimate the complexity of even minor fixes.

This this is not some obscure off by one error. You see it in basic game building tutorials. Hell, I will admit to making this mistake on an early game, but only once.

Not making the mistake in the first place should generally prevent the issue even if it was never fixed in any game ever. I am calling it incompetence specifically because it’s the kind of mistake you make when you don’t know what you’re doing.

PS: If detecting and fixing an issue like this is a significant issue for your team, that’s a much larger issue you need to deal with.

I imagine the reason you keep getting asked about the impact of a given bug is because fixing bugs is always (and should always be, given limited time) a value proposition where the time spent fixing has to be weighed against the improvement for the average player.

Even if that were true, fixing the kind of irrelevant bugs you describe would do far more damage to the games industry due to the cost of development (and I’m being generous here because I don’t even believe your claim that running sideways against a wall has ever caused a game studio to go bust let alone cost billions in lost sales).

You seem to believe this notion that it is possible to write bug free code. Which suggests to me you’ve never written anything serious because you’re comments are textbook examples of the Dunning-Kruger effect.

I am describing buggy games as costing billions, rather than suggesting this is the only bug that ever occurred. There are many expensive examples where excessive bugs tanked sales.

The kind of bugs that hamper game sales aren’t the kind of bugs that speed runners exploit - which is what you were originally arguing about.

Sure, some games are released buggy. But even there, blaming the developers just demonstrates how little you experience you actually have with professional software development. You think developers are really that stupid that they don’t know when their own games suck? Usually bad games get released because of financial and/or time restrictions rather than a lack of pride from developers. And often bugs will just be placed on a snag list and prioritised in order of estimated time to fix vs the severity of the bug. Which means many of the bugs you described would just never be financially beneficial to patch.

You keep talking about the monetary impact of bugs while ignoring the fact that software development is a business and thus saving will always be cut where needed. Having your development time prolonged by 12 months to fix bugs most people won’t even see is perhaps the single most expensive and unnecessary way to drive your development.

Frankly I’m astonished anyone would believe development happens the way you idealise, let alone dare to call other engineers incompetent for not writing perfect software.

> It’s not a net savings if it’s costing vastly more money in sales

I’d already addressed that when I said the kind of bugs you’re complaining about wouldn’t have an effect on sales.

> Anyway, cost is really not the driver for most of these issues it’s poorly scoping what can actually be finished in a given time and budget

That is exactly what I’d just said except you’ve overlooked that development time is still an expense.

> I have no idea what your background is in game dev, but it sounds like you don’t understand the overall development process.

Not my current role but my previous job was a lead developer. So I was not only hands on but I also had to manage workflows and budgets. Basically all the stuff you’ve just claimed I don’t understand ;)