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
It can be complicated. It may be just they didn’t found it or some code lines can cross with another lines.
Imagine you stocked a store with 100,000 items for sale, in various places all throughout your building. Where you and a couple of your team may try very hard to keep things orderly and up to date, that’s a lot of items to go through alone.
Now imagine your store opens and you get many thousands of people walking through and checking your products out. You’ll very quickly find issues with your stock, whether they be minor or major.
Software testing is a slippery slope of cost vs reward. You pay very high wages to bring to market product that depending on the complexity, your team, and how long/how much you’re willing to pay. Often the risk of glitches being caught by the community isn’t just a risk, it’s an active game plan, and your team becomes reactionary to the worst glitches first and then parse through the simpler ones.
I test software, it’s impossible to release perfect non glitchy code. Usually you go live with code knowing bugs are in there but it’s all about risk. What you describe does sound bad, but very often software releases are bound to fixed deadlines and money talks- usually until people start complaining and then patches are rushed out.
Like Scout_On_Drugs said, sometimes some code crosses some other code.
So generally with bigger programs, like games or other big software with a lots of functionality, there is too much happening to test every scenario.
Sometimes a bug is pretty apparent when testing and it gets sorted before release.
Maybe they change a part of a character and the game crashes when you load into a map. That will definitely be fixed.
Other times a bug would be caused if you have only a specific set of parameters. Like you have a team of 4 players, and something weird will only happen if character 1, 4, 9 & 15 was select for play. Maybe only even if character 4 has ability 3 loaded and character 9 picked up a weapon dropped by an enemy in a specific place in the map.
It can get very difficult to test these things, so we leave it to the consumers to test for us.
[removed]
Lets take an example: You tell your 7 yr old child to go buy milk, your instructions were: Walk along X road defined on the map, go into A store, buy B brand milk, pay the cashier and return home, avoid stranger on the way.
However, on the way, the kid see a wild Pedo bear walking along the road. It’s not on the list of instruction so it froze up. And maybe even drop the milk and run.
Unexpected things can happen during playing that the code was never intended to act, in most cases they ignore or restrict the player from performing the action, but every blue moon or so, the codes cross, so you’re stuck in the logic loop where the kid doesn’t know if he is to run the other direction or continue following instruction.
When tester test game and updates, they’re testing the road and instructions, they arnt exactly seeing the sceneries thus will probably miss the appearance of a pedo bear along the road.
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
🎼 *99 little bugs in the code,
99 little bugs in in the code,
You patch one down, you compile it around,
127 little bugs in the code*
Very long code will sometime be like a Jenga tower after a few rounds, yes just still standing up despite that wonky one at the bottom. Sometime you can fix up that brick no problem sometime just touching it will sent the whole thing down. Now if that wonky brick(bug) just cause you to clip that hedge funny might not be worth prodding at it too much for now, if that wonky brick(bug) turns your hardware into slag at the Loading screen you might want to do something about it.
With that said game development have a limited budget, if you can fix only one bug because of said money/manpower/time constraint, which one do you fix…. The bad one first, leaving the other one to be fixed later when the game start generating revenues.
An other meme is *But it ran fine on my machine*
Again PC have billions of variations on hardware/drivers/third-party stuff, console have less variable but they still have a fair amount of hardware revisions with or without added bells and whistles. The code might work fine on the devs machine because they all had say vgcard123xt but the bug crash when using the other guy vgcard, easy to fix but what if the bug happen only if you use the otherguy vgcard234se Pilgrim edition using crayon tracing™ on a 20.7:9.35 aspect ratio. No matter the effort put in it will never be found until it’s released.
And sometime you have an other program/firmware/OS that might force the whole machine to use 1+1=5, if your code expect 1+1=2 it might not work because someone else is forcing a bug into your correctly working code.
Latest Answers