(upbeat music)
Hi everyone, and welcome to the Optimizing Games for Chrome OS talk.
I'm Matt Monash,
and I work on the Chrome OS developer relations team.
I'm here today to guide you through what steps
you should take to best adapt your game for Chrome OS.
But first, let's set the stage. Why Chrome OS?
Chrome OS is great for gaming and its gorgeous and large landscape screens
and devices come built in with keyboards and trackpads.
Chromebooks also have access to the same Google Play Store’s Android
and features promotions for Chrome OS-optimized games.
These devices can run all the same games you know
and might have even developed
with some specific exceptions that we’ll get to later.
When you target Chrome OS,
you’re also capturing large-screen Android devices.
This means growing your potential player base.
We've run case studies with partners who have optimized their games
and they've reported increased engagement
in terms of session length and increased revenue.
So, not only can Chromebooks allow for a better experience,
but games are already available there, and players are taking note.
What’s more, Chrome OS is, as of last year,
the second most popular desktop OS and is still growing.
Couple that with the fact that usage of Google Play games tripled in the past year,
and you have a powerful platform ready to make waves.
That said, while all of these games can run on Chromebooks,
the experience isn't always great.
Being designed for a smaller screen or for a portrait orientation,
a game might look awkward on these large landscape screens.
While touch does map well to attract that,
there's still input mechanisms that don't translate well.
In situations like these, the controls need to be adapted
to better suit Chromebooks.
And performance sometimes suffers on Chromebooks too.
For all these reasons, not all games are great on Chrome OS.
But you can change that.
These are by no means insurmountable problems.
And today, we'll break down the biggest barriers
to a great experience in Chrome OS.
Let's go.
There are three key areas we’ll be discussing today:
First, what specifically in the design of your game should be adapted.
Second, how to best test and verify these changes.
And third, how to publish to ensure your Chrome OS audience can install your game.
And we'll tackle them in that order.
So let's start with game changes.
But before we get truly started, I have a quick mention to make.
I’ll be pointing out a bunch of different resources and talks and links.
But don’t worry about writing them down on the spot.
In fact, I'm not even gonna have links on slides until the very end.
So if you want to follow up, you can refer to that final frame
or find the section down below this video
that also has the links to all the referenced resources.
All right, with that out of the way, let's roll.
The guiding principle here is to design beyond mobile.
Of course the mobile experience should still be considered and maintained,
but to succeed across Chromebooks,
we'll need to consider how to adapt designs
beyond just our handheld devices.
We'll look at ways to redesign a game visually
and also what input pitfalls to watch out for.
On Chromebooks, you have more screen real estate to work with.
This gives you the ability to do more with your layouts.
You can display more information at once or perhaps give existing elements
more breathing room to alleviate a cluttered UI.
You can also consider changing the placement of UI and HUD elements,
since the device won’t be held or mainly interacted with through touch.
If your game is locked to a portrait orientation,
consider designing a landscape mode as well.
Chromebooks do allow for windowed games, but we found higher engagement in games
that designed for full-screen landscape experiences.
Regardless of the orientation of your game,
it would serve you well to apply the aspects of fluid design to your game.
This allows your game to take advantage of all the available screen space
and provide the best experience for your players.
Please check out these talks from this year’s Google I/O.
While they're not games focused,
they are great resources that explore different layout strategies.
The talks are, “Five things You Can Do Right Now
to Prepare Your App for Large Screens with Material Design”
and “What’s New in Foldables, Tablets, and Large Screens.”
For even more inspiration, please check out the Rally demo app.
This example from our material design studies,
while also not a games example, is still a great resource
on how to maximize functionality and visibility
across a variety of screen sizes and orientations.
Now let's talk about input.
Because Chromebooks are such a different form factor,
there'll be new ways that users interact with your game.
Keyboards, mice, trackpads and gamepads might literally be on the table.
And be aware that not all Chromebooks have touch screens.
Our recommendation is to first and foremost
make sure that your keyboard, mouse, and trackpad support are all on point.
To this end, there are a couple aspects that I like to keep in mind
when considering what controls to adapt and how for Chrome OS.
These both come in the flavor of game classifications.
To start, is your game a fast-twitch game?
Games where your speed of input is important
will be greatly improved by having keyboard mappings.
The more you can reduce needing to click on-screen action buttons,
the smoother the experience will be.
So if your game requires quick reflexes or has elements of time pressure,
you'll want to add keyboard controls.
Next is complex touch games.
Games where there are control mechanisms
that require two or more touch input at the same time
absolutely require new input schemes.
Think of actions like pinching or unpinching for a change in camera zoom
or using a virtual gamepad where there’s a joystick on one side for direction
and virtual buttons on the other for actions and abilities.
You can certainly get some of these gestures to work on a trackpad,
but you want to ensure your players using a mouse & keyboard
will have a positive experience as well.
In these scenarios, either creating keyboard mapping for these controls
or mapping them to scroll on a trackpad or mouse will do the trick,
but you'll likely want to do both.
Some games don’t need as large an input treatment.
If your game resembles a classic Match Three,
the emulation we provide for touch to mouse and trackpad may be enough.
However, we still recommend having some basic keyboard mappings
like Escape to pause or open the settings menu.
This all said, the more care you put into your input adaptation,
the more accessible your game will be too.
Also from this year’s Google I/O,
we have a great in-depth talk on this topic.
If you’re interested in learning more, be sure to check out the talk,
“Input Matters for Chrome OS.”
Across both visuals and input, handling configuration changes is important.
Nailing this will make your game feel responsive
and will reduce frustrations from your players.
You might already be familiar with some kinds of configuration changes,
like rotation and split-screen, but you should also be aware
of other form factor transitions like tent and tablet mode.
Some devices can detach from the keyboard entirely too.
You’ll also want to be aware of connecting and disconnecting peripherals
like external mice, keyboards and gamepads,
to make sure that not only are you displaying
your input legends and tool tips correctly,
but you're reading input from these devices as well.
As an extra tip,
please be sure to build for x86 architecture.
The Chrome OS fleet of devices supports both ARM and x86.
And while there is a translation layer
to allow for ARM games to play on x86 machines,
you’ll get better performance and stability
when there's a published API that matches the device's architecture.
And because Google Play Store only sends down the necessary files for installation,
including additional ABIs in your Android app bundle
won't increase the install size.
You can easily set up your build process
to generate these ABIs by editing your ABI filters
from your build.gradle file.
But, what if you're using a game engine?
Well for Unity developers, I have good news for you.
If you update to the Unity 2021.2 beta,
you'll be able to build for Chrome OS including x86 support.
There’s no new build target to worry about,
because everything is contained within the Android build target.
You can find these options inside your player settings.
Once you change your scripting backend to IL2CPP,
you’ll be able to select additional target architecture and target devices.
You can learn more about the support
from Unity's own documentation listed in the resources.
Chrome OS support will be back ported to 2021.1 and 2020 LTS later this year.
Now that we’ve covered changes, let’s talk testing.
Here, we’ll cover two topics:
how to launch your game for testing purposes
and then what profiling tools exist to evaluate your game.
The biggest takeaway here is that there’s no better place to test than on real hardware.
While you can certainly test functionality like keyboard mappings using Android Studios’
Android emulator profiles, there is no such emulator for Chrome OS.
Thankfully, it's easy to prepare your device for debugging.
There's no need to enter your device into developer mode
and there's just two steps required.
Turn on Linux developer environment and then enable ADB debugging.
If you have multiple accounts on the device, be aware that this setting is managed
only by the device owner.
Once that's done, you'll be able to connect your device
with ADB over a USB or WiFi.
Once connected, you’ll be able to run ADB commands as you would expect.
Install, logcat, dumpsys, and the like will all work.
Conveniently, Android studio will pick up the connected device
and you'll be able to deploy directly from there.
So being able to connect via ADB is all well and good, but what about devices?
There’s many different Chromebooks available.
Which one should you have in your testing pool?
There are a few aspects to consider:
leading edge of Chrome OS version updates, your intended audience, and spec variety.
When we discuss families of Chromebooks, we use their board names to categorize them.
And that's how we'll be discussing things here.
There’ll be a link below showing mappings of these board names to real devices.
So first off, to be at the forefront of Chrome OS updates,
you'll want a hatch device.
These are typically high-end devices
and they’re also x86 machines, which will give you easy access
to test those fancy new x86 builds you should be exporting now.
This makes them a great choice for a first testing device.
Next, consider your audience and what devices they might be using.
This is more specifically a call up for games that have a big EDU presence.
School settings heavily use Octopus devices.
So if that’s your game, be sure to pick up one of these.
They’re also typically less powerful devices,
and so they’ll serve you well as a lower bound on performance tests.
And last is making sure you have a variety of features.
Some Chromebooks are convertibles
which transform between laptop and tablet by folding the keyboard behind the screen.
Some are detachables where the keyboard can be removed entirely.
Some come with styluses and some don't have touch screens at all.
Keep in mind that there are ARM Chromebooks and that, while we strive for parity,
there may still be differences between
how games run on Android devices and on ARM Chromebooks.
To better test your configuration change handling and performance,
as well as visual and input design treatments,
you’ll want to aim to cover as many of these different setups as possible.
Now, this may sound like a lot of devices,
so the order we've discussed them here also ranks their importance.
Start with cutting edge of Chrome OS versions and upper bound on performance.
Then consider if your audience is using a specific board.
Finally, try to cover any feature gaps not already covered by the machines you own.
All right, now you have a device, it’s set up for debugging,
and you have your game running on that device.
How do you monitor performance?
Well, allow me to introduce some profiling tools.
In previous years, we’ve talked about the Arc Graphics Tracing tool.
Since then, we’ve built the new Arc Overview Tracing tool.
It's a good general tool that comes built into every Chromebook.
This will help you measure FPS, render quality,
power consumption, among other metrics.
While Arc Graphics is more powerful,
Arc Overview is a good place to start and is easier to understand.
So I recommend it as a place to begin your profiling adventures.
There's also Perfetto.
Think of it like Systrace but with some extra bells and whistles.
You can trace Android events as well as Linux kernel events
and receive logcat messages too.
This is helpful when you want more context around what’s happening on device.
What’s great here is that there’s also a query API that you can harness from Python.
Through this interface, you can automate performance tests.
And that can be a huge benefit for teams big and small.
This tool is available on all devices running Android 10 or later.
So we've made changes. We've tested those changes.
Now you just need to roll it out.
This is the final stretch, so let’s get right to it.
The TLDR here is that as long as you haven’t specifically excluded Chromebooks
there’s a high likelihood your game is already available, but let’s walk through it.
Google Play Store on Chrome OS uses the same listings as Android.
And so when you create a listing and publish through the Play console,
the listing will be considered for Chrome OS devices.
To reduce maintenance overhead and ensure the improvements you make to your game
can be seen across all devices, not just Chromebooks,
we advise that you maintain single listing and a single build.
This means that you'll be uploading your APKs and AABs
in the same way you have been; same listing, same track.
Do make sure that you haven't listed any Chromebooks
in your device block list.
Beyond that, your manifest might also be preventing your game
from appearing to Chrome OS devices.
Typically this happens in the form of required features
like forward facing cameras and GPS.
Sometimes these required features sneak their way
into manifest as a result of copying old manifest
or using some boilerplate files.
So be sure to audit this and remove what you don't actually need.
Of course, if your game absolutely requires them,
perhaps like a geolocation RPG, then you should absolutely leave them in.
Finally, make sure your min sdk is not too high.
All Chromebooks currently support Android P
with R being rolled out devices over the course of this year.
As long as your min sdk is 20 or lower, you're good to go.
And, well, that’s about everything, so let’s wrap it up.
Remember to design beyond mobile, both in terms of visuals and controls.
Consider the different form factors and input schemes open to your users.
And don't lock these changes to just Chromebooks.
Allow all your users to enjoy the benefits of fluid layout design and new control options.
Remember that there's no substitute for testing directly on hardware.
You'll get the truest results by testing on a Chromebook itself.
And you have a suite of profiling tools to help you out.
Remember to verify that your game is on Google Play Store on a Chromebook.
And if it's not, check your block list, your required features, and your min sdk.
By following all of these steps,
you can deliver a much improved experience not just on Chrome OS, but on Android too.
Your players will certainly thank you.
If you'd like to learn more about adapting your game,
please check out our developer site, chromeOS.dev.
Here you can find step-by-step guide and code snippets
for optimizing experiences on Chrome OS.
You can also find news reports, including more information
about our partnership with Unity,
as well as case studies that show what optimizations
other apps and games developers took and how successful their adaptations were.
And for real now, that's it. That's the talk.
Here are all the resources I mentioned throughout the talk.
You should also be able to find them underneath this video.
Thank you for coming.
Truly, the future of gaming on Chrome OS is in your hands.
I can't wait to play the games you make.
(gentle music)