How to Make a Massively Cross-Platform Game
blog.brokenfunction.com
blog.brokenfunction.com
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.
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.
I am writing a simple puzzle game, and am doing a totally different UI level for even mouse and touch. For example when dragging, with touch it is nice to offset the piece so it is easier to see, whereas with mouse you probably want it dead-center.
It was actually a platformer. SDL has great support for Joysticks/Keyboard so that was no trouble. The same goes for JS. As for touch screens, I found a good alternative control scheme that takes advantage of the touch screen. You are still right, but the game was designed to be straightforward enough to handle different control schemes.
- 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.
Impressive, this was actually major issue. The game requires no specific aspect ratio, so that wasn't a problem. Still, we don't want it to look tiny on HD monitor while looking normal on an iPhone, so the resolution of the images in the game can scale up and down at different sizes (1x, 2x, 3x) depending on what's ideal.
- The QA effort alone could be huge. Testing on quirky desktop browsers or buggy Android devices alone could be a dealbreaker.
No problems with modern browsers, if they supported Canvas, they supported the Javascript that was needed. I admit Android might've been a problem, I can't test on everything.
- 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.
That was actually the original plan. I ended up porting it to some new area whenever I would get stuck on some other problem and got caught up in that part of the project instead because I found it fun. Since the requirements were so intentionally minimal it wasn't very hard. I didn't know anything about iOS or Android development going in for example, they each took about 2 weeks.
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.
That is not the case for mono as Xamarin compiles Mono code into native IOS code which is Complain with Apple guidelines.
> 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.
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... , I'd be interested to see how much longer it would have taken to do natively!
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!
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.
You will have a hard time making a performant AAA
title without some low-level and platform specific
code
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.
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.
In any case is there any serious benefit to using JIT over static compilation on fixed targets like the 360 and PS3?
Lisp might encourage the first approach and Haxe follows the second.
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).
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.
Ten years ago, maybe. Today, JS is almost ubiquitous, thanks especially to the growth of AJAX. Never mind that tech like V8 has blazed new trails for JS far beyond the browser.
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/
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.
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.
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 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.
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.
Open-source your game. If there is demand on a platform, it will be ported.
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.
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.