Simple debugging in Unity. Cheap and Painless.

Debugging with Unity can be done very easily. You can for example, connect MonoDevelop to the Unity editor and set breakpoints and all that kind of stuff. This is explained pretty well in the official documentation here, so I will not talk about it on this post. Instead I will explain some alternative methods and tricks that can help you to debug your game that can be sometimes more convenient (because they are Unity exclusive).

First of all, I would like to remark that while you are making any program, great amount of your time and efforts is spent debugging. Depending on your methodology, the amount of time can be lower. In an ideal situation you would be using a TDD aproach, so you fix your bugs before they occur. Unity made a big step releasing the official test tools for Unity (I will write a post about such great plugin in the future). But the sad truth is that many times you can´t just write tests for a videogame.

Bug free software. What a big lie!

Your biggest friend while debugging in the Unity editor will be the console. The console will capture the prints and logs from your code and display them in the editor. It will also retain a reference to the monobehavior involved in the cast if you want (context), so you can click on a console message and the GameObject will be highlighted.

There is many ways of sending messages to the console. The first is using the static class Debug. Debug allows you to Log messages with context, errors, exceptions and warnings. There is another function called print (a wrapper for Debug.Log in the monobehaviour classes). These are all pretty much the same, the difference is that errors can stop the editor if the "Error Pause" option is selected in the console. If you double-click on the console line, it will point the line in the code where the error or log is inside monodevelop.

Click to highlight the context. Double click to go to the code.

Another way of pausing the editor is the the break method. You have to keep in mind though, that this is not the same as setting a breakpoint in the monodevelop. The pause in the editor will finish to run the frame you are at, so the function that called the break will also return before pausing. Still a good option when you do not need that precision.

Once you are paused in the editor, you can go step by step of your game clicking on the "Step" button at the right of the "Play" and "Pause" buttons in the middle top of the editor. This is good when you need to debug fast paced interactions inside the game.
 
The editor has also a "Debug mode". If this mode is activated, you can see in the inspector all the private information of the monobehaviour. Great to keep things hidden but accesible when needed. It really helps to know why your game is not working in a fast way, without needing to write a debugging line of code.

Debug mode allows you to see private variables. You still cannot modify them.

Lastly I will talk little bit about debugging outside the editor. Sometimes you cannot test your game in your computer. For example when you are testing mobile touch input for Ipad. In this situation is good to use simple GUITexts that will update the important variables of your game in the screen. Remember that GUITexts are affected by the resolution of your screen and can look very small once deployed.

Debug menu in Super Mario 64. Debugging can be also a creative task :)

In conclusion, you should know the tools that you have at your disposal and use the one that serves you best at any moment. In the end, there isn't a perfect solution to solve your problems, but there is always a faster one :)