The Great Porting Adventure: Day 2

Where's the Start Menu on this thing?

Yesterday, I spent a chunk of time looking into various possibilities for porting my XNA-based game to non-Microsoft platforms like iOS and OSX. In the end, it seemed like learning Unity would be a prudent move and now would be a logical time to start that process.

In true indie fashion, I’m calling an audible.

I wrote off MonoGame rather quickly without much justification, other than saying it felt too much like magic and I would have trouble resolving any roadblocks I encountered. While that may be true, I think the benefits outweigh the small price of experimentation.The biggest potential upside, other than reusing 95% of my codebase, is that I can maintain a single copy of the game moving forward.

After all, if the MonoGame solution works I should be able to get my game running on something like OSX in a very short time. I figure that’s worth trying out. I’ll spend today setting up my borrowed MacBook, getting my environment in order and running through some MonoGame examples. I figure the OSX port will be a good first test, since it will play identically to the Windows version.

Maybe the first 99% of porting with MonoGame will go smoothly. Maybe the last 1% will prove impractical or impossible. Let’s find out.

Advertisements

Meta-Platforming

There comes a time in every XBLIG developer’s life when they ask themselves, “How can I put this”

“onto one of these?”

This year, I want to hit more platforms than just the Xbox LIVE Indie Games market. My first priority is PC, specifically Windows. In this context, XNA is fantastic. I basically get a Windows build of my games for very little effort (some resolution management and key binding support). But what about OSX and Linux? The Humble Bundle (and the feedback I’ve received) has shown that these are non-trivial segments of gamers.

And then there’s mobile. Even I own a smart phone now, so that means pretty much everybody has one.

So if I’m going to go through the trouble of porting, I figure I might as well shoot for the stars and try to hit as many platforms as possible.

Of course, XNA doesn’t “just work” on these platforms. Porting XNA games has been done before by developers like Radian Games (Super Crossfire) and Fun Infused Games (Hypership Out of Control iOS), so it’s not completely foreign territory. Here’s a quick look at my current thinking:

Goal: Port DLC Quest to as many of the following as possible: iOS, OSX, Android, Linux

Approach #1: Native iOS Port

Rewrite the game from scratch for iOS.

  • Pros:
    • Free (other than iOS publishing fee, but all approaches will include this)
    • Potential for good/great performance, as this is as close to the metal as I can get
    • Learn a lot
  • Cons:
    • Most work. Total rewrite.
    • Have to learn Objective-C
    • Doesn’t directly allow for publishing on Android or Linux
    • Not sure how to port to OSX either

Thoughts: This is the most work, to hit only some platforms. But there’s no “magic” – I would know how everything works.

Approach #2: Port to Cocos2D or similar engine

Rewrite the game using Cocos2D as a base.

  • Pros:
    • Free
    • Save considerable time rewriting engine
    • Works on iOS and OSX
  • Cons:
    • Have to learn Cocos2D engine
    • Still have to rewrite game in Objective-C
    • Still does not directly publish to Android or Linux

Thoughts: Similar to above, but cuts out considerable engine work. But I already have an engine anyway.

Approach #3: Convert using ExEn, MonoGame, etc.

Use a MonoTouch based library/framework to do the heavy lifting and keep my codebase mostly intact.

  • Pros:
    • Use existing codebase, kinda (game needs adapting for touch devices/screens anyway)
    • Might be easier to maintain multiple versions in one solution
    • Write in C#
  • Cons:
    • $400 for MonoTouch (and an additional $400 for Mono for Android)
    • Does not directly publish to OSX orLinux
      • Whoops, apparently OSX is supported. Wizorb also managed a Linux version, so that’s a ‘maybe’.
    • Likely won’t work perfectly, require learning how MonoGame works to fix it

Thoughts: This feels like a magic bullet approach. I’m wary of things not working perfectly and then having to grapple with an unknown technology to try to fix it.

Approach #4: Unity

Re-write the game with Unity and reap the multiplatform benefits.

  • Pros:
    • Write once, hit iOS, Mac, Android, Flash. Possibly even Linux soon.
    • Get experience with Unity, which seems like a sensible business choice
    • Write in C#
    • Can potentially reuse some code
  • Cons:
    • Need to rewrite at least some of the game
    • $400 each for iOS and Android publishing. Potentially $1500 for Unity Pro + $1500/iOS/Android if needed.
    • Large learning curve for the “Unity way” of doing things
    • Likely have to invest in SpriteManager or similar library
    • Basically magic

Thoughts: Unity seems to make the most sense, but I’m also reluctant to use it because it feels like I give up too much control.

And the winner is…

Looking at this (and having slept on it), it seems like all signs point to Unity as the way forward. I’m not a big fan of the “magic” involved with Unity but that’s likely largely attributable to a lack of understanding. I’ll give it a shot and see if my reluctance is warranted or not.

I think the last time I used a Mac for more than 5 minutes was with an iMac in computer class over a decade ago. This oughta be interesting.

You said it dog.