Porting a HTML5 game: 6 platforms, 1 codebase. | Hacker News Reader

Porting a HTML5 game: 6 platforms, 1 codebase.

blog.greweb.fr

62 pointsgren11 comments

That's a great idea for getting the most out of your dev efforts (and hitting the maximum number App Stores ;) - but do you end up with a lot of "conditional code"?

edit: ah, missed the internal link - it's explained in more detail: http://blog.greweb.fr/2011/06/automating-web-app-development...

If you are developing for iOS, you could also package your game with a more "native" wrapper, like my iOSImpact[1] instead of PhoneGap. This has better performance (OpenGL graphics instead of the browser view) and perfectly working sound with all the same source code as the web version.

[1] http://www.phoboslab.org/log/2011/04/ios-and-javascript-for-...

I'm continusly impressed by the progress of Javascript recently and WebAppBuilder does look like it took a lot of hard work. BUT... quality cross-platform-automated-build-100-appstores-deployable unicorns are still fantasy. It might work for simple games, like the one in your example, but add a serious physics engine and sprites in there and too much creativity and such frameworks become more pain than help. Web is still high-level and hard to compete with platform specific optimizations and low-level APIs. Especially in a creative world like game development.

I have heard so many times friends/colleagues dreaming of apps which you write once and deploy it on everything. Can we please put a stop to these stories and take the time to build quality games, rather that get rich quick fart apps?

It might work for simple games, like the one in your example, but add a serious physics engine and sprites in there and too much creativity and such frameworks become more pain than help.

Funny that you should mention physics engines and sprites...have you ever played the Chrome version of Angry Birds? Sure, maybe it's a simple game, but it's hardly a get rich quick fart app.

Are you aware that though it's ultimately a Javascript app, it was built using the Forplay framework (http://code.google.com/p/forplay/), which includes a (very slightly modified) version of JBox2d (the Java port of Box2d) for physics, compiled down to JS through GWT? See http://code.google.com/p/forplay/source/browse/#svn%2Ftrunk%... - that's almost exactly the JBox2d trunk, with a few modifications because of a couple of things that GWT doesn't allow (reflection, for instance).

I assure you, we did not have GWT in mind when porting Box2d to Java, so there are no special optimizations for it or anything, we've always just targeted pure Java - GWT didn't even exist at the time, and even once it showed up, I was so convinced that it could never run fast enough for physics that I didn't even bother to try. You can see the results yourself, most of the demos (other than the stress tests, which are supposed to be slow) run quite well for me on recent versions of Chrome, Safari, and FF: http://gwtbox2d.appspot.com/

"Chrome version of Angry Birds", "Chrome version" was not built for all platforms from the beginning. Neither was the normal version of Angry Birds.

I highly respect GWT, but it's far from smooth on my mobile.

"Chrome version of Angry Birds", "Chrome version" was not built for all platforms from the beginning. > Well mine neither.

Google cache: http://webcache.googleusercontent.com/search?q=cache:http://...

Thanks, It's up now :)

It's great to see a real-world writeup of cross-platform development using HTML5. One question: I tried the app on Android, and it looks pretty much identical to the web version, so -- success. However, the animations seem very slow and chunky -- I'm guessing less than 10/frames second, sometimes significantly less, even though the game is very simple visually. Is this an inherent limitation of HTML5 animations on Android? What about other mobile platforms (e.g. iOS)?

That's probably because I use HTML Canvas. The balls are currently not animated with CSS but with Javascript (in a requestAnimationFrame loop). Making a full DOM version with CSS Transitions (or Animations) would be probably better because it's hardware accelerated (especially on iOS). Android browser has different support/behavior between android versions. Using lot of CSS Animations is in my opinion a little too ambitious (for now), that's why I stayed on a slower HTML Canvas solution.

But for iPhone / iPad, that's not the case, animations work better than Canvas, I have to try a DOM solution to increase these performance :)

Well done. Surprising good fun to play !

Reply on news.ycombinator.com