[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]