34
\$\begingroup\$

Some years ago, if you wrote in C and some subset of C++ and used a sufficient number of platform abstractions (via SDL or whatever), you could run on every platform an indie could get on - Linux, Windows, Mac OS of various versions, obscure stuff like BeOS, and the open consoles like the GP2X and post-death Dreamcast. If you got a contract for a closed platform at some point, you could port your game to that platform with "minimal" code changes as well.

Today, indie developers must use XNA to get on the Xbox 360 (and upcoming Windows phone); must not use XNA to work anywhere else but Windows; until recently had to use Java on Android; Flash doesn't run on phones, HTML5 doesn't work on IE. Unlike e.g. DirectX vs. OpenGL or Windows vs. Unix, these are changes to the core language you write your code in and can't be papered over without, basically, writing a compiler. You can move some game logic into scripts and include an interpreter - except when you can't, because the iPhone SDK doesn't allow it, and performance suffers because no one allows JIT.

So what can you do if you want a really cross-platform portable game, or even just a significant body of engine and logic code?

Is this not a problem because the platforms have fundamentally diverged - it's just plain not worthwhile to try to target both an iPhone and the Xbox 360 with any shared code because such a game would be bad? (I find this very unlikely. I can easily see wanting to share a game between a Windows Mobile phone and an Android, or an Xbox 360 and an iPad.) Are interfaces so high-level now that porting time is negligible? (I might believe this for business applications, but not for games with strict performance requirements.)

Is this going to become more pronounced in the future? Is the split going to be, somewhat scarily, still down vendor lines? Will we all rely on high-level middleware like Flash or Unity to get anything cross-platform done?

tl;dr - Is porting a problem, is it going to be a bigger problem in the future, and if so how do we solve it?

Improve this question
\$\endgroup\$
5
  • 2
    \$\begingroup\$ Section 3.3.2 of the iPhone Developer Program License Agreement allows for game scripting now, though it is still a bit convoluted. - "Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application." \$\endgroup\$
    – Bachus
    Sep 7, 2010 at 11:34
  • 3
    \$\begingroup\$ Apple changed the license agreement again yesterday, and game scripting is now totally a-okay. - "Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework." \$\endgroup\$
    – Bachus
    Sep 10, 2010 at 7:03
  • \$\begingroup\$ I'd say that you've lumped a bunch of things together that don't belong--mobile devices, consoles, PCs, and web-based games? Consoles and PCs, sure, should be able to share a codebase with some tweaking. Mobile devices are vastly different in capability from dedicated computing hardware (in terms of raw graphical power, storage, threadedness, etc.), and so you wouldn't really even be able to use the same solutions. And web games are, you know, web pages. What do you want? The fragmentation here is across device paradigms, not mere computation architectures. \$\endgroup\$
    – ChrisE
    Apr 17, 2011 at 16:04
  • \$\begingroup\$ Actually I said nothing about web games. I think it's reasonable to want to run some of the same code on all devices - input mapping, or an abstracted graphics API, or an entity system, file parsing, networking - these are all the same basic paradigms regardless of platform. But the question is also 8 months old, and was borne out of concerns that don't apply much since NDK gathered more support on Android and Apple stopped their stupid policies. \$\endgroup\$
    – user744
    Apr 17, 2011 at 18:57
  • \$\begingroup\$ I mean, you did mention HTML5...that's kind of intended for web games, right? \$\endgroup\$
    – ChrisE
    Apr 17, 2011 at 21:16

9 Answers 9

Reset to default
14
\$\begingroup\$

The Unity engine gets you a huge chunk of the way there. Write once and you've got Mac/Windows Standalone and webplayer based. Tweak your inputs, and mind your draw calls and you're on iOS/Android.

Improve this answer
\$\endgroup\$
12
\$\begingroup\$

For a small indie developer, with limited funds/time (and maybe more of a focus on 'making something cool' than 'making something profitable'), trying to go cross-platform from the start could be counterproductive. It takes a lot of effort to engineer solid cross platform tools and tech (different graphics APIs, endianness, input devices, and more) - time that could be spent on the more creative side of game development.

But you probably want to make sure you've got a great game that works really well on one platform before worrying too much about getting it onto as many platforms as possible! If the game is a flop, there's no point wasting time and effort making it a multi-platform flop, is there?

If you're coding in C/C++, mostly from scratch, then as long as you keep the code fairly modular and make sensible decisions about data formats and middleware/libraries, then supporting other platforms later shouldn't be too painful.

If third-party cross-platform tech/tools (e.g. Unity) is an option for your project, then it's certainly worth considering.

The main 'problem platforms' for indies would seem to be Xbox360 Indie Games (C# only, limited network access, etc), and possibly Android (massive differences in device performance/screen size/input devices). If you're determined to support these, expect a more sizable porting job, or plan to focus on them exclusively.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ Yeah, Unity3D rocks. www.unity3D.com \$\endgroup\$
    – BerggreenDK
    Dec 1, 2010 at 2:42
  • \$\begingroup\$ I agree with @bluescrn - better to know almost everything about almost nothing, than knowing almost nothing about everything: Jack of all traits, master of none. \$\endgroup\$
    – rodrigo-silveira
    Jun 10, 2013 at 13:05
3
\$\begingroup\$

You say cross-platform independent development. The biggest hurdle then is resources, and that means a lack of time most of the time, but also lack of know-how and possibly finances (license fees, buying devices, etc).

Indie or not, the biggest hurdle is actually design. As you say, a game that runs on Xbox360 and iPad might work, but they also need to be fundamentally different in terms of design. The 360 has a controller, the iPad a touch screen. Also, development for the 360 is done in Windows using C# as language, the iPad can only be targeted on Mac OS computers and using C, C++ or Objective-C. Or Javascript, if you prefer. Some things just don't mix that well whatever you do.

What you say about the different platforms holds true today. Use C/C++ and SDL and you can write your program cross-platform on PC-like machines, probably much more smoothly than years ago. However it was always a problem and will always remain a problem to port games from PC to console to mobile, and vice versa. It has just become more pronounced in the recent years by allowing Indie developers to program for consoles (or developers hacking access to it to create homebrew games) and by the rise of mobile devices powerful enough to run games.

Porting has the same problems it ever has, but there are more devices to port to. And some ports just don't make sense without re-designing the core of the game. This is not a problem that can be solved, it's one you have to consider from the outset even before you write your first line of code. Then it will be manageable, no more, no less.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ Actually, I would say time to port is one thing an independent developer/group is more likely to have than a large publisher-driven studio. \$\endgroup\$
    – user744
    Sep 6, 2010 at 21:47
  • \$\begingroup\$ There are plenty of game designs that make sense on all platforms - turn-based virtual board games, for example, are consistently a hit on all platforms. So are many falling / matching block puzzle games. These can't even be "ported" in the traditional sense anymore - moving a game from e.g. XBLIG to the iPhone is a guaranteed rewrite of all the code. \$\endgroup\$
    – user744
    Sep 6, 2010 at 21:49
3
\$\begingroup\$

A simple, portable and open interface framework is really needed, I think. Some musings:

There currently seem to be four common kinds of game input methods: Keyboards, Mice, Controllers and Multi-Touch Surfaces. (I'll gloss over the issues of differing capabilities between, for example, gamepads and joysticks for now, though that should eventually be addressed.)

Ideally, our developer would be able to specify in a general way a few different UIs that make sense for the kind of game being written. (They might decide to provide a Keyboard and Mouse UI, a Mouse Only UI and a Multi-Touch UI, as an arbitrary example.)

The framework is then responsible for mediating IO between the platform and the game code, similar to how cross-platform GUI frameworks like QT and GTK function.

Having such a framework wouldn't solve the incompatible language requirements problem, but would at least encapsulate all the system-specific calls behind a common API, which should make language porting much more straightforward.

Well, now that I've written all of that: Does anyone know if a framework like that already exists?

Improve this answer
\$\endgroup\$
3
\$\begingroup\$

With projects like MonoTouch and XNATouch it was looking like XNA might get you on most platforms with a bit of tweaking. Unfortunately Apple kind of torpedoed that when they changed their Terms and Conditions to restrict which languages you can use. Unity goes across pretty much everything now, although on XBOX it will get you on XBLA but not XBLIG, so not an option for smaller indies.

One approach might be to create a framework that uses the same conventions across multiple languages/platforms, then it is just a matter of tweaking syntax to port games. You might want to launch your game in Flash, which can be developed quickly and reach a large audience, then if it is successful port to iPhone, XNA etc. This way you know you have a fun game before over-committing yourself.

Improve this answer
\$\endgroup\$
1
  • \$\begingroup\$ stupid apple, who restrict programming languages! WHO?!?! \$\endgroup\$
    – FreshJays
    Apr 18, 2011 at 12:44
2
\$\begingroup\$

I think this is an economic problem, not a technical problem. Platforms like xbox360 have a strong incentive to be exclusionary, because they're trying to get users choosing their platform instead of some other platform. "We have these cool exclusive games" is way more interesting than "we can also play these games that everyone else has". The ecosystem is dominated by the hardware manufacturers.

I suspect this will change when social-networked gameplay matures, because there's potentially a lot more money in getting everyone into the same social-gaming system than in making yet-another-FPS-with-sexy-graphics.

Improve this answer
\$\endgroup\$
2
\$\begingroup\$

I just discovered Haxe and NME. It claims to be a cross-platform app that supports all major desktops and mobile devices, and Flash, from one code-base. Worth a look.

Improve this answer
\$\endgroup\$
1
\$\begingroup\$

A cross-platform development tool that is so new I don't necessarily recommend it is http://www.monkeycoder.co.nz/

It hits every platform you mentioned.

While it is too new to really judge, it has a great pedigree: it's creator previously made Blitz3D and BlitzMax, which were great development tools for indie game developers.

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

I've had luck with the airplay SDK - at least on x86 and apparently targets iPhone well (although I still have yet to put an app on an iPhone yet).

Improve this answer
\$\endgroup\$

You must log in to answer this question.