Debugging, How do you do? Options

[Villain]

I think almost everyone wastes more time debugging your code then actually programming it. The chances that you write a code and make it work exactly the way you imagined in the first run are really slim. To help people out debugging their codes:

How do you debug? Which techniques do you use?

I think to examine strings, the best way is saving the one you want to probe to a txt file everytime it change, so you can watch how it transforms over gametime.

Another nice way for debugging is using sound. Sometimes you just don't know what's going wrong. If you don't know for sure if a block of code is being read by GameMaker, maybe because of a condition that may be never furfilled by the way you set your variables, add a sound_play(snd_debug) in that code block. This way, if you hear the sound, you know the program is going there.

I'm sure that there must be another tatics for cachting, and better, avoiding bug creation. Post here your ideas!

[EricDB]

Well, obviously the first thing I do is hit good ol' F6 to run my game in debug mode. It's much easier to add variables to the watch list than to write them to a txt file. Plus, you can press Ctrl-E to get a popup where you can enter some GML code for your game to execute. I can't count how many times that's come in handy.

Troubleshooting is always an exercise in logical thinking. Every problem is different, but it's surprising how similar the process is. Here are some pointers from my experience in debugging code, roughly in the order you should do them:

MAKE A BACKUP: Before you start debugging, save your code to a new file!  You're going to be tinkering around, changing things here and there, running experiments to figure out what's making your game misbehave.  There's a very high likelyhood that you'll break other things in the process.  Think of this as a "checkpoint": no matter how bad you screw up, you can always restore to your backup. 

Fix one bug at a time:  If your game has more than one problem, pick one and work on it.  Don't try to fix more than one thing at a time.

Reproduce the error: This means you need to be able to cause the bug to happen on demand.  Unless you can do this reliably, you'll never know whether you've actually fixed it or not.

Understand the bug: Make sure you know exactly what's going wrong.  I'm not talking about the cause here (that's for later).  Just be clear in your mind about what you want the game to do, and what it's doing now that's different.

Change one thing at a time: This is a biggie.  Debugging is a process of making hypotheses, checking them out (by changing your code), almost always finding out that you were wrong, and repeating.  Each time one of your theories turns out wrong, you need to undo the changes you made before you start on another.  Otherwise your code will quickly become a mess, and you won't know which change actually fixed the problem.

Fix your backup copy: When you finally do find the problem, don't continue developing with the "debugging copy" of your game.  Go back to the backup you made before you started, and fix the problem there.  This serves two purposes: it confirms that you really did find and understand the actual cause of the problem, and it prevents any code changes from failed theories from remaining in your program.

Now, I'll admit that I don't do all of these all of the time, especially the backups. If I'm just starting out with a game, there's gonna be a million bugs and I just fix'em as I see them. But once the game starts to get more complex, it's very important to be disciplined about how you tackle those pesky remaining bugs.

[Yako]

I just put messages everywhere. They also allow you to pause the game to check things out.

[Highwaydog]

in addition to the debug mode, i also use the show_debug_message() function instead of the show_message() function Yako told us about

[GcDesign]

For me it's similar: I use the normal messages nearly all the time - now often debug messages too.

Sometimes I let variables show up in the room caption to check them all the time - also if the game screen isn't drawing correctly.

[viestituote]

I haven't thought of using sounds before, I've used show_message().

[MasterMind]

me?

i grab a fly swatter.

i pretty much do everything above.

thats my fly swatter.

tho, heres a handy tip.

when working with varibles and something goes wrong, check your spelling. i was workking with views, and i kept getting errors. after trying everything i could, i took a break. (if you are getting frusterated, do this. it'll clear your mind, and you can think straight.)
i came back, and relised i had spelled view "veiw"

since then, i keep a tex document of all the varibles, a slight description of them, what the differen't thing asighned to them mean.

its saved me from alot of headaches.

[databot]

show_debug_Message() is a great addition to GM, in my progs i just scatter it and beofre i quit i save all the data sent to a txt file
**checks "log folder"
lets see, hmm 5 MEGS of log files!
but thev'e saved me time and time again.
a tip would be to make sure variables aren't objects,rooms etc. just place obj_ or spr_ in front, i use this and have never had much variable problems.

[darkhitman]

I put global variables at every step of the script I'm fixing, to find out where the condition is not passing when it should. Then I look at every piece of code related to that condition.

[Time of Death]

What do I do when I find a bug? I usually glare at my monitor for a minute, then pick it up and throw it across the room, then grab something heavy and slam it against the wall

Okay, here is my serious answer. I always have a main controller which is persistent and is in the first room. In the step of that object, I have something like this:

CODE

if keyboard_check(vk_f12)
   execute_string('Enter the code to execute','');

That way I can go to whatever room I want and such in a flash. I can also do things like this:

CODE

if instance_exists(obj_menu) {show_message("Yes")}

So then if it shows a message, I know an instance of obj_menu exists.

[bearSoft]

beside all the fine advices above i have this
on obj i add a method for drawing
i do this on an dummy-event like key-release z
in this i have say 4 fields for writing vars to the obj at x,y
when i change the key-release z to draw-event i no longer have the obj sprite, instead i have n running vars atach to the object
this takes care of the 'gm-bug' that f6 tables cant be 'locked' over a certain running var that u want to follow ( u know the list scrols to the top)
after monitoring the running vars i simply change it back to key-relase again
its a bit hmmm -but it works for me ;)

a pure debug-obj to do 'silly stuf' on can also be handy
delete it after use and the project is restored

[Icenfire]

I isolate pieces of code by putting // in front of it ... [it's easier then 'ctrl+x']

Another nice way for debugging is using sound. Sometimes you just don't know what's going wrong. If you don't know for sure if a block of code is being read by GameMaker, maybe because of a condition that may be never furfilled by the way you set your variables, add a sound_play(snd_debug) in that code block. This way, if you hear the sound, you know the program is going there.

That always works for me, but I don't use a special 'debug' -sound, I just use 'jump_snd' [for example]

:sniched

[Tarik]

I use a message for that.

[Adam]

I rarely, if any time, use GM's built in debug feature, I basically do the following
1) find if everything's working
2) if a problem is found I go to the object and think my head off
3) I test a few more times
4) I experiment a little to zero in on the problem
5) if it's fixed I permanently code it in and if not repeat the steps after step 2

[correojon]

I never use show_debug_Message(), most of all because i didn´t know it was there. Looks a interesting feature, maybe i´ll start using it.

Anyway what i normaly do is have a debug object that draws on screen the values of the variables i want to check. I normally do it this way because each time time you run the debugger you have to manually enter the expressions to watch. But don´t get me wrong, i use the debugger as much as i can, it´s one of the features of GM i like most.

[megamushroom]

i maje an object called obj_debug that draws my arrays on screen, as the in built debug mode does not show them. I change varibales to make sure that if they work I know they do like show a message, the sound idea is a good on aswell. Most imporantly, i think of everyting that that object has to do with, scripts and sprites. many time i have been unable to find a bug, only 2 realise that it was in a script that it used that i had missed.

so there ya go

mega

[correojon]

i maje an object called obj_debug that draws my arrays on screen,

yeah, it would be great if the debug could show all the elements in the arrays....

[Magicman657]

Hmm, I never would've thought of playing a sound, thats a rather good idea...

I can usually get the code to run after a few tries just by looking at it, but if I'm having difficulty, I run debug to show the variables, and that gives me a pretty clear idea of what part of the code is not working properly....I was kinda suprised though, because lately I've really been using debug mode LOT more than I ever did before...

[KC LC]

correojon said:

Anyway what i normaly do is have a debug object that draws on screen the values of the variables i want to check.

I do the same thing... for the same reason. This seems to be a common approach for folks.

I've also used sounds to let me know that a particular piece of code was actually executed. Also common, apparently. Just remember to turn off / remove these before you distribute the game... lol!

[shalaloushaska]

The best way, in my opinion, is to have a developers mode. In all of my games I have an object called cONTROLLER_mAIN. I simply add in a 'Key Release : D' and that toggles "Developers Mode" In the draw tab, I code:

CODE

if( global.devmode == true ){draw helpful debug variable;repeat w/ new var}

It works pretty well to help zone in on bugs.