The Bugs You Will Find at IGM

We all encounter bugs while playing games. We may have wondered why developers release games with bugs in them. Then, we start programming our own games.


Bugs are errors made in the programming process. These errors, left uncaught, lead to strange behaviors in the program. They vary in degree and how easy they are to fix. Some bugs have subjected people to high doses of radiation. (Link: Bugs in games tend to not be as lethal.


How bugs happen:

A program can be thought of as a system of interlocking parts. An error in the design of the system leads to problems. This is true of code and real-life systems. As systems get more complicated, oversights are more likely to happen. And games can get awfully complicated. As students, we are restrained by time and a lack of resources. It is easy to let the complexity get the best of us.


Syntax Bugs:

Remember the phrase “Let’s eat, Grandma.” and “Let’s eat Grandma”. A computer would actually eat Grandma.


Syntax bugs happen with missing commas, forgotten periods, or when using the wrong word. This usually prevents the program from working outright. Our tools can highlight these problems most of the time. When our tools don’t find it, the program will run with the error. That makes it harder to find.


Math Bugs:

Game software can be math heavy. Let’s say you need to find the hypotenuse of a triangle (which comes up a lot actually). We all know Pythagorean theorem:


c2 = a2 + b2 or c = √(a2 + b2)


A programmer might make a mistake and write it out like this:


c = √(a2 - b2) or c = √(a + b)2 or c = √(a3 + b3)


The key to fixing these kinds of errors is to create test cases and run the code with them. If a = 3 and b = 4 then c = 5. If we don’t get 5, then we know there is a bug. After you try fixing the code, run the tests again.


Logic Bugs:

This is when the code does not work the way you intended it but does run. In programming, you use a lot of if-then logic which is to easy to mess up.


The key to fixing these bugs is to think in the most exact possible way, what is it you want the code to do. Then go through each line to make sure that it follows that.


Garbage In, Garbage Out:

There is a phrase in computer science, “Garbage in, garbage out”. What it means is that if the bad data is inputted into a system, then bad data will output.

Imagine creating a spell checking program. It reads through a document and checks each word against a list of correct words. You run it, and almost all the words in your document are wrong. What happened? You look back at your program and the code seems fine. However, the list of words was in Spanish. Of course, it thought all the words were wrong.


How to fix Bugs:



Some bugs are easy to fix. However, when I encounter a difficult bug, I tend to follow these steps. For this example, let’s say the game crashes when I hit an enemy.


First, I try to find ways of causing it to happen again. Does this happen with all enemies? Does this happen with all weapons?


Second, I try to isolate the bug. To do this, I turn off sections of the code to see if the crash still happens. Is it the enemy animation? Is it the on hit effect? Is it the subtraction of health?


Third, I examine the offending section step-by-step. I think critically about what I want the code to do and look for any possible flaws in implementation. I’ll play around with it. I may try rewriting the section.


Fourth, I am not afraid to ask for help. Google is your friend. You can also ask the professor, the TA, or a fellow student. They may have encountered the problem before.


Fifth, if I still cannot figure it out, I step away from the problem. Maybe I’ll go hang out with friends, take a nap, or eat lunch. Then, I come back with a fresh mind.


Sixth, I come up with excuses. This bug is clearly a feature. It’s an avant-garde statement and everybody else just doesn’t get it.


Seventh, the plan is to move to Canada, adopt a new life and a new name. Never touch a computer again.