Not trying to criticize anyone, just curious about the process.
When I report a bug that the developer acknowledges, why does it take so long to fix it? For example, 2 months ago I report a bug where the characters weapon disappears in this very specific area. 2 months later, after several updates, the bug is still there and the response I get is, “we are still trying to find a fix for this”.
In: 7
Frequently, because all the ways they’ve found so far to fix it break something else instead.
And it’s not necessarily the highest priority bug they’re currently working on.
They might also have very few people working on that aspect of the game depending on what it is.
Developers get a lot of tickets to fix issues, and they need to be prioritized, because they’re not able to fix all of them at once. Generally, there are two things you’ll look at when prioritizing a bug: 1. does this have a huge impact and 2. will this be difficult to fix.
Stuff that has a huge impact will get prioritized first, and for smaller issues, the ones that are easy to fix tend to get done before others. In your case, there are probably other bugs with higher impacts that they are investigating, or it would be incredibly difficult to fix that bug and the developers don’t think it’s a big enough deal to prioritize it.
Real answer: how long did it take you to program “Hello World!” In JavaScript?
In no particular order: reproducibility, cost, and priority ranking.
Reproducibility – while not apparently applicable to your specific example, sometimes problems appear due to unknown conditions. If you don’t know how to make it happen, you can’t get to figuring out what causes the issue, and then fix it.
Cost – this issue may take a lot of resources to fix. It may not be a simple issue, a code change may ripple into other aspects of the software. And then you’ll have to do regression testing, making sure that everything still works after the change.
Priority ranking – ties into cost, there can be dozens or hundreds of open bug reports. There are only so many people, and so many hours in the day, that you have to be choosy which issues you want to devote the time and money towards. If it’s considered an issue you can live with – maybe it only pops up very rarely, or under odd circumstances – then it’s not as important as something that could impact gameplay or crash the system.
The end result that you see can be really obvious, but the exact chain of code that actually causes it can be really difficult to pin down. Knowing the exact area it’s happening definitely narrows it down a lot, but it may not be narrow enough to be worth the dev time of just trudging through the code.
A really important step of debugging is finding out how to reliably reproduce the bug. Not just “it happens in this area”, but a step by step process of “do x, y, then z” that causes the bug 100% of the time (or at least very reliably).
Also, whatever is causing the bug might be important for some other part of the code. So fixing the bug well cause more bugs, and there’s just a chain of bugs that need to fixed.
Code is held together with duct tape, remove some tape to fix the bug and some other stuff might fall apart making the game unplayable.
Measure a bug on two scales: [Severity (how bad the bug is) and Priority](https://i.stack.imgur.com/21aRl.png).
Taking from your bug description – Severity is low, because as I understand it’s a visual issue?
Now how many people it would affect – also low, because it happen in very specific area.
It’s a lowlow bug that go into backlog to be fixed “when we will have time”.
[This story] (https://kotaku.com/outer-worlds-developer-finds-bug-that-caused-companions-1840416626) talks about a particularly prevalent bug in The Outer Worlds in which follower NPCs were dying even when they should have been immune to death – the QA team had to spend a lot of time testing basically every possible way to kill an NPC and find out what might have caused the follower NPC’s immunity to death to not happen. The end result was a bit of weirdness that I can’t imagine how they thought to test it, but if a follower was climbing a ladder when you started talking to another follower, something didn’t trip when they reached the top of the ladder and so that first follower just… kept climbing… until they died for being too far out of bounds (which was likely a hard check to get them back in bounds of the game).
Now, that is a game that that team, from my understanding, did the bulk of the coding for. That isn’t always true. Particularly for visual issues, it likely is due to a weird edge case or quirk of the rendering engine, which I am confident saying 99% of game developers didn’t code themselves.
So even if it is highly reproducible, it might be hard to track down what part of the code is actually interacting weirdly.
1. Software is complicated. Especially software written in a rush, for as little money as possible. Just because the symptom is obvious doesn’t mean the problem is obvious. And even if you know the problem, a proper fix isn’t always obvious. I might fix y our problem and then find out that some *other* problem is happening.
2. priorities – someone at the company is probably in charge of prioritizing bugs. for whatever reason, they may have decided your bug is less important than a bunch of other bugs. or it might be rated important but also time consuming to fix, so they are working on fixing a bunch of equally important but quicker to fix bugs.
3. if the bug is in a PC game, both of the above points get even more tricky because the bug might only impact folks on one particular combination of video card, CPU, memory, motherboard, etc. So it’s harder to troubleshoot, and if it only impacts folks with a weird set of hardware, it’s not going to be high priority.
Obvious to the user is not always an obvious cause and ever farther removed is a solution. Like your weapon disappearing.:A dev needs to know if it just isn’t being displayed, is non-functional, is removed from the player or from the game entirely. And then they need to know what the area has to do with that. And the dev needs to track down the exact internal chain of events that leads to the disappearing. Is it the loading of the new area, the leaving of the old one, is the character changed, are the resources reloaded? etc. Once you’ve got it really nailed down to a specific event with a specific state you can start stepping through the code watching for the weapon’s disappearing behavior. And finally you see that the size of the list of weapons is limited in this area differently than others and this particular weapon was the last in the list so it was dropped. So you resize the list and now you can’t enter the area at all without the game crashing so you revert and decide to solve it later.
Latest Answers