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.
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.
- Designing a game that is fun and intuitive to play with a wide variety of input controllers (touch, mouse, keyboard, joystick).
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.
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.
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.
>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).
That is not the case for mono as Xamarin compiles Mono code into native IOS code which is Complain with Apple guidelines.
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.
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!
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.
You will have a hard time making a performant AAA
title without some low-level and platform specific
code
Since the author mentions platforms such as js and flash, I highly doubt we're talking AAA games here- there's plenty of genres (basically all "casual" games) where performance isn't an issue.
> 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.
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.
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?
Agreed. Being cross platform at the expense of having to write your own OpenGL and OpenAL renderers for each platform seems almost as bad as writing hand-coded assembly for each processor architecture.
I only wrote OpenAL/OpenGL code when it was necessary. Most platforms use some simple library (libgdx, SDL, etc). The OpenAL code is actually shared between the Linux/Windows/Mac port and the iOS port. Only the iOS port uses OpenGL directly, and I imagine that code could also be shared between different platforms.
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.
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).
> 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.
> Oh well, I guess it is javascript's lot in life to be hated and ignored.
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.
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.
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.
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.
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.
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.
It was painful for me as well. The Flash port was just not up to snuff though no matter what I tried, and there were no options left for browsers that don't support Canvas.
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.
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.
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.
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.