January 4, 2012 7 Comments
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.
- 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
- 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.
- Save considerable time rewriting engine
- Works on iOS and OSX
- 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.
- 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#
- $400 for MonoTouch (and an additional $400 for Mono for Android)
- Does not directly publish to
- 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.
- 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
- 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.