Unity3D Windows Store – Part 1: Building The App

At slash games, we’ve started working on our first very own game project now, and Windows Store is one of our target platforms. While being quite experienced with Unity3D, there were some challenges building our first Windows Store app with that engine, and I’d like to share some of our learnings with you.

If you’re thinking about porting your Unity game to the Windows Store platform as well, take a look at the official Unity porting page.

Initial Situation

We’ve been starting with a more or less empty 2D Unity project. More or less means: While there wasn’t any game logic or other game-related code yet, we planned to use a handful of plugins we’ve been using in our previous projects:

  • NGUI. Probably the best-known UI toolkit for Unity. We didn’t want to wait another five years for the new Unity GUI system, and NGUI served us well in previous projects.
  • FingerGestures. Unity plugin that abstracts from the underlying hardware and detects common input gestures, allowing you to handle touch events and mouse clicks the same way.
  • Spine. 2D skeletal animation for games with Unity support. Allows your artists to create 2D animations just like you would for 3D games.
  • log4net. .NET library that allows logging to different targets and to enable, disable or change the log level without having to recompile the application.
  • Slash Games Framework. We’ve been using and improving our own game framework at slash games for over a year now. The slash games framework is a collection of .NET libraries that provides a lot of features like AI, entity systems, custom collections or math classes for all of our games.

After having added all of these plugins to the empty Unity project, the first thing I tried to do was building the player for the Windows Store target platform, before creating any game objects or scenes.

Building the Unity Player

The first try failed immediately. Verbose log output told me that log4net was relying on a whole bunch of namespaces that aren’t available for Windows Store apps, most of which are related to File I/O:

Error building Player: Exception: Failed to run Reference Rewriter with cmdline –target=”Temp/StagingArea\log4net.dll” –framework=”C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5″ –platform=”C:\Program Files (x86)\Windows Kits\8.0\References\CommonConfiguration\Neutral\Windows.winmd” –support=”Temp/StagingArea\WinRTLegacy.dll” –system=Unity –dbg=pdb –alt=System.Xml.Serialization.[Temp/StagingArea\log4net.dll]

Error: type System.DBNull doesn’t exist in target framework. It is referenced from log4net.dll at System.Void log4net.Appender.AdoNetAppenderParameter::FormatValue(System.Data.IDbCommand,log4net.Core.LoggingEvent).

Error: type System.DBNull doesn’t exist in target framework. It is referenced from log4net.dll at System.Void log4net.Appender.AdoNetAppenderParameter::FormatValue(System.Data.IDbCommand,log4net.Core.LoggingEvent).

[…]

Error: method System.Boolean System.IO.File::Exists(System.String) doesn’t exist in target framework. It is referenced from log4net.dll at System.Void log4net.Appender.RollingFileAppender::ExistingInit().

As we had experienced similar issues with Unity web players before, there was already a logging abstraction layer in our framework, and a compilation symbol log4net that was used for wrapping log4net-specific code. Thus, for eliminating the above errors, I just had to switch to a configuration without that compilation symbol defined in Visual Studio.

Rebuilding all libraries and giving it another try created a Visual Studio solution for a Windows Store app that you need to build in order to generate the app package itself, similar to developing iOS apps with Unity.

Building the Windows Store Solution

At first, trying to build the solution in Visual Studio failed as well:

Error: DEP0700 : Registration of the app failed. Windows cannot install package MobileProject because the package requires architecture ARM, but this computer has architecture x64. (0x80073cf3)

The solution exported by Unity is initially set to the active solution platform ARM. Opening the configuration manager and switching to x86 (not x64) allowed me to successfully compile the app.

Running on Local Machine

While you could start the app on the local machine now, it crashed almost immediately with the meaningless error message

Template.exe has triggered a breakpoint.

You could step two or three times through mscorlib before the app was killed. After some research I found out that another configuration setting was wrong: For Unity games, you are supposed to build the solution with the Master configuration. Opening the configuration manager again and switching the active solution configuration fixed the problem.

In fact, not doing so would lead to a failed certification test when running WACK for the app:

The debug configuration test detected the following errors:

  • The binary UnityPlayer.dll is built in debug mode.

I’ll go into details about WACK and how to pass all tests in the next post of this series. I’d like to add that I highly recommend checking in the Visual Studio solution into version control at this point. Re-building the Unity player will replace the Data folder of your solution, only. Thus, the other files, particularly your manifest and any native code you write can be stored in your Git repository (or whichever VCS you prefer).

Feel free to share your thoughts or ask any questions in the comments below!

Next: Unity3D Windows Store – Part 2: Windows App Cert Kit

Author: npruehs

Nick Pruehs is a Co-Founder of Slash Games, Hamburg. In 2009, he graduated as “Best Bachelor” in computer science at Kiel University. Two years later Nick finished his master’s degree in “Sound, Vision, Games” at Hamburg University of Applied Sciences, becoming the Lead Programmer of Daedalic Entertainment shortly after.

6 thoughts on “Unity3D Windows Store – Part 1: Building The App”

  1. We developed natively previously and just ported over the Unity and then we found the “Any CPU” configuration is no longer available. There is only “x86” or “ARM”, which likely means that we cannot publish to both Windows 8 platform in one package as before. Are you encountering the same?

    1. I actually went ahead and create the submission package, selecting both x86 and ARM, resulting in 2 packages, both of which can be uploaded to the store (though I have not actually published yet). Had always used “Any CPU” when developing native and did not realized that you can upload multiple packages.

Questions? Comments? Suggestions? Your turn! :)