Why does game breaking glitches exist in videogames? Take for an instance the new call of duty weopon that shoots and kill thru walls or pathfinder in the new apex legends update were half the screen gets blocked when he uses is ability. Doesn’t the developers test updates before they launch it or whats happening? The changed the cooldown system on his ability and you still somehow manage to make him unplayable and you may think they would’ve noticed that if they were testing.
In: Technology
Hi! I’m a software support specialist, and while I don’t deal with games specifically, I know enough to translate the skillset.
These bugs can happen for a few reasons. First, IMO, the most common one:
The honest truth is that for modern software, there is no testing that can be done in a reasonable amount of time that will test every single possible glitch that the code could encounter. Every time my company releases software, I know personally that there is a team of about 25 people who get paid to go through tests with the software to try and spot bugs before release.
However, they use a small sample of test data and are 25 people running what a software tester thinks of as a regular day’s work.
When the software gets released, thousands of users are trying to do as much work as possible.
Further: our test conditions are known; our corporate office gets our testers a certain model of computer (or one certain Mac and one certain PC) and they test the latest browsers on those clean systems; when the software gets into the wild, it could be competing with any of a hundred different other tasks, it could be sharing traffic with something we’ve never heard of, it could be on hardware we never tested with….
For consoles, there is a lot of stability in the platform: everyone has the same hardware from a performance standpoint, but once you get into PC land that all changes; in theory everything should work, but because of how crazy computing is when you dig down into it.
Next reason: The change *should* have been simple, but wasn’t for whatever reason.
For a hypothetical example, let’s say that at some point in Apex Legends that this ability was supposed to have a proc that had a large screen effect whenever a certain condition was met; it was never implemented and they were on a deadline so they just changed the code around what triggered the proc so that that condition could never be met. Then, the really big problem: someone never wrote that down (or they did but it’s impossible to find these notes when you don’t know to look for them when working on getting some new feature working), and so whatever change to cooldowns that was made also changed other related variables in such a way that that proc condition either *could* be met, or *was always* met; but when it goes to play the video file, it was never made (since the planned feature got scrapped) and that causes a crash or unexpected behavior.
Next reason: Source control mess-ups
The next one is a bit weird if you’re not a coder; if you’re working on a big project like a game, often you will have a lot of people working on it all at once. This could be a nightmare if you were all writing your own files, or if you had to write files one at a time, and so what came to pass was a sort of “check-in, check-out” system; there are a lot of different implementations of this, but the most common one works like this mini-ELI5: If you pull down the latest version of a piece of source code and edit it, you then make a new branch of that source code from there. In smaller projects, these are just version updates, but in bigger projects what tends to happen is that different people will check out some of the more central files at the same time, and both check in their own versions with their own edits; then, either the software can tell of the updates are compatible and can merge them, or can have human intervention required.
This can get problematic if there are people who are working at different speeds. To use the example above: Say that Alice was working on that hero’s moveset at the same time as Bob was working on removing that proc, but Alice checked out her version of the code *before* Bob finished removing the proc. Since Alice had the older version of the source code, when she checks it back in with the balance updates, it undoes Bob’s work if someone doesn’t notice that Bob took that out for a reason before committing it to the main/live branch of the code.
Final reason: human error.
I do a bit of coding, and I cannot for the life of me tell you how many times I’ve made the mistake of putting a + where a – should be, or mixing up > and < or even just having a typo in one of my variable names somewhere. Hell, my first attempt at a game I did something like that and instead of coming to a stop when I stopped pressing the “move right” button, the sprite accelerated and started looping the screen at insane speeds.
These are the things that are caught in testing most of the time, but due to a lot of programming switching over to a rapid development/testing/deployment loop, a lot of the easy stuff that would otherwise be caught gets missed because of the crunched timetable. Doing a thorough search into a game to find these things takes time.
For a fun instance, look at [the ladder bug](https://www.pcgamesn.com/the-outer-worlds/ladder-bug) that Obsidian ran into with The Outer Worlds, and look at how it was not really easy to reproduce in-house with testers, and once the game went live more people than they thought hit the bug, and it was such a random event that would cause the bug, but when you have 50,000+ people playing the game, it’s much easier to hit a 1 in a thousand chance.
Most bugs fall into one or more of those categories: either there was a simple typeo
Latest Answers