Debugging and Building

The most “basic” form of debugging is achieved by the Debug.Log statement. In short, any Debug.Log statement will print out a string-based message to the Unity console window when executed at Run-Time. Debug.Log is not restricted to printing only string literals, such as “Hello World,” but also numerical values such as floats and ints and bools, by using their native ToString method, which is supported for all C# object types. This member converts an object’s internal values into a human-readable string. The primary use of Debug.Log is to help a programmer understand program flow, such as whether a specific function is called or whether a specific line is reached, and what variable values are at that time. Consider Code Sample 10.1. 1

Code Sample 10.1: Using Debug.Log to Print Console Messages 01 // Use this for initialization

The Debug.Log statement is especially convenient as a debugging tool. This is because it’s easy to use and works for all versions of Unity, in all operating systems, and it doesn’t depend on the code editor you use, whether MonoDevelop, Visual Studio, or another. In assembling Debug.Log statements, it’d be great, however, to have more control over how a specific object responds to the ToString method. When coding your own custom objects, you’ll want control over the actual string returned from ToString, allowing you to generate more descriptive and meaningful text that’s helpful when debugging. Well, you can do this, by simply overriding the ToString method in descendant classes! See Code Sample 10.2. 2

Code Sample 10.2: Overriding ToString to Improve Debugging of Objects 01 //Sample Ogre enemy class

One problem with using Debug.Log statements is that you, as a developer, only see and respond to them via the console window, when playing and debugging games from the Unity editor. If you send compiled versions of your game to testers, who could be anywhere worldwide, they won’t necessarily have the benefit of viewing any Debug.Log statements. They won’t be running your game inside the Unity editor. And, in most cases, they won’t even have the benefit of detecting or observing errors at all, except those that either crash the game or result in immediate and visible effects in gameplay. In all other cases, errors (or the causes of errors) pass unnoticed, and we want to solve that. Specifically, we can create an error logger feature. This detects errors, as and when they happen, and records them inside a text-based log file, using human-readable statements,

and saved externally to the application. This file can then be sent by testers back to us, the developer, for closer inspection. This helps us see what went wrong for the tester during their play session, and perhaps lets us reproduce the error on our system to begin solving it. The following class in Code Sample 10.3 (ErrorLogger.cs) can be added to an application for recording any errors to a text based log file. 3

Code Sample 10.3: ExceptionLogger.cs-Logs Errors to a Text-Based File 01 //---------------------------

The two central drawbacks to using Debug.Log for debugging is, first, that it requires you to edit the source code itself and, second, it can “spam” the console confusingly when inside loops. Ideally, when debugging, you want to take up a position outside the code, inspecting it from the outside looking in without ever changing it, except to correct a bug once found. Debug.Log corrupts this ideal. To resolve this, we can use MonoDevelop’s debugging feature set, which consists of many tools. The most critical is the breakpoint. This lets you mark a line in a source file at which execution should pause, or suspend, when it’s reached. Here, the developer may inspect the state of the application and its variables, and continue execution on a line-by-line basis, monitoring program flow as it unfolds. This can all be achieved without changing the code. Let’s see how. 4

To get started at setting a breakpoint for debugging, choose a line in your source file where execution should pause for inspection, and then choose Run > Toggle Breakpoint from the MonoDevelop application menu, or else press the keyboard shortcut F9. After setting the breakpoint, the line turns red and a red circle mark appears in the margin. 5

Next, you’ll need to attach MonoDevelop to the Unity Editor as a connected process, allowing MonoDevelop to detect when Unity enters Play-Mode and when gameplay should be observed. To do this, choose Run > Attach to Process from the application menu. 6

From the Attach to Process dialog, choose the Unity Editor from the process list. If you don’t see it listed, then make sure the Unity Editor is running, and make sure Unity Debugger is selected from the Debugger drop-down list. Then choose the Attach button. 7

Then switch back to Unity and click the Play button to run your game inside the Game tab. Execution automatically pauses when a breakpoint line is executed, and the Unity Editor is suspended completely, waiting for your input from MonoDevelop.