
How to Make a Massively Cross-Platform Game - markokocic
http://blog.brokenfunction.com/2011/11/how-to-make-a-massively-cross-platform-game/
======
hyung
A cross-platform game engine sounds awesome. But I wonder what kind of game
can truly be write-once, run-everywhere, and considered "fun" on all
platforms.

A few major challenges:

\- Designing a game that is fun and intuitive to play with a wide variety of
input controllers (touch, mouse, keyboard, joystick).

\- Handling the entire spectrum of screen resolutions, from older iPhones to
high-end desktop computers. The game would also probably need to work in both
portrait and landscape modes.

\- The QA effort alone could be huge. Testing on quirky desktop browsers or
buggy Android devices alone could be a dealbreaker.

\- I'd argue that the time spent trying to figure out a game design or
technical workaround for a particular platform would be better spent focusing
on one platform and making the game more fun. In my experience, trying to make
a fun game involves a lot of trial and error and iteration, and I personally
don't think I could do it if I also had to keep in mind multiple distinct
target platforms.

I can envision a couple one-button games like Angry Birds or Tiny Wings
possibly having a chance, but even in those cases, I'd argue it'd be better to
nail one platform first and then incrementally add other platforms instead of
spreading oneself too thin.

~~~
jiggy2011
The closest you will get to this I think is Unity although that doesn't
currently have Linux support.

All programming is done using Mono and it also contains a load of proprietary
tools for asset generation as well as stuff for AI etc.

~~~
Pedrom
Yeah... But even with Mono you have to use the proper classes for display, so
it's not completely code once play anywhere.

~~~
robert00700
It's Mono running on top of Unity's own graphics/control/audio abstraction

------
jiggy2011
What about Java? It has some quite mature 3d game libraries now, checkout
jmonkeyengine for example and 2d is a doddle.

It can run on all 3 major desktop platforms as well as android (though you may
have to use different libs for some parts) and can be embedded into a webpage
easily via an applet.

The only platform you would need to re-implement for would be iOS but your
going to hit that problem whatever you do (not sure what it's JS support is
like though).

Of course the most crossplatform would just be to build the entire game using
web forms in RoR or something.

I'm not sure though that cross platform games are even that great an idea as
in reality you tend to end up with lowest common demoninator.

As a PC gamer I'm getting a bit annoyed by new games that used to be based
around PC coming out primarily for console and then being ported to PC with
dumbed down controls and graphics that don't do a high end PC justice.

~~~
mherkender
I didn't like the idea of using Java, since it requires the Java runtime
everywhere. This also limits my options in console environments. The goal of
this project was to minimize such requirements. I also didn't want to rewrite
the game ever if possible, so rewriting it for _just_ iOS was out of the
question.

> As a PC gamer I'm getting a bit annoyed by new games that used to be based
> around PC coming out primarily for console and then being ported to PC with
> dumbed down controls and graphics that don't do a high end PC justice.

It's an indie game, high-end graphics were not a priority on any platform,
gameplay is.

------
robert00700
I'd definitely recommend Unity3D for this. It provides (as far as it can)
platform-agnostic abstractions for controls, graphics and audio, although if
you want to get down-and-dirty with a particular platform you can easily write
native plug-ins.

Very technical people often have reservations over such systems that seem to
cater for non-techie developers, but I found it made game development much
more enjoyable- less platform-specific graphics boilerplate and more enjoyable
challenges like AI.

I ended up creating this simple ragdoll game over a few days for iOS-
[http://itunes.apple.com/gb/app/ragdoll-
spike!/id384354298?mt...](http://itunes.apple.com/gb/app/ragdoll-
spike!/id384354298?mt=8) , I'd be interested to see how much longer it would
have taken to do natively!

~~~
pace
Your game looks nice. Do you maybe have a blog post about the making of? Was
it your first Unity3D game? What prior experience do you have in game
development and in general programming, which languages? How long did the
development take?

Sorry for all the questions—I'm about to dive deeper into one of the game/3D
dev frameworks and an HN reader's opinion would be highly appreciated!

------
jheriko
This is a good analysis, however, the focus is on being cross-platform at the
expense of all else. You will have a hard time making a performant AAA title
without some low-level and platform specific code to squeeze the most out of
your hardware. One intermediary approach is to use C to optionally fill gaps
where there are big wins to be had... C is almost universally supported and
correctly designed C APIs can be used together with most of the major
languages, where its not available (the web, without some kind of plugin
download) you "simply" lose out on those potential optimisations...

Saying that though this kind of approach is great for small projects. Lua is a
great choice because its already been extensively used for games on many
platforms and there are heavily used and highly optimised implementations
available for all the PC platforms and consoles.

I don't know if there has been any serious effort to get many other languages
than C/C++ and Lua targeting consoles beyond the XNA stuff from MS - but,
those with compilers/interpreters written in clean, cross-platform C should be
straightforward options as well (e.g. GCC compilers).

Another important consideration is the range of performance on the various
targets - designing everything so that cosmetic features can be
reduced/disabled dependent on platform is simple, but if not done early on can
turn into a chore. This way the lack of performance on the web can be
counterbalanced by having, e.g. less particles, half-res textures, fewer
animations.

~~~
teamonkey
> those with compilers/interpreters written in clean, cross-platform C should
> be straightforward options as well (e.g. GCC compilers).

C++ is essential for consoles (at least the 360) if you're not going the XNA
route. Moreover, you have to compile with vendor-approved compilers, link with
the vendor-provided libs and use approved graphics functions (e.g. DirectX on
the 360).

Of course, many console games use Lua for scripting. LuaJIT, however, is not
supported on consoles.

~~~
mikemike
Correction: LuaJIT is _not yet_ supported on consoles. I'm confident the
remaining legal issues can be resolved soon.

Note this is referring to the high-speed interpreter written in PPC assembler
which gives you a 2x-6x speedup over plain Lua. Not as good as with a JIT
compiler, but definitely something to consider.

The JIT compiler will be disabled on the consoles for now. This is not the
last word on that matter, though.

~~~
teamonkey
Good to know. I thought the major problem was that the console hypervisors
don't allow arbitrary code execution, which made JIT difficult if not
impossible on those platforms.

In any case is there any serious benefit to using JIT over static compilation
on fixed targets like the 360 and PS3?

------
arocks
Extremely useful information here. A naive way to approach cross platform
architecture would be to work at a higher level of abstraction like working in
a Domain Specific Language or pick a language with a good set of cross-
compilers for various targets.

Lisp might encourage the first approach and Haxe follows the second.

------
ZenPsycho
He dismissed Javascript rather quickly without really explaining why. Oh well,
I guess it is javascript's lot in life to be hated and ignored. On the other
hand, lua was a very good choice indeed. Lua and Javascript are very similar
languages indeed- though I would say Lua is probably a lot less hairy and
weird.

A couple options he missed though- There was already a lua to javascript
translator. (I think). There is also Pyjamas, which is a python to javascript
compiler. It comes with a whole pile of gwt along with it, but you can
honestly ditch most of it and just use the compiler if you really want to.
(though some would argue that python without all the libraries isn't python).

~~~
lloeki
> He dismissed Javascript rather quickly without really explaining why.

Actually he did not, and visibly considered it a good contender, but wanted to
look for other options before jumping to conclusions. In the end he simply did
not go back to JS since Lua fit the bill.

------
larubbio
Disclosure: I work at Zipline Games building out our cloud platform. We also
have a cross platform game engine that lets you develop in lua. The engine is
focused on mobile games so it runs on android, iOs and Chrome native client.

The cloud portion would make an excellent compliment to this since we host a
mongo database for you, allow you to write and run your own lua code so you
can develop your backend logic in the same language you build your game in. We
also provide a set of RESTfull services for common game needs.

Check it out at <http://getmoai.com/>

~~~
seclorum
I've been playing with moai with much fun the past few weeks, and I have to
commend you on a job well done. You've given a lot of love to the use of Lua
to properly solve the platform problem, and its a joy to use moai to quickly
get stuff done.

------
aerique
_A solid lisp implementation could be easily ported everywhere. I think this
would’ve been my choice had I not found Lua._

While I'm a total Common Lisp fanboy a __solid __Lisp implementation is not
easily ported everywhere. It's perhaps easier than most other languages but
unless we have differing opinions of what solid[1] means it is by no means as
easy as he makes it sound.

[1] So not my-first-Lisp-interpreter that everyone writes but actually
something like Common Lisp or a Scheme implementation with lots of extensions.

------
CJefferson
The only disappointing part of this is that he did, without mentioning it as
clearly as I would like, chuck away the 15% of people using IE before version
9.

On the other hand, non-canvas browsers have got down to 15%? I'm chucking my
(painfully and buggy) DOM engine for my game this afternoon and ging just
canvas. I should have paid more careful attention.

~~~
ido

        The only disappointing part of this is that he did,  
        without mentioning it as clearly as I would like, 
        chuck away the 15% of people using IE before version 
        9.
    

Are you sure your target audience has 15% IE<9?

On my website [1] I only have ~7% IE and that's 1/3 IE9 and 2/3 <9 (mostly 8).

[1] - <http://tametick.com>, which is pretty representative of the kind of
people who buy/play my games.

------
davedx
Unity.

~~~
teamonkey
Or, depending on your choice of targets and desired featureset:

Monkey - <http://www.monkeycoder.co.nz/Monkey/about.php>

GameMaker - <http://www.yoyogames.com/gamemaker>

Love2D - <http://love2d.org/> ; <https://bitbucket.org/bmelts/love-
iphone/overview>

Unreal3 - <http://udk.com/>

And many more. Shouldn't stop people for developing their own though.

------
slowpoke
You want to be truly cross-platform? There's exactly one way to do this:

Open-source your game. If there is demand on a platform, it will be ported.

------
stonemetal
Unreal Script? UE covers all the platforms he is trying to hit except Wii.
Though the web stuff requires flash.

~~~
Pedrom
That is in theory.... In practice If you have a game that look pretty well on
consoles you would have big challanges for mobile devices, and just reducing
quality on art assets might not be enough.

~~~
teamonkey
Unreal is used in Infinity Blade 1 and 2 on iOS.

~~~
Pedrom
Yeah but we are talking here about massive multi-platform games and Infinity
Blade was specially tailored for IOS.

In practice, to use Unreal in a game that would run on consoles and mobile
devices, you have to fork your code and made a lot of adjustments.

~~~
teamonkey
Unreal iOS uses the same toolchain as the PC and console versions, including
the same scripting system - that's the point of having a multi-targeting
engine. Unless you modify the engine substantially you probably won't need to
fork. In fact, if you use the UDK you can't modify the engine source anyway.
In most cases you'd probably worry more about assets that work on multiple
platforms rather than code.

But anyway, I think this exercise was to have the option of deploying to
multiple targets, not every single target at once. The difference between the
Flash, HTML5 and iOS versions of your game could be very small. For another
game you could use the same toolchain to target PC, Mac, consoles, etc.

~~~
Pedrom
Well in the case of the game we were working on there was no choice other than
fork our codebase. No considering the controllers (which is different enough
from the consoles) the frame rate of our code base was awfully slow on IOS, so
we had to rethink the whole project to target IOS properly. Actually I don't
know any unreal game that sucessfuly have been launched on IOS and consoles
with the same codebase, and after my experience with the engine I don't think
you would like to do that in the sense that you always would like to exploit
consoles capabilities. It's a tradeoff very hard to avoid.

