Develop Games with Firebase (Google I/O’19)
Articles,  Blog

Develop Games with Firebase (Google I/O’19)


[LOGO MUSIC] PATRICK MARTIN: Hi, everybody. Thank you for coming
out here this morning. I know this is the first
talk of the game session, so I hope you’re all
coffee’d up and ready to go. We’re going to talk to you about
developing games with Firebase. My name’s Patrick Martin,
and I am a developer advocate with Firebase for games. JUSTIN BROUGHTON: And
I’m Justin Broughton. I’m the engineering lead
for Firebase Test Lab. JON SKRIP: And I’m Jon Skrip. I am a software
engineer with Google, specifically, working on
the Firebase growth team. With that, we’ll let
Patrick take it away. PATRICK MARTIN: Well,
we have a brief map of where we’re
going to go today, on a kind of a fun adventure. I will talk about building
games with Firebase. JUSTIN BROUGHTON: And I’ll talk
about the exciting adventure of testing games with Firebase. JON SKRIP: And then I
will talk about growing your game with Firebase. And now we will let
Patrick take it away. PATRICK MARTIN: Yeah,
now you’re free to go. JUSTIN BROUGHTON: Let him go. PATRICK MARTIN: Just one more
brief piece of bookkeeping– we’re only going to skim the
surface of Firebase today. If what we talk about
sounds interesting to you, we’ll be right back
there with Mecha Hamster so you can ask questions. As well, there’s a
Firebase tent over there. So with that, let’s get to
building games with Firebase. So I want to give you all a
little bit of my background. I started about a decade ago
making mobile social games, and then I eventually got into
prototyping with actually, robot toys. And typically, I find that
the tool set for each of these is normally astoundingly
different, right? With a prototype, you
just care about getting to the next checkpoint–
getting approval to work on it more, whereas
long-standing shipped titles need to be accessible
from all over the world, at all times of day. And, you know, there are just
different considerations. But I think Firebase is really
good at bridging the gap. So, as game developers,
as I assume many of you are here today– as game developers, we
do not have the luxury of just looking at a
game design document, implementing everything
by the letter, and hoping we get a good
game out at the end. We’re always
questioning what we do, and always trying to make
sure that what we built is fun and interesting. And I think Firebase
helps because it shortens the distance from
that idea you have that you want to test
to the implementation and experimentation. It’ll tell you
whether or not it’s something you want to run with. And even though it gets a lot
of the back-end architecture stuff out of the way,
if for whatever reason you find that we’ve made
the wrong abstractions for your particular situation,
Firebase is a Google Cloud product, and at any
point, you can switch over to the Google Cloud
Dashboard and just pick up right from
where you left off and build out whatever you need. But I’m going to
focus today, actually on using Firebase and
trying to show how easy it is to work with by augmenting
the single-player game called Mecha Hamster. This is an open source project– again, we have it back
there in the garage– that we use as our testing
ground for every new feature we add to Firebase for Unity. It’s a very simple game. You tilt your phone to get
Hammy the hamster over here to the end of this maze– a
lot like those wooden marble mazes you probably
played with as a kid. Let’s see– so what
we’re going to do is add a level
editor to this game. There are a lot of
reasons to do it. One of them is so I
can talk to you guys up here about Realtime
Database, but also it will help improve the
developer experience. Let designers build a level,
then test it immediately just by clicking this Play button. Also, I’m based out of Colorado. A lot of my co-workers are
out in California, out here. So it’d be really awesome to
have this Share button so they can send a level to
me immediately and get my feedback without having
to wait for the build server to kick something out. So, of course, we use
Realtime Database. This is really neat to me, at
least, because it represents all of your data is a large
JSON document which Unity has built-in serializers
to and from, so there’s not much custom
code to write to support this. It’s synchronized in real time,
as its name probably implies. As game developers,
I should warn you, that this isn’t–
this is not real time, like a Quake 3 dedicated server. I’d recommend checking out
Agones for something like that. But if your experience
can be like Google Docs, with multiple people
working on one document, this is a perfect tool. Or it would be awesome for
asynchronous multiplayer games. It’s also cached. If you’ve worked on these
mobile, social, whatever sort of game, you probably
have experienced all the annoying corner
cases around “the user went into a tunnel and
did something,” right? So everything you do is cached
offline as transactions. You can query the
database immediately to see what your
current state is, and when you reconnect
to the internet, rather than just
replacing this data on the server with
your local copy, you replay the transactions
that got you there. That way if you’re storing
score, for instance, you don’t just replace a
potentially higher score with a lower one
you have on-device. You just add 10 points, or
whatever the Lambda function is you provide to the transaction. And there is something else. I am a front-end dev,
and I get super nervous when it comes to exposing
back-end stuff like this to my users. So it would be really awesome
if Firebase had some way to let me securely share this
information without a lot of the nervousness that comes
with writing custom server code. For that, we actually
have a verbose rules.json file that you can store
next to your database. This is a JSON document,
and right here– this is a small snippet– I’m saying that the map list–
so all the maps in the game are readable by anyone
with this database URL. But with a small change,
I can restrict it to only authenticated users. Now, you may realize at this
point it’s still not secure, but since this takes a
JavaScript-like syntax, you can do something like store
the UID of the creator of a map in that map node,
and verify it here. And you know it’s running
on a secure server in a way that an attacker would have a
really difficult time spoofing credentials. And this comes from something
called Firebase Authentication. In Mecha Hamster, we opted to
use email address and password as our authentication mechanism,
as well as something called anonymous auth, which I
know sounds a little weird, but all anonymous auth
is is a unique identifier associated with a combination
of game and device. So the same game
across multiple devices has different identifiers,
as does different games on the same device. But it’s a really nice way to
just give your users an easy single-click button to access
your online components, knowing later that they want
to migrate up to a better– a different auth method. So I mentioned that we use
email address and password. This is not me rolling
my own auth system, this is a product from Firebase. It just has credentials
unique to your game. But we also support all of
these other identity providers. And as I mentioned, they support
merging and migrating accounts. So Game Center, for instance,
is a new integration. If you have an existing Firebase
game on the market using authentication, you can just
integrate the Game Center client SDK, turn it on in
the Firebase Cloud console, and then prompt your users
to merge their account with the Game Center one. And now they have that one-click
experience that your iOS game players probably expect from
other games just seamlessly integrated to your own. Now, I would love it if all
of you got really wired up and ran home and used
Firebase right now. Right? But I know that
that’s unreasonable, and it’s even hard for me to
hand you this open-source game and say, look at it and decide
if this is right for you. So we created this project
called Unity solutions on GitHub. And in particular, we have this
Firebase Leaderboard solution. This implements a
leaderboard, which many games require one of those, directly
on top of Realtime Database. So you can try Firebase in your
own project and your codebase and see if it’s right for you. And if it’s not, it’s really
easy to take out a leaderboard, but at least I think
it’s really fun and you’ll get a kick
out of using this. And as I mentioned, we test
everything in Mecha Hamster, including the code
path that all of you would use if you integrated
this Firebase Leaderboard. In particular, since
it’s open source, we want you to expand upon it. So we, in Mecha Hamster, decided
to try adding a replay system so you see how someone
got that really awesome 2-millisecond score
on Easy Breezy, right? Obviously, the naive approach
I might do when I first approached this problem
is just hit the data, I have the memory for the replay
with Unity JSON Serializer, and try to drop that into
the Realtime Database. But at some time, at
some point, this database isn’t real-time
just because there’s so much data you’re trying
to send over the wire. In this case, in
a protobuf, which is the format we’re using,
this is 30 to 60 kilobytes. You can probably easily
double that for a JSON file. So we decided to use Cloud
Storage for Firebase. This is a key-value
storage solution. It’s another kind
of database that lets you store a key, which
is just a string path, as well as any
arbitrary binary blob. So in our case
replays, that could be player avatars, videos. If you wanted, you
could probably even put APKs and binaries up there. And our flow becomes– when you get a high score,
you log in the leaderboard, but at the same time, start
uploading the replay data to Cloud Storage. You get a callback when that
completes asynchronously, and at that point, we
can store a reference to the file we just
uploaded in a new node we added to the RTDB. There is still
one other problem. Now we have high scores
in two locations. If you’re like me,
most games I’ve shipped with a leaderboard– I’ve been– I’ve been
on it at the point I click the publish button. I might have even had the high
score on a particularly small game, but within
the hour I’m just gone, by, like, an order
of magnitude, right? It would really
stink if I was always paying for that Cloud Storage
space for this replay, effectively from day zero
for the rest of the game’s lifetime. And you can’t really
rely on user clients to behave well and
clean up all this data as a new score goes up. Even in the best case
scenario, someone’s phone might just stop working,
like they drop it in the ocean or something,
in the process of uploading a score. So we use Cloud
Functions to listen for when a node is added to
some path in the high scoreboard and then perform our cleanup. In this case, check
to see if there are more than 5
high scores and get rid of the associated
replay data. Now, Cloud Functions– they’re
brand new, out of beta. They let you run mobile back-end
code without managing servers. They’re written in
JavaScript or TypeScript and they’re also secure,
just like Realtime Database. If you create something
called a callable function– you get end-user SDKs to
integrate it with your client app– you’ll automatically get the
user’s login credentials, and they’re pre-verified by
the time your code executes. And not only can you communicate
between different Firebase products, but you can also
communicate between Firebase and the rest of the internet. So if I were to try to call out
some use cases that you might want to use in a video
game, it could be, if you’re making board games–
let’s say you’re making Monopoly Battle Royale, right– someone’s going to figure
out how to always roll doubles in jail. So roll your die in
a Cloud Function, very easily, store the result
in a Realtime Database, you’ve mostly eliminated
the potential of cheating. And if you have
gadget mechanics– a lot of games now have loot
boxes for monetization– some user is going
to figure out how to make every loot box
a Gjallarhorn if you let them claim what their prize is. So, again, roll
it in the server, distribute it through
Realtime Database or some other mechanism,
and you have control. Later on, Jon’s actually going
to talk about another product called Crashlytics. You can listen for when
a new crash happens. You can automatically log a
bug in Jira for your team. You can even get a callback
when a bug spikes in prevalence and send an SOS to
your team’s Slack to be like, hey
guys– drop everything and take a look at what’s
happening all of a sudden. JUSTIN BROUGHTON: All right. So, Patrick, we were
talking offstage about some of the horror
stories that you experienced while developing games. What are some of the
most horrible things that you ran into? PATRICK MARTIN:
I mean, there was a time when I dropped
a game from five stars to one overnight. JUSTIN BROUGHTON: Which
I’m sure you were popular when you did that. PATRICK MARTIN: That
was a hard week. There was also a time when
a producer on our contract product I was
working on actually managed to get my phone
number at midnight and called me with
an issue where I was getting a blank screen on
only a device his friend had, but, of course, it
was the contractee, so he had the final
say in whether or not our game was approval ready. So you know, I ran through– tore through our entire
device inventory, could not reproduce it. I was there until people started
showing up the next morning. JUSTIN BROUGHTON: So if
only you’d had access to Firebase Test Lab,
which is perhaps, the most contrived segue ever. PATRICK MARTIN: You
still earned this. JUSTIN BROUGHTON:
Thank you so much. All right, so we’re going
to turn our attention to testing games with Firebase. And so for all you games testers
out there, when we test games, what are we looking for? Well, in some respects, games
are just like applications. So we’re looking
for signals which might indicate a problem
or a bad experience, such as slow startup time. We’re looking for crashes,
which give a particularly bad experience to the user. We’re also looking
for incorrect behavior when the app or game does
not behave as we intend or as the user expects. But games are
different in the sense that we care about the
rendering performance. That is because games provide
an immersive experience that is seriously damaged if the
rendering is janky or slow. So what are test devs
doing today around testing? Well, from talking
to many of you, there’s a whole hell of a lot
of manual testing going on. There is some automated testing
but it’s generally homegrown, so it doesn’t work
outside of the game engine that you’re using, or indeed out
of the company which you work. So the question
is, why do we care? Well, obviously, we care
mostly because of the expense. Training all of
those testers to get to some of the late
levels in your game and then manually testing across
a variety of different devices and verifying the results
is pretty expensive. And then the testing
needs to be repeated on every single
release of your game. The testing is also
done late, which means you don’t find
the problems early when they’re cheaper to fix. And lastly, there’s
no safety net for your developers,
which means that they have no idea if any change
they’re about to make is going to break the game
in some fundamental way. So why are games devs not
flocking to automated testing? Well, as it turns out,
testing games is pretty hard. Firstly, games are rendered
with OpenGL or Vulkan or some other opaque framework. So the testing tools that
you can use for apps, like UI Automator, or XUI Test,
Espresso don’t work for games. Games also offer a
wider array of inputs. You can imagine games like World
of Warcraft or Clash of Clans where you’re basically
placing your characters or building your towers
anywhere you like on the screen. So the number of inputs
is virtually infinite. Games are often
deliberately unpredictable. This is because we want to
give a different experience to the user every time
they play the game. And often the issues within
games are really hard to reach. You can imagine that your
favorite ogre on Level 10 is dying and you’ve no idea why. So, up until quite recently, the
only generally available option for testing games
was Monkey testing, which was not particularly
helpful because it rarely gets very far into
the game to be useful. It also doesn’t exercise
the game as a human would, so you may not even care
about the problems it finds. It’s good for finding crashes on
startup, but very little else. So, before we get into some
of the testing solutions that I am going to present,
I want to first introduce you to Firebase Test Lab. This is something
I’ve been working on for about the last
five years or so. Firebase Test Lab is part of
the suite of application policy products in Firebase. It allows you to test your
app or game in the cloud, across lots of
different devices, including some
high-end gaming devices and as of today, Android
Q, and even Wear devices. So if you’re building
a game for Wear, then you can now
test it on Test Lab. You can also test on iOS and
Android, on physical devices, on virtual devices, in
different languages and locales, and, of course, with
different screen orientations. And you get comprehensive
test results, including video and screenshots
and performance metrics– so, startup time, most
importantly for games, frames per second, and network
and CPU and memory, all synchronized with the video. So you can see what’s happening
in your game at the time that you see some spike or
some problem in your metrics. You also get crashes
and logs and much more. Now, Firebase Test Lab is also
the engine behind the Play pre-launch report. So how many of you
here have heard over use the pre-launch report? Hands up. Not as many as I hoped. All right, Play pre-launch
report is a free report– that’s a free report– where you get testing
for free by simply uploading your game
into the testing track within the Play Store. So take advantage of that. So we’ve heard from many of you
that the security of your game is incredibly important,
much more so than even for application developers. This is because the leak
of a pre-production game would be absolutely disastrous. That is why we
completely clean up the device between test
runs, so that in most cases we’re simply
flashing the device. We also do a security check
on the submitter of the game, as well as the game itself. So how much is this going
to cost me, I hear you ask. Well, I don’t hear
anybody asking because it’s a bit early in
the morning for heckling. But it’s going to
cost you about $1 per hour for a virtual
device and $5 an hour for a physical device. But the trick here
is we only charge you for how long the test runs. We don’t charge you for how
long it takes to install it, to pull the results
off the device, to ship them off the device
storage to post-process them, whatever. We only charge you– so if you
send a test and you ask to test for five minutes on a Pixel
2, say, running Android Q, it’ll cost you about $0.40,
which is pretty cheap. So really, there’s no excuse
not to implement some automated regimen of tests for your
game, which brings us to how you might go about doing that. So firstly, it’s important to
prepare your game for testing. So you can upload a
special build to Test Lab or you can build
testability into your game. There’s a special
property you can check for that tells you whether
you’re running in Test Lab. Now there are many
things that you can do to make your
game more testable. I’ll talk about a few of them. You could, for
instance, remove part or all of the game preamble
of login, registration. So you can get to
Level 1 pretty quickly and allow your test
to focus on that. You can also remove
randomness from the game so that your testers see
the same game each time and they know they’re not flaky. You could also start the
game at a specific level, maybe increasing the
experience of your characters or giving them artifacts
so that you can test some of those later levels. So you can run lots of different
kinds of tests on Test Lab. Some of them are targeted
specifically at games. One test which requires little– really, no effort on
your part– is Robo. Robo is a framework of
different application crawlers that are used under
different conditions. So when Robo sees an opaque
screen, such as that rendered by OpenGL, it will switch to
the enhanced Monkey actions crawler. This is a crawler that
uses machine learning to interpret what’s on
the screen and interact with those screen elements. Now, Robo shows a
yellow circle, which you can see on the
bottom right there, on the video whenever it
interacts with the screen. So you can tell that it’s about
to click on the Let’s Roll button, which is exactly what
it needs to do to actually get to level 1. And as of I/O, and
that’s not going to be very readable to
half of you in the back, but you can now run
Robo locally, which means with this link, you can
download a version of Robo and run it against
your own games. And that’s available
to you as of I/O. With a little more
effort, you can actually record test scripts and execute
them locally or run them in Test Lab. Last year at the Game’s
Development Conference in San Francisco, we announced
a partnership with NetEase. NetEase is one of the largest
game companies in China. They developed an integrated
testing environment which they use for
testing their own games and they made it freely
available to anybody. They also open-sourced a
couple of testing frameworks including Airtest, which
uses image recognition to interact with the games. They also open-sourced
POCO, which uses instrumentation
in the game engine to allow it to the test
to interact directly with the games. They have support
for Unity and Cocos and even the Android framework. You can record scripts with
the game running locally and then you can package them
into instrumentation tests and upload them
to Test Lab, where you can run them across a
variety of different devices. And when the UI changes,
as it always does, you simply rerecord the test. It’s that easy. And thirdly, we have Game Loops. Game Loops allow you to
define critical user journeys through your game. You can do, say one
critical use journey– one Game Loop per level, or
maybe one per character– and Mecha Hamster, which
Patrick talked about earlier and you can see behind me,
has a built-in Game Loop. So check it out. And also, the pre-launch
report that I mentioned earlier will preferentially
run a Game Loop if it finds one in your game. So if you upload a game
with a Game Loop in it to the Play Store, you get
free testing of your Game Loop. So when should you use each
of these different kinds of testing? So Robo is really good for
testing the game preamble. It’s also great if you
don’t have any tests yet. It’s also used, as it is by
some application developers, as a last-ditch attempt
to make sure you’re not doing something stupid as
you push to production. So maybe a smoke test. AirTest is good for navigating
the UI and basic gameplay. and Game Loops, which test
the same critical user journey each time, are really
good for catching performance regressions. So now all you have to do is
add those tests that you built to your CI system– and I
assume you all have a CI system, right– so that every time
you make a change, you can be much more
confident that you did not break the game in
some way, which makes your developers happy. It makes your users happy, which
is ultimately what we want. So now I’ve completely put you
to sleep talking about testing, we’re going to wake Jon up. Hey, Jon. JON SKRIP: Thank you so much. JUSTIN BROUGHTON:
So how can Firebase help once you push your
game out into the wild? JON SKRIP: Great question. So, basically, at this point,
you have your game built. You have your game tested
and things are fairly stable, let’s say. What do you do? There’s a lot of
options and I’m going to start with Predictions. The reason I’m going to
start with Predictions is because it’s so
simple to enable. All you need to do is
literally go to the console and click the
button to enable it. From this point on,
Predictions will use machine learning to
start classifying your user base into predictive groups. By default, it will
start predicting who will spend or not spend, and
who may churn or may not churn, but this is fully extendable
with any sort of custom events that you would like
to add into your game. So what do we do once we
have some groups that we want to target? A/B testing is a
great place to start. Setting them up is super easy. All we need to do
is– first we need to select our target users. So let’s say we use our
predictions from the Prediction service, and let’s
target our spenders– our potential spenders–
because money is good. We like that. We next need to
create variants, which are the things that you want
to test– the changes that you want to test. We’ll say that you have
some remote configuration parameters that you
would like to work with. Maybe you have some seasonal
aspects within your game– you want to run a winter
event because it’s winter. And for our goal, we can
say our potential spenders– let’s see who’s going to get
excited about this winter event and let’s see who’s
going to spend. With Remote Config, we can
then deploy these changes if we find that
they are successful. And we have our
Hammy’s Snow Day event. But this is also– you don’t have to go
through an A/B test. So say we did this
test and you find out that seasonal events are great. Spring rolls around and you
know that these seasonal events are working. You don’t have to go
through an A/B test. You can go directly
through Remote Config. You just change your parameters
that you have programmed into your game and you
can launch a spring event, or summer, or whatever. Remote Config is super
useful, and this is barely even scratching the surface of
the things you can do with it. So things are going great. You’re making changes. You are gaining users. Stuff’s happening. Maybe you’re moving too fast. Maybe you didn’t test as well
as you probably should have, or maybe just some edge
case was discovered. This is about the
last thing that you want your users to see. Within Crashlytics
console, you get information such as the
frequency, the device type, the OS version– really the who, what,
where, when, why, and how many times
your game has crashed. What’s really useful is it
gives you the stack traces– the likely stack traces–
back to your code, so you can easily diagnose
issues within your game. And as Patrick
mentioned, you can also rig this up to alert you or your
team, which is super useful. I would recommend
integrating with Crashlytics even if you don’t integrate
with any other part of Firebase. It’s super useful. And one notable point is
that Crashlytics is now integrated with Unity. This means you can
take your Unity game and you can integrate
directly with Crashlytics, get the same insights into
your game as you would with a native application
or really anything else that is outside of Unity. So this is super exciting
for game developers. So maybe you’ve had some
crashes or maybe not. Maybe you just want
to alert your users to some exciting news. Cloud Messaging allows
you to target your users in the same way that you
would target them elsewhere. You could use your predictive
groups if you want. You could send it to everybody. You could really– really
target any other user metric that you have available. I want to mention Cloud
Messaging because it’s just so straightforward. You target and you
create your message. That’s it. You send it. I should also note that these
are A/B testable as well. So, if you want to target a
subsection of your user base, you can test out different
variants of your notifications and see which ones are
most effective– who’s clicking on them the most. So, with all of this, how do you
know that things are actually going well or maybe
things are not going well within your game? Firebase Analytics gives you
a bunch of insights– really, all the insights
that you would want– into your game performance. Here we can see some mock
data for Mecha Hamster. Things you can see in
the analytics console include revenues, what countries
your game is the most popular in– where your
usage is coming from. And you can rig up, really,
any other type of custom events that you have trigger
within your game as well. So it’s super useful for
tracking funnels and things like that. So I’d like to invite
my friends back up here. As we have gone
over a plethora– JUSTIN BROUGHTON: A plethora? JON SKRIP: –a smorgasbord
of features within Firebase– just to kind of wrap things
up and go over what we hope you have learned today. So we’ll start with Patrick. PATRICK MARTIN:
Yeah, as I mentioned, I really think
that Firebase will help you shorten the
distance from any idea you have to its implementation, and
would encourage you to give it a chance even in a
Game Jam situation. JUSTIN BROUGHTON:
And, of course, I talked about a number
of different ways that you can test,
automatically, your games. So I really encourage you
to take advantage of those. JON SKRIP: And I
have gone over– just really, a
quickfire– of available features within Firebase
that I urge you to leverage and experiment with. There is so much
provided out of the box that it’s really worth
your time to discover what Firebase can be. JUSTIN BROUGHTON: There
might be a plethora of it. JON SKRIP: A plethora. [LAUGHTER] And with that, that
will conclude our talk. Thank you so much for attending. Thank you, everyone,
for watching online. And come see us in the Firebase
and Mecha Hamster sandboxes. [MUSIC PLAYING]

One Comment

  • uNicoDev

    Well made talk.
    I have actually used the Firebase Database solution for leaderboards in a bunch of my games; I have also used it to create a custom level editor for another game of mine. They are pretty simple and straight forward to use.

    I am really excited to see Crashalytics and Firebase, in general, being implemented in Unity.

    I am wondering when the Firebase Unity SDK desktop workflow will be out of beta and will be available for public games (not just as a development tool). I was forced to use REST APIs for my other games due to this restriction (since I want my games to work also on desktop environments)

Leave a Reply

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