Play testing
You've now completed your first game in Unity! It's time to take it for a test run and then finally build it. Testing in Unity firstly consists of pressing play on the toolbar and simply playing your game to see that it works as intended from the perspective of a gamer. In addition to playing, you can also enable debugging mode from the Object Inspector to keep a watchful eye on all public and private variables during runtime, making sure that no variable is assigned an unexpected value.
To activate the Debug mode, click on the menu icon at the top right corner of the Object Inspector and, from the context menu that appears, select the Debug option. See Figure 2.32:
After activating the Debug mode, the appearance of some variables and components in the Object Inspector may change. Typically, you'll get a more detailed and accurate view of your variables, and you'll also be able to see most private variables. See Figure 2.33 for the Transform component in Debug mode:
Another useful debugging tool at runtime is the Stats panel. This can be accessed from the Game tab by clicking on the Stats button from the toolbar. See Figure 2.34:
The Stats panel is only useful during the play mode. In this mode, it details the critical performance statistics for your game, such as Frame Rate (FPS) and memory usage. This lets you diagnose or determine whether any problems may be affecting your game. The FPS represents the total number of frames (ticks or cycles) per second that your game can sustain on average. There is no right, wrong, or magical FPS, but higher values are better than lower ones. Higher values represent better performance because it means that your game can sustain more cycles in one second. If your FPS falls below 20 or 15, it's likely that your game will appear choppy or laggy as the performance weight of each cycle means it takes longer to process. Many variables can affect FPS, some internal and some external to your game. Internal factors include the number of lights in a scene, vertex density of meshes, number of instructions, and complexity of the code. Some external factors include the quality of your computer's hardware, number of other applications and processes running at the same time, and amount of hard drive space, among others.
In short, if your FPS is low, then it indicates a problem that needs attention. The solution to that problem varies depending on the context and you'll need to use judgement, for example, are your meshes too complex? Do they have too many vertices? Are your textures too large? Are there too many sounds playing? See Figure 2.35 for the coin collection game up and running. The completed game can be found in the book companion files in the Chapter02/End folder: