Debugging typically refers to error-busting techniques for runtime use; that is, it refers to the things you can do to find and correct errors when your game is running. This understanding of debugging, of course, presupposes that your code is already valid and compiled. The implicit assumption is that you can write valid statements in C# and compile code, and you just want to find runtime errors that occur as a result of program logic. Thus, the focus is not on syntax but on logic, and this is indeed true. However, in this section, I'll speak very briefly about code compilation, about writing valid code, and using the console to find and correct errors of validity. This is important, both to introduce the Console window generally and also to establish a firm basis of thinking about debugging in more depth. Consider the following code sample 2-1 script file (ErrorScript.cs):

01 using UnityEngine;
02 using System.Collections;
03 
04 public class ErrorScript...

Perhaps, the oldest and most well-known debugging technique in Unity is to use Debug.Log statements to print diagnostic messages to Console, thus illustrating program flow and object properties. This technique is versatile and appealing because it can be used in practically every Integrated Development Environment (IDE) and not just MonoDevelop. Further, all the Unity objects, including vector and color objects, have a convenient ToString function that allows their internal members (such as X, Y, and Z) to be printed to a human-readable string—one that can be easily sent to the console for debugging purposes. For example, consider the following code sample 2-3. This code sample demonstrates an important debugging workflow, namely, printing a status message about an object at its instantiation. This script, when attached to a scene object, prints its world position to Console, along with a descriptive message:

01 using UnityEngine;
02 using System...

The following code sample 2-3 demonstrates the convenience of the ToString method when used in conjunction with the Debug.Log debugging. ToString lets you convert an object to a human-readable string that can be output to Console. In C#, every class inherits the ToString method by default. This means that using inheritance and polymorphism, you can override the ToString method of your class that customizes it as required and produce a more readable and accurate debug string that represents your class members. Consider the following code sample 2-4 that overrides ToString. If you get into the habit of overriding ToString for every class you make, your classes will become easier to debug:

using UnityEngine;
using System.Collections;
//--------------------------------------------
//Sample enemy Ogre class
public class EnemyOgre : MonoBehaviour 
{
//--------------------------------------------
//Attack types for OGRE
public enum AttackType {PUNCH, MAGIC, SWORD,...

Debugging with abstract or textual representations of data (such as Debug.Log) is often adequate but not always optimal. Sometimes, a picture is worth a thousand words. So, for example, when coding the line-of-sight functionality for enemies and other characters that allow them to see the player and other objects whenever they come in range, it's useful to get a live and graphical representation of where the line of sight actually is in the viewport. This line of functionality is drawn in terms of lines or as a wireframe cube. Similarly, if an object is following a path, it'd be great to draw this path in the viewport that displays it as a colored line. The purpose of this is not to create visual aids that will really show in the final game but simply to ease the debugging process that lets us get a better idea of how the game is working. These kinds of helpers or gizmos are a part of visual debugging. Unity already provides us with many gizmos automatically, such as the...

When you compile and build your game to distribute to testers, whether they're collected together in an office or scattered across the globe, you'll need a way to record errors and exceptions as and when they happen during gameplay. One way to do this is through logfiles. Logfiles are human-readable text files that are generated on the local computer by the game at runtime, and they record the details of errors as they occur, if any occur at all. The amount of information you record is a matter for careful consideration, as logging too much detail can obfuscate the file and too little can render the file useless. However, once a balance is reached the tester will be able to send you the log for inspection, and this will, hopefully, allow you to quickly pin-point errors in your code and repair them effectively, that is without introducing new errors! There are many ways to implement logging behavior in Unity. One way is using the native Application class to receive exception...

It's sometimes claimed that Unity has no debugging tools built into the editor, but this is not quite true. With Unity, you can play your game and edit the scene at the same time while the game is running. You can even observe and edit properties in the Object Inspector, both private and public, as we saw earlier. This can give you a complete and graphical picture of your game at runtime; and allow you to detect and observe a wide range of potential errors. This form of debugging should not be underestimated. To get the most from in-editor debugging, activate the Debug mode from the Object Inspector by clicking on the context menu icon in the top-right corner of the inspector and then choose Debug from the menu, as shown here:

Accessing the Debug mode from the Object Inspector

Next, make sure that your viewports are configured appropriately so that they allow you to see both the Scene and Game views simultaneously during the Play mode, along with the Stats panel. To achieve...

One additional tool that's used partly for debugging and partly for optimization is the Profiler window, which is available only in Unity Pro by clicking on the Profiler tab in Window in the application menu, as shown in the following screenshot. In short, the profiler gives you a statistical top-down view of how time and workload is distributed across the different parts of your game and across system hardware components, such as the CPU and graphics card. Using profiler, you can determine, for example, how much time is consumed by camera rendering in the scene compared to physics calculations or to audio functionality, as well as to other categories. It lets you measure performance, compare numbers, and assess where performance can be improved. The profiler is not really a tool that alerts you to the presence of bugs in your code specifically. However, if you're experiencing performance problems in running the game, such as lags and freezes, then it could guide you to...

Earlier, we encountered the Debug.Log method of debugging to print helper messages to the console at critical moments in the code to help us see how the program executes. This method, while functional, however, suffers some significant drawbacks. First off, when writing larger programs with many Debug.Log statements it's easy to effectively "spam" the console with excessive messages. This makes it difficult to differentiate between the ones you need and the ones you don't. Second, it's generally a bad practice to change your code by inserting the Debug.Log statements simply to monitor program flow and find errors. Ideally, we should be able to debug without changing our code. Therefore, we have compelling reasons to find alternative ways to debug. MonoDevelop can help us here. Specifically, in the latest releases of Unity, MonoDevelop can natively attach itself to a running Unity process. In doing this, we get access to a range of common debugging...

A Watch window allows you to view the value of a variable that's active in memory in the current step, and this includes both local and global variables. One way to quickly add a watch for a variable while it is in the break mode is to highlight it in the code editor and then hover your mouse over it. When you do this, leaving the mouse hovered for a few seconds, a pop-up window appears automatically. This window allows the full inspection of a variable, as shown in the following screenshot. You can contract and expand the members of a class and examine the state of all its variables.

Inspecting a variable with hover watches in the break mode

You can inspect practically all variable values for any active object using this hover method. However, typically, you'll want to place a more permanent watch on a variable and even a group of variables so that you can see their values collated together in a list. For this, you can use the Watch window docked...

After reaching a breakpoint and inspecting your code, it's likely that you'll want to exit from the break mode and continue program execution in some way. You might want to continue program execution, which effectively hands program control back to Unity. This allows the execution to continue as normal, until it meets the next breakpoint, if any. This method effectively resumes execution as normal, and it'll never pause again unless a new breakpoint is encountered. To continue in this way from MonoDevelop, press the F5 key or press the play button from the MonoDevelop toolbar. Otherwise, choose the Continue Debugging option in Run from the MonoDevelop application menu, as shown here:

Exiting the break mode and resuming with Continue Debugging

There are many occasions, however, where you don't want to continue execution in this way. Instead, you want to step execution over the lines of code, line by line, evaluating each line as it progresses...