Google I/O 2011: Kick-Ass Game Programming with Google Web Toolkit

Google I/O 2011: Kick-Ass Game Programming with Google Web Toolkit


Cromwell: Hi, good afternoon. My name is, uh, Ray Cromwell.
And this is Phil Rogers. And we’re members
of the Google Web Toolkit team. And today, our session is called “Kick-Ass Game Programming
with Google Web Toolkit.” Now you might be saying, what does “kick-ass
game programming” mean? So we think it means
two things– the first is
that the kind of games that you’ll be able to produce using some of the tools
we’re going to show you today are not kind of, like,
HTML5 toys or prototypes or kind of, like,
hobby curiosities. But they’ll be real games
that, um, will be fun to play, and that people
will be willing to pay for. And the second thing is, is that by using
some of the tools, you’ll get such a boost
in productivity that you’ll feel that just the programming
itself kicks ass. So if you remember
from last year, um, we show–we showed
the “Quake 2” port to HTML5 called “GWT Quake,”
and that was done with GWT also. And, um, I thought that was
a pretty kick-ass demo, but a lot of people came to me
and said, you know, “Could you show me something
more recent than 1997?” [laughter]
Cromwell: So, um, this year, we were happy to oblige, and in partnership with Rovio, who did an incredible job
on short notice using its tools, um, we’re happy to show you
“Angry Birds,” which you might’ve saw
in the keynote. And I’ll tell you some things
about it as Phil is playing it. So one of the things,
of course, is that it runs
incredibly smoothly at 60 frames per second using, uh, WebGL or whatever technology
your browser has to do the rendering. And so as we were building this, one of the concerns we had was
the physics performance. So, you know, “Angry Birds” is a computationally
intensive game. When you smash down the level,
the, um– your engine
basically has to calculate where each and every one
of the pieces has to land in terms of their interactions
and their collisions. And that’s very intensive,
so we were wondering, Was JavaScript fast enough
to run it? And thankfully,
the answer is yes. So with Chrome 11,
V8 is just so incredibly fast that the physics layer runs
buttery smooth. But three things I want to say
about the actual implementation–
Bird: Aah! Ow! Cromwell: Don’t get
carried away, Phil. [laughs] Three things I want to say
about the implementation are, is that, one, uh,
it was built with GWT, two, it was built with–
purely with HTML5 technology, and three, it was built
with a new library for GWT that allows you to write games that we’re going to present
to you today. So, um, if, you know,
Phil can manage to stop playing– and all right,
I’ll tell you what, I’ll let you shoot
one more bird. Rogers: All right.
[chuckles] Cromwell: All right.
Bird: Aah! Oh… got it.
[applause] Cromwell: Okay, so the question
some people might have is, “Why GWT”?
What is GWT going to do for you? So if you’re a seasoned
GWT developer, you already know
that GWT is pretty awesome for developing enterprise apps. But, you know, games, you know– does enterprise have
anything to do with games? Well, if you’re
a beginner JavaScript pro– um, GWT programmer, or JavaScript–
JavaScript programmer, you might be saying, “I already know
how to write JavaScript. “I already know HTML5
and CSS and Canvas. “Why would I
write my game in GWT when I can just do it by hand?
What–where’s the benefit?” And I’m not going to say,
actually, you should use GWT. Um, if you are most comfortable
in JavaScript, or your team is most comfortable
in JavaScript and HTML5, that’s a very viable strategy, and it’s a very good way
to write a game. And as many of the presentations
that Google I/O has shown you, including Seth’s awesome
“Super Browser Turbo Mix HD,” showed you yesterday, you can build a game very fast
in HTML5 and JavaScript. But hopefully, we can show you
a few additional things that GWT can provide that might persuade you
to just try it out, because, um,
it’s going to boost, um, some of your capabilities. So let’s take a look
at some of those. First, um, it lets you leverage
a familiar Java toolchain. So if you’re
a Java programmer already, and you like Java IDE, if you like Eclipse
or IntelliJ, you like your debug environment,
you like your build system, you like your testing framework, um, you’re gonna get
all of that. Plus, you can leverage
a lot of libraries that are already out there
in the ecosystem, like physics libraries,
AI libraries, image processing libraries,
and so on without having to do much work. So you sort of get
to leverage stuff– work that people
have already done. The second thing is,
is that you can share code between the client
and the server. So let’s say you’ve got a game, and you want to put
anti-cheat mechanisms in it. So you’re posting high scores
back to the server, and you don’t want people
to just, like, do their own HTTP or XHR post
to your server and say, “I got a million points.” So how would you verify that? So one of the things you can do
is you can take your game logic, like, um, your physics
and your AI, and since it’s written in Java,
you can run ’em on the server, like an app engine, so that when you post
a high score, you can send over
a couple bits of data, like what the user actions were and what the random number
generator seeds were, and replay the game in the server engine
environment, and validate that actually
what they were saying is true. And that’s actually, um, we’ve actually done
some work on that, and it works pretty well. So you get to leverage code
between platforms, including, say, Android. So you might’ve
written some code where– for your game on HTML5,
but since it’s written in Java, you could reuse those same
classes for an Android game. So that’s another benefit
you get. And then you also get,
of course, small, fast JavaScript. So let’s go to the next slide. So as an example of leveraging
familiar tools, you might be familiar
with Box2D. It was originally a C++ library to emulate rigid-body
2-D physics. And I don’t know what
the actual statistics are, but probably 90%
of all the top games in the iPhone store
were written using Box2D, including, like, “Angry Birds.” So it’s very, very popular
for doing game engines. Um, now some guys
actually went out and they ported it to Java.
It’s called JBox2D. And that’s been around
for a while, but I don’t know very many
people who are using it. And that actually helped us
out a lot, because a couple of guys
at Google saw that library, and in just 30 minutes,
they were able to port it and optimize it
to run efficiently in V8 inside the browser with GWT. So that demonstrates the ability to leverage
the existing ecosystem very effectively with GWT and also to leverage,
um, code-sharing, because it was originally
written in Java for an–
a whole nother platform, and we were able
to repurpose it. So just to sort of, um, say a few things
about the GWT Compiler, which actually I happen
to work on. Um, it basically is not just
a Java-to-JavaScript translator. It’s an optimizing compiler
like a regular C compiler. And what it does
is it does things like removing unused code. It evaluates things that–
in compile time that it doesn’t need
to do at run time. It inlines functions, and it heavily obfuscates
the result. So, um, one aspect of that is that smaller code
tends to load faster. So the smaller the code
that’s compiled, the faster your game’s
gonna load up. Secondly, when it
compiles the code, it computes a hash
of the code, and it names the output file
according to that hash. Now that’s very important,
because it allows us to do something
called perfect caching. So when the user
accesses your game, it–the file name is related
to the actual bytes of the original source code. And that–your browser’s told
to cache that forever. So the next time you come
to play the game, even if you’re offline
or online, it doesn’t even go
to the web server at all to even check if it’s been
updated or changed. It basically says, “Oh,
I’m just gonna load that up. It’s cached forever
right out of my cache.” Now if you do happen
to change the game, what happens is, is you get
a new file on the server that has a different file name, and there’s a very small GWT
booster app script that checks, um–
that–that is downloaded and basically points you
at the new– redirects you to the new file. But that’s only gonna
be downloaded once, so you only download
when things change. Actually, you might have to go
the server to revalidate. Last but not least,
inlining the code actually helps the compiler
make it smaller, believe it or not. But for every function call
you eliminate, that’s excess overhead
in your run time that the V8 engine
doesn’t have to worry about trying to optimize. So inlining also speeds
things up, so you get smaller code
and faster code. So let’s talk a little bit
about HTML5, because HTML5–
when people use the term, it actually tends to mean
two different things. So there’s the HTML5 spec that’s in
the standards committees, which is the formal HTML5 spec. And that includes things like,
you know, Canvas, and audio tags and video tags
and the app cache, but it doesn’t include things
like WebGL or, um, say,
the new web audio API. But when you go look around
in the Twittersphere or the blogosphere,
and people say “HTML5,” what they really mean
is colloquial HTML5. They mean what’s
in the latest sort of tip of the source repositories
of the browsers out there, the latest things they’ve added, because HTML5 is
a continuously evolving spec. And so that’s what
we’re kind of targeting, and so throughout the rest
of the presentation, when we talk about HTML5,
that’s what we’re talking about. But so what does HTML5
do for games? So WebGL is big. Any browser
that has WebGL will able– will be able to really, really accelerate
graphics operations directly to the hardware. You won’t have
much of JavaScript or the operating system
getting in the way. If you don’t happen
to have that, um, CSS 3 is usually
hardware-accelerated on many platforms,
including mobile platforms, so that actually is
a big help, as well. And we’re gonna show you
in some demos later how we leverage those things. So next slide. So let’s talk a little bit
about the game– overview of a game architecture
before we move on. So typically, you need
three things when you’re programming a game. First, your game
needs to be able to communicate
with the outside world. And that means you need to be
able to get input from the user, like he pulls the trigger
to fire, or you get a packet
over the network because some other person
pulled a trigger, and he’s firing at you. And you need output.
So you need to be able to, um, display those changes
back to the user. And you need to be able
to play sounds, and you need to be able
to send packets back to other people
who you’re connected to. So you basically need
an I/O system. Secondly, although programming
the code for the game takes up a lot of effort, for most really polished games, the art assets actually are
the most important thing. So dealing, like,
for example, you know– probably “Angry Birds” or–or another game like that, the assets probably
make up a factor of ten times or bigger
than the actual code. So being able to load
those assets efficiently and cache them offline, um, and load them
in the right order so you can get the person
playing as soon as possible is very important. So asset management
is important. And then third is the game loop. So most games have,
like, an internal clock that’s usually keyed
to the, um, frame rate or the vertical sync period. And what happens is,
is at every tick of that clock, three things happen. One is we process all input
that–from the user. So maybe, you know, the user
pressed their mouse button or he–you know–
he touched the tablet. Maybe you got a packet
from the network because somebody
chatted with you. So you need to take those inputs and then feed them
into the next stage, which is to update
the state of the world based on those inputs. And that usually takes
into account things like running physics
simulations, running AI, um, running game logic, like updating the scoreboard
’cause someone got a kill, things like that. And then finally, after you’ve
updated the state of the world, you need to communicate
the state of the world back to the user, and that means
rendering graphics. That means rendering,
um, audio, and sending packets
back out to other players. So that’s basically very briefly
the three important things that make up a game engine. So let’s discuss
some of the challenges. So when you’re developing
for multiple browsers or for multiple platforms, it’s very difficult to get
optimal versions of these components
on various platforms. Uh, to give you an example, let’s say you’re doing
Canvas work. Now Canvas–
the Canvas API on some browsers is accelerated really well. For example, IE9,
believe it or not, does an amazing job
with Canvas. And as you’ve seen, uh, Chrome 11 and Chrome 12
and later versions actually is doing
really well with it now, too, but other browsers not so much. So the problem is, is if you
program directly to Canvas, you never know which particular
draw call you’re making is going to be
the accelerated path, or which is going to be
the slow path. So that’s sort of a minefield that you don’t want
to basically get into. You want someone to absolve you
of that responsibility. Then on other browsers,
you have WebGL. WebGL’s pretty much always
guaranteed to be fast. However, some browsers
don’t have WebGL, so if you wrote your game
purely to WebGL, you might kind of be stuck. And last but not least,
you know, maybe you’re using CSS 3
to do all your sprite graphics, and they’re not accelerated
on a particular platform. So that’s basically
one of the big challenges. Likewise, asset management– so each and every platform
has a different– unfortunately,
a different way of dealing with offline assets right now. So some browsers implement,
you know, app cache. They have local storage. They have index DB, DOM storage. If you’re on Android you have
a different storage mechanism. If you’re using Flash, you’ve got a different way
of controlling assets, so managing assets,
loading them over the network, and caching them locally
is typically a challenge. And then last but not least,
the game loop– so you might have seen
in several presentations here that traditionally, like, if you’re
a JavaScript programmer, you think in terms
of using timers to kick off your rendering loop. Well, that’s pretty bad,
because when you use, like, setTimeout in JavaScript, the browser doesn’t really know
what you’re doing. So you could be rendering, but you could be doing
something else. And that’s unfortunate, because if you’re
in a different tab, uh, or you–
or the window’s minimized, the browser is just gonna
keep firing that timer and doing tons of work. And it’s gonna chew
your battery life, and it’s gonna heat up
your machine. So different platforms
have different ways of syncing with the vertical
blanking period, or the redraw period
of the–of the platform. So in the newer version
of the browser, you should have
this requestAnimationFrame in colloquial HTML5. That sort of takes care
of that for you. But if you’re deploying to,
like, Flash, it’s different, and if you’re deploying to,
like, Android, it’s different. So that’s
basically another challenge, is basically syncing–
syncing video and timing events
on different platforms. So basically, I’m gonna hand it
over to Phil right now, and he’s actually gonna describe how we solve
some of those problems with GWT and the new library
we’re introducing. Rogers: Cool, thanks. So to answer these questions,
abstraction is key. Um, you might remember
that GWT abstracts away the differences
between browsers, which is Firefox 4 or IE9. We can apply that same logic
to games, abstracting away not only
the browser differences, but the differences
between platforms, as well, so the Java platform
or Android as a platform or the browser as a platform. So to do that, we wrote
a library called ForPlay. ForPlay is an abstraction layer
for games written in Java,
but is GWT compatible. So you get all the benefits of your Java
development environment, but you can also compile it onto fast and efficient
JavaScript. And this is all free
and open source. It’s a very alpha version
at the moment, but as you can see, we wrote
a kick-ass game with it, and we hope you guys will to. The source is available here,
as well as samples for everything we’re gonna
show from here on out. So you might be thinking, service provider interface
in Java, and that is what–
what this is. Basically, you write to a core game API
called ForPlay, and we swap in
the implementation for each platform. For instance,
if you’re running on Java, we’ll swap in the Java platform. If you’re on GWT,
we’ll swap in that platform, Android, and maybe even Flash–
we’ll show you later. So let me start with a demo–
always fun. And then we’ll actually dive
into the game and such. So this is a game. It’s running in the browser,
as you can see. We’re actually using
WebGL here. This is written using ForPlay. And you can see, this is
a simple sprite-based game. I click the mouse.
We have physics. We’re using the Box2D
physics engine here. And you can see it’s a–
it’s a fairly simple game. You click our things.
They bounce. We have different, say,
physics properties on, say, this blue thing
versus the box. We even have some fun stuff
in here. [laughs]
[laughter] Rogers: And–and what’s
really cool about this is look at how, uh,
performance it is. So this is, like,
in the browser, and we’re running
lots and lots of physics. And, like, there’s not
really a problem here. So that’s just kind of cool,
actually. Let’s see how far it’ll go. [Cromwell speaking indistinctly] Rogers: Oh, they’re all crowding
in the portal now. And now you can see the hacks
I did to make this all work. Oh, there we go. We’ve got
the infinite loop going. So… So the components of ForPlay– uh, we have–these are
the three main components we just talked about for games,
abstracting out the game layers. We have the game loop,
the I/O system, and asset management. ForPlay provides
the abstractions for you and swaps in the appropriate,
uh, code for each platform. So for instance,
on the browser, we’ll use requestAnimationFrame
where available for your I/O loop, whereas, say,
on the desktop environment, we might sync to Vsync
or something like that. And, uh, so you can see here in the game update loop,
we have init. So you write the game
to the core ForPlay game layer. You automatically get calls
to init, update, and paint. And so this is
actually for– for instance, you might want to run your physics update
at 30 FPS, but you might want
to draw at 60 FPS. We actually even provide– you can see a “float delta”
on the paint line. What that’s for is so that you
can, say, interpolate. So you’re drawing much faster
than you’re updating, and you want to interpolate
to make it really, like– really smooth. Uh, for your I/O system,
we have tons of stuff here– uh, fast graphics
for 2-D sprite-based graphics. We have audio.
We have nets. We have keyboard input/output,
touch input and output, um, and all this
is kind of abstracted in a really easy-to-use way, and I’ll show you that
a little bit later. Last, we have asset management.
The web is asynchronous. There’s a whole bunch
of issues there. It provides ways
to get your sound, your input, your text,
including JSON as well as callbacks
for when these things happen, so you can make, say,
a loading screen or something like that. ForPlay provides the–
the magic that happens to swap in the correct platform
that you’re running on. So you really write
to one API, and you get– you write very little,
actually one line of code, or one–maybe five lines
of code per platform, and you get swapped in
the correct one. I’ll show you
a little bit later. So this is–this is kind of
the beginning of a game. This is, uh,
“My Game” we’ll call it, and this is how you would write
the ForPlay API. You simply implement
the game interface, and we have init, update,
and paint. Like I said before,
these just get called for you once you start your game. Let me go to the next line and show you
the interpolation code. So again, you’re, say,
drawing at 60 FPS, but you’re only running at 30
on your physics update loop. And this is where–this is
how you could, for instance, interpolate it in a 2-D game. And you can see here,
we have interpolation code. It’s fairly trivial. [Cromwell speaking indistinctly] Rogers: Init is usually where
you’d load your resources, and the update loop is usually
where you’d process the I/O and basically update your
physics layer or run your AI. And then the paint is basically where
you redisplay everything. Oh, yes, that’s right. Sorry. Actually, we’ll show you
in more detail– actually,
I can show you the source of the pea physics game. So, um, input devices– this is kind of the basics of how you would start
writing your game. The is the same MyGame
implementing Game, but now we’ve added Pointer
and Keyboard. You can see we automatically
get callbacks into onPointerMove
or onPointerScroll or onKeyDown. And ForPlay handles the fact that you’re kind of running
asynchronous code sometimes on some platforms, so you’re not gonna get
these callbacks in while you’re doing
your physics update loop or in your paint loop. It’s all gonna be
spliced correctly. Now really, the–
the real meat to ForPlay is handling of the image system. So there’s three graphics
primitives ForPlay provides. We have Image, Surface,
and Canvas. Image is your fast-path,
simple drawing of images, and this allows you to get stuff
on the screen, rotate, scale,
and translate it. Surface takes image and takes it
a little bit further. What Surface really provides
is the fast path to OpenGL or WebGL. What it provides is things
like fillRect or also drawImage. It can draw multiple images, have them cached
on a single surface. Canvas is the superset
of both the previous two and even more. It actually provides
what HTML5 Canvas provides. We’ve abstracted away the different things
on different platforms. so you could do things
like text, like strokes. And really, it comes at a cost,
because these things– you don’t want to be
updating a canvas at 60 FPS. So what we do is we let you
cache the canvas result onto a surface
and then draw the surface fast. And this whole system is done
inside a layer– layer system
really similar to Flash. So it allows you to put
a whole bunch of canvases or surfaces or images
into the different layers and move them around separately. I’ll show you that
in more detail. So this is the pea physics
sample we saw before. Uh, we have three group layers
in this case. In the first group layer, we have a whole bunch
of image layers inside of it. this is where all our peas
are being drawn, and they’re being moved around.
This is all dynamic. And the next layer– this should really be
implemented as a surface layer. So on the initial init,
what we would do is we would draw
a whole bunch of our blocks, the static blocks.
We’d have them cached there. Then we’d just redraw
this cached image each time. So it’s gonna be really fast. Lastly, we have
just a simple image behind the whole thing that’s
just being drawn by itself. So this is the asset management. You’d really want to do this
in your init cycle, like Ray was saying. And what you’re doing is– this is a simple example
of how to load an image. So you simply say Image. You ask the assetManager for it. And if you want, you can
get a callback, as well, when this is done loading. And so this is kind of
the simple way to do it. You can also have, like,
a loading screen. For instance, Rovio did this
with “Angry Birds.” And what–what we’re doing here
is we’re adding images to our AssetWatcher, and we get a callback
once they’ve all loaded. So this is really great for– for–kind of Rovio’s
kind of situation. Now the cross-platform magic– So, you know, all the–
what I’ve said so far, everything you’re writing to
is platform-agnostic. You don’t know what platform
you’re running on, but this is where
the magic happens. This is those few lines
I said you had to write that were platform-specific. We have up here
HTML and Java. One of these comp–
compiles down into a JavaScript/HTML5 game. The other one compiles down
to a desktop app. And you can see how similar
the two are. You’re simply starting the game, and the ForPlay magic is
getting swapped in behind you. So to wrap up a little bit, ForPlay is open source.
It’s free. You write to a core
platform-agnostic API, and you get swapped in
the correct code, uh, to really
give you performance. It’s written in Java, so you get
your familiar desktop– you get your familiar
debugging environment. I’m gonna show you some
really cool stuff with that in just a second. And, um, it compiles down
to HTML5, so you get a really fast–
fast game, as well. So let me dive down
into the actual details of writing a game and show you some neat stuff
about that. So this–we’re gonna be
using the pea sample. Remember that this is, uh,
this is available online, so you can actually dive down into the source
a little bit more. But what I’d like to show you
is how great it is to debug in ForPlay. So up here, I have– this is–this seems very similar to what we showed
just a few slides ago. What this is, is the– this is the game entry point,
essentially. And we have
PeaPhysicsGame implements Game and a listener for Pointer. And as I scroll down,
you can see, this is
the initialization cycle. Now I don’t expect you
to actually read this, but the idea is
we just have, uh, a game, we have some inits, and we don’t know what platform
we’re running on in this case. Let me go down
a little bit further to this group. What we’re looking at here
is the onPointerStart callback. This is gonna get called every time you click
on the game. Oh, embarrassing.
Cromwell: [laughs] Rogers: There.
Um, sorry about that, guys. So– Cromwell: This is what gets run
when you click to add peas, when he was dropping peas. So that’s the line
of code he used. Rogers: Exactly.
And what we’re doing is we create a new pea
when that happens, and we add it to the world. Cromwell: And world is
a group layer that holds multiple image layers,
which are the peas. Rogers: Exactly.
So let me actually dive down into what a pea is. A pea is a simple
sprite-based thing. You might see something similar
in, say, “Angry Birds” or any other 2-D sprite game. But what I’d really like
to show you is some of the cool things
we can do in the debugging environment. Remember that we’re writing
in Java, so this stuff is really easy. And watch this.
I’m actually gonna run my game. We saw it before running as an HTML5 app. Now let’s see it here
running as a Java desktop app. You can see, it’s the same game
we were talking about before. Nothing has changed. Let me go over here,
and let’s say, um, let’s say my boss
comes in and wants– wants me to change
some physics parameters. Or, you know,
Chrome is really big. Let’s say we want to use
the Chrome image instead of the pea image. Let me just go in here
and change the radius of the little peas
that we were drawing. Or let me use a different image. Instead of the pea image,
we’re gonna use something else. Now remember that I haven’t
actually restarted the game. It’s still running here. And now we have Chrome balls.
Cromwell: Yeah. Rogers: Thank you.
[applause] Cromwell: But just
to emphasize that, so you think about when you
normally develop, and you have an edit,
compile, and run cycle. And even today, with JavaScript
and normal web programming, you have an edit refresher. You edit the JavaScript, you hit
“refresh” in your browser. With GWT DevMode, you hit–
you edit the Java code, and you hit “refresh.”
How about just edit? You edit, and as fast as you can
tab over to the window… [snaps fingers]
it’s already been updated. I think that’s–
I think that’s kick-ass. Rogers: Um…
[clears throat] So–and also,
because we’re running in our familiar
environment of Eclipse– a lot of you guys know this is
the standard GWT world– uh, we have our
“push to app engine” button at the very top, and we can just push this
and push our game to app engine. Cromwell: But he’s not
gonna do that today, because of the Wi-Fi.
Rogers: [laughs] Yeah, right. So because we can push
to app engine so easy, how about pushing this
to the Chrome Web Store? This is, like, three steps.
It is so easy. You push–you’ve already pushed
your game to app engine. You have it hosted in the cloud. It’s–it’s awesome. You now visit appmator.com. You upload your URL.
You download a zip file. You then go
to the Chrome Web Store and upload that same ZIP file. And then third is profit. [laughter]
Cromwell: [laughs] Rogers: Unlike the meme,
I mean, this is the real deal. You can either sell your game,
or you can put ads on it. It’s really easy to do. Cromwell: Or you can do
in-game payments, and we only take 5%.
Rogers: I know. This is so awesome. If they would’ve told us that
before the presentation, we could’ve worked it in. So I’ll hand it over to Ray.
Cromwell: Thanks, Phil. So Phil actually showed you
the game running as Java and running in HTML. So we’ve kind of danced
around the fact that we can also run the game
on other platforms. And so one of the things
you might be saying is, “Well, maybe I don’t want
to target the Chrome web store. “I’m not really sure
if I’m gonna target, you know, “170 million Chrome users
or 100 million Android users. I’ll figure that out later on
when I finish the game.” You might want
to defer your judgment and target Android. Well, you can do that,
because– because it’s written in Java, you can take the exact same game
and compi– and just with a few lines
of code, recompile it, deploy it
to any Android device, and it should work
out of the box. So, um, if things go okay, I’m gonna show you a demo. So I didn’t get, uh,
time to prepare a way to show it to you
on the big screen, but I’ll just really quickly
just show– you’ll see something moving
on the screen. So this is the peas demo. I’ll give the guy
maybe time to zoom in. But I can drop peas.
You see it runs fast, real fast. I can drop, like,
hundreds of peas, so… [applause] Cromwell: It runs very fast
on Android, so it–that’s pretty cool. So–but what about– well, I’ll get to that
in a second. Let me just show you
what you have to do to make it run on Android. So you create
your game entry point. And rather than saying
JavaPlatform.register or HtmlPlatform.register, you say
AndroidPlatform.register. We swap in the fastest
native pass to Android, and your game basically runs. You just recompile,
package it as an APA, put it in the Android Market,
and profit. [applause] Cromwell: Thank you. But for some of you, that still might not be enough. So you might happen to have some poor slobs coming to you
with IE6, who haven’t upgraded
to the latest HTML5 browser. But you know they have Flash,
probably. So wouldn’t it be nice if you could take the game and actually run it in Flash? And it turns out
you can do that. So what I’m announcing today
is a new back end to the GWT Compiler. It’s an add-on that basically compiles Java
to ActionScript 3 and builds a Flash application.
[applause] [cheering] Cromwell: And so here’s
an example of– Well, first, let me
just show you a demo before I get to the example–
the peas Flash game. So here–here’s a version of it. This is actually
a different version. Because of the Wi-Fi,
I couldn’t actually get the most recent version
on here. So it doesn’t have the portal,
for example, and some of the physics
constantly turn, but I’ll show you
by right-clicking here that it’s Flash, so… [applause] Cromwell: So how does it–
what do you have to do to get it to compile to Flash? You have to do one thing. You say FlashPlatform.re–
two things, actually– FlashPlatform.register, and you have to make
a GWT module file that inherits from, um, the ActionScript compiler,
that .gwt.xml file. That’s all you have to do. So let me just talk
a little bit about the GWT to Flex compiler. So it’s not a fork
of the GWT Compiler. It’s actually an add-on.
So you just drop a JAR file into any of your
normal GWT projects, and you inherit from a module,
and this thing kicks in. And what does it do? Well, basically,
it does a couple of things. First, because JavaScript
is similar to ActionScript, it basically has a couple
of extra passes that inits safe ActionScript
on the back end so that this Flex compiler
can compile it. Secondly, I’ve wrapped a lot of the flash.display media and other APIs that are part
of the Flex SDK with overlay types in GWT. So you can just call directly
into the native Flash platform if you want to,
just from Java code, like create a sprite
and add it somewhere. So you don’t have to use
ForPlay, actually. You can just write
a Flash-only app if you want, your Flex app. And third, it has a specialized
set of linkers on the back end that package up
ActionScript resources and run the Flash compiler. And later on, actually,
they’re gonna use swfmill to do asset packaging. So it will package your
other images and artworks directly into the SWF file,
um, for you. So… Let’s wrap up. Um, why GWT? Performance,
ease of writing code, and portability. Um, I’ve showed you
the core components of architecting a game–
the I/O system, the asset management,
and the event loop. And we’ve shown that by using
an abstract platform that’s not really GWT-specific
or Android-specific, you can write a game
that can target multiple, including Flash. Um, and the last thing
I’d like to say is, um, go build a game. So download this library.
It’s in an alpha state. Documentation is kind of poor
right now. We apologize. We’ve been spending more time
preparing for presentation than documenting, but we’re gonna be working on it
over the next couple days. But take a look at it
and have fun. And, um… we have a lot of time
to answer questions, ’cause we anticipated
there will be some. So it’s question time. Thank you.
[applause] man: Hi, um,
so is there, like, the equivalent of JSNI
for the Flash pack-in? So can we write
native ActionScript to interface between
the Java world and the usable– Rogers: Would that–
would that be “ASNI?” [laughter] Cromwell: So, um, yes,
and in fact, that’s how the ForPlay library
is written. So there is a whole bunch
of JSNI classes that are already there for you to access, like,
flash.display, flash.advance, flash.net, uh, flash.media. So I’ve covered
sort of the minimal set of Flash APIs already
that you’d want to call into for the game, but if you download
the source code, you’re welcome to actually write
your own JSNI classes. man: And is the source
for that available, as well, for that back end? Is that out
on the same web site? Cromwell: Yes.
Uh, they’re– they actually parallel–it’s–
it’s really easy to find. You’ll just see
a source directory, and there’ll be, like,
flash/net, flash/display, so exactly parallel
to the Flash APIs. man: Oh, great. Thanks. Cromwell: By the way, I think
I might not have checked in a JAR file
for the Flash compiler yet. So if–don’t be disappointed.
After the session, I’ll go make sure
the web site has everything. Uh, go ahead. man: Uh, you mentioned that,
uh, you’ve abstracted the I/O from the, uh, drawings
and the control input, but what about stuff,
like, for networking for multiplayer?
Cromwell: Uh, good question. So actually, we have
a ForPlay.net class that abstracts the network,
as well as– so it doesn’t do WebSockets yet, but it abstracts asynchronous
push/pull response requests. And it even extracts–
um, abstracts JSON across multiple platforms. So you can fetch–
for example, the level beta to load, um, the peas level
as a JSON file, and there’s a parser on Android, there’s one on Flash, and there’s one on HTML5
and Java. Rogers: Yeah, to take that
a step further, this cross-platform JSON parser
is really useful, for instance,
for sprite sheets. And I think that Rovio used that
for “Angry Birds.” You essentially have
one single image, and you have different
little sprite sheets on it, and ForPlay’s really good
at that stuff. man: Does this use 2.3 or does it require 2.4 beta? Cromwell: It uses 2.3–
well, I built it with 2.3.3. Um, so it should–
should work on there. But I haven’t tested it
on 3.0 yet. Hopefully, it works there.
[chuckles] [man speaking indistinctly] Cromwell: Okay, 2.4. Oh, you were asking about GWT. Ah, I thought you were
talking about Android. Rogers: Uh, yeah.
No, it works on 2.3. Cromwell: It works on 2.3.
Rogers: The answer is yes. Cromwell: It just so happens
that I have 2.3 on my phone. man: So hi, um,
how’s the performance compared from the HTML version versus the Java
or Android version? And have you tested
on other branded, uh, mobile operating systems? Cromwell: Good question. So the performance
for desktop Java, for Android,
and for HTML5 browsers, at least the ones
that we all like, uh, is actually very good,
as you saw with “Angry Birds.” The performance in Flash, of executing the code in Flash, is not quite as good as V8. Um, so the Flash game
is not quite as good as V8, but it’s also because the code
that I’m generating out of the GWT compiler
is not optimal yet for Flash. So I generate
typeless ActionScript 3. And so I’m not giving
the Flash VM the opportunity
to do more optimization. So later revisions
of the Flash compiler will probably produce
more optimal code. But in my testing, it actually runs well enough
to do a game on Flash, as well. So–so to answer your question
about mobile platforms, I don’t know if we can
give numbers, but I will say we have loaded up
some of the games we’ve done, including “Angry Birds,” on, uh, an iPad 2. And the frame rate
was way above my expectations. I wouldn’t say that people
would be happy about it compared to the native version, but what it gives–
says is that if they make the browser slightly faster
on the mobile devices, or if Moore’s Law kicks in, and the iPad 3 is,
like, twice as fast, you might be able to get
60 frames per second with an HTML5 game
on those devices. man: Um, yeah, you kind of
just answered my question about the Flash player speed. I wonder if you could elaborate
that on–you know, any more, sort of what things
you might plan for that, or if that was
just an example. Cromwell: Yeah, so, um,
there are a couple of things that we’re not doing
that we could do. So one is, we don’t–
we don’t generate, um, types. So we could generate
ActionScript 3 classes for each Java class and generate methods
instead of functions. So basically, we’re using the existing GWT back end
with modifications. So a lot of things just become
JavaScript functions instead of ActionScript methods. So that compiles fine,
and it works, but it probably
does not run optimally in the Flash VM. But, um, I’m–
that’s the next step. So the next to-do for me
is to make the compiler generate much more optimal
ActionScript 3 code. man: How about size–
how about size-wise? Does it make a fairly large SWF,
or do you have, uh, any way of making modules
or rCells or anything like that? Cromwell: So it–
it actually makes– it makes actually
pretty small SWF. I believe the peas game
was about 58k, and there’s some packaged
resources in there, but it could–
it could be better. Um, GWT, you know,
has code-splitting capability, and, um, we could use that
to leverage by splitting an application
across multiple SWFs and loading them in
on the man– but we haven’t
investigated that yet. That’s a good question. man: So I apologize if this
has been covered already, but, uh, so does the ForPlay API
cover audio at all? Cromwell: Yes, it has–
Rogers: That’s a good point. Cromwell: Yeah, okay.
Rogers: Go ahead. Cromwell: So, uh, yes, but it
covers very primitive audio, because when we started, uh,
we knew we had to target basically what was enabled
in Chrome 11 with just a regular audio tag, which is basically just based
on streaming basic audio. Um, so basically, yes, on Flash,
we used the Flash sound APIs to play the audio. On HTML5, we used the audio tag or we’ll use SoundManager 2
Flash library to do it. Or on Android, we used
a native sound API. So sound is supported,
but it’s very–it’s very basic. You can play, um,
OGG or MP3 or WAV files on cue, but you can’t do
much manipulation. But that–
that will change. man: Okay, thank you.
Cromwell: Yep. man: I’m kind of wondering
what your support is for binary data over the wire
when it comes to AMF, if you were sending it
to BlazeDS or protocol buffers
or something else. You talked about JSON,
but I don’t know if you… Cromwell: Right.
man: Had any experience dealing with mapping
ActionScript objects to POJOs and cogenerating that
in JSON… Cromwell: Yeah, so we haven’t
added any support yet, because we kind of wanted– we took the least common
denominator support for that. So you can fetch
known binary assets, like, um, media assets, right,
as binary. And that works because
it basically translates directly to the Flash
loader API or URL loader. But, um,
if you just want to load up an arbitrary binary file,
we don’t really support that, because until very recently, it was slow in HTML5 to load
large-scale binary objects. But that’s changing now. There’s the type, the RSpec, and there’s a couple
other APIs for doing it. So that will
probably be added later. man: Thank you. Cromwell: Hey,
what are you doing here? Rogers: Who let this guy in?
[laughs] man: I actually have a question. So actually, like, how do you
guys simulate the event loop in–in JavaScript
on the web platform? Because it’s just–I don’t know. Do you–do you use time-outs?
I’m just curious. Cromwell: Okay,
so for the browser– If your browser supports
requestAnimationFrame, we use that. And what happens
is the browser will– when it’s drawing– so if you actually focus the tab
that’s on the screen, it’s visible–when it’s
drawing at 60 times a second, it will call you, basically,
so on a schedule. Uh, if your browser
doesn’t have it, then we’ll fall back
to setTimeout or setInterval. Um, obviously, not as efficient,
so it– we basically take as efficient
a path as we can. And on Android, of course,
we use multiple threads and looper, um,
and handler objects to basically, you know, have
everything run in one thread, and then we post messages
to it with events. Rogers: And what this means
is for something like peas– your physics actually runs
in the background using set time-outs. but your phy–your drawing–
your paint update loop doesn’t run at all.
Cromwell: Yeah, actually, it’s interesting on Android,
because Android supports multiple threads,
unlike the browser. Um, you actually get
a little bit of a boost, because you can run the physics
and stuff in the background, and you can run the paint loop
in a different thread, which is pretty cool.
man: Thanks. man: Is–is the new
Flash back end gonna become a part of GWT,
or is it gonna– is it gonna just be
part of ForPlay? Is it gonna be, like, a–
will it be supported for non-game use, I guess,
and those kind of things? Cromwell: So, uh, this is not
an official Google project. This is kinda like
the personal pet project of a bunch of people who have,
like, an itch to scratch. But, uh, so it will be
part of ForPlay. And, um, going forward, um, we will be supporting it, ’cause we’re gonna be using it
for multiple things. So you don’t need to use it
for games, actually. So if you wanted to build a traditional
enterprise Flex app, but you wanted to use
Java to do it and Eclipse, you could actually use
the Flash compiler to do it, because we exposed
most of the Flex APIs, and it’s easy to expose more with regular GWT JSNI methods. And you could
theoretically build a Flex–a Flex ML,
you know, application. man: But you don’t intend to
fold it back into mainline GWT. It’s gonna remain
a separate project? Rogers: I don’t think Google
would support something called ForPlay.
Cromwell: Yes. [laughter] man: I meant more
the Flash back end. It’s not gonna find its way
back into mainline GWT? Cromwell: No, this is actually
one of the first times– ’cause the compiler
does have some hooks for attaching other back ends, and this is sort of
the first real ever, like, add-on back end
that’s been made public. And there are other ones
in the pipeline, so it’s possible,
like, there might be a separate web site,
like an incubator, where we drop these things
in the future. man: Thanks.
man: Hi, I was wondering if you could clarify
how ForPlay development compares to
or, you know, interacts with sort of normal
GWT development? So, you know,
would it be possible to sort of build
your game Chrome, you know, your menus
and your launch screens and everything
in sort of normal GWT, and then have sort of
the play area be in ForPlay? Or is it really
expected to be an entirely ForPlay
Canvas-based thing? Rogers: Sure,
I can kind of answer this. It’s kind of twofold. One is ForPlay allows you
to call out into the browser, if you want to, so in this–with this mechanism, um, you can definitely write it
in the standard GWT way. But the core of ForPlay–
like, writing a game to that–
to the ForPlay game layer is you’re really writing
in pure Java, and GWT is kind of a side issue. Um, so–yes.
Cromwell: ForPlay development is actually not really
GWT development. But I–there’s a caveat
to that. You can actually match it up
with any arbitrary GWT app. So, for example, I believe,
and correct me if I’m wrong, but “Angry Birds” actually–
like, the– some of the buttons…
Rogers: Yeah. Cromwell: Surrounding it, like switching
between HD and SD versions– there are other things
around the actual game that are actually done
as you would normally expect in a GWT app.
man: Okay. And then when you talk
about cross-platform support, and–but that
that applies really to just the sort of game area
part of the game, the ForPlay part of the game
is what– Cromwell: Yes, I’m– man: And so you redo
your Chrome on each platform. Cromwell: That’s right.
In theory, somebody could create, like, a widget library
to abstract, like, a list interface
and a tree interface and so on and map those onto, like,
Android widgets and onto GWT widgets,
and that would work. Um, we kind of hope, actually,
by making it open source, people might do
those sort of things, sort of build things on top.
man: Okay. Cromwell: Um, actually,
one of the other things is that there are people
in the audience who are experts on, like, asset pipelines
in games. One of the things
we actually need is–is, um– ForPlay’s asset management
is very basic, and for importing things
like SVG or Collada models and things like that and meshes, it would be cool
if people sort of built tools to sort of assist in that part, tying into the rest
of the R pipeline. There you go.
man: Thank you. man: Hi, again. Uh, we just tried to enter
the Chrome “Angry Birds.” Cromwell: Uh-huh.
man: And it asked for Flash. Is it compiled in Flash?
Cromwell: No, it’s not. Um, but what it is doing is,
is that, um, it’s using it for audio,
to play sounds. So we originally were using
the built-in HTML5 audio tag to play audio. But we ran into some hiccups
at the last minute, and I believe
those are being fixed in newer versions
of the browser. But in order to make sure
that the game was smooth and had–and basically was
as bug-free as possible, we–we used Flash
for the audio for now. But–so that’s not a–
sort of a knock against HTML5 audio. It’s just that there were
some problems, and we wanted to make sure
that the game ran perfectly. man: So for multiple platforms, how do you handle, like,
in-app purchases and, uh, advertising? Rogers: So there’s callouts
into the browser. Like I said, for instance,
in “Angry Birds,” what Rovio did was
when you click, I think, some of the buttons
in the game, that you’re basically
calling out into the browser. You do the same thing
for the– for your in-app payments
or whatever. Um, in terms
of architecting it, you basically–your–
you have several entry points for each platform that I showed,
those small snippets. Um, you can basically stick
that kind of code in–into the platform-specific
entry point and call into it
in that manner. Cromwell: But to be
more specific, there’s no high-level
service-provider API in there for that, but that would be a nice thing
to add in, like, the beta version, uh, so that, like,
if you’re in an Android app, it uses the Android
in that purchase, then if you’re on Chrome,
it does that. So that’s a great idea.
And actually, so anybody who doesn’t want
to contribute code, you can actually just go
to the issue tracker and put in what you want,
and, you know, maybe somebody will pick it up. Rogers: I think that’s it.
No more questions? Cromwell: So we’re letting
you guys go home early today. You can get out
and play with your– play some more
with your tablets. Thanks for coming to Google IO.
Rogers: Thanks. [applause] Cromwell: And, uh, go forth
and make kick-ass games.

51 Comments

  1. Ray, I'm a fan since i/o 2009 or 2008 where you were a guest speaker. You sure didn't disappoint at i/o 2011. Google is lucky to have you.

    Why isn't the Flash back-end compiler for GWT front page news??

  2. @beardymonger Thanks, I'm glad you enjoyed it. Each year I try to pick something out of the ordinary to do (since my original GWT Extreme! talk), but I'm running out of ideas. The flash compiler was actually mentioned in my 2008 talk, but I didn't get a chance to make a non-toy version until recently. Hopefully after we fix up the ForPlay site and check in a lot more documentation, tutorials, and build scripts, it'll get more traction. (which will happen very soon)

  3. @degoban, why don't you tell us what's your vision. You mentioned Flash, but i have a hunch your affiliation is Silverlight. I'm not saying HTML/CSS/JavaScript is easy, but it's an open stack, and not vendor tied.

  4. Runtime code adaptation — this is incredibly powerful and will push productivity hugely. Of course, it only applies to Javascript.

  5. @tiagotrinidad An exagerration. First of all, it's Quake2, not Quake1 that was ported. Secondly, Quake3 and Rage iOS have been ported and shown to run. In fact, the more modern games offload more work to the GPU, paradoxically, they can run well in JS. For example, Quake2 does keyframe interpolation in Javascript, but in newer games, this is done with vertex shaders.

    Not all games are CPU bound.

  6. touch input AND OUTPUT???? I want Touch output =P (i can see where they got the name for the ForPlay library =D)

  7. Last time I touched games was in like '84 on a commodore 64 when I played with the 8-bit sprites there. This video really got me interested now in game dev~! You still need some graphic design talent to make those images…

  8. I use windows, ubuntu, mint, and mac..Why not be smart about what platform your using. Just saying windows is lacking doesn't say a whole lot. Everyone of these platforms is lacking something. So i'm going to make sure I know why I'm using the platform I am.

    Windows and Ubuntu in combination have been my favorite environment.

  9. Your a dumbass. Just because you can't afford one, or have never owned one, doesn't mean they are shit. I got a virus within 2 weeks with a shitty windows. My Macbook with 2.6Ghz i7 Quad core and 16GB of ram will rape any computer you put up to it. Macs are meant for business, they're more organized and don't wreck to shit if something goes wrong. The interface is much smoother and easier, and comes with actual USEFUL APPS ON IT.

  10. Windows sucks, even though it is the most popular OS. Macs are too closed (like every other Apple product), but better than Windows. (They're also expensive) Linux is the best. Seriously. They're much more stable than both other OSs, they're lighter, they're faster and if you grab a distro such as ubuntu, it is fairly easy to use. Every machine I had Windows on, I removed and installed Linux. Mac + Linux = best setup.

  11. You're retarded. Anyone with a speck of common sense can avoid virus's easily. And just to let you know ALL platforms have virus's.

    And how much does that cost? I bet around 3-4k. I could find a windows laptop with those specs for 1 – 1.5k.

    That's why windows is the most mainstream os in business…

    Apple Fanboy xP

  12. Why are people arguing over what company to buy a computer? I have both a pc and a mac, and there isn't a whole lot of difference. The only thing that I can say from personal experience: I've had my mac for 6 years now, and it still works like it was new, during this time I've had to get three pc's. The reason for the pc's was that the first pc I got was terrible (a Sony Vaio), the second two where Dell. I have a feeling that mac's might last longer. But only from my experience.

  13. They laughed when I told them I was going to earn much more cash with Certor Cash Code, but then I showed them the results. Go google Certor Cash Code to see their reaction. (You should see their shock!)

  14. almost all google developers use macs to write code for some reason. And usually programmers use macs or linux.

  15. It would be a shame if you did not build muscle when other people accomplish it so easily using Max Muscle Method (go google it).

  16. yeah all macs r used to surf facebook. its not like all googlers (except for a few teams) use macs or linux computers

  17. It only took 2 weeks and N…oft gonna pay me $21.25 an hour to test their G…d W..s expansion video game tester jobs visit end check out GAMETESTERCAREERS.ALLALLA.COM

Leave a Reply

Your email address will not be published.


*