Building Better Mobile Gaming Experiences With Firebase (GDC ’19)

Building Better Mobile Gaming Experiences With Firebase (GDC ’19)


[APPLAUSE] CHEN LIENG: Hello everyone. How’s it going? I hope you all had a great
GDC experiences today. And welcome to Firebase where
we talk about mobile gaming experiences and how we can
make it better for you. Hi, I’m Chen. I’m the iOS tech lead– sorry. I think I don’t have the click. There you go. Hi, I’m Chen. I’m the iOS tech lead for
Firebase Cloud Messaging. I’m here today with two of
my Google colleague, Patrick and Sumit. PATRICK MARTIN: So yeah,
my name’s Patrick Martin. I’m a developer advocate based
out of Boulder, Colorado. I actually have a degree
in game development. And I’ve spent the last decade
or so building mobile games and ultrarobotic toys. SUMIT CHANDEL: And
I’m Sumit Chandel. I’ve spent a number of years
at Google Developer advocating a lot of different products,
including Google Web Toolkit, AdWords API, Android
Wear, and most recently, Firebase. So we’re pretty excited
about sharing with you how Firebase can help within
your game development. And with that, I’ll
throw it back to Chen. CHEN LIENG: Awesome. Thank you, guys. So there’s three
parts of the talk. First, we’re going to give
an overview about Firebase along with some of
the latest updates. And then I’m going to
invite Patrick back on stage to show you how to
view the game with Firebase and Cloud services. Patrick’s going to cover some
of the new features coming up this year. So it’s going to be a
great technical overview. And then we’re going to bring
Sumit back on stage to show you how to grow your users. Driving player engagement is a
critical part of the business. So stay tuned for that. So what is Firebase? On a higher level,
Firebase is Google Cloud’s specialized mobile and web
app development platform. Let me give you a little
bit of background. If you come here to any of
the Google Cloud talk today, you probably already know
that the Google Cloud is a powerful tool. It is built on cutting-edge
technologies in both hardware and software infrastructure. It is also platform agnostic
because no matter what platform your games are
at, GCP can support it. It can be your
backbone because you remove the burden of
provisioning and managing your own server. And it provides a variety of
tools to help you to scale. So tools like App Engine, Cloud
Storage, BigQuery, TensorFlow and many, many other tools. It’s very powerful. And it provides a reliable
and secure connection so you can safely deploy
your code to the cloud. So what is Firebase? Firebase is built
on top of the GCP. And it is specialized in
mobile and web applications. So if you’re building a
mobile game or web app, Firebase is more tailored
to your experiences because we focus on many of the
common problems, engineering problems that mobile
developers facing. And also we provide custom
APIs so your app can easily communicate with the GCP,
the Google Cloud Platform. So in a way that would
provide quicker path to get you started on GCP. So here’s a subset of
the Firebase products that we are going talk
to you about today. As you can see, Firebase
deliver solutions throughout the entire lifecycle,
from building a game, improve the quality, to
engage more users, and driving player retention. And no matter what
you team size is, it could be one person startup
or enterprise-level companies, we have tools that can
support any use cases. And our products also focus on
many aspects of the business. If you’re engineer– engineer
like to focus on problem like, how do I do this
more efficiently? Or how do I scale? So we have tools like that. So, for example, if you’re
sending push notifications, we have Cloud Messaging. And then if you want
to do [INAUDIBLE] flow, we have authentication. Or if you wonder, how do I build
a serverless infrastructure, we have GCP tools like
Cloud Storage and Firestore. And these are the
critical components of building a game app. And that’s why the
engineers was focused on. And Firebase provide
tools so that you can– help you to save– and save the cost. And it also help you
to build infrastructure so you don’t have to do that. If you’re a product
manager, you wonder, how does my game perform? You want to understand
your users better. So we have tools
like that as well, like Analytics, A/B
testing, or BigQuery. A lot of our products can
export BigQuery easily so you can do deep
analysis on GCP. And you can also run experiments
to understand your users better while making the
product decisions. And lastly, if you
have QA team, we’ve got great tools there to cover
like any aspects of improving your apps quality, like
Crashlytics, Performance, and Test Lab. Later in the session,
Sumit and Patrick will do a deep dive on
some of the use case to show how exactly
you can do this. And what’s best about
Firebase and GCP is that they work well together. Under the hood, they have the
same project and same billing account. So it’s very easy
for you to manage. And if you’re a
Cloud customer, you can import your project
to Firebase instantly. And many of our
Firebase products are already running on GCP, such
as Cloud Storage, Firestore, and Cloud Functions, so
anything with a cloud. So say you’re a first-time user. What do you get outside
this Firebase package? Let me help you to viralize it. So first you get
Firebase console. It serves as a
developer control panel. It’s where you set
up a new project. And you can configure and
monitor your Firebase services. And then you get a bunch of SDK. You pick and choose
the one you need. You install in your game. And you run a bunch of code to
quickly enable functionalities. And the client will
make secure connections to the Firebase service on
the Cloud and to this console. So it will all sync up together. And the best part is
you don’t have to build any of the infrastructure. And it is secure. It’s scalable. Oh, and one more thing. Firebase, the console
is also great tool for your game designers
or marketing people if they want like monitor
data or added game contents. And we’ll provide
a variety of SDKs. For Android developers
here, the game developer, we have SuperPass and
Unity cross-platform SDKs. And if you are iOS and
Android developer like me, we have that as well. And lastly, our web SDKs
supports both mobile and web applications. Firebase was
launched since 2016. And over three years, we’ve
seen tremendous growth. To this day, we have over 1.5
million monthly active apps. And developers choosing
us because, A, Firebase is easy to use, it’s powered
by Google Cloud technology, and integrates well with many
cross-platform and third-party tools. Now I have some new
updates for you. If you’re a Unity developer,
now the onboarding flow has become easier for you. Previously, when you set up a
Unity cross-platform project, you had to set it up twice. You had to go to
the iOS platform, set it up, and do
it again on Android. Now we get this
shiny Unity button. If you click on it,
now it can set up both your iOS and Android
app at the same time and download the
configuration files and import to your project and finish
with downloading the Unity SDK. Again, it’s quick and easy. Lastly, I want to talk
a bit about open source. At Firebase, we really value
the transparency of our SDK. We understand that it is
important for the developers to know the exact behavior
of our source code, especially when it comes to
how we handle the user privacy and data, which is why we’re
excited that our C++ SDK is also open source now. Now if you’re a C++ developer,
you can choose to integrate one of our open-source SDK. With the source
code accessible, it provides great flexibility
in your development flow. First, you can audit
your source code and make modifications
at your own pace. And the Firebase
open-source community has continued to
grow over the years. And more and more SDKs
from different platform had been open source. And now you can help contribute
back to the community. You can be part of it. First, you can help port the
SDK to a different platform that we don’t support. Or you can help
making contribution to the existing SDK by adding
new features or fixing issues. Now I’m sure you all
got excited about using Firebase in your games. I’m going to pass that to
Patrick to talk about it. [APPLAUSE] PATRICK MARTIN: Hi, everybody. Thanks, Chen, for
that introduction. And what I want
to talk to you now is how to build– what it’s like
to build a game in Firebase. And I think what
will make this easier for everyone to understand
is if I first gave you guys a little bit of background
from where I’m coming from. So for the past
couple of years, I’ve been doing a lot of research
and development and prototyping. And it was the
kind of thing where I’d have a few
days, maybe a week, to throw a whole bunch
of stuff together, get a concept off the ground,
and get it testable. And I didn’t need that test
to live past the meeting where it got approved or something. So I used a very different
stack than I did back when I worked on asynchronous
multiplayer games. If you ever work on
something like that, you need your servers to be
accessible all the time, 24/7, and for any play length. And the tools to achieve
each one of these are typically completely
different sets. You’ll normally rip everything
up from your prototyping and do something brand
new in production. And I would say
that, yes, there go! The job of every developer,
every game developer, is really to find the fun. Whether you’re in preproduction,
post-production, or working on a game, your users
aren’t paying you for just pretty
graphics or cool tech. It’s something fun
that they can enjoy. And Firebase, I think,
helps shorten the distance from any idea you have in your
head to being able to actually experiment and iterate on it. And not only is this then backed
by Google’s Cloud Platform, as Chen mentioned, but
if for whatever reason Firebase doesn’t meet your
needs once you scale up from prototyping
to production, you do have the full brute force
of Google’s Cloud behind you. And you can work
directly there if that’s where your needs take you. So I want to show you what it’s
like building a game really quickly using actually a
single player game called MechaHamster, which is our– it’s our testing project for
Firebase’s Unity integration. So MechaHamster
is really simple. It’s like one of those old,
wooden marble maze games. You just tilt your phone
and get Hammy the hamster to the end of this maze up here. Yeah. Pretty simple. I’m sure you guys all get it. And what I’m going to do is
enhance this single player game by giving it a Cloud
backend with secure and shared data in
it that I probably wouldn’t want to risk otherwise
if I didn’t have something like Firebase to host it on. So the way we decided to
start expanding this game was to build our
own level editor. The basic idea behind it
is that normally a designer would have to go through
the entire dev stack to get a build onto
a phone to test it, which could sometimes
take minutes. And then other people
wouldn’t necessarily get to play unless you
walked over to their desk or you pulled it down
from a build server. So we really wanted
to build something that it could work on the phone,
press play, test it instantly, and just share it
out to the whole team really quickly, like at
the press of a button. And since these levels
are just like a 2D grid, it’s a very easy thing
to serialize, store, and interact with. So we decided to use
Firebase’s real-time database. This represents all of
the data in your database. It is effectively, a
very large JSON document, which I know some people love
JSON, some people hate it. The point isn’t that
you’re writing JSON but that many languages and
game engines, like Unity, can serialize to and from it
just as a library function. So we just hit a node
with the JSON serializer, get all the data
out into a database. And I want to focus
on the real-time bit just a little bit. This isn’t real-time
like 30 frames a second, like a video game. But this is real-time enough
that you could do something like Google Docs,
collaborative editing. I find that sometimes I can
even type on one computer and look at another
and kind of know what I’m doing in a Google Doc. You could do the same
sort of synchronization in a level editor if you
built out the UI for it. But the other really cool
thing a real-time database does for you is cache everything. So if you’re offline, if you’d
like drove through a tunnel while you’re working
on a level, all your writes are still
instant to the database. So you can use the database
provided in our SDK. It’s kind of your
single source of truth. And then whenever
you go back online, your local copy doesn’t
get stomped with the web. And the web copy doesn’t get
stomped with your local copy. We just replay the transactions
you made while you’re offline, which is kind of a nice way
to protect against data loss as you’re doing
these migrations. It’s kind of a hard
problem if you’ve ever had to implement this on your own. And a cool thing that
came out of all this work to build a level editor is a– well, we’re all game
developers, right? We’re at the Game
Developer Conference. And I’m sure we all had
that moment when we realized that games are not
magical plastic disks that appeared in like a game store
or, in my case, cartridges. For me, the moment
that I realized this was when I found the
Quake 1 level editor. And I started making,
actually, really bad maps where only I knew
the cool weapon drops or like sniping positions or something. So why couldn’t we enable
fans of MechaHamster to express their
creativity like that and maybe join us in
the creative process? And even though we’re storing
this data in the Cloud, we’re able to confidently
enable this kind of curated user sharing with this
rules language that we have with Realtime Database. This is just a JSON object
with annotations that lay parallel to your database. And they’re relatively simple. I I’ve actually
simplified this a bit more just so it
fits on the slide. But here we just saying
the node map list is readable by the
entire internet. But by changing this to the
string off not equals to null, we guarantee that any user
trying to read this map list will only get it if
they are logged in. And these statements
you put here can be JavaScript expressions. So you can enforce rules like,
only the creator of a map can use it until they market
it as shared, stuff like that. And where that auth
came from is actually from Firebase authentication. In MechaHamster, we opted to
use email address and password account management
as well as something called anonymous sign on. Anonymous sign on in
particular might sound weird. But all it’s doing is
associating your device with the account instead of
like a username and password. And later on, if the user
wants to share their data between devices,
they can migrate up to an email address account. And you can, of course, opt out
of signing in if you just don’t want these online features. And I should stress that
this email address password authentication isn’t me
being silly and thinking I can implement my own sign
in logic with all the security issues associated with this. This is a Firebase product and
has all of Google’s security guarantees. But we also support all these
other authentication providers. Now if you’re prototyping,
and you’re just trying to get an idea of the
ground as fast as you can, use email address and password. But all you have to do is
integrate the client SDKs for each one of
these auth providers. We do everything else
in the cloud for you, validating the user token. We even let you merge
and migrate accounts. So GameCenter on iOS
is a new integration. If you added it to your app,
you could allow your users to add that to their account. And all of a sudden,
they have a new way of signing on that doesn’t
require them to start again from scratch. So another thing we wanted
to do is add leaderboards to MechaHamster. This is super-common in games. And it’s so common that we
just made it open-source. So it can go up here,
grab the source code for a sample
leaderboard integration, actually start playing with
the Realtime Database right now in your existing game
writing just a minimal amount of code, get your feet
wet, decide whether or not it’s right for you. So that’s at Firebase Extended
slash Unity solutions. So we wanted to augment
our leaderboard though with user replays. Now for reasons that might
become apparent later in my talk, we had replay
recording in MechaHamster. So we decided we’d
show how people got– oh, there we go. Yeah. We wanted to show how people got
the high scores that they had. And you might just
think, hey, I’m going to use JSON
serializer and Unity and just dump whatever
data structure I have for the replays
into the Realtime Database. But it turns out even
compressed in a flat buffer, these replays are around
30 to 60 kilobytes. And at some point, the
RealTime is not real time just because you’re
passing a lot of data. And also you don’t want to
collaboratively edit replays. To me, that sounds more like
cheating than a feature. So we needed somewhere
large [INAUDIBLE] to store this replay data. And we decided to use
Cloud Storage for Firebase. Now this is another database. It’s a key value storage where
the key is just any path. So logically order
this however you want. And the value is
really anything you want to put up
there, videos, player avatars, in our case, replays. And the flow for
uploading a high score now becomes you add the high
score to the high score table. There’s an extra node there
for– the replay will live. You start asynchronously
uploading the replay data, get a callback when
that completes, and you can just update
the note in the leaderboard to point to your replay. There is one problem
with this, though. Now that we have
two databases, when a high score is no
longer a high score, the replay data will leak. So we use something called
Cloud Functions to listen for when there’s a change,
in this case, a Create event in the Realtime Database. When that happens, we check
how many high scores there are for the map you’re
on, knock off the lowest if there are more than five, and
cleanup the associated replay data. So Cloud Functions are
actually a really awesome tool for someone like me who’s lived
mostly in the client space. They’re just now out
of beta for Firebase. And they let you run
mobile back end code without managing the servers. Again, if I’m prototyping,
this is an awesome shortcut to get to where we need to be. And it is still on Google’s
Cloud infrastructure. So these are reliable
and scalable. You write these in
JavaScript or TypeScript. And you have the full MPM
package manager to deal with. So you can really go crazy here. They are still secure, so
Firebase authentication still applies. Auth not equals to
null is a valid way to check if a user’s log in. And the user is guaranteed
to not be spoofing their user token or something by now. And these let you
not only communicate between different
Firebase products but also between
Firebase and the web. So just some examples of
what you might use these for in games, if you have like
asynchronous multiplayer board games, rather than just
trusting players to not claim that they roll
nat 20s all the time, they’re the Gandalf of
monopoly or something, you can push your die rolls
off into a Cloud Function. If you have a gacha
mechanic in your game, you can use the Cloud
Function to make sure they have enough
capsules or whatever, subtract one, roll the loop. But if you’re using something
like Crashlytics from Firebase, you can actually listen for a
new crash to happen in the wild and actually automatically
file a Jira for your team. Maybe if a crash
spikes an occurrence, you send a message to the SOS
channel on your team’s Slack, and everyone starts
rallying around it. So now it’s time to ship a game. And the thing that keeps me up
at night, whenever I hit go, is when the inevitable
review comes in that says, game is a
blank screen on launch or it crashes on launch. It worked in all our
devices in the QA test lab. But there’s just something
in the wild we kind of take account of. So you really need to run
your game on actual hardware. You need to test various OS
and hardware combinations because even if you’re using
test-driven development, something like you’re using
a feature in a shader that’s not supported will still cause
a shader compilation error. Actually once had a game
as blank screen on launch because the OpenGL context
claimed that it supported a level of antialiasing
that it actually didn’t. And it just failed to
create my context for me. And you really want
these to be automatic, like not just a
human going through. You want to be able to
shove these up to a server where some cadence built into
like your build pipeline and be able to know the very
moment a build fails. So for MechaHamster,
we’re using Robo tests in Firebase Test Lab. Now MechaHamster didn’t
have many unit tests. And at least, in my
experience in the industry, that is really common
in video games. But with Robo tests, we can
just upload the production APK and– well, the way
I like to imagine it is a friendly
little robot walks into your game, kind of
stares at your view hierarchy, and then presses all the
buttons as fast as it possibly can until it crashes
or it times out. And this will run
on real hardware. There’s literally like
racks of phones or something in a data center somewhere. And what’s really
cool about this, especially for the
kind of test it does, it might be hard
for me to reproduce. I might C&R the bug
just because like it required tapping in a specific
spot in the splash screen or something. So it records the
video, shows you little circles of where
this robot was interacting. You get the stack
trace if it crashed. You get the log of everything
that happened leading up to it. And you know that this ran on
kind of a clean environment. There’s not like
that weird app that kills applications in the
background to theoretically save battery life or something. This is just a stock device
that you’re running this on. But some engineers
in the room might have noticed that I said this
robot walks around and looks at your view hierarchy. And we’re game developers. Our view hierarchy is
probably just a GL Context. So this seems kind of useless. So, of course, we decided
to use our AI Chops to create something that we
call AI assisted monkey testing. This uses machine vision to
look at the output of your game like a human, find things that
look interactable, usually buttons, and concentrate the
random presses at these buttons so you don’t have to expose
your custom UI to Robo test or, in this case, AI
system monkey testing to get a useful test. As you see here the AI
assisted monkey testing video is already to the logical
end of this unit test, whereas the Robo test
is still clicking around in some corner of
the screen somewhere. If anything else, this is just a
safety net for your existing QA team. You don’t have to do any
additional integration or APK. This is running
on actual hardware in a data center,
as I pointed out, or on virtual devices if you
want to test like weird OS or screen combinations. And, yeah! It’s pretty cool. Had another bullet
point, but, yeah. I already went over it. So there’s another
kind of unit testing though that we usually call it
like demo loops or a profiling test. In Firebase Test Lab,
we call it game loops. And the general idea
of this is that you know what parts of the
game you need to hammer, how to implode all
the shaders, get a bunch of geometry on screen. And not only do you want to
see if phones will run it without crashing,
but you might also want to profile this and make
sure you’re hitting your min frame rate targets
on all your devices and kind of build up a list of
which devices you need a lower performance profile
on or something. So once again, you upload your
production APK to the cloud, run it on real devices that
span the range of low end to like flagship phones. And the way this works in a
production environment is it sends something called
an intent, which, if you’re not familiar
with native Android Dev, you’re just coming from
the Unity background, this is basically a command line
argument but to an Android app. And I’ve spent a lot
of time in Unity. I wasn’t quite sure
how I’d get this in. So when I looked
at MechaHamster, I found this Game
Loop manager class. I’m not sure where it came from. It’s actually from
this code lab. It’s very easy to follow. If you already profile
or use demo loops, I’d recommend–
walk through this. And you just instantly
grow your QA test pool for this sort of thing. Again, even if you
don’t want to do this, if you want to put the
minimum amount of effort possible into testing– I’m not saying that’s a
bad thing, but sometimes it’s the reality– just upload your APK now. And you just gave your QA an
extra little bit of safety net as they go through the
normal approval process. So you’re still going to
have crashes in the field. You can’t catch everything. Again, there’s like
that crazy app that kills games in the background
and people root their phones and all this other stuff. You’re still going to
need crash reporting. And Crashlytics is kind
of a really neat way to gather crashes from
the field and sort them by frequency, device type,
OS version, everything you need to– stack traces as
well– everything you need to not
only figure out why a crash happened but see if it’s
something you need to address. Because the reality is
that some phones will just have a marginal market share. And if he cannot reliably fix
the crash in a short amount of time, if this phone is
a fraction of a percent of your market, it may be more
fiscally pertinent to just blacklist it on the Play store. But if when the brand new
flagship phone comes out, and your game is crashing
all the time on it– this actually happened to
me when the first multicore phones came out– if you have that Cloud
Functions hook running, you might get a spike
in the SOS channel, this bug is happening
a whole lot. And you can rally
your team around, make sure you get
that preorder in, and start testing on the new
phone if that happens to you. And Crashlytics is now
integrated with Unity, which is really awesome to me. Again, in the past, what would
happen is I’d get like the C++ stack trays, and I’d have to
bring that into the IL2CPP output, and then try to figure
out what C# generated that, which was kind of a process. There are helpful guides for it. But it took me a
little bit of time. In this case, I
accidentally cleared a field in a game object. And I got a stack trace. And Crashlytics,
almost instantly, I was refreshing
the dashboard that showed me exactly where
to look to find this. And in this case,
this isn’t even a bug I would have made
it as a programmer. Or I could have made
it as a programmer, but also a designer or an
artist might have made this. Or it could have just
happened from version control. So Crashlytics, is pretty
much a free integration if you’re already
using Firebase. So you might as well
just drop it in, again, for a little bit
of extra safety net just to bump the quality of
your app up a little higher. With that, I’m going to
hand this over to Sumit to talk to you about growth. [APPLAUSE] SUMIT CHANDEL: All right, y’all. So we built the game. We shipped the game. And now it’s time
to grow the game. Now when you grow
your game, there’s the traditional marketing
methods and teams that your company
or startup might be using where
they run a campaign and try to grow your
player or user base. And there’s a lot of different
tools and innovations available to those teams there. And that’s probably something
you want to continue to use. That, however, is
different than what I wanted to talk about
here in the context of Firebase developer
services and Google Cloud. So within the developer context,
what you want to be able to do is easily A/B test new features. So you’ve shipped your game. You know where you’re at now. And you want to figure out
as you release new features, are they good or bad? How are they going
to be received? And certainly, you
don’t want to damage what you’ve already released. So you want to be able to easily
A/B test and then furthermore, measure the results
of those A/B tests as well to determine
their effectiveness. Personally, I’m
still A/B testing whether Gregory’s
Coffee, Starbucks Coffee, or Third Rail Coffee makes me
more productive in the morning. Results so far, inconclusive. All right. So I’ll set the stage with this
question or this opening use case of, how can I track
how my game is doing now? And how can it easily
test new features and see if those are good? So we’ll look at the first
part of this question first, which is, how can I track
how my game is doing now? OK, so to track how
your game is doing, you’ve got to look at data. And depending on the type
of game that you have and the number of
players, we could be talking about a lot of data. So take, for example,
a massively multiplayer online RBG game
where you’re not just logging single events of
users tapping on your screen or interacting with your game as
single events that are getting recorded, but you’re
collecting a stream of events over a long interval of
time, maybe a few hours. In that kind of game, a
player might be interacting with other players in the game. And you’re logging that. They might be buying,
selling, or trading items. And you’re logging those. They might be completing quests
or accepting new missions or taking a certain
direction on your map. And these are all events
that you’re collecting over hours for one player. Now imagine if you’ve
got thousands or millions of players. That’s a lot of data
that you’re collecting. So hence, the image
of this data center to represent a
whole lot of data, for example, on one of Google
services that relies on this. So that’s where Google
Cloud BigQuery can come in. So if you’re a
large game publisher and you’ve already collected
a lot of player data, Google Cloud BigQuery has
a free bulk loading tool where you can upload all
of that data into BigQuery and then start
slicing and dicing it using SQL-like queries with the
computational power behind them to actually return the results. So you can start establishing
a view of what your players are doing in your game. A couple of quick things
to note about BigQuery is that, one, it’s
fully managed and server and, second, storage and compute
are independent from each other and can scale up or
scale down and on demand. So that kind of flexibility can
save a lot of business costs from your side because you
don’t have to invest upfront in building your own
infrastructure for logging or storage pipelines to
manage all this data. And, of course, storing
that amount of data is already a pain let
alone analyzing it to figure out what’s going on. But maybe you’re
not ready to invest a lot of logging
infrastructure in the game as you just released it. Maybe you just want
to release your game and start getting
some kind of analytics without having to invest in
that logging or storage pipeline infrastructure. So for such a situation,
you can use something like Google Analytics
for Firebase. The way it works is pretty much
as soon as you add the Firebase SDK to your project,
you’re going to start getting out of the box
events automatically reported. And when you log into
your Firebase console, you’re going to see these
reports automatically being generated for your game. So that includes things like
in-app purchase revenue, user engagement, retention, daily
active users, and so forth. But more importantly,
Analytics also allows you to use custom events
that you can log in your game as well. So those are things that are
more specific and interesting for your game. For MechaHamster, this
might be things like, did anyone use the map editor? Did someone create a map? How many times did they retry
a level before they gave up? Did they even manage
to finish the level? Which levels did they select? These kind of things
are custom events that you might want to
record or that we’d want to record for MechaHamster. And you can also choose
that for your own games and have it available in
the Analytics dashboard. And then while we’re talking
about creating these custom events, you’ll want to mark some
of these as conversion events as well. And you can do so in
the Firebase console by hitting those toggles– one second, I’m trying to
click the thing, OK, sorry– by hitting those toggles to
mark whatever events that you’re recording as conversion events. So those conversion
events are things that are especially
important for your app and what you want to
direct your users to do. So these could be things like,
did they create an account? Did they invite your friend
to the game or their friend to the game? Did they give premium
currency to their games or give something to their
friends for the game, those kind of things. Sorry. I need go back to one slide. And the other advantage
with marking these things as conversion events, these
important things for your game, is that Firebase
can use that to feed that back to any ad campaigns
you have to attract more users. And it’ll tailor the
audiences that it goes after there based
on the conversion data that you care about. So with Google, with
Google Cloud BigQuery, and with Firebase
Analytics, you’re starting to get a picture. You’re starting to be able to
paint a picture, basically, of what is going on in your
game and what your players are doing. So we answered the first
part of this question of, how can I track how
my game is doing now? And once you know that, you want
to look at the second part of, now how can I easily
test new features and see if those are good? So typically, when you want
to test a new set of features, you might have an
alpha or beta channel where you’ll release
that new set of features and expose it to a test group. And that’s well and good but can
often have a lot of overhead. For one, you have to match the
cadence of your team’s release cycle to get your build
available for each of these channels. And then, of course, you
need different build variants that you deploy to
alpha or beta, which can start becoming a bit of a pain. Furthermore, if you’re
releasing a new feature and you want to easily get
feedback on it, if you’re just releasing it to
alpha or beta users, you might not be
getting a large amount of data versus
your whole audience or at least a larger
percentage of your audience where you’re
getting the feedback behind that new feature and
being able to determine– and validate that it’s working. And then here’s
another use case. What if you want to just
release a temporary, seasonal, or promotional new
feature in your game? So in the case of
MechaHamster, let’s say we want to change the
color of the hamster ball to white and red
just for Canada Day when it’s Canada
Day in that user’s device in the date/time
of that user’s device and for Canadian users. Oh, sorry, I have
here one slide back. So including that
one change, one seasonal change or temporary
change into your build can complicate that build
because you’ve already got a few things planned. And if you’re using
this one new feature, it can add some delay to that. In addition to that, if
there’s other higher priority issues that come up for
your team’s current build, this might get dropped. There might be other things
that they have to focus on. And this is not really
something they can do. And then you risk
losing it entirely. So for both of those
use cases, when you want to release
new features and easily test them as well as for
seasonal changes you want to introduce in
your game, there’s Firebase Remote Config
that we want to introduce. So if you haven’t
heard of this before, you can think of it
as a key value pair that– a key value store
that lives in the Cloud. And it allows you
to control the look and feel of your game or
the behavior of your game remotely without
having to rebuild different versions of
your app and deploy it to all the different
channels and app stores. So this is the way it works. Going back to our example for
the Canada Day hamster ball, here’s some default values
for what the hamster ball looks like now. So we’ve got ball_color,
ball_glow, and ball_size as Remote Config parameters we
defined with these defaults. So whenever the user starts up
the phone for the first time, these are normally the
values that they’ll see for their ball. Next, we introduce
some new values for the ball, ball
color being white and the ball glow being red. And we can condition those
or gate them on specific– any kind of conditions. In this case, it
would be that it is Canada Day on
the user’s phone on their date/time
on their device and that they’re
located in Canada. For those users, we want
to push these values. These will then be
waiting in the Cloud, ready to replace the values
that we’ve set as the default. And then when the condition
hits and everything is true, it’ll combine those
values, pulling the delta, and then change the look of the
ball for those Canadian users. Another cool thing about
the way Remote Config works is that it only downloads
the delta, or the difference, the diff of the values for
the Remote Config variables and not the whole
set every time. So you’re not going to eat
up a lot of your user’s data by using Remote Config. Now you might be
thinking, wait a minute. Isn’t this kind of like
feature rollout flagging? And yeah, it is. That’s kind of the
idea behind it. So it allows you to easily
control feature rollouts for your game without having
to redeploy different builds and enable and disable that
via the Firebase console. One thing I should
mention actually in the previous slide–
can I go two slides back? Sorry. So those new values
that you set, you’d actually set those in
the Firebase console directly. So you can do it through
the Firebase console. Or you can do it
via the REST API. So that’s how you
can set and condition the new values you
want to set on. OK. So we saw a little
bit of how to use Remote Config for this
new seasonal feature that we want to
release for Canada Day. But how about like for
more general use cases? There’s some other times where
Remote Config can be helpful. And more importantly, when
you’re testing or releasing these new features, you want to
get the feedback behind them. So let’s take a look at that. OK. So taking a look back
at the custom events that I created for Google
Analytics for Firebase for MechaHamster, if
you look at the ones on the right-hand
side, I’m collecting retries, whether the
user finished the level, and what levels
they’ve selected. Well, you could imagine that,
let’s say a user who just started playing this game, they
have a large number of retries for a given level or they never
did manage to complete one or they’ve only selected a
certain group of levels that are fairly easy to complete. You can imagine that those
are beginners to my game. Well, one cool thing about the
way Remote Config and Analytics works is that it allows you
to create different audiences based on these custom
events you can filter or out of the box events as
well in Analytics. In this case, for
MechaHamster, I’m creating a beginners audience. And I want to target Remote
Config variables only to that audience. I’m defining that
as any players who have a number of retries
recorded as greater than 5 and who haven’t
completed a level. So I’ve identified
this beginner audience. And for them, I’m going to
change the values of my Remote Config parameters
and set the ball size to big and the gravity
to 0.5 to make the game easier for them to play. OK. So that’s cool, right? I can easily release new things. But what about different
variants that I want to try? So for example, for
my beginner audience, that new ball size
and gravity that I set might make the game way too
easy for them and quite boring. For cases where I want to
test multiple variations or combinations of these
to see which one works best for my beginner
audience, there’s Firebase A/B Testing
as well that works in combination
with Remote Config and Analytics for that purpose. And here are the steps for
setting up A/B Testing. So the first thing is
you define your target. Whether that’s 5% of
your total audience or whether that’s all your
users who speak Korean, you can set that up
however you like. For MechaHamster, that’s going
to be the beginners audience that I defined earlier. Step two is you
create your variance. So again, for MechaHamster, that
would be different combinations of ball size and
gravity, so just to see which combination works
best for this beginner group. Step three is to determine
the goal for your A/B test. So these can be out
of the box goals that come from Analytics, things
like daily user engagement and that kind of thing. It can also be custom
events that you care about. So what is the goal? What are the things
that you want to measure with these
different variants to see if your experiment
is successful or not? For MechaHamster,
that would probably be that I want my daily
user engagement to increase, I want the number of retries
to go down so that they’re having an easier time. And I might add secondary goals. For example, user retention
is a secondary goal that I’d add here because I want
to make sure I’m not negatively affecting the
retention of my game among other beginners in
that group who might find all those variants
boring and might stop playing the game entirely. So you can choose what goals you
want for your A/B test as well and set those here. And then the last step is
just to kind of wait and relax and let the experiments
run for a couple of weeks and start generating some
data that you can look at. By the end of that, you’ll
be able to determine if there’s one group that
performed extremely well and then roll that
out as the new control more broadly among your
beginner audience or whatever other audience you define. So thus far, we’re using Remote
Config to release new features. We’re using A/B testing
to test different variants and figure out
which one works best and then roll that
out more broadly. But this up to now has all
been reactive things we’ve been doing for our players. We’ve been seeing how
they behave so far and then basically adding
new features based on what we’ve seen at that point. Wouldn’t it be cool
if we could anticipate what they’re going
to do and, in fact, if we could predict
the future and predict how our users can behave
instead of reacting to it? So if only there was someone
who could tell us our futures. Well, there is. And that’s Firebase
Predictions, another product available in Firebase. So Firebase can
harness the power of machine learning
to create groups of users who are predicted to
exhibit some kind of behavior in your app. The general idea is that as your
players are playing your game, Google Analytics is collecting a
bunch of data and storing that. And then Predictions
can take a look at that data to see if
there’s any patterns that exist for things that these
players have done before they took some other desired action. So let’s say, for example,
that desired action is a player who spent
money in your game or made an in-app purchase. What Predictions will
do is go ahead and look at users who have
already made purchases and look at the past data. Then it will use a neural
network powered by TensorFlow to see if there are any patterns
that these users have exhibited before they made that purchase. Once it does that,
it will start making groups of users categorized
as likely spenders or unlikely spenders. And once those groups have
been identified by Predictions, you can use those groups in
other features in Firebase. And you can target
those predicted users who are predicted
to spend in your game. So whether that’s in Remote
Config or in A/B tests, you can now choose that
group and specifically target different changes that
you want to roll out to just them. So let’s look at a few examples
of different developers who have done this. Nope, we’re going to look
at that later [LAUGHS].. Can I go back one? Can I go back one slide? All right. So how do you enable
this magic of machine learning to your games? Do you have to go back
to school and take a neural network [INAUDIBLE]
programming class and graduate from that again? It might not hurt. But you don’t have
to do any of that. You can actually just press this
button in the Firebase console. So once you press this,
it turns Predictions on. And from that point, it’s
going to start collecting data. And within a few
weeks, you should have some Predictions data
that you can play with. Now out of the box, the
two different events that Predictions works
for is to determine spenders and
nonspenders and also users who might churn from
your app or continue using it. But in addition to those, you
can use other custom events that you care about
and use Predictions to figure out if those actions
are likely to happen as well. So those are those custom
events that I mentioned earlier that you would mark
as conversion events or things that are particularly
important for your game. So you can mark those. And then Predictions will start
training over that as well. OK. So here’s where I was getting
to earlier about examples of different game
publishers who have used some combinations
of these features to realize some
pretty good value. So in this case,
there’s Halfbrick. What they did is that
they use Predictions to determine churners,
people who are likely to stop playing their game. And in that group, they
targeted notifications that gifted them premium
currency in their game. And in doing so,
they saw a 20% boost in seven-day user retention. And it performed better
than a fixed reward system that they had earlier. There’s also Rockbite. So they used a combination of
predictions and Remote Config. And in their case, they use the
groups that check for spenders. And for those that were
determined to spend, they changed the store layout
to better match their patterns. And for those who are
determined to not spend, they had a different layout
through the Remote Config that they’d configured. And in doing so, they
increased their profitability and remain competitive
in an already competitive mobile gaming industry. OK. So at this point,
let’s say, you’ve used analytics to
collect insights into your data for
Google Cloud BigQuery and upload your data
to slice and dice it. You’re using Remote
Config, A/B Testing to test different variants. And this is all great. And let’s say, as a result of
this, you’ve got a lot of users and a lot of players. And that’s fantastic. That’s what you want. But now you’ve
got a lot of data. You’ve got a lot of
players and a lot of data that you’ve
accumulated across all of these different features. So remember the image
of that data center that I showed earlier when I
talked about a lot of features and then I very sneakily
introduced BigQuery? Well, here’s another example
where BigQuery can help. So Firebase and BigQuery
integrate really easily with each other. And you can export all
those different features that I just mentioned,
so Analytics data, Crashlytics data, as
well as Predictions data into BigQuery
where you can slice and dice it for other insights
that you want to gain. So this is really
useful because there’s some things to these dashboards
themselves might not do but that you could write your
own queries against to figure out all kinds of things. Here’s some examples. So for Analytics, if you
export your Analytics data into BigQuery, you can
analyze user retention trends for your game and identify
root causes behind them. For Crashlytics, you can segment
crashes by levels, libraries, or any other custom key that
you include in your crash logs. So whatever custom
key you put in there, once you’ve exported your
Crashlytics data into BigQuery, you can now use that–
if you’d like to see, OK, level 3 has an
issue, and level 3 is where most of these crashes
are happening– fairly easily. And then for Predictions,
one really straightforward use case and a very common one
is to identify your biggest spenders by city or by country
by running a query again in BigQuery once you’ve
exported your data. So this kind of wraps
up everything we wanted to share with you guys. We hope this helped you feel
excited about using Firebase for your games. We hope there’s at
least one or two use cases where you see that
you can use Firebase to help in your game development. And hopefully, you get
started and reach out to us when you have any questions. At the moment, I think we
still have some time for Q&A if there’s any live Q&A you
guys want to do in the room. Otherwise, we’ll be
just outside of here. I think they’re closing
down this room at 6:00. So we’ll be just
outside and hanging out if you have any
questions for us. But let’s first, I
guess, open the room and see if anyone
has any questions. You guys want to return
back on the stage? Any questions on using Firebase? Going once, going twice. No? PATRICK MARTIN: Awesome! We did our job. [LAUGHTER] CHEN LIENG: There’s one. AUDIENCE: I have [INAUDIBLE]. SUMIT CHANDEL: OK. Oh, I think there’s a
mic coming as well just so other folks can hear ya. AUDIENCE: Hi. Does the Unity plug-in natively
support Windows or just iOS and Android right now? SUMIT CHANDEL: I believe
that it’s just Android– Android and iOS, right? CHEN LIENG: Yeah. Right now, it’s just
iOS and Android. AUDIENCE: OK. So if I wanted to use Windows,
I’d have to use the Wrap the C++ SDK? PATRICK MARTIN: I believe the
C++ SDK right now is an early beta. And not all of the
features are spec’d out. It’s good enough for you
to use in the Unity editor or to test in desktop. But we’re still working on it. And it is open-source now. So if you go faster than
us, you can get there too. AUDIENCE: Thanks. SUMIT CHANDEL: All right. If there are questions you
guys want to ask us in private, we’ll be just outside. Also want to remind you guys
to scan your badges on the way out just to make sure you get
the evaluation forms to give us feedback on the talk. And with that, thank you,
again, for participating. Also if you want to download
MechaHamster and give it a try, you can download it from
the App Store Play Store. We also have all the code
hosted on GitHub there if you want to download that,
build it, and check it out. And to learn more about
how Firebase can help with your game’s development,
there is that URL right there, firebase.google.com/games. And we’ve got a booth. And we’re going to be
there most of the week. It’s in this building
at spot P1501. I think it’s in– yeah, South Hall is here. So we’ll be there
all that week if you want to come by and say hello. All right. Thank you very much. CHEN LIENG: Thank you. [APPLAUSE]

Leave a Reply

Your email address will not be published. Required fields are marked *