To walk through the use of preprocessor directives, let's handle one such platform that needs some attention, that is, Windows 8. In Unity's implementation on Windows 8 (due to its asynchronous way of working), they have added some specialized classes because the default implementations of these classes are not available on Windows 8 (in this case, the File class). On Windows 8, you need to use the UnityEngine.Windows.File class instead of the normal UnityEngine.File class.

So, open up the GameState script and update the following code by adding the highlighted snippet:

  public static void SaveState()
  {
    try
    {
      PlayerPrefs.SetString("CurrentLocation", Application.loadedLevelName);
      var playerSerializedState = SerializerHelper.Serialise<PlayerSaveState>
      (currentPlayer.GetPlayerSaveState());
      #if UNITY_METRO
      UnityEngine.Windows.File.WriteAllBytes(saveFilePath, playerSerializedState);
      #else
      using (var file = File.Create(saveFilePath))
      {
        file.Write(playerSerializedState, 0, playerSerializedState.Length);
      }
      #endif
    }
    catch
    {
      Debug.LogError("Saving data failed");
    }
  }

In the preceding code, we have added a preprocessor directive for the UNITY_METRO target (and moved up the playerSerializedState variable as it can be used by all platforms).

Now when you build for Windows 8, it will use the first block of code. For all other platforms, it will use the second block.

We have to perform something similar for the LoadState class as follows:

  public static void LoadState(Action LoadComplete)
  {
    PlayerSaveState LoadedPlayer;
    try
    {
      if (SaveAvailable)
      {
        #if UNITY_METRO
        var playerSerializedState = UnityEngine.Windows.File.ReadAllBytes(saveFilePath);
        LoadedPlayer = SerializerHelper.DeSerialise<PlayerSaveState>
        (playerSerializedState);
        #else
        //Get the file
        using (var stream = File.Open(saveFilePath, FileMode.Open))
        {
          LoadedPlayer = SerializerHelper.DeSerialise<PlayerSaveState>
          (stream);
        }
        #endif
        currentPlayer = LoadedPlayer.LoadPlayerSaveState(currentPlayer);
        }
      }
      catch
      {
      Debug.LogError("Loading data failed, file is corrupt");
    }
    LoadComplete();
  }

Additionally, since the File class on Windows 8 only returns a byte array (byte[]), we need another deserialize function to work with the byte arrays instead of a stream. So, open the SerializationHelper script and add the following method:

public static T DeSerialise<T>(byte[] input)
{
  T output = default(T);
  //Create an XML formatter
  var serializer = new XmlSerializer(typeof(T));
  try
  {
    //Create an in-memory stream with the serialsed data in it
    using (var stream = new MemoryStream(input))
    {
      //Deserialize the data from the stream
      output = (T)serializer.Deserialize(stream);
    }
  }
  catch { }

  //Return the deserialized output
  return output;
}

Finally, one last fix. If you build for Windows 8 now, you will still have one error that remains in the SerializationHelper script. This is because the implementation of the MemoryStream class on Windows 8 doesn't have a GetStream method. Now, you can use another preprocessor directive and use a different implementation for Windows 8. However, in this case, if you simply switch to using the ToArray() method, it'll give you the result you want.

Currently, there have been a few inconsistencies among the builds of Unity. In some builds, the project works fine; in others, it crashes when you try to use the singleton classes.

In testing, it seems as though the execution order of singletons is altered, and they are actually destroyed after they are created. This mostly seems to affect the .NET-based builds.

If this happens, you will need to compensate with a minor update to the singleton script in AssetsScriptsClasses and update the OnDestroy method with the following code:

  public void OnDestroy()
  {
    #if !UNITY_METRO
    applicationIsQuitting = true;
    #endif
  }

By specifying !UNITY_METRO, we are stating that this code should be run on all platforms except Windows 8 (in the last tested build 4.5.2, Windows phone was unaffected). If you find this occurring on other platforms, add them to the ignore list. Consider the following instance:

#if !UNITY_METRO && !UNITY_ANDROID

This process doesn't actually destroy the singleton script as it is recreated each time it is used (if it has already been destroyed). However, this flag is there to ensure that it is not recreated when the application is actually shutting down.

Once you have built a project for the .NET platforms, you have a ready-to-run solution.

The player that deploys with the project also gives you indirect access to all the components and game objects within your scenes through the UnityEngine namespace.

For the game objects, you can simply query with the GameObject.Find method, as shown in the following code example:

var _cube = UnityEngine.GameObject.Find("Cube");

The preceding code will give you a game object that you can manipulate however you wish to, as if you were in Unity itself.

Alternatively, if you want to access scripts or non-standard content, you will need to cast the objects you search for to use them properly. Refer to the following example:

var mainScript = (MainScript)UnityEngine.GameObject.FindObjectOfType(typeof(MainScript));

This will give you a reference to an instance of a class of the MainScript type in your current scene.

The second method to access your Unity project from .NET platforms (such as Windows) is to expose specific variables outside the confines of your game or app.

To do this, declare a static variable within a class in your project, as shown in the following example:

public class MyExternalCass : MonoBehaviour 
{
  public static bool TurnOnAds;
}

Then, from your project, once you have built it, you can access this variable using the following code:

MyExternalClass.TurnOnAds = false;

You will then have the logic in your game to make use of these variables.

We covered events back in Chapter 5, NPCs and Interactions, to enable a loose coupling between an action and a dependency. We can reuse events to bridge the gap between Unity and the .NET platforms such as Windows and Windows Phone.

We will begin by defining a static event in Unity, which is intended to indicate an action the project needs the native platform to enact:

public static EventHandler PurchaseRequested;
public static void Purchase(string productID)
{
  if (PurchaseRequested != null)
  {
    PurchaseRequested(productID, null);
  }
}

The previous code sets up a delegate that can be used to enact an in-app purchase on the native platform. When requested in code, it tells whatever object is listening that the user wishes to purchase an item in the game.

Then, in the platform project, you will hook up to the delegate to perform the action when the event is raised, for example, on Windows Phone to complete a purchase, you would need to use the following code:

private void Unity_Loaded()
{
  //Hook up the IAP request to platform
  InAppPurchase.PurchaseRequested += PurchaseRequested;
}
private void PurchaseRequested(object sender, EventArgs e)
{
  var ProductId = (string)sender;
  //Purchase requests must be done on UI thread so use dispatcher
  Dispatcher.BeginInvoke(() => PurchaseItem(ProductId));
}

private async void PurchaseItem(string productID)
{
  //Do stuff to purchase the item from the store
}

The code hooks up to the previous PurchaseRequested event in the InAppPurchase class, and when a purchase is requested, it is routed to the UI thread and the item is purchased.

The example is kept simple just to demonstrate one method for your Unity project to communicate with the platform solution.

The only other method to enable the platform features in your Unity project is to create your platform class library and embed that library in your project.

To enable this, Unity has even more special folders in the Assets folders. The root folder of this structure is the Plugins folder, shown as follows:

To enable your plugin to work for each platform, you will need to install it in each of the previous folders per platform.

However, on the .NET platforms, you also need an attritional editor plugin (explained in detail in the next section) that provides the basic interface for your plugin due to the way .NET plugins are compiled.

namespace MyAwesomePlugin
{
  public class MyPluginClass
  {
    public static string GetPlatform
    {
      get
      {
        return "This is the Editor";
      }
    }
  }
}

namespace MyAwesomePlugin
{
  public class MyPluginClass
  {
    public static string GetPlatform
    {
      get
      {
        return "Welcome to Windows 8";
      }
    }
  }
}

string WhatsMyPlatform = MyAwesomePlugin.MyPluginClass.GetPlatform;