Google I/O 2012 - Ten Things Game Developers Should Know


Uploaded by GoogleDevelopers on 10.07.2012

Transcript:
>>Ian Lewis: (Off mike.) >>Dan Galpin: I think there are about two
people who got -- >>Ian Lewis: Everyone in the front row got
that joke. The rest of you, doesn't matter. [ Applause ]
>>Dan Galpin: It's not a very Googley joke, though, as they go.
I guess we're going to go with half of a screen. >>Ian Lewis: People on the right side of the
room, sorry, man. Sorry. >>Dan Galpin: Now we need volume off of that,
believe it or not. Ooh, that's good. >>Ian Lewis: Oh, no. That one's better. Here.
(Sound effects). >>Dan Galpin: There we are. Each week, deep
in their secret chambers below Google building 44, the Android editorial board meets to decide
which apps and games will be featured in the Google Play Store.
This is an important decision. For a lot of developers, it's a matter of life and death.
So we take it very seriously. >>Ian Lewis: At the same time, it is an editorial
decision. What does that mean?
You have no control over this. I have no control over this. The -- my wife wants to call me,
but that's not going to happen. [ Laughter ]
>>Dan Galpin: The one time you're allowed to say "no."
>>Ian Lewis: Exactly. [ Laughter ]
>>Ian Lewis: You can't pay for featuring in Google Play. You can't bribe people. You can't
send us bottles of Dom Perignon and then get featured. That actually doesn't work as well
as some people seem to think. >>Dan Galpin: But keep trying.
>>Ian Lewis: There's no sure-fire recipe for getting featured. The decision is made by
the editorial team according to their own criteria. So you're never going to see a talk
called, "What to do to get featured on Google Play."
At the same time, Dan and I have spent a lot of time with the editorial board, and we've
seen a lot of games, a lot of excellent games, get rejected for what seem like sort of minor
reasons. A lot of them are problems that are really easy to fix. So although we can't talk
about what to do to get featured on Google Play, we can talk about what to not do to
not not not get featured on not -- [ Laughter ]
>>Ian Lewis: -- not -- yeah. Anyway --
>>Dan Galpin: The transcription is going to be great there.
>>Ian Lewis: More succinctly, ten things that every Android gamer developer should know.
So let's start with number one, Dan. >>Dan Galpin: All right.
So one of the things that people do when they go out and buy their great new Android handset
is they come back and go to Google Play, and they want to get great stuff. And, you know
-- that was good -- we at Android love all your releases, but we always have a special
place in our heart for our newest version and we love it when people use our newest
operating system. We also love it when people buy now Android
devices. So we tend to avoid featuring anything that's incompatible with the latest and greatest.
The first thing you want to do is make sure you support high resolutions. You'll need
to author your assets today for at least 720p. And remember that not all 720p displays are
equal. Assets that look great on a ten-inch tablet aren't necessarily going to work on
a seven-inch tablet or phone. And this is especially true for UI elements that have
to be sized like your fingers, like drumsticks. >>Ian Lewis: Oh, Dan, tell them what the dpi
the Nexus 7 is. >>Dan Galpin: So the Nexus 7 is in between.
But you should really think of it for the most part as being an hdpi device. We refer
to it as tvdpi. And what this means is, don't expect to have a resource that's sized for
your finger. Instead, look at the display density and scale your resources accordingly.
>>Ian Lewis: Because you do not want to be the guy that designs the Xbox one controller;
right? I've seen tablet games that basically do that.
>>Dan Galpin: Another thing you want to make sure is do -- make sure your app isn't running
compatibility mode on Honeycomb and above. You can tell you're in compatibility mode
because there will be extra icons in your status bar like the menu button. Not everyone
knows what this means, but to experienced users, it's a red flag.
So what can you do about it? It turns out the solution is very simple. Just specify
a target API of 11 or above. The target API for what reason is called target SDK version
in your application manifest and you should really target the latest version as much as
possible. All that really means is I have tested on the latest version of Android.
And this is good, because we won't turn on any compatibility shims.
>>Ian Lewis: Now, the compiler will give you a warning. It will say, hey, you just specified
a target SDK that's greater than your min SDK, like that's a problem.
>>Dan Galpin: Yeah, yeah. So that's the one time -- Normally, look at Lint and be, like,
"Yes, Lint is right." In this case, --
>>Ian Lewis: Don't believe its lies. >>Dan Galpin: Yeah. Lint will actually do
the right thing and it will actually tell you if you use API levels that aren't going
to work on your target devices. So it's good.
A lot of programmers worry that specifying a high-target API is going to mean it gets
filtered out on the Play Store. Of course, that isn't the case. It's just designed to
turn off compatibility shim. Filtering is done with min and max SDK version.
And, in general, it makes sense to send min SDK version to the lowest version that your
game will run on, set target SDK version to the version of the SDK you're compiling against
or testing against, and really don't ever set max SDK version.
But you know what's cooler than API level 16? Lights out. You can almost completely
hide the soft buttons. And this is really easy to do. Just, literally,
take -- go to your view and set your view to status bar hidden.
You can only do this on Honeycomb and above. The good news is that it's very easy to put
in a conditional around that, as long as you're, you know, not targeting Donut or something
like that. >>Ian Lewis: Right. They told us by the way
to put a code sample in for that and we're like, these --
>>Dan Galpin: They don't need a code sample for that.
>>Ian Lewis: We'll be posting code sample later.
So thing number two, how to evade pirates and symptom vampires.
So by "pirates" and "vampires," we mean people who steal software and people who steal bandwidth
by downloading game (indiscernible) resources when they haven't actually bought your game.
Now, we can go on and on about whether pirates represent lost sales or theoretical lost sales
or a wonderful new distribution mechanism that's going to make us all rich. But of the
two, vampires are the ones we're most concerned about, because they represent an immediate
bill to you for bandwidth that you're using to download assets that were never paid for.
So we want to stop vampires the most, but we do want to stop them both.
When we're talking about stopping pirates, a lot of times we talk about copy protection.
There's one thing that you should never do. And that is check the copy protection box
on the Google Play publisher site. We had this thing when we were sort of young
and naive as an operating system called forward-locking. And it prevented users from casually copying
APKs from phone to phone. We optimistically called it copy protection because we thought
that it would help to curb piracy. It turns out we were completely wrong.
[ Laughter ] >>Ian Lewis: Forward-locking doesn't actually
stop piracy at all. It's supposed to keep users from copying games. But what it really
does is prevents the completely legitimate activity of putting a game on the SD card.
But it gets better. Not only does forward-locking prevent you
from moving to SD card, but it also expands the size of the APK on your internal storage.
So you basically have got the worst of both worlds if you check that box. If you did ever
check it, go uncheck it now. Just remember that once you remove forward-locking, you
will have to do another APK upload to get that update to come out.
We're actually removing it very soon, because it turned out to be a bit of what they call
a Charlie Foxtrot in the business. So what do you do?
Well, first, in order to deter pirates, you should use the license verification library.
Now, this isn't a perfect solution. But it will help to deter casual piracy. It will
not stop the most determined hackers. For vampires, though, we have an extremely
good solution. It's already saved many of our partners hundreds of thousands of dollars
in bandwidth. And that is APK expansion files, which means that Google is hosting your large
files for you instead of you having to use your own content distribution network.
This is good for two reasons. First, no cost to you. Second, unless you're a very, very
large company yourself, we probably have a better CDN than you do. So faster and cheaper.
Use APK expansion files. You can also, if you do want to serve your
own files, watch Dan's presentation from last year's Google I/O to understand how to tie
large file downloads to the LVL, license verification library. That's actually what the APK expansion
system does internally. And you can do it externally as well.
Large file hosting is available now. It works on almost everything. And for the devices
that were unable to get the Google Play update that enables large files, you can download
Dan's excellent shim library that is chockful of best practices for how to do a background
download, and you'll find that your user experience for downloads is much, much better.
>>Dan Galpin: Thank you. So now to point 3, which is don't mess with
the buttons. And as you noticed, these Android devices
have buttons on them, things like the lock button and the volume button and the back
button and the home button and the, you know, app switcher button.
And, basically, the goal with most of these is -- is either leave it alone because you
can't do anything about it, or try to use the default behavior of the framework.
In the case of the volume keys, you want to make sure those volume messages go to the
framework so you actually get the normal popup that the user expects for controlling the
volume. Now, the one real question that game developers
have is, what do I do about the back button? Because most games actually consist of a single
activity. And the default behavior for the back button is just to close, destroy the
activity, and remove history. So the way we like to think of the back button
is it's sort of like the escape key. So let's take our example game here. And,
you know, basically, you know, this is -- you know, this is a simple arcade game. And we
start the game. We go through a few menus. We're in the middle of our playing. And we
hit the back key. And, boom, what does that do?
Well, it makes sense for it to take us back here, because that's what the user expects;
right? That's the screen the user was on. Even though this was all a single activity,
we expect the Android navigation paradigm to be, you know, used.
So another option is to actually pop up a dialogue. And this is very common. A lot of
game developers do this. It's not the best practice because it really doesn't match the
Android navigation paradigm. But it's very well known, and we certainly don't have anything
against this practice. So the real question now is, you put up this
dialogue. And where do you want it to go after you hit the back key again? Do you want it
to go back to this screen? Or do you want it to go back to the game play?
And, really, if -- since this one is obviously looking like a dialogue, we expect it to behave
like a dialogue in Android. We pop the dialogue in the back key, and we expect it to be dismissed.
In general, what we're talking about here is choosing the UI that will disrupt the user's
game experience the least. So dismissing the pause menu like a dialogue actually will be
what the user expects. But even better again, we skip the pause menu
entirely, go back to our previous screen. We have some very obvious option to allow
the user to continue where they left off. >>Ian Lewis: Now, I realize that this is an
incredible mockup and you're probably thinking, okay, I want my game to look exactly like
that. But the truth is, Dan and I made it in Photoshop and we're not professionals.
So you might want to steer clear. But the main point that we're --
>>Dan Galpin: Are you saying we don't have elite design skills?
>>Ian Lewis: No. No, we don't. The main point is that you want to be able
to go back to a previous UI screen, but always have a way to go forward again.
>>Dan Galpin: Exactly. And here's the thing really, really not to
do. And there's a lot of reasons why this is bad.
One that, obviously, this is a system dialogue which drops the user out of their game. It's
better than just quitting without warning, admittedly, you know, because at least the
user hasn't lost data and lost the state here. But not by much. It -- just don't do it.
So here is our back button recap. And believe it or not, there have been internal discussions
about this, and debates. >>Ian Lewis: Ad nauseam.
>>Dan Galpin: Yes, exactly. But this is the basic theory of back button
in Android games. In a dialogue, dismiss the dialogue. In a
UI, whenever possible, move to previous screen. In game play, either pause or do one of the
following: Show an options dialogue, move to the previous screen. And make sure that
they haven't lost any state. And at the initial UI screen, you can just dismiss the app. There's
no need to put up a big screen that says, "Do you really want to quit?"
>>Ian Lewis: Do you really want to quit the title screen? This is an awesome title screen.
>>Dan Galpin: This is an epic title screen. >>Ian Lewis: Exactly. But the most important
thing is, never lose progress. >>Dan Galpin: Never.
>>Ian Lewis: Never allow the user to lose progress. That would suck. To a certain extent,
that also means don't lose progress in terms of needing to go back and load for 30 seconds,
which sometimes you can't do much about. All right.
Number 4, respect the life cycle. We're going to illustrate the life cycle problem
with a little story. So wake up early in the morning. First thing
I do is reach for my phone. Can you get a little gaming in before work? When I'm going
to go to work and play for games. But let's pretend this isn't me. This is some other
dude. So, right, on a roll. Everything's cool. Totally
lost track of time. Oh, no, I'm going to miss my bus.
So really quick, throw on my -- my work clothes, which totally look like this, and jump on
the bus, head off to work. Now I'm giving a presentation to my boss. Everything's going
well until I've got to check something on my phone; right? Exactly.
Pull that baby out. Turn it on. Oh, my God, what's going on here?
It's not just that it's playing music. It's playing music and the phone is locked. And
now I'm really stressed out and I've got this lengthy PIN code that I need to enter and
I can't even remember what it is; right? So everything sucks, my boss thinks I'm more
of an idiot than he already did. I've just ruined my whole day.
What's the problem here? Well, the issue is that the life cycle here
is complicated. Not only is it complicated, it's varying slightly from OS to OS, none
of the delivery order that you're seeing here is guaranteed. In fact, it is changed in Jelly
Bean because -- (Clap) -- we told them to. [ Laughter ]
>>Ian Lewis: So the problem is, you lock your phone, and the app gets an onpause.
And then it gets an onstop at some point. When you -- and, actually, the really great
thing is, on Honeycomb and ICS, there were some cases where while the phone was asleep,
you would get an onresume. We didn't cover that here. But sometimes that will happen.
Then the user goes back and presses the lock button again and the phone tries to wake up
and sends the foreground app, an onrestart, onresume.
Now, you might be thinking at this point, who's the foreground app?
You would be justified in assuming that it's the app in the foreground, which is the lock
screen. Wrong. It's actually your app because until Jelly
Bean, the lock screen didn't count as an application, it was sort of a random overlay.
So what will happen is your application thinks that it's woken up and starts, you know, playing
music or doing whatever, but it's actually being hidden by the lock screen still, and
that's a really, really annoying behavior. There's actually a very, very easy way to
fix this. And forget about all this life cycle stuff because it's difficult. There are edge
cases, it's incredibly annoying to get right. All you need to do is this: If your application's
paused, if your game is paused, stop playing the sound. And when you want to start playing
sound again, what do you look for? Not some Android life cycle, you look for the game
getting unpaused which requires some sort of user activity, right? So the user hits
a button to take you out of pause and go back to game play, that's when you restart the
sound. It turns out this is great for two reasons: First, it avoids all this nonsense.
Second, it turns out it's a great user experience to leave the app and then when you come back
in it's paused, so you don't just get thrown right back into game play before you're prepared.
Of course, hitting lock screen isn't the only way that your game can get paused or even
killed during game play. This is a consequence of being on a mobile operating system, right?
It's not about multitasking, it's not about, you know, which model we chose or how we tombstone
or anything like that, it's just the fact that your user is playing your game on a device
that's designed to let him know when important things happen like a phone call comes in.
It's designed to be put in a pocket when he needs to catch the bus. Android, by its very
nature, being a smartphone OS, is interruptible, and so you need to be completely prepared
to handle those interruptions in a way that doesn't waste your users' time.
So we said it before and we're going to recap now -- never, ever, allow your user to lose
progress based on an interruption that's beyond their control or even an interruption that's
under their control. Should we go to thing five?
>>Dan Galpin: Exactly, all right, so Ian, this is your chance to get on the synthesizer
here. Just want you to know we're using an FM synthesizer that is unfortunately -- there
we are, we needed some volume. This is an open source project, so you're more than welcome
to download it and Ian is going to give me some nice -- that's good, all right.
[ Music ] >>Ian Lewis: Howdy-doo, Dan!
>>Dan Galpin: So minimize permissions. This is an actual application on Google Play. This
is actually the list of permissions that the user has to see.
[ Laughter ] >>Dan Galpin: And, you know, like, what is
the user going to be like, gee, what am I agreeing to? Okay. That is actually from the
web interface. So what we have now is our top ten bad game permissions. Yes, this is
a top ten list inside of a top ten list. >>Ian Lewis: By the way, you can tell that
this is a Dan Galpin slide deck because we used the fire effect more than once. Totally
broke that rule. [ Laughter ]
>>Dan Galpin: Number one bad -- Number 10 -- excuse me -- bad permission for a game
to have is change Wi-Fi settings. Why are you doing this? You're turning -- you're toggling
Wi-Fi on and you have no idea whether the user has actually set up Wi-Fi and even better,
there's an intent to throw the user right into the Wi-Fi chooser. So don't do it. Receive
boot completed. Okay, admittedly there are some games that are resource management kind
of games and they really want to make sure they can constantly set alarms, but in general
most games don't need to do this unless they're trying to spam the user with something. Just
please don't do this unless you absolutely have you have to. Probably the only good use
of actually starting your game up is because you want to set an alarm. And that's pretty
much it. You want to make an alarm persist across a boot. Do very, very lightweight stuff
here. The real key thing is, whatever you do, do not have a consistently running service
that makes a network connection and sucks the user's battery down. And we'll talk about
that a little later. >>Ian Lewis: Unless you're making a game for
me because I love it when my game notifies me that my cow needs to be clicked, I would
forget to click that cow. >>Dan Galpin: Yeah, absolutely. Not to mention,
it's really nice, it helps to keep your hand warm as the phone's radio is constantly being
kept on in your pocket. All right. Query running tasks. Why does a
game want to spy other tasks? There are a couple semi-legitimate reasons for this, but
most of the time, your game doesn't need to know what other tasks are running.
Obtain fine location. Okay, now, there's a lot of people, like, I have a location-based
game, if you have a location-based game, if your game actually maybe has a change in it,
if the user walks into their local coffee shop, then, yeah, obtain fine location is
cool. For most games, users are concerned with analytics, they want to know approximately
where people are playing their game, they want to know a little bit about the demographics
of their marketing. Obtain fine location is just kind of creepy and it requires firing
up the GPS, using a lot of battery. Don't do it, course location is good enough.
>>Ian Lewis: A lot of people will come back and tell us, well, my ad network required
that. You know what, no. Because, you know what, this guy does not need different ads
than that guy, all right? [ Laughter ]
>>Ian Lewis: This is not the way things work. So course location is fine for that.
>>Dan Galpin: Read system log. Now, I've got bad news for you guys. If you haven't watched
some of our other presentations, read system log actually is gone as of J. There is no
more read system log that you can get. However -- however -- J allows you, without a permission,
to read the system log for your own app. All right? C'mon, this is really cool stuff.
[ Applause ] >>Dan Galpin: So the good news is no creepy
spying on what the user is doing by turning on their read system log permission. And at
the same time you can still get to the useful logs you need to help your debugging if the
crash recording and all the stuff we have on Google Play isn't enough.
All right, directly call phone numbers. We've seen this in a lot of applications. I'm like,
seriously, there's an intent. Fire off and call a phone number. Why would you actually
use this permission? That's just like -- like do you really want the game to pop up something
that directly -- I don't get it. All right. Read and write contacts and calendar.
Now, admittedly, there are some uses, but most of them, 99% of them can actually be
done with contact choosers and contact figures, you don't actually need to have the contact
permission if you just want to have the user fill in a name. The only reason you need this
is because you need to do something like spam every single user, or even worse, go and read
their contacts and suck them into your own service and use them for nefarious purposes.
And remember, these are not things that we're saying you can't use. What we're saying is
if you use these things, you're going to really reduce your chance of ever being featured.
Okay, so this is really the key thing about this list is that we're going to take what
you're doing reading the user's contacts and calendar, and unless you have a really, really
good excuse, we're not going to feature the app. That's what the team is going to do.
>>Ian Lewis: I just got a reminder, it's 9:30 a.m. Click cow.
>>Dan Galpin: Oh, yeah. [ Laughter ]
>>Dan Galpin: Reading and writing bookmarks. Super creepy. I want to go and check out --
>>Ian Lewis: This is eastern European porn site stuff, people.
>>Dan Galpin: Do you really -- does a game really want to know the sites that someone
else -- that's awful. And writing to the bookmarks is even worse. Like wait, where is that super
annoying site and how did it get to my -- so, you know, look, unless you have a -- I can't
think of a legitimate reason for using this, which is why it's number three, but you're
going to have to justify it seriously to the editorial board if you want to get a game
featured with that. Display system level alerts. This is the way
you make your app do creepy stuff and pop up on top of other applications. And it's
just not good. There's a very, very good chance your game has no possible useful way of doing
this. Use the notification system we have built into Android. That's what it's for.
And then finally, our number one top ten bad permission that is likely to get you not featured
is send and receive SMS. [ Applause ]
>>Dan Galpin: And first of all, so receive SMS really sucks because it actually allows
your app to filter every single SMS message that comes into the device. Awful, awful,
awful. As a user, I'm like no way am I downloading that app. Okay? And then send SMS, well, that
allows you to bill people without them knowing that, isn't that awesome? So, yeah, seriously,
if you ever want to get featured and this is there, I mean, like the chances are basically
zero. But there is a way, if you really want to allow the user to share to all their friends
over SMS, use the intent. There's no permission involved and the users will thank you.
All right, so there we are, our top ten list of bad permissions for games to not get featured
on Google Play. >>Ian Lewis: All right.
[ Applause ] >>Ian Lewis: And we're only half done, folks.
But we did sort of front-load this thing because we thought you'd all be gone by this point.
So item six, ready? There is no item six. [ Laughter ]
>>Ian Lewis: Like two guys got that. Why did you do the hat? That's so unfair, you upstaged
me with your Cruella De Vil pimp hat. >>Dan Galpin: Hey, it was Pride last weekend
here in San Francisco, okay, they were selling these all over the streets.
>>Ian Lewis: Pretty amazing. >>Dan Galpin: And it does say on my I/O tag
"wears funny hats," there we are. >>Ian Lewis: Good point. Well, actually, we
brought out the funny hat because -- yeah, this is the boring, freaky part. We're in
San Francisco, Dan drives a Prius. >>Dan Galpin: You know, not everyone needs
to know that. There are at least two or three Google employees who do not drive Priuses.
>>Ian Lewis: That's true, I drive a '95 Integra that doesn't pass emissions. That's the kind
of guy I am. Environmental policy aside, it's important to be green on your app on the phone.
It's important to conserve your users' resources. You're game developers, you want to make the
coolest game possible, you want to monetize and do some analytics and drive engagement,
but these are portable devices, they have limited capabilities, they have limited resources.
Your battery, your network bandwidth, your memory and storage are all precious, precious
commodities that your users try to maximize at all times. And because users try to maximize
these, we give them tools to understand what's going on. And if you haven't already, you
will find that users use these tools all the time and they watch your game. And if your
battery usage is high, if you're always on the network, if you've got long-running services
in the background, they will find out and they will publicly shame you off and on Google+.
APK expansion files. See, what will happen is Google Play drops your APK expansion on
the SDK card, which is cool, and then a lot of people say, you know what, I actually had
that all packed up into one file because the man wouldn't let me upload more than two files.
So I'm going to go ahead and unpack that so that I can actually use it. Oh, but then,
wait, I've just used up a bunch more storage so my policy's going to be let's delete the
original APK expansion file. That seems like it would make a lot of sense, but it does
not, three times, you see? See, we're so bad. The problem here is that now you've unpacked
your APK expansion file, you've left all this junk over the user's SDK card and the expansion
file is gone so what does Google Play do? What every sane system would do, dude, your
file's gone, want 'em back? [ Laughter ]
>>Ian Lewis: So now instead of a gig or whatever it was, you've got two gigs and you've got
some very unhappy users. Unfortunately, the way this works is you have
to use your APK expansion file in place. Now Dan's written a bunch of samples that -- do
you notice, by the way, every time we talk about sample code, it starts "Dan's written,"
and every time it's something I did, it starts "I was so drunk." This is exactly why he's
the senior member of our team. >>Dan Galpin: Because I'm a month older. There
we are. >>Ian Lewis: That's true. So what you want
to do is if you have your own binary blob reader, you have pack files or whatever, go
ahead and use that. If you don't, we do have some samples that show you how to use an APK
expansion file or even any type of zip file as a mountable file system and that can actually
make things easier for you. >>Dan Galpin: The thing is an APK file is
really just a zip file. A lot of people are like, well, I can't put it in my APK, so it's
not going to work. I'm like you can just put another zip file on the drive and you can
do exactly the same thing. In fact, a lot of people are doing this. In fact, they figured
out that when they're using something like unity, which normally pulls all of its resources
out of the APK file, all you have to do is point to unity and say actually my APK file
is actually the second thing that I download and then all of a sudden unity will pull all
the files out of that. And there's actually a tool that someone has made that takes all
of those unity files and pull them over to the second file. So it's not hard. But if
you don't have it built into your tool, I have a couple of things that you can look
at. Look at the APK expansion file libraries, there's actually a zip resource file that
I put down there. There's a content provider example, so if you really want to go all the
way Android and you want to store content that's referenced using an asset content provider,
it's actually all there in sample code for you. So no excuses, man, okay?
>>Ian Lewis: All right, we ready for seven? >>Dan Galpin: We're ready for seven.
>>Ian Lewis: This is going to be so good. >>Dan Galpin: Oh, yeah. Oh, yeah. So one of
the things that happens when you sign up for Google Play is that you're actually asked
to look at some things like what you should do and what you shouldn't do on Google Play.
If you think about Google Play is it is this ecosystem where OEMs and developers and carriers
all get together to make sure there's one awesome place to find great stuff.
>>Ian Lewis: A lot of times we do sort of envision in our heads Google Play is like
the old "Star Trek" when Spock would play this three-dimensional game of chess except
instead of Spock, it's Andy, and that's actually totally downplaying the complexity of the
system. There's a lot of players in the system and it all combines to give you 400 million
devices to sell to, but it does come with some restrictions.
>>Dan Galpin: And the real key thing is we want to make sure you can publish once and
you don't have to go and hunt and to find all sorts of places and rules and different
sets of rules to publish your apps, so here are our rules and they get you to the largest
number of devices. All right. >>Ian Lewis: The three commandments.
>>Dan Galpin: The three commandments of Google Play. One, thou shalt have no payment providers
but Google Play. This is basically pretty simple. You're listing on our service. Don't
confuse users by having them input all sorts of different information, sending them to
different places, billing them without their knowledge. We want one straightforward way
that users understand they're paying for content. >>Ian Lewis: We would also like to be able
to continue paying for Google Play so that's -- we do have a bit of a selfish motive here.
And these rules aren't -- >>Dan Galpin: We want carriers to keep putting
Google Play on our devices. That's probably the most important thing.
>>Ian Lewis: Yeah. So, sir, you in the back, with the golden cap, put that away.
>>Ian Lewis: Two, thou shalt not upload an app that downloads other apps. Now, because
the main goal of Google Play is to be a place where people go to find content and it's not
a place to distribute your app store. If you want to distribute your app store, distribute
it somewhere else. Android is an open platform, okay? The second thing is if you're actually
installing other apps, it's a really bad user experience, you'll find out. So, yeah, don't
do it, and it's a good way to make sure things happen badly with our enforcement team.
All right. And then finally, thou shalt not bribe thy customers for five-star reviews.
>>Ian Lewis: For that is hateful in my sight, sayeth me.
>>Dan Galpin: That was good. So don't provide incentives for specific review scores. Google
Play will not feature an app that incentivizes review scores, partially because it's hard
to tell what people actually think of your game when they're being paid to rate it five
stars. Besides, it's actually impossible for your game to find out what score a particular
user gave you. So promising to pay for a specific score is kind of dishonest. So at the same
time we don't want to discourage apps from asking for ratings. The right way to ask for
ratings is to be upfront, honest and sincere. Ask users for their candid feedback. If you
want to, you could incentivize your user to leave a rating, just don't ask for a specific
rating. You could also ask for a specific rating without offering an incentive, that's
within the letter of the law, but not really the spirit. The whole point of a review is
to get honest feedback so you can improve your game.
>>Ian Lewis: So here's some examples that we pulled from actual games and simply, you
know, altered a little bit to protect the innocent. And so when we did this presentation
for our team, we got two major pieces of feedback. One was the Australians thought that thing
six was racist. And two was -- you don't even remember what thing six was so we didn't -- you'll
wake -- the coffee will kick in in a little bit. Two was we see these -- these example
dialogue boxes, but there's no real feedback is -- as to which ones are good, which ones
are bad and how good and bad they are. So I've enlisted my baby daughter to help out.
"Thanks for playing, please take some time to rate this game on Google Play. We want
to know what you think." Baby daughter says, "Oh, Daddy, that's so great!"
>>Dan Galpin: "Did you enjoy this game? Rate it five stars!" Whew.
>>Ian Lewis: Baby daughter says, "That's a little sketchy, Daddy."
>>Dan Galpin: Even worse, "Having fun? Your five-star rating helps us to keep this game
updated!" Oh, sad daughter! Or how about this, "Want more GalpinBux? Rate
this game five stars and get 100 GalpinBux right away and all of your friends will think
you're cool!" Bad! So there's some shady characters out there
that will claim these rules don't apply to them or they're not enforced or they have
some sort of arrangement with Google that allows them to use a third-party payment processor.
This is not true. Do not believe their lies. All right? So we are giving you the straight
story here. And that takes us to point 8. >>Ian Lewis: Awesome. In-app payments are
unfortunately easy to get wrong. Now, our in-app payment system seems like it should
be relatively easy. Okay. Customer decides they are going to buy something, they hit
the big button, delivers the thing, and the customer receives it and everything is cool.
They are super happy. >>Dan Galpin: Thanks, bro.
>>Ian Lewis: But what really happens is a little bit like the FedEx scenario here, but
you are asleep. Sometimes your app will be sleeping when this message arrives. In that
case, normal real world -- okay. Normal real world delivery companies have a policy, right?
They are going to try to deliver and if there's somebody home, like your roommate, they will
be like, oh, can you sign for this? Yeah, totally. And then later on your roommate gives
you the package and you're, like -- >>Dan Galpin: Thanks, bro.
>>Ian Lewis: Excellent. But what if your roommate is this guy?
[ Laughter ] >>Ian Lewis: So here's what happens. Very,
very common in games because so many games use native libraries. Game is going to be
written with a big game piece and this little billing service piece that you tacked on as
an afterthought because our documentation said that you had to. There is big shared
library that both of those pieces are going to talk to. And that is totally fine as long
as you're launching with the expected process. Right? So the user has clicked on your icon
in a launcher, launcher sends action main, game starts. It starts up the shared library.
Service starts. Talks to the shared library, listens for billing messages. Billing message
gets there. It does whatever you do in the game to acknowledge billing and fulfill it,
and everybody is happy. But sometimes things don't go as planned because when the message
gets there, your app is no longer available. Why? Why would that happen? It's conventional
wisdom to think this is because our billing process took way too long and that's actually
untrue. Not because our billing process is lightning fast, although it frequently is,
but because we actually just canceled the whole thing after what is it? 45 seconds?
>>Dan Galpin: These are, for the most part in your applications, these are synchronous
transactions. >>Ian Lewis: Why is your app asleep? The first
culprit is Google Play itself. In order to the in-app billing, we have to launch Google
Play. Google Play is not maybe the slimmest service in the world and, in general, games
aren't either. So when two large processes start on the Android device, the OS starts
to freakout. Like okay, one of these things has got to go, right?
>>Dan Galpin: One of the things to note is your application will get long memory and
it has the ability to eject stuff at this point and try to keep itself alive. But, you
know, a lot of game developers don't really want to do that. They are like, life cycle,
whatever, we will let ourselves die. That's what happens. We go, you're the biggest thing
going and we can get rid of a lot of space to allow Google Play to actually run.
>>Ian Lewis: Ironically enough, launching the in-app billing kills your process, and
then when you come back from in-app billing, your process should restart but you frequently
don't take care of that correctly. This is a little unexpected. But that aside, there's
actually another really good reason for your app to be asleep when a billing message arrives.
I would like to illustrate this point with a small shot of a portion of Dan's desk.
[ Laughter ] >>Ian Lewis: A lot of people have multiple
devices. And Google Play policies allow you to buy something once and use it on multiple
devices. Customers love this. I love this. It's a great policy. But what it means is
if I bought something on my phone, my tablet is going to get a billing message. And since
my tablet probably isn't even on, the app that's supposed to receive it is probably
asleep. So what happens? Well, of course you will wake up. We need to deliver this thing.
So Google Play is going to try and wake you up. But it's not going to try to wake up your
whole app. It just wakes up the service. The problem is, when the service wakes up, you
haven't written it to initialize all of the other code. You wouldn't want to. Right? A
lot of times initializing the shared library, loads your resources. You are doing a lot
of expensive work. If the shared library is not there -- and by shared library, that's
a catch-all for your in-game message system, unity messages, shared memory between yourselves
and game. Anything that's not persistent. That will kill everything.
>>Dan Galpin: I want to make it clear that I actually didn't put the fire effects in
this presentation, okay? >>Ian Lewis: I thought you did.
>>Dan Galpin: Only one of them. >>Ian Lewis: Then I got a little excited.
I want to be like Dan. A lot of times people say that's not a problem, right? I read the
documentation. This isn't an issue. You guys are reliable. If I don't acknowledge your
receipt, then you're just going to keep calling me back, right? Which is somewhat true. If
you do not acknowledge a billing message, we will keep calling you back until it gets
acknowledged. Let's leave aside the fact that some developers will acknowledge the billings
message anyway without successfully delivering it. Those guys need to get their act together.
Waiting for our billing message to be re-sent has two issues. The first is, because we don't
want to completely spam the users device, we use exponential back-off. Since you have
gotten yourself into a situation where your app needs to be running in order for the billing
message to be received, you're in a crap shoot here because the user has to have launched
your app in order for that billing message to be received and the billing messages are
comings at a slower and slower rate. It's very, very unlikely that they are actually
going to have the app open at the correct time. Especially if they just closed it in
frustration because they think that you cheated them by not delivering the goods that they
just purchased. But there's a second and more compelling reason to be careful about this.
And that is, during this entire time that we are essentially leaving post-it notes on
your door. Tried to deliver, we'll be back tomorrow. Tried to deliver, adult must sign.
That whole time the user has already been billed. So let me just emphasize that. The
user has already been billed. We billed the user when we sent the first acknowledgment.
Why? Otherwise it would be trivial for an user to buy something and then block your
port so you couldn't send an acknowledgment. Then we would be like, oh, it never got delivered.
Meanwhile you are like, oh, I guess it got fulfilled. The user is, like, hee-hee-hee.
The user will see this show up on its credit card. If you don't fulfill it immediately,
they will think that you cheated them. You sort of did unintentionally. This turns into
a support call for you. Often a support call for us. Overall a poor experience. Be very,
very -- >>Dan Galpin: Bad ratings. That's the key
thing. Bad ratings keep your app from being featured.
>>Ian Lewis: Absolutely. What should you do? The right way to do this is to be reliable
for yourself. We took care of reliably delivering this thing all the way across the Internet
through miles and miles of fiber optic cables and harsh vacuous space, the least you can
do is reliably deliver it from one piece of your app to the other. The right way to do
this is persisting it. When your service wakes up to receive a notification from the billing,
it should persist that to some sort of storage. I don't care if you want to use a file, SQLite,
or whatever, then send your in-game message to say, they, go check your mailbox. Your
app will check that and see that the message came in and deal with it. If your app was
sleeping at the time, then, fine, you don't get the notification that says, hey, go check
persistent storage. But the next time your app starts up, the first thing do you is check
for persistent storage. A purchase came in. Congratulations, you have a hundred more Galpin
bucks or whatever it is you are giving away. The user can immediately see that they did,
indeed, purchase and get value for the money that they just spent.
>>Dan Galpin: Let's go quickly on to 9. Let's take a quick talk about testing. We have a
lot of devices and the problem with lots of devices is people are trying to figure out,
how do I test with this vast ecosystem that we have out here. But the truth is, most of
this stuff is actually really straightforward. Input devices, there are not that many input
devices on Android and you should support as many of them as you possibly can. Form
factor, it's pretty straightforward. We don't actually have that many different form factor
styles in Android. You have to support a series of aspect ratios between 69 and 133. And it's
not the end of the world for most titles if you started off the design of the title to
support that. If you decided you will support one aspect ratio from the beginning and then
you are, like, oh, my goodness, I am now going to Android that I have to support four, essentially,
then this is going to be a rough transition for you. It's good to start off designing
for that. Even if you haven't designed for it, there are things that you can do that
are fairly straightforward to make it look like you designed for it. OS version, that's
pretty straightforward. The OS versions don't differ all that much. It's pretty easy to
get. Here we get to the hard stuff. The driver stack and the GPU hardware. There's kind of
two things to look at. One, of course, is -- this may be hard to believe, there are
sometimes bugs in drivers. I'm sure none of you have ever experienced this on any other
devices, but it actually happens. GPU hardware differs. Let's talk quickly about the most
common GPUs you will see in the Android world. We have Adreno, PowerVR, Tegra, Mali, Vivante,
and Broadcom. Many of you probably haven't heard of the last two, but they are in many
devices as well. All of them essentially work differently than PowerVR. So if you all go
and say I just tested on that second one, if you only test on the Galaxy Nexus, if you
only performance, profile and optimize around the Galaxy Nexus, you will be sad. Because
on PowerVR usually you get a lot of performance by sorting things like by materials. You pretty
much want to ignore sorting things by geometry, depth, and complexity. On every one of these
platforms, you get an enormous performance boost by doing that. you want to have your
engine and renderer to be able work both ways. First of all, performance, there's that element.
Also we have several different texture compression formats. If you want the highest possible
performance, and all of these devices are ultimately fill limited. Then of course you
want to use the best texture compression possible. So for your non-alpha textures that are actually
fairly light photographic, you can use ETC1 on every single one of these platforms. But
when you get into things that are using alpha, then you're going to be stuck going to one
of the proprietary formats or using a shader and 2EC1 textures which will slow things down.
These are decisions you have to make as to how optimal it is. You want your game to be
how necessary it is to make these optimizations. We actually support multiple APKs based upon
texture compression formats. So you can have a separate APK with a separate APK expansion
file. There are ways to tackle this problem. And again, it may not be necessary for your
title. The thing to do is make sure you have one of at least four of these, probably the
top four as they represent the largest majority of devices out there to test on. And that's
just the most important thing. If you are doing a 3D game -- if you're doing a 2G game,
chances are you may not notice. But if you are doing a 3D game, it's important to make
sure that you work with these different drivers. >>Ian Lewis: Excellent. Thing 10, I took a
little bit about play listings. So let's say that you have done everything that we have
asked. You've got a great game, great ratings. You didn't screw up the in-app billing. You
didn't do anything shady with your permissions and we totally want to feature you. One problem.
We need to actually get you into the store. And where a lot of people end up having problems
is on the listing itself. Now, it may not be obvious but when you upload the gigantic
graphic that we use on our web site, you are also actually uploading the little itty-bitty
graphic that we use on the device. >>Dan Galpin: It looks gruesome in both modes.
>>Ian Lewis: It really does. We chose this graphic, A, because the game is featured this
week. B, because it does have a serious problem in that the contrast here isn't really great
enough for you to be able to read the title Shane Reaction when that thing gets shrunk
down to about an inch across. What I will usually tell people to do is attach this to,
like, Gmail or something that does a thumbnail preview. Get up from your desk, walk about
six feet back, look at it on your web browser and ask yourself, can you still read the title?
Does it still look good? If it doesn't, then it's not going to look good on a very small
form factor device. So be careful to give yourself enough contrast. Use a large enough
area for the title. And be a little careful of subtitles. You can see for instance on
Real Soccer, although they did a great job of making the RS and the Real Soccer big enough
to read -- >>Dan Galpin: Dude.
>>Ian Lewis: Oh, wow. >>Dan Galpin: That was a software update that
came right in the middle of our presentation. >>Ian Lewis: Thanks Google. All right. So,
yeah, when you look at that on the small device, the subtitle gets nearly lost. We usually
tell people that if you're using about 50% of the surface area of your graphic for your
logo, that's probably going to show up okay. If you are using less than that, you will
want to do some serious testing to make sure that it's not going to become Illegible when
it gets tiny. Speaking of feature graphic, sometimes people
omit them entirely. Like this famous developer, who apparently knows nothing about Android.
At least a few people recognize this game. So the problem with this now is that since
he didn't upload a web feature graphic, we are actually unable to feature the game at
all because we don't have anything to put in that space. You might say, oh, can't you
guys use some other graphic, wouldn't that be smart? Sure, but you know how software
works. We totally don't have that pipeline. Some day we will, maybe. But not today.
>>Dan Galpin: Besides, would you want to choose one of these random screen shots? It doesn't
make any sense. >>Ian Lewis: If you don't have a graphic here
on your web store listing, you're not going to get featured. You're also not going to
get featured if your description is terrible or if you use this space to do some key word
spamming or if you've got, all capitals, super excited stuff. Or if you say things like now
the hit game on this other platform finally comes to Android because it sucks less or
something, you know. [ Laughter ]
>>Dan Galpin: The feature team loves that. >>Ian Lewis: By the way, if you've got a screen
shot here or more commonly a game play video that ends with a spinning shot of some other
device with a now available on some other store, that's sort of a party foul. You don't
want to do that. We won't feature you. We will get on the phone, can you upload a different
video. But save us both some time and don't do that.
>>Dan Galpin: Another thing to note here. There are rules against spamming and key word
spam in here. So you should actually go through the Google Play terms of service because one
thing you don't want to do is say, if you really liked blah game and blah game, and
blah game, you should like our clone of it. First of all, it looks kind of awful to do
that. And second of all, it is key word spam as far as our team is concerned. And it can
actually get your game, believe it or not, suspended. So it's actually a very serious
rule. They don't want people to try to leverage other games' key words.
>>Ian Lewis: The other thing about this description is, although we don't want you to key word
spam or use other service optimization techniques, there are an optimization that will boost
you in the search ratings. That is to make sure that your description is localized. If
your description is localized into the users language, then that description will appear
higher on search results compared to similarly-ranked queries that are not localized. People say
what should I localize into? And the most common response is going to be EFIGS-CJK.
English, French, Italian, German, Spanish, Japanese, Italian, Korean. But if I had to
pick two of these, the first is English because, you know, we're white dudes. But second if
you can only pick one non-English language, you will probably best -- now, of course,
this isn't advice that is universally applicable, you would be better off with Korean because
Korea loves Android. It's a huge, huge market for Android products and Android games. So
you go there and then maybe Japanese. >>Dan Galpin: Japan is pretty awesome. It
depends on the title whether it is culturally important. Most importantly, point 11.
>>Ian Lewis: Because it goes to 11. >>Dan Galpin: Make a great game. I know, I
know. So obviously as we said before, editorial process. Ultimately, making awesome games
is the way to get featured. But if you do all of those other things, you're going to
not get featured. So we've told you what not to do and now go out, make awesome games.
Don't let these things block your games from getting featured. We wanted to thank you for
coming. We are out of time. [ Laughter ]
[ Applause ] >>Dan Galpin: We actually don't have time
for Q&E. Ian and I will hang out after the session a and answer your questions individually.
Thank you all for coming to ten things Android game developers should know.
>>Ian Lewis: Don't forget to catch our YouTube show every Friday 2 p.m. It gives us an excuse
to drink beer and you information for games we are looking at featuring and why or why
not they might not pass our review process.