Developing with Unity for MonoGame

This is part one of a multi-part blog post about developing with Unity for MonoGame. Mombari is an upcoming game for Windows Phone 8. First take a look at the first gameplay video of Mombari.

I sat in the audience as David Helgason announced the support for Windows Phone 8 at the Unite conference 2012 in Amsterdam.

I expected it in the summer of 2013, but it could be available sooner, especially if one takes this blog entry into account: Unity 4 Beta program for Windows Phone 8 apps

So why MonoGame then?

MonoGame makes sense when you consider that the framework has supported Windows Phone 8 very early and this approach has allowed games testers to already test the game during the early stages of development on the real target device.

A First Overview

Overview

FFWD is an open-source framework written by Thomas Gravgaard from the Danish company PressPlay that allows you to port your Unity3D projects to XNA.

So wait, XNA isn’t supported on Windows Phone 8, right? On current Windows Phone 8 devices there is only a restricted version of XNA for backward compatibility available. Since you can’t use the new features of the hardware its only role is to run WP7 apps. Then MonoGame entered into the frame. MonoGame is an open-source framework that implements Microsoft’s XNA 4 framework on several platforms, including Windows Phone 8. It is developed thanks to several volunteer developers.

The game is developed and tested in Unity. FFWD has a two-fold job: it converts the Unity project into a XNA project at compile time, and at runtime it emulates a subset of the Unity runtime environment on top of XNA.

The XNA part has been overtaken by MonoGame. Underneath MonoGame one finds SharpDX, which is a tight C# wrapper around the native DirectX API. SharpDX is also an open-source project started by the developer Alexandre Mutel. MonoGame on Windows uses SharpDX as an interface to the native DirectX functionality.

Both MonoGame and SharpDX are actively maintained.

The Beginning

I always want to test for showstoppers at the beginning of a project and not when you have already made substantial progress and burned a lot of your budget.

To be frank, what I first thought about actually using this stack of frameworks was that it wouldn’t work. I started to play around with MonoGame and then I gave myself two weeks to build a prototype with the core elements and was prepared that I would fail somewhere.

Interestingly, the prototype actually ran really well.

That’s it for today. See in the next part of the blog post what a typical turnaround cycle looks like: Unity -> FFWD -> VS2010 Content Pipeline -> VS2012 -> Windows Phone 8 Device.