Handling the Windows Phone 8 Back Button in Unity

Windows Phone apps must support the hardware back button. This button gives the user control of their phone, such as easily returning to the previous screen or exiting an application.

Since Unity is cross-platform, there is no specific command to support Windows Phone’s back button, but it’s easy to implement.

Unity treats the Back button as if it’s a keyboard’s Esc (escape) key, so we just need to detect when this ‘virtual’ Esc key is pressed. Add the following code where you detect user input (typically the Update() method):

#if (UNITY_WP8 && !UNITY_EDITOR) // only run this if the target platform is WP8 and the game is not running in the Unity editor
            if (Input.GetKey(KeyCode.Escape))
            { 
              OnBackButtonPressed(); 
            }  
#endif

The above code is calling a method called OnBackButtonPressed(), which you must now create, and add in code to take the appropriate action (e.g. to navigate to another screen or to close the application).

void OnBackButtonPressed()
{
  // add code here to handle the back button press
  Application.LoadLevel("PreviousScreen");
}

I put the escape key detection code in every scene in a script’s Update() method, and create a specific OnBackButtonPressed() method for each scene. For example, pressing Back from the Settings or About screens should take the player back to the main menu. Perhaps in your game pressing back on the game screen should pause the game, then return to the menu if is pressed a second time.

Keep the user experience and Windows Phone guidelines in mind when implementing the Back button. It must work intuitively. Don’t use the Back button as a control for your game. Use it to take the user back one level in the hierarchy of your game.

Plug time:
To see this technique in action in an actual Unity game on Windows Phone you can check out my game Clowntraptions:
http://www.grogansoft.com/Presskit/sheet.php?p=clowntraptions

Beware of Class/Namespace Duplication in Unity Windows Games

I recently had some trouble building the Windows Store version of my upcoming game, Clowntraptions. I was getting the bizarre error below:

Image

‘Window’ is a standard class in WinRT (Windows.UI.Xaml.Window), and this error was troubling! I couldn’t build the project let alone deploy and test it. What was wrong?

I had a script in my Unity project called ‘Window’ holding a class called, of course, ‘Window’. This conflicted with the Visual Studio code that referenced a different ‘Window’ class.

So I renamed the class in my Unity project to something else and those errors went away. The class in question was actually a part of a plugin, so I wasn’t really to blame, and the plugin creator can’t be blamed for inadvertently using the same name as a Windows RT class.

Relieved, I rebuilt from Unity, opened up my game in Visual Studio, and hit the debug button to have a play test…and instead of my awesome circus game I got this before the game even managed to get past the splash screen:

Image

Sigh. The web build was working fine, and more notably the Windows Phone 8 build was working fine…so what was causing this issue in the Windows Store build (and it was an untouched, fresh build with no extra code or plugins added in – straight from Unity). Was it a problem with the recent Unity 4.5 update? I tried everything…and was on the verge of filing a bug report…but then I had another look at my code and realised I’d made the exact same mistake I’d only just repaired. I’d created my own script a few days prior, and called it ‘Notifications’, which Visual Studio got confused with ‘Windows.UI.Notifications’. I renamed my script and class to something different and, Hey Presto! My build was then successful.

So if you come across weird errors like above in Unity projects that work on other platforms, make sure you don’t have any poorly named classes that clash with existing Windows classes.

To avoid these mistakes:

  • Keep your scripts organised in folders (and subfolder if required) so they are easy to browse through.
  • Give your scripts/classes descriptive names (avoid single words).
  • Make good use of namespaces in your project.