

Porting a HTML5 game: 6 platforms, 1 codebase. - gren
http://blog.greweb.fr/2011/07/same-game-gravity-technical-notes/

======
mrspeaker
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...](http://blog.greweb.fr/2011/06/automating-web-app-development-
for-multiple-platforms/)

------
phoboslab
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-...](http://www.phoboslab.org/log/2011/04/ios-and-javascript-for-real-
this-time)

------
tudorizer
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?

~~~
bermanoid
_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%...](http://code.google.com/p/forplay/source/browse/#svn%2Ftrunk%2Fcore%2Fgwtbox2d%2Forg%2Fjbox2d)
\- 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/>

~~~
tudorizer
"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.

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

------
CWIZO
Google cache:
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://blog.greweb.fr/2011/07/same-
game-gravity-technical-notes/&hl=en&strip=1)

~~~
gren
Thanks, It's up now :)

------
snewman
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)?

~~~
gren
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 :)

------
MetaMan
Well done. Surprising good fun to play !

