Building an awesome game for Android (Indie Developer Day, Seattle 2018)
Articles Blog

Building an awesome game for Android (Indie Developer Day, Seattle 2018)

September 8, 2019


BEN GABLE: Hello, everyone. As Sarah said, my
name is Ben Gable. I am a developer advocate
working in games. And I’m super excited
to be here today– two reasons. I used to be an ex-indie
game developer myself, before I joined Google,
as Sarah was as well. And also I went to school at the
DigiPen Institute of Technology over in Redmond, so Seattle
is kind of my old stomping grounds. So kind of continuing
the flow, there’s going to be a lot
of information. I’m going to be going through
it very quickly to stay on time. So I’m here to talk to
you today about building an awesome game in Android. And really, what does that mean? Well, you guys know how
to build awesome games. It’s all about building a
high-quality game in Android. Android is the largest mobile
operating system out there. And what that means is just
tons of people all around the world that are
going to be playing your game on different
devices, on different versions of the OS, and it’s
a huge challenge. And you want to make
sure that you’re developing a super high-quality
game so that when somebody picks it up on a certain
device or a certain version of Android, they don’t
have that experience. Because if they have
a bad experience, it could turn into
bad reviews, or they could uninstall it, or not
tell their friends about it. So it’s super
important to consider all the different
places and ways that people are going
to be experiencing your game on Android. And really, this breaks
down into two areas I’m going to talk about today. So first two areas is,
like, what’s new in Android from a technical perspective,
and what are the new branch– so there’s a new
branch called Chrome OS that we’ll talk about a bit. And the second part is going
to touch more on, as indies– having resources to
test and make sure that your game is delivering
a high-quality experience is hard. So I’m going to talk
about maybe some solutions that you can consider
that, hopefully, will make that a lot
easier for your guys. So let’s jump in. So Android P– this just came
out a couple of months ago. And one thing I
wanted to bring up before we jump into Android
P is there was a new Play requirement that actually,
just yesterday, you need to be targeting
API level 26 or above in order to launch any
new updates for your game. So if you weren’t already
aware of this update, and you’re planning on
launching updates soon, you might have some
extra work to do. So please be aware of that. But the bigger thing
I wanted to bring up is, next year, we
have a new requirement coming, which is more
relevant to game developers. And that’s, you’ll need to ship
a 64-bit version of your game for whatever architecture
you’re targeting. So this is something
that you could have lots of
external dependencies on third-party
plug-ins or something. Or your game engine,
you might have to consider updating
your game engine to support a 64-bit build. But as more and more 64-bit-only
devices are going to be launched in the
Android ecosystem, it’s important to make sure
that games are available– so again, continuing
the theme of making sure that you’re aware of all the
different kinds of flavors of devices that people are going
to be playing your game on. So notches have come to
the Android ecosystem. You guys have seen Pixel 3. I am personally not a notch
guy, but a lot of people are. So it’s important to
consider that your game might be being played on a
Android device with a notch. So we’ve added a bunch of
APIs, best practices online, and actually some developer
tools where you can simulate notches on a device. So I recommend that
you take a look at how your game is
running on a notch device and make sure that the
UI is not being cut off or there are other rendering
issues either happening there. Notifications–
notification channels are now compulsory
as of API level 26. So you’ll need to specify
a specific channel for each of one of your notifications. And basically, what
this lets users do is activate or deactivate
certain channels that they maybe care about. And also, they can customize
the behavior of each one of the notification channels. So really what this
means for you guys is to think about what
kind of channels you’re putting your
notifications in and not spamming the user and
being aware that people might be turning things on and
off as they upgrade to Android P. For NDK, there’s been
a bunch of new stuff that we’ll go over briefly. Basically, we’ve added
APIs for neural networks on JNI shared memory. So that’s a huge deal
and super exciting. We have now Client++ is the
default compiler for NDK builds. And libc++ is now the only STL
implementation that comes with the NDK. So please be aware of that. And then also, we’ve now
got the LLD linker as of r18 is available for
testing, which we’ve seen can greatly speed up
your linker times. So sometimes building and
deploying is super slow. So I recommend you
check that out, as it could help you speed
up that process greatly. OK, some other
Android P features– we’ve got ARCore, Vulkan 1.1
support, neural network APIs. We’ve got a JobScheduler
for background workloads, which should be super
helpful for some of you. And also we’ve got an
indoor location API, which– you guys being indies, come
up with the craziest ideas– I’m sure somebody will come
up with an amazing game idea based around that. So excited to see what
you guys do with it. Cool. So now let’s jump on
games on Chrome OS. So maybe a quick
question– how many of you have used the Chromebook before? Yeah, OK, so some people. And how many of you were aware
that your Android games can now run on Chromebooks? OK, a few more, but not a lot. So this’ll be exciting. So if you didn’t know, Android
games can now run on Chrome OS. So you can see
here on the right, we’ve got the Pixelbook,
which is a more traditional laptop-style device. And just announced
was the Pixel Slate, which is coming out later
this month as a tablet with a detachable keyboard. And Chrome OS, as I said,
games can now run on Chrome OS. So your Android game is probably
running on Chrome OS right now. And there’s probably people
that are asking to play it or are already playing it. The biggest ask
we’ve been getting from users on Chromebooks is
they want to play games on it. And Google is putting
a huge amount of effort into building out the
Chrome OS ecosystem. So again, kind of
going back to building that high-quality
experience, you might have users that are
playing on Chromebooks. And you should be
aware that they could be playing on Chromebooks. So this is a huge
new area of Android that presents a huge opportunity
to collect more users and also play it in a way
that, for your gameplay design might actually be a much
better way to play it. So then you might be asking,
deploying and testing and all these versions of
Android is already hard. Device fragmentation is real. I’m an indie dev. I know how that goes. How can we possibly
support Chrome OS? Well, the good news
is that most of it is probably already
done for you. The Play Store is the same on
Chrome OS and mobile devices currently. So if it’s on the
Play Store right now, it’s probably
running on Chrome OS. There are a few
permissions and stuff that, if you’re
asking for it, it will list it as incompatible. But we can talk
about that later. It’s the same APK on both
Chromebooks and mobile device. So there’s no extra
libraries, no other plugins you have to integrate. It just works. And as we’ve seen,
a lot of times, 90% of the time, the
games work great. But with that said, there
are some key differences I’ll touch on in a moment. So how does this work? Basically, on top of the
Linux kernel on Chromebooks, you’ve got Chrome OS, and you’ve
now got the Android container. So it’s not a VM. It’s Android running natively
on top of the Linux kernel. It’s the full
version of Android. It’s on a stripped down
or special version. So anything that works
on a mobile device works on Chromebooks. So that makes it a lot
easier for developers to target and support it. And moving forward– so
you can see Android P just hit the Canary Channel for
Chromebooks a couple weeks ago. Moving forward, all the
major releases of Android will also hit Chromebooks. And they’ll
basically be in sync. So again, important to consider
that this is happening. So as I mentioned, there
are some key differences you should be aware of. So first off, you’ve
get the bigger screen– so more pixels to render. You could look at performance. Also, you could look
at UI considerations. You’ve got all this extra
screen real estate space to take advantage of. Default landscape
orientation– so those of you with a portrait-default
orientation might want to take
a look at that. If you don’t do
anything, there might be some giant, ugly black
bars there that are no good. On Chrome OS, dynamic
resizing is the default. So when you launch any
kind of Android app, it’s in a window that can
be dynamically resized. Fortunately, in the game
world, we don’t really deal with an dynamic resizing,
and a lot of game engines don’t handle that very well. So consider maybe
disabling dynamic resizing or just locking to full screen. And then obviously,
the biggest difference is now you’ve got a keyboard,
in the case of the Pixelbook, attached to the device. And as we see more
and more games blurring the line between
consoles and PCs– you’ve get things
like PUBG, Fortnite. The same gameplay that’s on
PC is now coming to Android. Obviously, implementing
keyboard and/or mouse controls could be a huge benefit to
provide the best possible game experience for your Android
players on that device. So consider that. Also, one thing
that’s not listed here is that a lot of mobile
devices are ARM-based. And a lot of developers
don’t ship an x86 version. A lot of Chromebooks
are x86-based. So you should be aware that
you might see some performance degradation due to the
translation that happens when you try to do an ARM– so an ARM APK will run
on an x86 through Houdini translation layer. But you’ll kind of get
that overhead there. So if you can ship
an x86 version, you should definitely
take advantage of that. So Vainglory is a mobile
app, for example, developed by Super Evil Megacorp. They implemented
full skill bindings for their keyboard skill
bindings and item usage. And they still left the
touchscreen controls in. And they actually
told me they found an interesting hybrid approach
where you can tap the screen to select enemy heroes much
quicker than with a trackpad and then use the keyboard to
fire off skills and items. So they found a lot
of their pro players actually prefer that
input method compared to the one way or the other. And then Gameloft has developed
Asphalt 8 and recently Asphalt 9 for Chromebooks. And on mobile, they’re just a
tilt- and touch-base control. But on Chromebooks,
they actually detect that the keyboard
is connected and allow you full WASD and
arrow key controls. And obviously on
the bigger screen, it looks a lot better too. They’ve got some great graphics. And the other interesting
thing that they found is that, when they
launched Asphalt 8, they found a 6x increase
in daily active users and 9x increase in
monetization, which, again, speaks to
Chromebooks– people want to play games on them. And I think this speaks to
players are clamoring for it. One other quick note is
that Linux is actually on Chromebooks now too. So there’s a full [? NVM ?]
running on Chromebooks that you can actually
install Android Studio. You can install Steam. It’s not very fast yet. Don’t worry, I tried. But we’re really working on
trying to improve compatibility and speed of the Linux VM. So definitely check that
out if you get a chance. Cool. So that was a quick run through
of these big new branches and areas of things
that users are going to be experiencing
in the Android ecosystem. And you, as game
developers, should try to be aware of these new
features and these new devices that people are playing on and
try to target that and provide the high-quality experience. Now let’s talk about testing and
how you can, from that aspect, provide a high,
stable performance, no crashing, fewer bugs. So we’ve got some tools
that we’ll talk about here. And the first off, in
Android Studio 3.3, you can now sample
native C++ threads. So for any app that is API level
26 or above, you can do this. So maybe a raise of hands,
how many of you have never, ever left debug logging
code in production code when it’s shipped? Anybody? OK. Good, because I was going
to call them a liar. So now, if you’ve done
something like this, “it might do something
cool” function. Inside Android Studio, I can
see the “might do something cool” function is doing
something not very cool at all. And I can fix that. Systrace is now coming
to Android Studio. It’s not quite in Canary
yet, but it’s coming. And basically,
systrace gives you a snapshot of how
your game is running on the Android in addition
to the Android system. So you might be
using Unity or Unreal or have your own profilers
that are happening, but they might not
give you as much detail about how your game
is running in terms of the rest of the
system processes. So inside Android
Studio, in a bit, you’ll be able to
see this whole view. So you’ll see up on the top,
you’ve got the CPU time. You’ve got your
different CPU cores. You’ve got display of all
the threads that are running. And at the bottom, you’ve
got your call chart. So there’s a couple of
really useful use cases for this that will
hopefully make debugging and profiling
and optimizing for Android much easier. So the first here is
you can see that we’ve highlighted this thread. And I don’t know
if you can see it, but there are some red
frames right there. So that kind of indicates
those are slow frames. So you can dig in and see,
maybe outside of your game, why something might be
causing those slow frames. And here, you can
actually see, on this, we’ve highlighted this thread. You can see it’s jumping
across the different CPU cores, which could be causing
some performance impact. So you might consider
setting thread affinity for that specific thread
to stay on one core. And here we can see that this
is a very, very terrible frame. It’s taking a long time. But now inside
Android Studio, you’ll be able to dig in and
figure out why it’s so slow. You can see down at the
call chart at the bottom, there are multiple
calls to inflate, which obviously is
inflating the frame time– so super useful
tools that are coming very soon that we hope you guys
will take advantage of and hope it provides value. Also, a super exciting– I think is the
biggest thing– is you’ll be able to
basically instrument and provide your own
events for your game. So you could do things like
set events around your loading screens. You could set events
around your shadow passes or other areas of
high-intensity gameplay where your performance
is a problem. And basically, that’ll
show up inside systrace much more clearly. And you’ll be able to
get those deep insights that you need in order
to optimize for Android. And in the future,
we’re working on adding more support around
viewing v-sync events and timing around that. So there are some other
things coming to for games that will be announced really. Cool. And then one the other tools
that I wanted to bring up was GAPID. So GAPID basically– it’s
our graphics API debugger. It basically lets you
trace, inspect, and replay all of your draw calls. So for example, if you’ve
got some weird graphical bugs or maybe some performance
is not as you expect, you can sample a
portion of your gameplay and go through all the
frames, all the draw calls, view things like models,
textures, shaders, basically view everything that the system
is doing to compose that frame. So it gives a lot of insight
that you might not be aware of to help debug issues. It supports both OpenGL-
and Vulkan-based games. So if you’re doing either
one, you should be covered. And it runs on both
Windows and Mac. Cool. So now, let’s talk
about game testing, which we know game testing
on Android is hard– all these devices, all these
different versions of the OS. A lot of the existing tools are
also not built around games. So we kind of went on a quest. We wanted to find a solution
that was easy to write scripts inside of an IDE. You could run it on
your local device, run it maybe on a farm of
devices in the cloud somewhere, simple to use, and
confident in the results. And we actually found a solution
being built by a Chinese game developer called
NetEase, called Airtest. And basically what
it lets you do is test your production
APKs with no instrumentation required. You can run it on
your local device. And it also integrates
with Firebase Test Lab to run these tests on the cloud. So you can see here the IDE,
but I actually got a video here that we’ll kind
of go through it. So you can see on the
right is your game. And then in the middle
is your script window. And as you play through the
game like you would normally, it’s writing a test
script for you. So it’s trying to do all the
things that you’re doing. And basically,
what you can do is you can write out
this entire script. You can tell it to do things
like click on buttons, assert that player models that
should be there are there, move things up and down. Basically, anything that you
could do playing the game, Airtest can also emulate it. And then what you do
is you run the test. And it actually plays
through your game, each step, gives you all the output. And for each step in the
test, after it’s done, it’ll give you a
report here we’ll see in a second that shows you
the results of all those steps. So it’ll show you what
steps failed, if there are any warnings or errors. It’ll give you a log
of all the screenshots of all of the different steps. So it’s really
useful to maybe do this for things
like first-time user experience or tutorial level or
just other kinds of boilerplate areas of your gameplay that
you might test at one point and everything works fine. You go and you do a
bunch more changes for a couple more weeks,
some new features, and then you go back
and everything’s broken. So this is a great way
of writing these tests and automating the whole process
that you don’t have to do it over and over and over again. And kind of underlying
Airtest here is there are two
frameworks at work. There’s Airtest, which is using
image recognition just looking at the pixels on the screen. And then if you want more
integrated testing or more kind of complex test cases,
you can integrate Poco, which basically, it
exposes the UI and object hierarchy inside your game. And there are plug-ins for
Poco, for Unity, Cocos, and other custom game engines. So you have two
flavors you can use depending on how deep you
want to integrate this testing solution. And the really interesting thing
here, and the most exciting thing is that this all
integrates with Firebase Test Lab. So what you can do– I guess those of
you that don’t know what Firebase Test Lab
is– it is basically a cloud of devices. There are physical
and virtual devices running all different
kinds of the Android OS. And you can upload
tests to it, and it will test your game for
you and give you reports. And with Airtest, you can
basically build your test APK. You can upload it to
Firebase Test Lab. You can create a suite of these
automated tests that will then kick off whenever you want. There’s actually a command
line interface to hook into your continuous
integration. So every time one of your
developers pushes a change, it’ll kick off these
tests and select which devices, which versions
of the OS you want to target. And it’ll actually give
you a very detailed report that shows you all the failures. It shows you all
the system logs. It’ll actually give you a
video replay of your tests of your game running. So you can actually
see and verify that what you thought it was
doing is actually being done. And it actually gives
you performance data, syncs to the video. So you can see
things like CPU time, memory usage, network usage. It’s basically a QA
army at your fingertips. So it’s super exciting. And I think this is one
of the biggest challenges for indie game
developers is that you don’t have a lot of
resources to test your game. You’re trying to build a
game, not necessarily test it. So being able to setup
these automated tests and just have them running
over and over again, again– make sure that you’re
maintaining that high quality bar and delivering
a great experience. So here are some links
for some more information. You can find the IDE at
Airtest, the first one. And then we’ve got
some GitHub projects. And now let’s talk about vitals. Sarah briefly mentioned this. But vitals– you know
Airtest and Firebase Test Lab are for pre-launch
development, building new features, testing. Vitals is basically
a way to see– you get actual data
from devices that have opted into the Android
vitals diagnostic system. So you get actual reports
from actual user devices out in the wild that are
actually playing your game. So this is a huge deal. And why we made this
is that, basically, we found that 50% of
one-star reviews mentioned stability and bugs. Again, providing
that great experience has a really big
impact on your rating, which impacts your success. It’s one of the many ways
that indie developers create success. So it’s important. And you might have seen this
already in your Play Console. But you can go in, and you can
look at your Android vitals report. It will give you a
detailed breakdown of all the different crashes
and all these other things that vitals is monitoring for. And some of the
ones that might be of interest to game developers,
specifically, obviously, are– these are bad behaviors
that Android vitals test for. So you’ve got crash rates. You’ve got ANRs. Around battery– as Android
P has introduced a lot of new battery and power measuring
tools for the users, so if your game is up at
the top of this list of– it’s a power hog, that puts
you in a dangerous territory of potentially getting
uninstalled or used less. So making sure that you’re not
waking up the system too often, or you are– don’t have any stuck wake locks. When your app tries
to get backgrounded, if you hold onto things
like audio handles or stuff like that, your game won’t
be backgrounded properly and continue to draw power. Cool. So let’s recap real quick. I went through a
lot of information. And really, again,
it’s providing a high-quality experience
because that really directly impacts the
success of your indie game in the hands of users. So the first two
parts I talked about was, consider where the users
are going to be playing, what kinds of environments
your players are going to be playing your game in. So all these new Android
P devices that are out there have these new features. Maybe consider how you might
integrate those new features. Consider that people
will probably playing on Chrome OS moving forward
and that you should make sure that your game runs
great on Chrome OS. And then the second
part is really, again, once you ship a
high-quality game, maintain that quality bar. So profiling and
optimizing your game so it runs great on as
many devices as possible, testing early and
often, and using things like vitals to attack
production issues quickly. So all of these things
kind of come together and will allow you hopefully– I hope you found at least one
thing in here that will maybe help you guys provide that
higher-quality experience and take some load off
so you can focus more on building gameplay and
the super awesome innovative features and some of the more
boilerplate game quality type stuff. Hopefully there’s something
in here that’s useful for you guys. So thank you very
much for your time.

Only registered users can comment.

Leave a Reply

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