Projects in Unity can be structured as collections of scenes, and scenes can be thought of as the different screens that are displayed while the game runs.

Upon launching, a game generally starts with a so-called main screen or home screen. This screen displays the relevant options to interact with the game. There is usually a Play button to launch the game, a button to edit game options such as audio and graphics, another button to launch a multiplayer session, and so on.

In this example, the home screen will be a scene in the Unity project, and each stage of the actual game will be a scene of its own, such as the Game Won and Game Lost screens. The following diagram shows the screen flow of our prototype:

Scenes and their contents are loaded when required at runtime through scripting. When a scene is loaded, all the game objects and components that were saved in that scene when creating the game are loaded as well.

On the other hand, when the scene is unloaded, all game objects that were in that scene are destroyed, so a problem may arise. As a game runs, a collection of data about the player's actions and achievements is made, for example, the level they are playing, how they are performing, whether they edited any game option, and the like.

If game objects in the scenes are destroyed upon switching from one scene to another, how do we keep track of this data from the start to the end of the game?

Video games are usually designed as so-called Finite state machines. Finite state machines are a technique to restructure complex processes into a collection of states. Each state describes a specific condition that the process may enter, and it interacts with other states by getting and passing small pieces of information to them.

Each state is thus a sort of black box that autonomously gets data, processes it, and then sends it to another state, with no state knowing what the other states actually do.

The advantage of this approach when designing software, such as video games, is that if you need to make heavy modifications to an important game function, you just have to edit the state that takes care of that function, without affecting the rest of your project.

With regard to the prototype we are building up, we plan to organize it as a finite state machine made up of different scripts that take care of each specific game state. So, we can get back to the beginning of this introduction: a finite state machine requires one object to be the manager that controls the flow of information and gives control to the appropriate state as the game runs. But we stated earlier that when a scene is unloaded, all game objects in that scene are destroyed. So how do we save the game manager?

Unity features two important methods, called Application.LoadLevel() and DontDestroyOnLoad(), that allow us to load new game scenes at runtime and prevent game objects from being destroyed upon loading a new scene.

Application.LoadLevel() is called to load a new scene at runtime. It accepts either a string parameter with the scene name or an int parameter for the scene index.

You can read more about the Application.LoadLevel() method by referring to the link http://docs.unity3d.com/ScriptReference/Application.LoadLevel.html.

DontDestroyOnLoad() takes a game object as a parameter and prevents that game object from being destroyed. More details about this method can be found at http://docs.unity3d.com/ScriptReference/Object.DontDestroyOnLoad.html.

In the following recipe, we create the game manager for the prototype and use it to switch between the main and the game scenes.