How does a glitch happen in a video game and how do they fix it? If coding is what I think it is and that’s where the issue lies, how do you locate a glitch in endless amounts of code?
In: 0
You’re right. It’s generally a programming mistake.
Finding and fixing these is a skill that you develop over time when you work as a software developer. Some of this is intuition. Based on what’s broken, I know that the issue is probably in this chunk of code so I’ll look there. Other times, you’ll need some way to narrow it down. Like, I know that these three sections of code work together to make this happen, so I’ll see which specific one is behaving incorrectly and that will narrow my search. Developers also have tools that can help them do that. These debugging tools can do things like pause the program when it hits a certain line and lets you look at what specifically a piece of code is doing in that situation.
You’re right. It’s generally a programming mistake.
Finding and fixing these is a skill that you develop over time when you work as a software developer. Some of this is intuition. Based on what’s broken, I know that the issue is probably in this chunk of code so I’ll look there. Other times, you’ll need some way to narrow it down. Like, I know that these three sections of code work together to make this happen, so I’ll see which specific one is behaving incorrectly and that will narrow my search. Developers also have tools that can help them do that. These debugging tools can do things like pause the program when it hits a certain line and lets you look at what specifically a piece of code is doing in that situation.
The code isn’t endless and it is structured, well good code is. Each piece of the code has a specific job to do. When debugging you can do a few things. Check error logging, this will often tell you the call stack. Then you can go to that code and start analyzing it for defects. Also you will attempt to reproduce the problem. If you can do this then your knowledge of the code base can be leveraged to determine what the probable components involved are and you can go there and start debugging. It is definitely a skill to debug code, actually different skills are used than just writing new code. Some devs like it, some don’t. There is an element of sluething involved to build a picture of what happened. Sometimes it is easy, sometimes you’re banging your head on the desk.
The code isn’t endless and it is structured, well good code is. Each piece of the code has a specific job to do. When debugging you can do a few things. Check error logging, this will often tell you the call stack. Then you can go to that code and start analyzing it for defects. Also you will attempt to reproduce the problem. If you can do this then your knowledge of the code base can be leveraged to determine what the probable components involved are and you can go there and start debugging. It is definitely a skill to debug code, actually different skills are used than just writing new code. Some devs like it, some don’t. There is an element of sluething involved to build a picture of what happened. Sometimes it is easy, sometimes you’re banging your head on the desk.
In most cases, I wouldn’t say it’s *endless* amounts of code. There will probably be a lot, yeah, but it’s probably tenable with enough developers working together on it. And it’s not like the code is in one big shapeless heap, either; it will have a structure that will let the developer know what parts are broadly responsible for what behaviors.
If you’re a firefighter looking for fires to fight, and you see smoke, you aren’t going to dash all over town to search for the fire. You are going to go directly to where the smoke is coming from. The fact that there is smoke at all is a clue to where the problem is. These days, programmers have tools that can tell them which part of the code the “”smoke”” is coming from when a glitch is noticed.
Where the firefighter analogy breaks down is actually fixing the problem. In the case of an actual fire, the fire is the problem, and it will almost certainly be exactly where you see the smoke. But in software, even if you know exactly where the fire is, how the fire started and how you can prevent another one in the future may not be so obvious. At the site of the problem, everything may have been working perfectly as it was designed to, and things only broke because something you didn’t expect to find its way there somehow did.
Like, maybe the fire started because a tanker truck full of fuel took a really narrow turn, tipped over, and exploded. But the site of the fire was in a small residential neighborhood. The question you should be asking is probably not, “how do we make the homes in the neighborhood more fireproof”, rather, “what the hell was a fuel tanker doing here in the first place?” And now you have to go on a long detective mission tracing back why it was there, who sent it there, what are your options to ensure that it never ends up there again, etc. *Maybe* the fuel tanker did have a legitimate reason to be in that situation, as the road it was on was the only road available to get to a fuel station on the other side of the neighborhood. So maybe the fix is to redesign the turn so it’s not so tight. Or redesign the fuel truck so it won’t fall over on tight turns. Or build a new road to the fuel station that avoids the problem road altogether. Or move the fuel station somewhere else entirely. *Maybe* the truck driver just got lost in traffic and got dumped into that neighborhood by mistake. Perhaps the fix for that is giving all trucks better GPS so they don’t get lost. Or maybe there’s a really bad intersection that forces trucks to be kicked off onto exit ramps they didn’t want to be on, and it needs to be redesigned.
The point of all this being, finding what causes a glitch is often surprisingly easy. But finding the best solution to the underlying problem, even if you understand exactly what happened in the incident, can be quite challenging.
In most cases, I wouldn’t say it’s *endless* amounts of code. There will probably be a lot, yeah, but it’s probably tenable with enough developers working together on it. And it’s not like the code is in one big shapeless heap, either; it will have a structure that will let the developer know what parts are broadly responsible for what behaviors.
If you’re a firefighter looking for fires to fight, and you see smoke, you aren’t going to dash all over town to search for the fire. You are going to go directly to where the smoke is coming from. The fact that there is smoke at all is a clue to where the problem is. These days, programmers have tools that can tell them which part of the code the “”smoke”” is coming from when a glitch is noticed.
Where the firefighter analogy breaks down is actually fixing the problem. In the case of an actual fire, the fire is the problem, and it will almost certainly be exactly where you see the smoke. But in software, even if you know exactly where the fire is, how the fire started and how you can prevent another one in the future may not be so obvious. At the site of the problem, everything may have been working perfectly as it was designed to, and things only broke because something you didn’t expect to find its way there somehow did.
Like, maybe the fire started because a tanker truck full of fuel took a really narrow turn, tipped over, and exploded. But the site of the fire was in a small residential neighborhood. The question you should be asking is probably not, “how do we make the homes in the neighborhood more fireproof”, rather, “what the hell was a fuel tanker doing here in the first place?” And now you have to go on a long detective mission tracing back why it was there, who sent it there, what are your options to ensure that it never ends up there again, etc. *Maybe* the fuel tanker did have a legitimate reason to be in that situation, as the road it was on was the only road available to get to a fuel station on the other side of the neighborhood. So maybe the fix is to redesign the turn so it’s not so tight. Or redesign the fuel truck so it won’t fall over on tight turns. Or build a new road to the fuel station that avoids the problem road altogether. Or move the fuel station somewhere else entirely. *Maybe* the truck driver just got lost in traffic and got dumped into that neighborhood by mistake. Perhaps the fix for that is giving all trucks better GPS so they don’t get lost. Or maybe there’s a really bad intersection that forces trucks to be kicked off onto exit ramps they didn’t want to be on, and it needs to be redesigned.
The point of all this being, finding what causes a glitch is often surprisingly easy. But finding the best solution to the underlying problem, even if you understand exactly what happened in the incident, can be quite challenging.
How do you fix a problem in anything that you write?
1. You re-read what you wrote.
2. You identify the mistake.
3. You correct it.
Not sure what you’re asking here.
Coding may look like endless gibberish to you, but it’s just like any other language. If there is a mistake in some part X of the game, go to the part of the code that describes part X, find the mistake, and correct it.
You wouldn’t ask someone who writes Japanese “How do you make mistakes and fix them when you write something in Japanese?” would you? It’s exactly the same.
How do you fix a problem in anything that you write?
1. You re-read what you wrote.
2. You identify the mistake.
3. You correct it.
Not sure what you’re asking here.
Coding may look like endless gibberish to you, but it’s just like any other language. If there is a mistake in some part X of the game, go to the part of the code that describes part X, find the mistake, and correct it.
You wouldn’t ask someone who writes Japanese “How do you make mistakes and fix them when you write something in Japanese?” would you? It’s exactly the same.
A glitch is basically any unexpected behaviour. That *can* come from errors (bugs) in the code, in which case a developer needs to find the problem code and fix it (debugging). A glitch could also be caused by faulty hardware or other problems, though that still generally involves developers debugging the code (until they either determine the hardware is at fault, or they give up and chalk it up as a one-off issue).
The process of debugging is a skill developers have like any other. As other answers have said, there is only so much code, the developers should already be familiar with how it works, they should have an idea what sections of code to look at based on the bug description and any data dumps/error logs (that’s why detailed bug reports are important), and ideally the code is structured well enough that it’s relatively easy to determine which code is responsible for which behaviours (failure to do so makes debugging harder, and is a major cause of [technical debt](https://en.wikipedia.org/wiki/Technical_debt)).
A glitch is basically any unexpected behaviour. That *can* come from errors (bugs) in the code, in which case a developer needs to find the problem code and fix it (debugging). A glitch could also be caused by faulty hardware or other problems, though that still generally involves developers debugging the code (until they either determine the hardware is at fault, or they give up and chalk it up as a one-off issue).
The process of debugging is a skill developers have like any other. As other answers have said, there is only so much code, the developers should already be familiar with how it works, they should have an idea what sections of code to look at based on the bug description and any data dumps/error logs (that’s why detailed bug reports are important), and ideally the code is structured well enough that it’s relatively easy to determine which code is responsible for which behaviours (failure to do so makes debugging harder, and is a major cause of [technical debt](https://en.wikipedia.org/wiki/Technical_debt)).
Latest Answers