[MUSIC PLAYING] TOM GREENAWAY: Good
afternoon, everyone. My name is Tom Greenaway. And I'm the games lead for
the Chrome and Web Developer Relations team at Google. Before joining Google, I
ran my own independent game development studio. And I created a
native mobile game called "Duet,"
which was downloaded nearly 20 million times. So I have a lot of experience
in game design, and production, but also in running a business. I joined the web team a
little over six months ago. And I've been researching
the web game space during that time. And I'll admit
that, when I joined, I was a little bit skeptical
about the success of web games and whether it's a truly viable
place for a game developer to build a business. But today, I'd like to share
with you some of my thoughts and discoveries in this area. And I hope, by the
end of the session, I've opened your
eyes a little bit to some of the new opportunities
that exist out there. Because the truth is is
that I think the best way I can describe the web
and the potential of web games is that it's an opportunity. In fact, I think it's a
huge opportunity that, with some effort and
some determination, can be incredibly valuable for
game developers to consider. But let's start by
facing some facts. As game developers, what do we
need to succeed as a business? Well, really, we need three
things, a functioning game, users, and a way
to monetize them. The first topic probably
sounds really obvious. You're thinking, Tom, of course
you need a functioning game. But to clarify, by
functioning game, what I mean is a game that runs
well on devices, looks good, and sounds good. Does the web provide
us with these things? Can we build a web game that
ticks all of these boxes? Well, the answer is, yes. HTML5 has matured a lot
in the last 10 years. And there is a long laundry
list of technologies that I could tell you about. And I'll touch on some of
them later in this talk. But to be brutally honest,
the viability of web games-- it really has nothing
to do with the tech. This isn't really a
technological problem anymore. It's a business and
ecosystem problem. And that's why these
next two points-- getting users and monetization--
are so much more important. Because if you don't have users
and if you can't make money, then you're toast. Now, I'm not saying
that the web is 100% equipped right now to
solve both of those problems. As someone who created
games for platforms like Google Play
and the App Store, I know how valuable it is to
have a platform provide you with users and eyeballs that
are looking at your product and also to have credit
card details and payment options readily available
to be able to transact with your users. So, does the web have
these things built in? Well, no, not to the same
degree that the native platforms like mobile platforms have-- or even desktop
stores, actually. But at the same time,
we should recognize that the web is basically
the most open platform that has ever been created. That is both its
greatest strength and its greatest weakness. So business models,
ads, subscriptions, or microtransactions--
on the web, you can literally do
anything you want. But at the same
time, it also means that users aren't always
familiar with what you're proposing. And that means there
can be less trust. And less trust means
more friction to pay. And discovering
and getting users-- now this is where things get
really interesting, actually, for the web. Because the web is
totally decentralized. And when it comes
to discovery, that's the reason why we have
things like search engines in the first place. That's why Google exists. And yet, at the
same time, there's no platform that is actually
more viral than the web. When users see a URL,
they know what it means. They know it means
that they can tap it, and they can be whisked away
to something that could be-- well, it could be anything. And yet, they trust it
completely to tap that link and to jump into something
completely unknown. So there is enormous
trust in web browsers to keep users safe. And we don't take that lightly. And that's sort of the
beauty of the web browser-- is that, as easily as you are
linked to a piece of content, you can now link another
user to that same content by sharing it. And so that cycle of being
linked and then linking others is really the power
of the web, really. We all know it. It's not just a series of tubes. It's actually a series of links. And not only is the web
the most open platform that has ever been created, it's
also the biggest platform ever. Every device has
a web browser now. Even smartwatches
can render web pages. And with new feature
phone platforms coming out that with HTML5 as their
primary app platform, it really means
that there are just billions of devices out there. That's the size of
the opportunity. The user base is
literally billions of users on browsers on
all sorts of devices. So why do we focus so
much on native platforms? As game developers,
I think we do it, because it tends to be easier. Because a lot of the work
has been done for us, especially when
it comes to things like discovery and monetization. But that doesn't
mean that we should ignore the potential of
the web and the opportunity that the web brings. For sure, continue
making native games. I'm not saying that
you should stop. But as we all know, all
businesses and business opportunities are governed
by risk versus reward. And the reward for
building native games is a well-known factor. So I think it would be great
to try tackling those three requirements I outlined
earlier, and look at them from the
perspective of web games to measure the potential
of that web gaming reward. So let's look at building a
functioning game on the web, finding users on the web,
and monetizing on the web. OK, so a functioning
game-- as I said earlier, HTML5 has matured a lot. So, what are the requirements
for a functioning game? I mentioned that earlier, too. You need to have it run
well on your device. You want it to look good. You want it to sound good. So that means we're
talking about things like CPU, graphics, and audio. So a very quick way to break
this down is by just grouping all game developers in the
world into two simple buckets, those who have their own
engine and those who don't. So if you're in the
latter and you're using an existing off-the-shelf
engine, I imagine 99% of you are using either Unity,
Unreal, or Cocos. And so, the reality is that
all these engines actually support HTML5. And they've supported
HTML5 for a long time. In fact, Unity has
a special new HTML5 runtime called
Project Tiny, which I'd like to highlight to you. But I'm going to save that
for a bit later in the talk. But if we flip to
that other bucket-- OK, you've got your own engine. Well, firstly, that's amazing. That's really great. And the reason why I say that
is because in my own company we had our own C++ engine. And it was kind of
completely ridiculous. But it was also completely
awesome at the same time. So if you want to bring
your own engine to the web, how do you do it? Well, if you do have
your own engine, I imagine that 99% of you
have written it in C, C++, or some other language
that compiles through LLVM to machine code. And if that's, the case
go check out Emscripten. So Emscripten is basically
a compilation tool chain that takes any language
that compiles through LLVM and can provide bindings for
a bunch of standard platform features, like file system,
graphics, and sound, and OpenGL bindings, for example. And as we know,
all this sounds-- well, actually, no, I
know what you're thinking. You're probably thinking
this sounds a bit like I'm cheating, like I'm not
going really in-depth on each of these topics. But the reason why is
because, at I/O, we have other sessions
on web assembly, and CPU, and
graphics, and audio. So I recommend you go and
check out those talks. And I'll highlight
them in a few seconds. But I'll go just
briefly at a high level on each of these topics. So here's a quick summary. So, CPU-- there's a cool new
portable binary instruction set called WebAssembly
that's available in all the major browsers. So it's safe. It runs really fast. It's actually close
to native performance. And it also loads really,
really quickly, too. Can you do threading in
WebAssembly or in Chrome? You can. And in other
browsers, it's coming. And you don't need to write
your entire game or engine in WebAssembly, actually. You can mix it with
JavaScript, as well. So Construct is a web-based
game editor and engine. It's super simple to use. And they used
WebAssembly actually to optimize their physics. Originally, it was just
Box2D ported to JavaScript. But they've replaced
it with a Box3D to WebAssembly port now for
even better performance. If you want to learn
more about WebAssembly, we have another talk called "Web
Assembly for Web Developers," which ran earlier today. So I recommend checking out a
recording of that on YouTube. OK, what about graphics? Well, there are
two parts of this. If you're using OpenGL, you
should really check out WebGL. The most prevalent version
of WebGL in the wild is WebGL 1.0, which is sort
of equivalent to OpenGL ES 2. And I know that's not
at parity with what native mobile platforms provide. But we all know
that good graphics-- it's not just
about raw fidelity. It's also about style. And in the future, what
about other modern graphics pipelines, like Vulkan,
or Metal, or DX12? Well, there's a new standard
in development called WebGPU. And it's a fully programmatic
graphics pipeline that gives you full control. So all the major browsers
are experimenting on WebGPU. But here's a little
demo of Unity's engine running the tanks demo
with WebGL on HTML5. And that Bitly link
will take you there. If you want to learn more
about WebGL and WebGPU, check out the
"Next Generation 3D Graphics on the Web" talk,
which is on tomorrow at 3:30 PM. Or check the
recording on YouTube. OK, but what about audio? Well, this is super
important, as well. I remember, whenever
I made a game, I would probably end up
adding audio late in the stage of the development. But as soon as I added it, I
really realized, how did I ever play this game without it? Well, you might
be wondering, what is most common audio
API on the web? Well, it's aptly named
the Web Audio API. And it's a versatile API that
can handle sound and music loops. And you can also write your own
programmatic effects, as well. But if you need to run effects
and ensure your audio never glitches, I'd recommend checking
out the AudioWorklet API. It's available in
Chrome and supports effects in either JavaScript
or WebAssembly, actually. And because it runs
in its own thread, it doesn't cause any
glitching or any jank. And if you want to learn more
about audio with the web, check out the "Sonic
Boom Audio Programming on Android and Chrome" talk. That was given
yesterday evening. So that will definitely need
to be checked on YouTube. So those are the key
technologies, in my opinion, to get a functioning
game up and running. Are there more things
you can do with the web when it comes to games? For sure. You can have things like
the Full Screen API, or the Gamepad API, or
Gyroscope for inputs. And there's a long list. But I don't want
to just tell you that web games
can match the user experience, and the
fidelity, and the features of native games. I want to show you. So here's a quick
example of "Crossy Road." It's an excellent indie game
from a few years ago running on native mobile but also
on the web, actually. As you can see,
they're pretty similar. So, which one is which? Well, the one on the
right is the web version. There are some clues like the
navigation bar at the bottom, the branding from
the web portal, Poki. But as you can see, the
overall graphical fidelity of the two versions,
the native and the web, especially in terms
of frame rate, is basically on par
between native and web. And how successful was "Crossy
Road" in the first place? Well, on iPhone and
Android, it actually got 200 million downloads. So it was a very,
very successful game. Was it pushing the
limits of mobile devices? Did it really need
high-end graphics or Super realistic visuals,
or physics simulations to achieve those
download numbers? No, it didn't. It just needed to run well,
look good, and sound good. But actually, it also needed to
have one other thing, really. It also really needed to be fun. That's not something I've
brought up before in this talk. But it's actually the most
important things about games. It needs to be fun. So why didn't I
mentioned it earlier? Well, I didn't mention
earlier, because I think it ties in really
well to my next topic, which is how to get users. So there's an old saying that
a great product sells itself. It's sort of the foundation
of product marketing. And honestly, I think it's true. So in a funny story-- in my company, while I was
running it, we made five games. And I'd like to talk about
two of them briefly today. Out of the two of
them, one of them was featured really
heavily at launch. And it got a big
burst of eyeballs looking at it when it came out. And then the other
one, it launched, but it didn't get anywhere near
the same level of featuring. So if you're wondering what I
mean by featuring, what I mean is, of course, when the mobile
platforms highlight your game on their stores. In other words, it drives a
lot of eyeballs to your game all at once. It's really awesome. It's like free marketing. And as an indie game
developer, that's gold. Now, one of those
games actually went on to become the most-financially
successful game that we ever made
by a big margin. And the other one was
the least successful. So which one do you
think made the most money, the one that got the
big spotlight of featuring at launch? Actually, no, it was
"Duet" that was the more financially successful
game-- the one on the right. And it only got basic
featuring at launch. Yet, its daily revenue was
really great from the start, and it just grew over time. And we did sales. And that sparked
things, as well. And actually, the other
game, "Time Surfer"-- it plummeted in
the download ranks when it wasn't featured, while
"Duet" just sort of glided every time it got
featured or had sales. And it just had this
slow gliding effect in terms of the download ranks. The question of why-- well, because "Duet" had
an interesting narrative. It had really
innovative gameplay and an excellent soundtrack. And for all of
those reasons, users really loved it, and shared
it with their friends, and talked about it. And that made it go viral. It's the same sort of
story for "Crossy Road". It's the same for all
great games that take off. They take off because
they're great. Now, I know some of you in the
audience might be thinking, but what about games
like "Flappy Bird"? That took off, and it was viral. But it wasn't great. But actually, I disagree. I completely disagree. I think "Flappy Bird"
is really great. It's so simple and
also challenging. But also, very importantly,
it's hilarious. It's actually pure comedy
gold if you think about it. Look at the face of that bird,
and tell me it's not funny. If you look at the
proportion of his duck bill to his tiny little wings-- I find it just adorable. And the sound effect when
you crash in the game, it's sort of like the
sound effect of someone being punched in the face. So you've got this ridiculous
bird flying through space and encountering these green
pipes-- which is another really great video game reference. And when they smack
into it, your reward for your frustration is the
sound of like a martial arts movie sound effect. It's a combination
of just how funny and how challenging
"Flappy Bird" was that made it so interesting
for users to share it. And so, what am I
getting at here? What am I saying? I'm saying that
the best way to get users is to make something
really fun, and innovative, and interesting. And that way, it's
likely to be shared. In other words, I'm saying,
you want to make it viral. And additionally,
you want to make that sharing process,
that viral loop, to be as fast as possible. And why do I think
this is particularly important for our
talk about web games? Because that's the
cycle of the web. That's what web users expect. They expect web content
to load really fast. And good game
developers know that, to capitalize on a
particular platform, whether at a software
or hardware level, it's important to embrace
the unique characteristics of that platform. If you're building a game,
say, for a console with motion controls, you should probably
think about the best way to embrace those motion
controls in your game. So ultimately, what I'm saying
is that you must respect the expectations of the
users of the platform you're building for. And in the case of
making web games, what do you need to respect? The speed, the seamless, and
the frictionlessness of the web. And I mentioned earlier that
the URL, and that sharing loop, and everything on the web being
a tap away is really important. Well, have you heard
this stat before that, for each additional
second of load time, you lose 20% of your users? Well, users aren't going to
wait longer just because you have a web page
that's loading a game. So you need to
design your web games to load within that
sort of time frame to download the minimum viable
game that your users expect web content download within. And you want to get that
user into your game, and engaged, and hooked
as fast as possible. So let's summarize that
viral feedback loop. We want to build our game so
it loads fast and gets the user playing it really fast. And then we want to make
sure that the user is pulled in and engaged. So you want something to be
interesting and innovative. And then you want to
give the user a reason to share the game
with someone else, ideally beyond just the fact
that it's an interesting game. So, how do we make it fast? What are good examples of
games or technologies that get users into a game quickly? Well, remember I mentioned
Unity's Project Tiny HTML5 runtime? So Unity is previewing
a new runtime, which provides a new modular
design for their engine. And that keeps the core
engine under 1 megabyte. This gives you the
power of Unity's editor with a much smaller file size. And additionally, C# support
is coming soon in the future. And from the tech
side, that's really an interesting example
of how to make sure our game loads quickly. You want to use tools that
ensure that the game is as small as possible. But let's also look from the
game production side, as well. What do these games
have in common? Well, they all have
interesting art styles that are visually
pleasing but actually also very simple at the same time. In other words, they're
sort of minimalist in style. And what does this mean? It means that the
overall download size of my game and the actual
content or assets that we need doesn't need to be as big. Because we're just
rendering games with an abstract or
minimalist art style. In other words, I'm saying
you can do more with less. Here's actually a
great example of that. So some of my other team members
in the Web Developer Relations team have made this
game called "Proxx." And game design wise, it's
basically like "Minesweeper." It's super lightweight. And it's less than 100 kilobytes
in total over the wire. So it really
demonstrates the fidelity and the athletically
pleasing nature of graphics that you can achieve
in a web game with just a really small
amount of file size. And what about making a game
as fast to start as possible? Let's take a look
at "Slither.io." This is a game that went
super viral on the web. And how have they
actually designed the first-time-user experience? Well, when a user
arrives, they're asked to pick a
nickname and press play. And it loads very
quickly, this login page. And then as soon
as they press play, it just throws them
straight into the game. And I would even advocate that
you can take that further. You could actually
maybe make it so that, the first time
the user arrives-- and if they've never
played before-- then just throw them
straight into the game. And then when they die
for the first time, then you could ask them if
they want to pick a nickname. So this is "Slither.io"
recognizing that getting the user
engaged and into their game as fast as possible
is really important. And here is an animation of
another game, "TypeShift." So this is from a game designer
and game developer, Zack Gage, based in New York. He did a talk at
GDC last year called "Designing Games That Are
Understandable at a Glance." The idea behind this
is that he advocates for designing your game so
that, visually, at a distance, it can be understood-- like, what your
game is all about, what the game design
and the mechanics are. Because if you design
your game at a distance to be understandable
in that way, then it's very likely that,
when your game is being played by a player directly
in front of them, that they're going to be able
to understand it even faster. It's when the game
explains itself. And all the elements
of the game, the mechanics and
the visuals, come together so that your game
is instantly graspable. But how do we create
a compelling game, one that pulls the user
into the experience after they've loved the
interface and the mechanics? Well, here are a few thoughts. Going back to
"Crossy Road" again-- I guess one way of
thinking about engagement or engaging a user is to
think about the fun factor. So in "Crossy," it has
a swipe-based game play that's sort of like an evolution
of the original "Frogger" game. But they also streamlined
it, so you can just tap the screen really easily
to progress further and just go in the straight path, which
is the most important movement you can do in the game. And then they made
it endless and then also added in this
slow-moving camera that adds a tension to the game. Because if you're too slow,
then you get left behind, and you lose. And another example
is "A Dark Room." So "A Dark Room" is a web
game that went really viral. And it starts out as
just a simple clicker genre, in which
you're just stoking this fire in a mysterious room. And while you're
stoking this fire, eventually a stranger walks in. And you speak to them. And then basically, the
game just evolves over time. You get more actions to do,
which is normal in clickers. The gameplay expands. But on top of that,
then the whole nature of the game and the game
genre changes, as well. It opens up to
have an overworld. And you're then exploring
a larger game world. And I think what's
clever about this is that it really highlights
the power of mystery that a game can have. Something as simple as just
the mysterious narrative and the thrill of not
knowing what you don't know can really pull you in
and keep you in a game. And then there's the
innovation side of things. So there's a web game
called "Black Room," which was from a web artisan
game designer, Cassie McQuater. And it recently won the
prestigious Nuovo award at the Independent Games
Festival at GDC this year. And the Nuovo award is
specifically for innovation. And this wasn't only in the web
category or anything like that. They don't have
categories for the web. It was across all the games
that were submitted to IGF. And so the key with
"Black Room" is it's got some really
funny ideas about how to embrace specific features
of the web platform. So when you're playing
the game, there are some levels where
you need to find something that's actually not
on the screen at the moment. And so, traditionally,
you might think that you need to pan the camera
around or scroll the camera to find these objects. But actually, in "Black
Room," what you need to do is you actually resize
the browser window and reveal more of the room. So it really highlights how
you can use the unique features of the platform in
your game design such that that game could not
be achieved on other platforms. Additionally, she also
incorporated ideas like being intentionally
linked out from the game to the open web, and exploring
parts of the open web, and then needing to explore the
open web to solve puzzles back in the real game. And lastly, I mentioned
that we want to give users a reason to share. We want the URL to
be really compelling. So there's a few different
ways you can do this. You can do it in competitive,
or collaborative, or maybe exploitative ways. Here's a competitive
example, which "Shellshock" at I/O. It's
an arena first-person shooter, similar to "Quake"
or something like that. So it's a competitive
multiplayer game. And using URLs, you can deep
link another player into a room to compete with you. So whenever you create a
room in the game to play, it generates a
URL that's unique. And so then there are all other
kinds of examples you could do. Think of all the possibilities. You could create a game
where you have the ability to create a puzzle
or a level in a game, and then that URL is
playable link to that level. Or you could speed
run a game or a level, and then have a player
ghost or a player trail that is left behind. Or you could challenge other
people to beat your score, to beat your ghost. Or you could have
a game that's like a big, open, rogue-like
style game with a really large, huge, open world. And you explore different
rooms, but you're able to copy and paste the URL
of the current room you're in and share it with a
friend to teleport them into that part of
the game world. So here's a little
game I actually made called "Space Board." And I built it using Construct,
which I mentioned earlier. And I made it actually
in less than a day to just see how fast
Construct on the web could be as a game
development platform. But not only that,
I designed the game to demonstrate how URLs can be
used to transmit data, as well. And so I put a little
level editor into the game. And when you play the
game, you can then send a link to your level. And all of the game
data of the actual level is transmitting that URL. It's hard to see that
full URL in the browser. But it's literally representing
each of the tiles of the game as characters in the URL. So if you try that
out, you can play it on either desktop on mobile. But why am I also
showing a QR code? Because QR codes also are URLs. And so I think that can be a
really interesting marketing tool for promoting content
in the physical world. If you access the
URL in this QR code, it's another level I
generated or created. And it's actually a
lot more challenging. It has a lot of enemies. So you can have some
fun trying out that one. But you could also
imagine that "Space Board" itself could generate
QR codes of levels right there on
the mobile device. And then other users
could scan the QR code and share it in
person, not just as links that are shared in chat
apps or anything like that. But once you've got users,
what are the best practices for monetizing them on the web? Well, the landscape has
been changing gradually. Banners are still a
form of web advertising that's really important
for web games. For example, Agar.io,
their web version shows a banner every time the
game loads or the player dies. But we also have
more modern forms of advertising now on the
web, like video interstitials. And several companies,
including Google, have solutions for
inserting videos in the middle of your web games. And ideally, you
should experiment with how frequently you show
these ads to your users. And meanwhile,
some companies have experimented with the rewarded
video ads and web games, as well. If you aren't familiar
with rewarded ads, it's a very popular ad format
that native mobile games have adopted in the last few years. Say, you're playing a
game, and maybe there's a currency in that game. What you would do,
as a game developer, if you want to display reward
ads, is you would make it so that you can watch a
rewarded ad to then get more of the currency in your game. And so that's why we
call it rewarded ads. Because when you
watch this video ad by choice instead
of having it pop in for you like an
interstitial, by opting in, you're getting a reward
as part of that process. And when it comes to
microtransactions, there are quite a few
different options now, as well. So Google Pay, of course,
is a JavaScript library which gives you
access the credit card details that are stored in
the user's Google account. But also, Chrome
supports the Payment Request API, which is a
open web platform feature. And this streamlines the
payment flow, as well, by making it easier
or quicker to access the credit card
details of your users, say, stored in the browser. But also, on a native
platform like Android, using Payment
Request, it actually will access the
credit card details that are stored in
Android Pay, as well. So those are two ways of
quickly getting the credit card details. But it doesn't really help you
with the payment processing and payment back ends. But nowadays, there are
a lot of companies that are operating in this space. And it's really
never been easier to set up a payment back end for
processing microtransactions. And what about web
portals, as well? Well, remember "Crossy Road"? I mentioned it earlier. They published
their game via Poki. And Poki is a web portal which
has quite a few different games available. Another example is
the "Subway Surfers," which has come out recently
on poki.com, as well. And I guess what I'm
getting across here is that you should recognize
that web portals can probably assist you in monetization
best practices and help you with
that user reach. Because they have their own
discovery ecosystems of users, as well. But also, let's think from a
totally different perspective, as well. Even if you've already
launched a game-- say, a native game-- on a mobile platform, have
you actually considered whether all your
potential users who are interested in your
brand are finding your game? Or are they perhaps searching
for your game on the web and finding web alternatives
built by other companies? Game design isn't patentable
nor is it a copyrightable. So it's important to
ensure you have parity with your competitors
and your offerings. If your game is
hugely successful, you should consider whether
you are losing traffic to other websites, which
may be ripping off your game and leveraging your product's
name on search engines. And if you do build a web
version of your existing native game, it doesn't have
to be the full experience. It can just be a
taste of the gameplay. And then up-sell the
user to your native app for stronger monetization. So you can think of it as like
a teaser trailer for your game. And on that topic,
if you weren't aware, playable ads are
a growing source of advertising that,
as an ad buyer, you might want to
support, as well. So these playable
ad networks need to be cross-platform
on Android and iOS. And so they actually leverage
HTML5 as a portable content format. And these ad units are known
to have higher conversion rates compared to other ad
formats when you acquire users. And they increase the
day seven retention of the users you acquire
versus other formats. So what I'm saying here is
that, if you're already building a playable ad and
it's an HTML5 game, then why don't you
leverage that advert, and also place in
on the open web, and direct users to your
native game from the open web? Another interesting element
that's appeared recently is Trusted Web Activities. So this is sort of
like the best way to deploy a website as an
Android app on Google Play. It's similar to Cordoba,
but it doesn't package the resources inside the APK. They're fetched
from your server. And Trusted Web Activities--
one of the cool features is that it shares
cookies, and local data, and IndexedDB, or
anything you can think of between the
native and the web versions of your app or your game. And so, with Google
Play, you can actually pull off Google Play
billing transactions via Android Intents. The only downside is that, when
you come back to the web app after the transaction, it
refreshes the web page. And technically, a
Trusted Web Activity is slightly faster than web
view, as it avoids some Android rendering overheads, as well. So just with these
last few minutes, I'd like to talk about
some of my thoughts on the future of the
web games ecosystem. Because it's not just web games
that are powered with HTML5 nowadays. There are a growing
number of ecosystems which leverage HTML5
as a portable content format for games. Typically, these ecosystems
live in messaging platforms or other walled gardens. So I think it's
really interesting. And I think we
should look at what ideas we can borrow
from these ecosystems. Maybe we could define a portable
content format specification for HTML5 similar to Flash. Maybe we could use
the new web packaging standard that's in development
to distribute these games, as well. And maybe we could have
more consistent monetization options, as well, to
increase the users' trusts. Additionally, we could
have new metadata formats for discoverability. Like, you declare the
genre of your game, or you could declare what inputs
are necessary for your game to be played. So I think, as an
industry and a community, there's a lot that we can do
to reignite the web game's ecosystem. So if you're a game developer,
an engine developer, an ad network, or a digital
payments platform, please reach out to me. I want to learn more about
what you think the web game's ecosystem needs to
succeed and what Chrome and Google can do
to enable and stimulate this ecosystem. I hope you found
this talk interesting and that I've challenged some of
your assumptions about the web. We have a few demos in
the Web Game Sandbox. So please come by,
and say hi tomorrow. Thanks very much. [MUSIC PLAYING]
