Practice English Speaking&Listening with: Google I/O 2011: Kick-Ass Game Programming with Google Web Toolkit

Normal
(0)
Difficulty: 0

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.

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