With the latest version of GameMaker: Studio, we are introducing an all-new debugger, allowing you to debug on all non-YYC native targets (currently except Windows8). This will provide a number of useful features which are not available in the existing debugger, so I’ll give you an overview of how to use it and what it can do for you!
So, you’ve written a beautiful piece of code…but for some reason it’s not doing what it’s supposed to, and you can’t figure out why…until now, you would probably have to resort to the rather painful process of adding a bunch of show_debug_message calls, and rummaging through screeds of output. Now things are going to get a lot easier!
A breakpoint is simply a way suspend the program flow at a particular piece of code. Press F9 in a code window in GMS to set (or remove) a breakpoint – indicated by the red dot at line 18 in the image below.
Run the game by pressing the orange debug run button, and the game will start, along with the debugger window. When “objButton” is left-clicked in the game window, the game will stop, and the debugger window will gain focus -
On the left is a tree view of all the objects with the events they contain, scripts, creation code etc. You can double click on an item to display its’ code in the source window.
In the centre is the source window – the yellow bar shows where the program execution has halted. You can also add or remove breakpoints in this window, by double-clicking a line.
On the right are a number of windows showing more details of the program state – here you can see local variables, the current instance “objButton”, and the console output at the bottom. The layout and types of windows displayed is customisable, so you can arrange everything to your taste (more on that later).
So now we can see where we are in the program, and we have some information (I’ve highlighted the “counter” instance variable in the instance window). But what is the code doing actually doing? Time for the next step…
Press the “step” button in the tool bar (or the F10 key), and the program will advance by a single instruction. With each step you can follow the flow of the program, and see how the values of variables change.
Here I’ve stepped forward a few lines, and the source window has changed to show the “scrDoImportantThing” script.
When you have a lot of variables in your code, it may be difficult to find the one you are interested in. Right click on the header at the top of a window, and you will get some options to change to a different window type (or to split into multiple different windows).
Open a “Watches” window, and you can type in the names of any variables you are interested in. Here you can easily see the value of the “mystring” global. Note that the program has stopped at the line with the yellow highlight, but that line of code has not yet been executed.
Data structures and arrays in GMS are extremely useful, but when things go wrong it can be tricky to know why. With the new debugger you can view the contents of all your data structures and arrays.
Because data structures are stored as an index value, you need to right click on the variable to show a list of structure types to display. For arrays on the other hand, you only need to expand the node to see the contents.
Here I’ve added a breakpoint in a Create event in GMS, causing the game to halt immediately on start-up. You can see how the “array” variable has had zero values assigned for the positions which were not set in code.
Although the new debugger is still in the early stages of development, it provides a number of useful features which were not available before, with the added bonus of being able to debug on devices. We are already finding it to be a useful tool, and hopefully you will too!