The Trials of Ouya Porting using MonoGame

Over the past month, I have been working on porting my second XBLIG / XNA release Abduction Action! to Ouya using MonoGame. Since this is something I haven’t seen a lot of people doing, I thought I’d take a little time to talk about the experience so far. I should note also that I started this article several weeks prior to publishing it and have revised it heavily as I discovered new fixes and ran into new issues. This is also my first venture into the Android world (Ouya is an Android based device) so there has been some learning required there too.

There are a fair amount of pieces required to install in order to deploy games developed with MonoGame to the Ouya. I expect this is pretty much the same as it would be for any other Android device but this was my first experience going that route. I spent the first day of my time on this project installing things like a newer version of MonoGame (I have worked with MonoGame in the past for PC ports), Xamarin 2.0, and the Android SDK. There is a MonoGame website and a MonoGame portal on Codeplex and they don’t seem to be in sync with the installation instructions and requirements which made this all a bit confusing but eventually I got my game to deploy (and promptly crash).

Out of the box, I’d say about 90% of my game worked after getting it deployed. Controllers mostly work, gameplay works, graphics work. The major pieces that didn’t were sound, screen resolution, loading and saving, and per-pixel collision detection. Unfortunately these couple issues have proven trying to resolve. While I have found a couple knowledgeable sources for help and information, there does not seem to be many people using MonoGame and Ouya together asking or answering questions. A lot of my web searches make me feel like I’m the first person ever to do this, a stark contrast from my experience working with XNA. Performance on the Ouya isn’t quite as good as this was running on my Xbox 360, there is a slight amount of choppiness that I will have to address. Since this is a port of the second game I ever made (I’ve released about 8 titles since and this game ran fine without ever optimizing it), I’m hoping I will be able to find some pretty simple performance robbing blunders in my code and easily get this back to running at 60 FPS.

MonoGame is built to work mostly like XNA does. When it comes to the Ouya controller, Y button aside, the control letters don’t match up with the letters in your code. This is a pretty minor issue overall, you just have to remember things like the O button on your Ouya controller is actually the A button when accessed in code. The face buttons of the controller all worked right out of the box though I did have to redo some of the UI graphics for these new buttons. For some odd reason, the Y axis on the analog stick was reversed. I found I had to resolve this but flipping all the logic in my game so that up is down and down is up when using either of the analog sticks. The system button (equivalent of the Xbox start button) didn’t initially work for me and after some asking and searching for answers, it was brought to my attention that this button worked in an older version of a MonoGame DLL. Using that DLL instead of the newest DLL resolved my issue and also fixed the backwards Y-Axis problem, forcing me to remove the logic I had previously added to flip this around in-game. I don’t fully understand the system used for checking in MonoGame updates but it appears the controller was at one point working correctly and then someone checked in code that broke some aspects of it and it was accepted into the main truck / distribution of MonoGame.

In XNA, you can set the screen resolution of your device / Window. I’ve designed all my games to run at 720P but the Ouya wants to run at 1080P. The code to change the screen resolution doesn’t work from MonoGame though, Ouya instead determines the highest ideal screen resolution and uses that. Being open source, this is apparently something I could dig into resolving, but since I am trying to do a quick port, I opted to draw my screen to a render target and upscale that to fill the entire screen. Not the ideal fix but a fix that works and could be easily modified to handle other resolutions (for instance if I did an Android phone or iPhone port).

Now a big reason why I haven’t moved quicker is that deploying the game is slow. Most of the time on my XBLIG and PC games, I simply run them on my PC which is pretty fast. It takes a couple minutes to deploy to the Ouya though. And even when I do deploy, I can’t debug. Anytime a break point is hit, the game exits. This has caused me to debug using Console.WriteLine() commands which is cumbersome at best. This seems to be an issue from both Visual Studio and Xamarin Studio (though deploying from XS does at least seem to be quicker than from VS).

Getting sounds to work right is the other big hanging point for me. It seems there is a lot of misinformation being presented on how to do sounds on Ouya using MonoGame. The content build process is a bit different than it is for XNA / XBLIG games where you build your XNB files first and copy those to your project. For sounds though, you want to use the Wave files directly in your project and make them Android Assets. It took a lot of trial and error and asking around to get this far. Thankfully getting my mp3 audio to play correctly was pretty straightforward, which only led me to more rework because I falsely assumed it wouldn’t be and spent extra time trying to figure out a solution for a problem that did not exist.

It’s probably not a big surprise to anyone that the typical XNA StoreDevices don’t work on Ouya. Converting to Isolated Storage wasn’t a big deal but it still ate up a day or two of my time. I have been running into instances of all my save files disappearing though. While I haven’t confirmed this, I believe it has something to do with the deployment process used on Ouya. I suspect periodically when I deploy, it is deploying my game to a new location on the file system of the Ouya and removing the previous install (it may be a time-elapsed expiration even) and thus my old save files no longer exist. I believe this won’t be an issue when I release the game but it is still a bit worrisome and somewhat annoying in that it causes me to replay early levels to unlock later levels that I had previously already unlocked (I should probably add a cheat / dev code to automagically do this).

The final thing not working in my game is per-pixel collisions. Getting the byte arrays from my textures doesn’t work as it did in XNA. I’m not sure if this is an Ouya/Android thing or a MonoGame thing. I’m not overly worried anyways, I believe I can get “good enough” collisions using just bounding boxes which do currently work just fine. I have been told this should work by others that have done MonoGame ports but it definitely is not working for me. The game can be slightly choppy at times so removing per-pixel collisions is probably a good thing to do performance wise anyways.

I also need to add support for IAP to my game. Ouya doesn’t allow people to just buy your game, they download the game and then pay within the game to unlock extra features (this is a poor way to handle it IMO and I hope someday users can see the price of a game without having to download and play it first). I’m not planning to be too elaborate with this in my game but rather just have a onetime unlock in order to play the full version of the game else you’ll be limited to a trial version. There is a MonoGame Ouya sample of how to do this that I’ve been working through but it would be nice to have some kind of tutorial rather than just looking through code and trying to determine the pieces I need. This is where doing something new gets painful.

After 30 days of using Xamarin (which is necessary to deploy MonoGame releases to an Android device) my free trial ran out. I then purchased the $299 Indie license. Despite the trial being listed as having the same features as the Indie version on their website, that is not the case (the trial version is more feature rich than what the website lists, it is basically the full blown everything included version despite being listed with matching features to the Indie version). Visual Studio support requires that $999 version of Xamarin, forcing me now to use Xamarin Studio to write my code and deploy my game. Xamarin Studio is no Visual Studio but it’s not terrible either, it is a much better environment than XCode. Unfortunately Xamarin Studio does not support MonoGame content projects, so I have to build my content (basically the graphics) from Visual Studio still and then copy the .XNB resource files to my Xamarin project. I hear supporting content projects is something Xamarin Studio will do at some point in the future, but it is not possible right now.

Overall it has been a frustrating process porting my game (still not done) that has taken much longer than I had hoped. A second or third game ported though I expect to be pretty quick as I will have worked through many of these issues already and possibly some of the problems I ran into will be resolved in MonoGame itself (controller buttons and screen resolution for instance). I like the general idea of Ouya and MonoGame has worked pretty well in porting to a new system without rewriting an entire codebase (minus a few previously mentioned issues). Now I’m really wondering if anyone will buy my game on Ouya? My original thought was that it wouldn’t matter for a two week port but now that I’ve invested $299 in Xamarin and over a month of my time, the stakes are a bit higher.