The project I used in that demo has 1150 lines of code in the left pressed event alone, and over 12k lines in total...Honestly, if I were trying to track specific reads and writes of a variable, it would make the process harder. Unlike tracking values in an emulator, cheat engine, and so on, my code isn't finished or basically bug-free. The trick is to decide how best to catch the behavior, and then to get the breakpoints going.
That probably didn't convince you
Let me try it this way: If you
were able to track all of the places where a variable changes (something like Find All inside the debugger), then you would have a very hard time identifying
why the values have changed in a way you didn't want. Jumping from write to write does not allow you to see the more complex interactions in your program--for example, most errors I run into in GameMaker come from the order in which events happen or the order in which objects execute their events. Tracking variable writes only shows me that a variable becomes an undesireable value at a certain place--it does not show me that an event has fired in a different order than I expected, and it doesn't show me that some earlier conditional statement caused a section of code to be skipped (or not skipped).
In other words, often times the source of the error isn't the line of code that changes your variable--that's sometimes the only correct thing! Often, the cause of the error is that the correct change to a variable was made at an incorrect time or under incorrect circumstances. You can only discover this by tracing your code.
In the example I showed, I guess it looks kinda like I know *exactly* where I want a breakpoint but that's not quite what I meant to illustrate. In that example, suppose that every time I click the "Mark" button in my game, something should happen but it's not working properly.
I go to the mouse click event and add a break point at the portion of code that is supposed to detect clicking the "Mark" button. I have now cut the problem in half!!! The issue is either ocurring because the "Mark" button isn't correctly detecting a click, or because something after the click has gone wrong. So, I add the break-point, and then I click. If the code "breaks" then I know that the issue is
not anything to do with whether or not the button correctly detected a click (it could have been--the only way to know for sure is to put in a break point).
Once I know that a certain action that I *think* should happen actually happened, I know that a value inside of a ds_map data structure should change. I
don't set a breakpoint at that line--I want to verify that everything leading up to it is working. So, I step through my code, watching the temporary values of computations leading up to that line, then confirm that it got the right value.
IF the value is set correctly (99% of the time, it is when you have a bug), then that means something happens
after the value is correctly set to make it go wrong. Often, this happens during the same game step, so it looks like the value never changed at all unless you use break points.
If you really, truly have no way to guess where to begin adding a breakpoint, then I can give you ways to guess:
1) Does the value become wrong consistently when the game is in a certain state or a certain room, or when a certain object is created, or when you do a certain interaction? Put a break point at the place where that room starts, that object is created, that state changes, or that interaction is detected.
2) Is the value definitely correct somewhere, after which it somehow gets wrong? Put a break point at the place you know it is right, then trace until it is wrong.
Now, that's foolproof. If your value was never right and never wrong then you've got a paradox, so surely one of those 2 places is a starting point. You can combine strats from there.
For example; set a breakpoint on a variable write line where you strongly suspect that the value is set
correctly.
When your code pauses at that point, continue down a line or two and make sure it changed correctly.
At that point, you probably don't want to click "next" 1000 times, right? So in the debugger, scroll down a bunch, past all of the lines that you think have no effect on the variable. Add a breakpoint farther down and "resume" your game--it should break at your next point. If not....you've narrowed down the problem location between 2 breakpoints.
If you think that the
entire rest of an event or script has no effect on the variable in question, then click the "step out" button on the debugger instead of setting another breakpoint. "Step Out" tells GameMaker to run the remainder of the script without pausing, and to pause as soon as it reaches a new event or script. This way, you'll see which event or script happened after your breakpoint correctly set the value.
Again, scroll down. Set breakpoints in the "next" event or script where you think things might change the value and hit Resume--or "Step out" if the event has nothing to do with the value in question.
By combining the addition of breakpoints, stepping out of events and scripts that aren't important, and stepping one line at a time through the logic surrounding the lines that do change, you should be able so sift through thousands of lines of code in under a minute and you'll quickly know where the error occurs. Then, you've gotta figure out why