Have you loaded up yer shotgun, checked yer grenades and painted yer face black yet?! We're going bughuntin' tonight.
One of the most important, most fun and most annoying parts of programming is debugging; finding and removing bugs. It often gets too less attention by the average programmer, resulting in programs with the stupidest bugs which take days to remove, and in the end it only turns out the plussign should have been the minus sign.
Here I will tell you about some debugging ways I use myself, how I used to debug, how I debug nowadays, because one thing you defenitely learn during your programming experiences, it is debugging.
..
Debugging is nothing more than checking for variables, if they have the contents they should have. When you start programming a part of your program, like the part where your NPC (Non Player Character, a sprite that walks independently of the player) is walking, you always start off thinking, what kind of structure you will code in.
Will you first do a part where it randomly assigns an X and Y coord to where the NPC walks? Or will you first make it check if it still is walking or not? Or first a random number deciding IF it will walk or not? Or maybe it can jump too? And what if it will walk, will it walk pixel by pixel? Will it have other abilities to walk?
Then you will decide what variables you need, and what EXACTLY is gonna be in them. This is important. You cannot debug if you don't know what is in your variables, or what should be in your variables. You need to know, that if your puppet is on the wrong spot of the screen, what variables to check. That's why it's always handy to use variables with a name that kind of tells where they are going.
Personally, I always use 'X' and 'Y' for a current location of an object, 'XT' and 'YT' for a current target destination of an object, 'Speed' of object movement, etc,etc.
When you determined that, dimensioned your variables and arrays (and the program still works, ALWAYS try to run your program as soon as it should be able to run and continue, because it get's allot easier that way which part of your code contains the bug) and start off programming the actual code, you need to keep in mind it should be easy to check your variables.
If you actually see onscreen what your variables are doing, it is allot easier to determine what wend wrong.
..
What I do nowadays, as soon as I have a font routine (or just PRINT), I dimension an array called Debug, like 16 words big. Then I create an event, when I press, for example 'D', the Debug array is shown onscreen, all 16, vertically, and it is being updated all the time.
It's handy to put the code to put it onscreen in a separate sub, so you can call it anywhere when necessary.
Now, when you're coding your NPC code or whatever, you can put contents of your variables in several Debug slots. This is allot easier than continually putting .. PRINT blah .. or PRINT blah everywhere. You just do, for example, DEBUG(1) = X: DEBUG(2) = Y .. and when you press 'D' you see your X and Y coords, live. Now you exactly can trace what went wrong or right when the NPC was moving.
..
..
You find a variable that is not acting the way it should, and you can't find the problem. What do you do now? We almost all had this problem before. Some stupid variable always turns out to become some number it SHOULD NOT become, but we can't find why it does that.
This requires allot of logical thinking to find the bug. First you do the above trick and look exactly at what the variable is doing. For example, it should be adding 1 every second, but it's not, it's decreasing 1 every second. Now you already know the bug is in connection with the 1 second timer, where it should add 1, so you should look at that particular code. This was a very simplistic example, but there are allot more complicated things like this which really requires some thought. It all depends on your coding.
The piece of code, you think your bug is in, you have to start using your mind. You look at the code, put a number in every variable you see (IN YOUR MIND) and then you start processing your code in your mind, see if it walks correct. If it does, do it again, with a different number.
You also can do it the other way around. You know which number ended up in the variable which shouldn't be there, and you go backwards and see how it could turn into that variable.
This is all very annoying work, but the more you do it, the more you code, the faster it will go. You will learn better to understand what your variables do in your programs.
Now, if you still can't find the bug. I assume by now you figured out which part of your code should contain the bug. You just put the Debug sub I talked about above, on practically every line, and put a SLEEP inbetween them. This way you can determine which LINE your bug is in, and now you really should be able to fix it.
..
Some more advanced notes.
In the more complicated QB games nowadays, you see consoles coming up. Some people (like myself) are building in a console, and make it possible to change or look at variables on an instant.
For example my console is like the INSTANT thing in the QB interpreter. I can add, subtract, print, or assign any value to allot of variables in my program. I also practically always have that Debug array I talked about.
Within my program I can test, test again, and play with any variables I like, determining very quickly the behaviour of my program, when I change a variable.
It is also fun! To have a console, since you can like, do godlike things with your program. It is allot more fun to play in a console than just do 'F1' for unlimited weapons.
Even more fun is, to make it able to load and save scripts and make it run in the console.
.
In this piece of writing I never mentioned QB interpreter's ability of watchpoints and debugging. You can use those, to also check your variable, but the disadvantage is, it's slow and not really live. It interrupts your program continually. I never use them and what I never use I don't describe. Maybe someone else can.
This piece was written on June 25th in the hot air of Cyprus where I'm on vacation right now.
This article was written by Marcade. (http://www.marcade.net)