Salad Solutions is a compilation of educational resources developed by the GameSalad team. Resources include: Question of the Week answers, Cookbook highlights, and webinar videos.
In today’s Question of the Week, our Customer Support Team tackles a common user question, which is how to properly use the debugging tool.
Question of the Week: Using the Debugger
The Debugger is a little known tool that, when used correctly, can help you solve some of the trickier logic issues. In our inaugural “Question of the Week” post, we’ll not only cover how to use this potential life-saver, but also show you a neat trick for collecting meaningful metrics on your project.
First, the basics. The Debugger is divided into two core components: The Debugger window (found under View in the GS Creator menu bar), and the Log Debugging State behavior. Opening the Debugger window reveals an empty box, which as it stands doesn’t appear to be particularly insightful. That’s because for you to get the information you need, you’ll have to imbed the Log Debugging State behavior at key points in your
project’s logic.
For purposes of this post, let’s say you are working on an endurance-mode style game, where the player controls a spaceship that is constantly besieged by endless waves of enemies from all directions. Let’s call this game “Endurance-Mode”.
You’ve just discovered that your newly implemented logic that controls the spawning of unique Boss-style actors is not having its intended affect. Rather than using process of elimination to examine and tweak every single piece of logic related to this feature, we’re going to use the Debugger.
The Debugger allows us to narrow down the scope of the problem, by ruling out potential causes. We’ll be using it to find the answer for a couple key questions: Is the primary Boss-associated rule even being triggered? If so, are its “then” statements properly updating the appropriate attributes?
Here is a screenshot of the original logic, prior to adding in Debugger behaviors:
Note: The cut-off attribute names are “game.Enemy Waves Destroyed” and “game.Spawn Boss Wave”.
And now that same logic, but with Log Debugging Statement behaviors added:
The first Log Debugger Statement let’s us know whether this rule is properly triggering. The second statement confirms whether or not the game.Spawn Boss Wave attribute is false prior to the attempted attribute change. And finally, the third reports on if the attribute was indeed changed to true. Based on how these are reported in the Debugger window, we’ll have a clearer idea on where the problem lays. Check below for the results:
We know that the game.Spawn Boss Wave attribute’s original value should have been false. Since it wasn’t, we now have a good lead about where to look next. Accurate and timely information = faster debugging of your project.
While the above example is fairly straightforward, you can get a sense for how the Debugger allows for you to collect and review data that would be difficult or impossible to observe otherwise.
This concludes our primary example, but on the topic of reviewing data, let’s go over a different way you might collect and leverage Debugger information, using the same hypothetical spaceship project mentioned above. In Endurance-Mode, we eventually want the heroic protagonist ship to fall, since the longer the player is alive, the more points he or she earns. So, the game needs to increase in difficulty until their inevitable
demise is guaranteed, regardless of their skill level.
Different ways to increase difficulty are: spawn more enemy ships at one time; give enemy ships more health or strength; increase the overall speed of enemy ships; make the boss waves spawn more frequently; give the boss spawns new and more powerful abilities; etc. We know that simply spawning more enemies is easy to create logic around, but also more costly in terms of game performance. Before you make any change though, let’s collect more data using the Debugger tool.
As the logic behind spawning enemy waves in Endurance-Mode is a complex, we can’t say for sure that we aren’t already pushing the envelope on the number of simultaneous on-screen enemies. To check this, you would add a game attribute that kept track of how many enemies were currently active. When an enemy is spawned, this attribute would increase by 1, and when an enemy is destroyed, it would decrease by 1.
From there, we just make a timer that reports the number of active enemies to the Debugger window every 10 seconds, like so:
Which reports the following data:
Now, let’s move that data over into an excel program (I use OpenOffice.org, since it’s free). However, while copying and pasting directly from the Debugger window is quick and easy, it’s also unorganized:
To clean this up, highlight these cells and select the “Text to Columns” option, under Data in the menu bar. Select “Comma” and “Other” under “Separator options”. In the space provided by Other, type “:” (minus quotes). Next, delete the first two columns, insert a new first row, and add some labels:
Create a chart on this data, setting the Time column as the X axis and the Enemies column as the data set, and presto — interpretable metrics!
To get a better picture on what this data might indicate for further development of Endurance-Mode, we’d likely want to expand this out beyond a single minute. That said, this should give you an idea on how you can use the Debugger to gather actionable information based on what’s going on in your project.
Thanks for tuning in, and good luck!
Tip: We recommend commenting out (turning off) your Log Debugger Statement behaviors, especially if you have a lot of them. However, leaving them in shouldn’t significantly impact your app’s performance.
Tip: The Display Text behavior is great for quick checks on what’s going on in your project in real-time. Simply have it point to the game or actor attribute you’d like information on and then place the actor which contains the Display Text behavior somewhere where you can see it. And of course, you can use the Display Text and Log Debugging Statement behaviors at the same time to take advantage of both perspectives.
