In this section, we will change the Update() method, and then using a Switch statement, change the overall flow of our application.

About the only thing that will not change in the update is the debugTextMesh line at line 70, we are using it a bit more as you will see shortly.

A switch statement is like a gate controller. The programmer calls switch (with a variable) with a number of case statements or potential outcomes. Depending on the value of the variable determines which gate opens up. 

For instance, using the MusicVolume given in the preceding section as an example:

Switch(myMusic)
{
case MusicVolume.Loud:
{
//make the volume loud
}
break;
case MusicVolume.Medium:
{
//make the volume medium
}
break;
}

You could think about it like a road intersection with only one path out. While not great for roadways, it can be amazing when you are trying to direct the flow of traffic:

Also, some more lines of code:

In the two preceding screenshot, you can see the new version of Update(). We are now using the enum myAppstate to test against nine states. As certain combinations of conditions are met, we can control the flow.

In some cases, I have what is a series of dominos, meaning that one enum state is changed inside another case. There is a definite argument for this not being efficient. All of the statements that are in cases which are connected together in such as way could all be in the same case.

That is absolutely correct. Also, depending on the complexity of the decision, this could be controlled with a series of if/else statements. However, as a program grows and becomes more complex, not only can I add more to each state and case, but I can easily add more states to the enum itself. I can create all new paths for the flow to follow with minimal effort.

You may also notice that some of the states have no code at all other than our debuginfo, StartGame and EndGame. These states are here simply for planning ahead, for when we need them. Soon.

These final two functions in our ApplicationManager are mostly the same, but they have been changed to test against the condition set by my AppState enum, another very useful feature of the enum

It is also worth noting that there will be an error message that pops up until we write the SyncSpawnSkee class, which will be done in the next section.

Now, if we go back and look at our AppManager object in the Inspector, we can see the new entries that we need to change. We will wire this up in a bit, but first we need to write the class that will oversee spawning our network-friendly Prefab.

These changes will break another class, so we need to fix that real quick. Let's follow the following steps:

1. Open PlaceSkeeBallMachine.cs.
2. Search for ApplicationManager.Instance.skeeBallMachinePlacementSet = true; in line 126.
3. Select and delete that line.