[MUSIC PLAYING]
MALE SPEAKER: Oven mitts for sale.
Oven mitts.
Oven mitts for sale.
Oven mitts.
TODD KERPELMAN: Oh.
Why, hello there, sir.
I could use an oven mitt.
In fact, I'll take two.
MALE SPEAKER: Here you go, kid.
Enjoy.
TODD KERPELMAN: All right.
Thank you.
This is just what I needed.
This is-- huh.
Hey, what's up with this?
MALE SPEAKER: Oh.
That's my invention, see.
Classic oven mitts, they're big and clumsy.
So I cut out windows in the mitts.
That way, you can use your fingers
while you're still using the mitts.
Great idea, huh?
TODD KERPELMAN: Wow.
This seems incredibly dangerous.
Have you tried this yourself?
MALE SPEAKER: Well, no.
I'm not much of a cook.
I'm more of what you call an oven mitt builder.
Anyway, enjoy the oven mitts.
Oven mitts for sale.
Oven mitts.
Oven mitts for sale.
Oven mitts.
Oven mitts for sale.
TODD KERPELMAN: Huh.
So maybe there's a lesson here.
If you spend all your time building tools
and don't actually use them once in awhile,
you can't really be sure they're any good.
I'm just going to put these down over here.
See, we at Google don't want to end up like our oven mitt
selling friend, and that, in a roundabout way,
explains why we released a game about pie throwing
to the Google Play Store.
Now, if you haven't checked it out yet,
"Pie Noon" is a fast paced action game
where you square off against your friends in a pie throwing
showdown.
It's built by our Fund Propulsion Lab's team,
the same folks behind such hits as the LiquidFun physics
engine.
But it does raise some important questions,
like why is Google making games?
Are we starting a game studio?
What's up with that?
Well, no.
For starters, the monetization model is terrible.
I mean, come on.
Where are the micro transactions folks?
No.
We really made "Pie Noon" because we've been making some
great new tools for C++ game developers,
but we figured maybe it's time we put our money where
our mouth is-- when it's not full of pie--
and demonstrate using some of these tools in a full blown
game.
Then we can open source the project
and let you see how we did everything.
So let's go over some of this tech we used one at a time.
First up, WebP.
WebP is a new graphical format designed
to keep your image file sizes tiny without sacrificing
quality.
Now, some people mistakenly think that WebP is just
for web pages.
Maybe it's the word web right there in the name.
But it's not.
You can use it in mobile apps as well.
WebP supports lossy and lossless compression
with lossless alpha channel support in both cases,
and it will give you considerable size improvements
over both JPEG and PNG files.
Remember, graphic assets can often
be the single largest component of your game,
and not everybody is downloading your game over 4G networks
onto 32 gig devices.
For many people, bandwidth and file sizes
are still real concerns, and the smaller you can make your game,
the more likely people are to install and keep it
on their device.
For "Pie Noon," our engineers started with target
files, converted those to PNG assets,
and then converted those to WebP format.
It was these converted files that
got used as the final assets in the game.
And how'd it turn out?
What started as, woo, 42 meg of [? TGAs ?] became 10.7 meg
of PNGs and ended up as a nice, slim 1.4 meg of WebPs.
In case you're curious, we went for lossy textures
with a quality rating of 90, which
gave us a good balance between size and quality.
You can judge the visual quality for yourself
in the game or just experiment with our conversion tool
and see what option looks best for you.
Now granted, you can still take this a step further
and export everything using GPU optimize textures, which
we still highly recommend.
But I know some developers don't want
to deal with multiple texture formats for different chipsets,
and for those people, WebP is a great alternative.
Next, up let's talk about MathFu.
MathFu is a cross platform C++ library designed to quickly
and easily perform common mathematical tasks that game
developers encounter.
So if you've got matrices that need multiplying,
or quaternions that need slurping, or just need
a randomly generated vector, MathFu could help you out.
Now granted, there are many math libraries out there like this.
But what differentiates MathFu from any of these others
is twofold.
First, it's optimized for SIMD chips,
like the one that is probably in your phone right now.
And this is pretty significant.
On a Nexus 5, you're looking at about a 5x speedup
just by using the SIMD optimization.
On a desktop machine, it's more like 20x.
Second, MathFu was designed from the outset
to be simple and streamlined.
The developers did not throw in the kitchen sink here.
They kept it focused just on performing tasks
that game developers need.
So if you're looking for a math library
to help you fold proteins or something,
you should not use MathFu.
There are better libraries out there for you.
But if you're looking to make a game,
this will cover all of your needs.
And again, this was something the "Pie Noon" team set out
to prove.
The developers used it for everything
from the particle system, to the camera positioning,
to the parabolic pie paths, and it worked great for that.
Finally, do you have level data, animation
files, or saved game data in your game
that you are defining as a giant block of JSON?
Well, if you do, stop it.
Seriously.
Stop it.
Stop right now.
Step away from the text editor.
Look, JSON is great for producing human readable data.
But in order to make things human readable,
you end up having to use a lot more space than you would
use otherwise, and in many languages,
your JSON to native code decoder is
going to be slow thanks to all the string parsing and type
guessing work your decoder needs to do.
Not only that, but the deserialization process
is probably going to wreak havoc with your memory
as a lot of temporary objects are allocated and deallocated.
So to fix this problem, Google created a serialization library
called FlatBuffers.
This is an open source tool where you write out a schema
describing your data, and the flap buffers library generates
a C++ file that can convert a byte array to a native object
and back without even having to unpack it,
meaning that zero superfluous objects are allocated
to memory.
It's fast, way faster than reading in JSON files.
It works cross platform, it's [? strongly ?]
typed to avoid careless mistakes,
and even has some nice versioning
support when you need to change your data format.
So the "Pie Noon" team use FlatBuffers
to define everything from the location of their UI elements,
to their particle effects, to storing
all of their gameplay settings.
But are you ready for the big twist?
They authored these values using JSON files.
So OK giant circle with the slash through it.
You can go away now.
Here you go.
Look at that.
You see, an intermediary step in the build process takes
a FlatBuffer schema and a corresponding JSON file
and converts the entire thing into a byte array,
which can quickly be read in as a native object
by the generated C++ file when the game starts.
So you can check out the CMakeLists file on the project
if you're interested in viewing all the dirty details.
But I think the point to take away here
is that the team got the convenience of still being
able to author in a human readable format,
but the speed of nearly native code by using FlatBuffers.
Now, this speed boost was huge from a relative standpoint.
FlatBuffers are like 400 times faster than JSON.
But in absolute numbers, it was actually modest
just because this game didn't have a lot of data to load.
So this whole speedup was pretty minor
compared to everything else the game had to do at start up.
But if your game happens to have large amounts of game data
or save files, this can save you a ton of loading time.
So there is some other tech the team used,
like the build all Android script, which ended up
being really useful to quickly iterate on a build,
and a CPU profiler, which frankly ended up
being not so useful because the game was actually GPU bound.
But that's a whole other episode.
Anyway, if you're interested in finding out more
about any of these technologies, we
have a whole list of links for you
to follow in the description below.
But more importantly, we have a link to the full project
so you can try it out for yourself,
fool around with the code, and build
your own version of "Pie Noon."
So you give it a try and enjoy.
As for me, I'm going to enjoy this delicious fresh baked pie.
Holy mother of God, that's hot.
Oh.
Like I said, you can spend your days building tools,
but unless you use them yourselves once in awhile,
you might get burned, literally.
I'm Todd Kerpelman, and I'll see you soon.
MALE SPEAKER: You know what I love about working at Google?
It's that no day is exactly the same.
Every day brings its own unique challenges and surprises.
For example--
MALE SPEAKER: You guys put your phones on silent and then--
TODD KERPELMAN: No one calls me anyway.
MALE SPEAKER: Sure they do.
TODD KERPELMAN: Wrong numbers.
I ask them to talk to me.
MALE SPEAKER: Hey, Todd.
I'm just checking.
Does that smell OK?
TODD KERPELMAN: What?
I think it smells fine.
Why?
I hate you Jeff.