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!
Full Version: Debugging
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:
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.
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:
QUOTE
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.
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.
I just put messages everywhere. They also allow you to pause the game to check things out.
in addition to the debug mode, i also use the show_debug_message() function instead of the show_message() function Yako told us about
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.
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.
I haven't thought of using sounds before, I've used show_message().
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.
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.
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.
**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.
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.
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:
That way I can go to whatever room I want and such in a flash. I can also do things like this:
So then if it shows a message, I know an instance of obj_menu exists.
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','');
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.
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
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
I isolate pieces of code by putting // in front of it ... [it's easier then 'ctrl+x'] 
That always works for me, but I don't use a special 'debug' -sound, I just use 'jump_snd' [for example]
:sniched
QUOTE
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
I use a message for that.
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
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
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.
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.
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
so there ya go
mega
QUOTE
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....
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...
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...
correojon said:
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!
QUOTE
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!
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:
It works pretty well to help zone in on bugs.
CODE
if( global.devmode == true ){draw helpful debug variable;repeat w/ new var}
It works pretty well to help zone in on bugs.
I never used GM's debug. Same goes for Visual Studio debugger.
Why? Never bothered to use it.
First, I try to analyze my code (only the portion where I think the bug is)
Then, I try to pop some messages boxes around the spot where I think the bug is so I know which instruction messes up. Not the most efficient method, but I'm confortable with it. I use messages boxes because they stop the game when they appear (with the proper game option enabled of course).
As for debug objects, sometimes. I often use a "debug" object so I can put "cheats" in it for testing purposes. When the game is finished, I simply delete the "bebug" object.
Why? Never bothered to use it.
First, I try to analyze my code (only the portion where I think the bug is)
Then, I try to pop some messages boxes around the spot where I think the bug is so I know which instruction messes up. Not the most efficient method, but I'm confortable with it. I use messages boxes because they stop the game when they appear (with the proper game option enabled of course).
As for debug objects, sometimes. I often use a "debug" object so I can put "cheats" in it for testing purposes. When the game is finished, I simply delete the "bebug" object.
I also use show_message() to see if a condition is met or not. I find it helpful that you can save all the variables you watch in debug mode into a textfile and open it again if you need them. That saves alot of time when you need to watch 2.5 Billion variables . And like someone said before, I also isolate code with /* */ rather than cutting/deleting it. I normally don't make any backups of files because I never change code so much that it could ruin the game and if I have to I just copy it and isolate the old code with /* */. Well that's some sort of backup I guess.That's pretty much it. Most of the time I spend on analyzing the part of the code where I think the bug is
. And like someone said before, I also isolate code with /* */ rather than cutting/deleting it. I normally don't make any backups of files because I never change code so much that it could ruin the game and if I have to I just copy it and isolate the old code with /* */. Well that's some sort of backup I guess.That's pretty much it. Most of the time I spend on analyzing the part of the code where I think the bug is
Commenting out problematic code useful. Especially when doing wall jumping!
I very rarely used the built-in debugger before I was working on my 3-D engine. I had a movement script that seemed to be working irratically but I didn't really know what was happening. I needed the debugget to figure ou what was happening. I also find the sound tecneque quite usefull.
I debug while I'm sleeping.
Sometimes I wake up in the middle of the night saying, "Oh, that's how it's done." If you obsess over a problem long enough, your brain will do some calculating in the background. It's just like those times when you couldn't find an answer to Sunday's crossword puzzle and while you were drinking coffee in that evening, you suddenly know the solution.
Sometimes I wake up in the middle of the night saying, "Oh, that's how it's done." If you obsess over a problem long enough, your brain will do some calculating in the background. It's just like those times when you couldn't find an answer to Sunday's crossword puzzle and while you were drinking coffee in that evening, you suddenly know the solution.
i mostly use two functions (script) in conjunction:
Log(message, filename)
ASSERT(expression, message)
i am used to ASSERTs from programming, and i got bothered putting show_message() in the code because when they pop up every step all you can do is kill the process
so ASSERT pops up a message if the expression evaluates to false, and gives you two options: "ignore" or "end game"
all assertions are also logged to the Logfile, as is other stuff
it is much easier to go through a log file than drawing variables in GM, because you need to store values in the step event, then draw them in the draw event ... tedious
also, Log() helps analyzing values which would not be decipherable when they are drawn and changing every step
of course there is also the GM debugging features, but other than displaying the occasional variable i rarely use it
i really wish for more variable breakpoints, then going in the code, seeing the line where to code halted, seeing all variables in scope with their values ... a kingdom for a debugger like visual studio has!
ps: if you want, rip these two functions from GM_ODE
Log(message, filename)
ASSERT(expression, message)
i am used to ASSERTs from programming, and i got bothered putting show_message() in the code because when they pop up every step all you can do is kill the process
so ASSERT pops up a message if the expression evaluates to false, and gives you two options: "ignore" or "end game"
all assertions are also logged to the Logfile, as is other stuff
it is much easier to go through a log file than drawing variables in GM, because you need to store values in the step event, then draw them in the draw event ... tedious
also, Log() helps analyzing values which would not be decipherable when they are drawn and changing every step
of course there is also the GM debugging features, but other than displaying the occasional variable i rarely use it
i really wish for more variable breakpoints, then going in the code, seeing the line where to code halted, seeing all variables in scope with their values ... a kingdom for a debugger like visual studio has!
ps: if you want, rip these two functions from GM_ODE
I put's messages everywhere. Are there anyone else that has notice that the debug mode only updates the variables every step, and not when they're set?
Heres my guide I WROTE:
"Icon image is not valid"
Why are you trying to hack it anyway? This error only comes up if you try to change the icon with a resource changer.
"Invalid argument"
"Invalid variant type"
These are usually errors in functions, ex. when it wants a string value, you give it a real.
"Unexpected error occured when running the game"
These usually occur in DLLs, or if your DirectX is not up to par. GM games require DirectX 5. To see your version, go to Start > Run and type dxdiag.exe
"Out of memory"
"Failed to run the game"
Try closing some programs!
"File not found"
"Invalid filename"
Its just that.
"Too many open files"
You have to many file handles open at once, or you forgot to close some.
"Disk full"
That cant be good.
"Wrong type of arguments to +"
You used a real value at the wrong time. Try string(realnumber)
QUOTE
- "Unsupported Application Extension block size"
- "Unknown GIF block type"
- "Object type not supported for operation"
- "Invalid GIF data"
- "Image height too small for contained frames"
- "Image width too small for contained frames"
- "Clipboard operations not supported for GIF objects"
- "Image exceeds Logical Screen size"
- "No global or local color table defined"
- "Invalid pixel coordinates"
- "Unsupported PixelFormat"
- "Invalid image dimensions"
- "Image has no DIB"
- "Color not in color table"
- "Color table is empty"
- "Failed to Save Stream"
- "Premature end of data"
- "Color table overflow"
- "Invalid color index"
- "Unsupported GIF version"
- "Invalid GIF signature"
- "Invalid number of colors specified in Screen Descriptor"
- "Invalid number of colors specified in Image Descriptor"
- "Unknown extension type"
- "Invalid extension introducer"
- "Failed to allocate memory for GIF DIB"
- "Invalid Image trailer"
"Icon image is not valid"
Why are you trying to hack it anyway? This error only comes up if you try to change the icon with a resource changer.
"Invalid argument"
"Invalid variant type"
These are usually errors in functions, ex. when it wants a string value, you give it a real.
"Unexpected error occured when running the game"
These usually occur in DLLs, or if your DirectX is not up to par. GM games require DirectX 5. To see your version, go to Start > Run and type dxdiag.exe
"Out of memory"
"Failed to run the game"
Try closing some programs!
"File not found"
"Invalid filename"
Its just that.
"Too many open files"
You have to many file handles open at once, or you forgot to close some.
"Disk full"
That cant be good.
"Wrong type of arguments to +"
You used a real value at the wrong time. Try string(realnumber)
heres mine:
QUOTE
Throws an Error:
1.) Panic
2.) FIx it
1.) Panic
2.) FIx it
What the pro developers do is they have a special debug feature where you can enter a certain type of code/string that will help them test the game (such as infinite health when there are lots of enemies). Then they just leave the feature in the game when they release it and when the players find them they recognize them as "cheats".
also they hire a team of 5 or more testers that play their game 8 hours a day.
i debug by running the game in Debug mode.
i add the variables i want to check, and make sure they all match up with what they should be.
or what i do more often since mostly all the problems with my scipts are small compilation errors , i just read the error message then go into the script and press the little "check the script for syntax errors" button and fix the line of code, usualy i just forget a bracket or soemthing.
for you poeple who do alot of debuging in there game,playing your game in debugmode is very powerfull and easy.
-you can look at the value of variables without getting errors incase the variable dosent exist yet.
-you can test equations easily without getting an error.
these features save alot of time.
and dont forget to ALWAYS READ ERRORS.
i add the variables i want to check, and make sure they all match up with what they should be.
or what i do more often since mostly all the problems with my scipts are small compilation errors , i just read the error message then go into the script and press the little "check the script for syntax errors" button and fix the line of code, usualy i just forget a bracket or soemthing.
for you poeple who do alot of debuging in there game,playing your game in debugmode is very powerfull and easy.
-you can look at the value of variables without getting errors incase the variable dosent exist yet.
-you can test equations easily without getting an error.
these features save alot of time.
and dont forget to ALWAYS READ ERRORS.
QUOTE (KC LC @ Jul 22 2004, 05:30 PM)
correojon said:
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!
QUOTE
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!
you dont need to do that.
the EXACT PORPOSE of debugmode is to save you the toruble of doing the above.
you can play your game in debug mode
save the variables in debug menu.
if you save them they will show up everytime and this way you dont have to worry about getting an error message if the varibale dosent exist anymore.
you alos dont have to worry about haveing alot of clutter on your game screen.
if you look in the tools menu of the debugmode screen there is even an option
to show all variables, or show all global variables, or show all objects.
if you concider yourself an expert user you should learn how efficiently debug your game.
show_message is the best function ever invented. I believe that it is the easiest way of debugging. Of course I run my game in debug mode every so often, but since I work mostly with scripts I prefer just typing show_message("brew-ha-ha") so that I know my program has gotten to a certain point in time.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.