About Me• Co-Founder of 282Productions• Working in the Israeli game development industry for 2 years• Released several Unity3D powered games• Currently working on several Unity3D ports to Windows 8
Goals• Create a Windows 8 App porting “check-list”• Highlight problems and pitfalls encountered porting to Win8,and present practical solutions• Give hands on examples of new Win8 features integration
Getting Started• To get started you’ll need:• A computer running Windows 8• Visual Studio 2012• Windows Developer Certificate on that computer – you’ll beprompted to obtain one automatically when first running VS• Unity3D 4.x with the Windows Store Apps exporter
Hello, Unity4!• Windows Store Apps exporter is available from Unity4,which means we might have to upgrade• Unity4 introduced a new GameObject active state behavior• In short, SetActive now affect all of an object’s ancestors• This has a potential of breaking apps that make use ofGameObjects’ active state in certain situations
Deprecated Types in NET4.5• By default, when targeting Windows Store Apps, Unitybuilds the CSharp assembly targeting .NET4.5• .NET4.5 removed some obsolete types such as ArrayListand Hashtable• These types existed historically, they were introduced in.NET1.1 and became obsolete with the addition of genericsin .NET2.0• For some reason, ArrayList and Hashtable are stillsomewhat commonly used.
Handling Deprecated Types• Do NOT use ArrayList and Hashtable, use List<T> andDictionary<Tkey,Tval> instead• If these types are used in a third party addon, find areplacement solution• If that’s not an option, you can build your CSharp assemblylike before, by setting Project->Build Settings->PlayerSettings->Compilation Override to NONE. This will not allowyou to access any of the new features in .NET4.5 though.
New Compiler Directives• With Unity4, two new compiler directives were added.#if UNITY_METROThis will compile, whenever theactive build target is Windows StoreApps.Usage:#if UNITY_METROm_versionString += “w8”#endif#if NETFX_COREThis will compile only when buildingan app targeting Windows Store(not in editor more(.Usage:#if NETFX_COREusing Windows.UI.XAML;#endif
Managed Metro Plugins• One major change in the Windows Store requirements isthat no WIN32 API calls are made from your app• In some cases, this would require us to modify or replacelinked libraries• Unmanaged libraries are handled as before• Before, managed libraries could be present anywhere withinthe project. They were parsed and added to the reference listas soon as they were added to the project
Managed Metro Plugins• Managed assemblies built targeting .NET4.5 can’t be placedanywhere in the project. Unity will still try to resolve linksagainst Mono, which will obviously fail, and you won’t beable to build your project.• Managed .NET4.5 assemblies must be placed under/Assets/Plugins/Metro• This, however, does not solve everything. Currently,assemblies under Plugins/Metro won’t be added to theproject reference list
Managed Metro Plugins• To solve this:• Create a mock assembly with matching method signaturesbut no implementation• Target .NET3.5 and build it• Add it to your project under /Assets/Plugins• This will add the assembly to the project reference list, butwhen building for Store Apps, it will get substituted by theversion under /Assets/Plugins/Metro
Managed Metro Plugins• Another quick word about assemblies in Win8 Store Apps:• Make sure you do not have any assemblies built in debugmode when trying to deploy your application• Apps referencing debug assemblies will not pass theautomated windows store certification
Ready to Export• Unity will export our project as a Visual Studio project, whichthen needs to be built and deployed through VS• Our target VS project has two main flavors: D3D and XAML• D3D Projects create single view application projects with aD3D context used for rendering Unity’s display• XAML Projects use the same D3D view, but with the additionof a XAML UI layer on top• According to Unity, D3D projects give better performance, asa tradeoff for the missing XAML layer
Metro Apps Threading Model• A metro app’s main thread is the UI thread• Guidelines require us to execute long running tasks inseparate threads• Some operations, mainly UI related, can only be executedfrom the UI thread• By default, Unity will run in a separate thread• Most likely 80% of all integration problems between unityand windows are thread related.
Unity <-> Windows Interop• Unity is NOT thread safe• Manipulating any object inheriting from UnityEngine.Objectoutside of the engine execution thread will either raise anexception or cause access violation• We’ve just mentioned windows UI tasks can only beexecuted from the UI thread, and Unity runs in a separatethread. How do we get them to communicate?• Using AppCallbacks!
AppCallbacks• AppCallbacks is a singleton object used to bridge betweenthe Unity Player and the Windows Runtime• On export, AppCallbacks is automatically defined in ourApp.cs source file• public AppCallbacks(bool appRunsOnUIThread);• By default, AppCallbacks will be initialized withappRunsOnUIThread = false• Don’t change that, understanding the threading modelinstead of hacking around it
Making That Useful• AppCallbacks.Instance.IntegrateIntoAppThread( item, sync)• Item = AppCallbacksItem, void task() delegate
Snapped View• Windows Store Apps can be resized to one of four sizes – FullScreenLandscape, FullScreen Portrait, Filled or Snapped
Reacting To Resolution Changes• Add an event to our game that will be used to notify game elements theresolution has changed. From here the event will propagate into oursystem• Next, attach the desired behavior to the event handlers: pause the game,display a message, etc…
Reacting To Resolution Changes• In your VS solution, add an event handler toWindow.Current.SizeChanged• And you’re done!
Live Tiles• Let’s try something more daring! Let’s update the app live tile from withinour CSharp assembly!
Debugging & Testing• Feature Support:• We can debug the code in our CSharp assembly from VS• We can either deploy and debug locally, or on a remotemachine• We can create test packages and distribute for testing
Debbuging CSharp Assembly• To debug our CSharp assembly in Visual Studio, we need toadd Unity’s CS project to our VS solution• In VS, right click the solution in the solution explorer, selectAdd->Existing Project, browse to the Unity project root folderand add the Assembly-CSharp.csproj• This will add our CSharp assembly to the solution view, herewe can browse our source files and add breakpoints
Remote Debugging• To debug remotely, we will need to install the VS2012 RemoteDebugging Tools on the target machine• The installation can be found on the VS2012 install DVD, orcan be downloaded from Microsoft’s website• Once installed, the target machine and the host need to beconnected to the same network, preferably through wiredconnection• To start debugging, select the “Play” button dropdown, andswitch to remote machine. This will prompt the remote debugconfiguration dialog
Deploying Test Builds• To distribute test builds, we will need to pack the application• From the toolbar select Project->Store->Create AppPackages• When asked if you want to package for the Windows Store,select NO• Continue through the remaining dialogs, until you’ve got anapp package ready.• Distribute your app package for testing
Installing Test Builds• The test package output folder contains the package, thesigning certificate file, and an installation PowerShell Script• To install it on a test machine, right click the PowerShell scriptfile Add-AppDevPackage.ps1, and select “Run WithPowerShell”• This script will automatically install the package• Keep in mind that to install test packages, you must have avalid developer license on the target machine