Galpin, and with me is Bruno Oliveira and Todd Kerpelman. And today, we're going to be
talking about the top seven developer mistakes people
make in setting up Google Play services. BRUNO OLIVEIRA: So our show
today is going to be entirely about mistakes. DANIEL GALPIN: Your mistakes.
BRUNO OLIVEIRA: Exactly. DANIEL GALPIN: So before we
start talking about your mistakes, let's do a little
summary of what Google Play game services actually are. This, of course, is Google's
backend to do achievements and leader boards, real time
multiplayer, cloud save, as well as some anti-piracy
features that are on Android, to help you game developers
implement best-of-breed services scaling to
Google scale. BRUNO OLIVEIRA: Exactly.
And I think especially with a
real time multiplayer, I mean, this is one big piece of
infrastructure that we are taking into our own hands so
that you can actually focus on what makes your games awesome. DANIEL GALPIN: Yeah. Instead of writing all that
boring infrastructure code, let us write the boring code. BRUNO OLIVEIRA: We like
boring stuff.
DANIEL GALPIN: Yea, exactly. And we like thinking about
scale, and you guys can think about fun. And I think that's a good way
of dividing things up. BRUNO OLIVEIRA: Yeah, exactly.
So with that, let's dive
into our list of top 7 developer mistakes. First of all, let's talk about
using the JAR file instead of the library project. As you know, when you're using
Google Play game services, you have to include the Google Play
services library project. And then if you're using our
samples, you have to include the BaseGameUtils
library project.
The mistake that some developers
do is thinking that library projects actually don't
mean anything, and they can just include
the JAR files. Well, JAR files are just
classes, while library projects are something that
wraps classes and resources into the same bundle. So the worst thing is that they
won't really notice if they make this mistake. DANIEL GALPIN: Yeah.
We don't actually go and
validate the APK to make sure the resources are there that
you're actually referencing when you're doing one
of these projects. That JAR file actually contains
references to resources that we're providing
in that library project, and if you don't put those resources
in, there's nothing in the compiler, there's
nothing in the deck, so there's nothing in the packager
that's actually going to catch that mistake. Who going to catch
that mistake? Your users are going to
catch that mistake. BRUNO OLIVEIRA: Exactly.
And you might not even catch it
during testing because the only place where you're going to
see this mistake is if the library actually wants to use
a resource from that bundle. And that's going to happen,
for example, when the user can't sign in and it has
to show a dialog box. So ironically enough, when the
library is trying to show an error message, then it's going
to figure out that it doesn't have that resource. And then it's going to have to
show an error message saying that it can't show their
message, and it's going to look something like that.
I mean, that's everyone's
favorite screen. DANIEL GALPIN: Absolutely. And the best part is it's
not a crash in our code. It looks like a crash
in your code.
BRUNO OLIVEIRA: It's going
to totally look like it's your fault. DANIEL GALPIN: Or
your mistake. BRUNO OLIVEIRA: Or
your mistake. DANIEL GALPIN: So there's
mistake number seven.
BRUNO OLIVEIRA: Exactly. DANIEL GALPIN: So I think we
should take it over to Todd Kerpelman, who is in Studio
I. Todd, are you there? TODD KERPELMAN: Hi, I'm here. Yeah, sorry.
I'm getting a little
tape delay. I'm kind of far away. But I'll try and stay current. BRUNO OLIVEIRA: And now we're
going to use our confidential teleporting technology to pass
this laptop all the way over to Studio I.
TODD KERPELMAN: All
right, thanks. BRUNO OLIVEIRA: There we go. That worked. Is it the same laptop? TODD KERPELMAN: It is, in
fact, the same laptop.
DANIEL GALPIN: That's our
Pixelante at work here. TODD KERPELMAN: There you go. This is a pretty laptop. That wasn't a product plug.
It really is a nice laptop. DANIEL GALPIN: It is. It's beautiful. TODD KERPELMAN: So our next
mistake is using the Google APIs Console instead of the
Google Play Developer Console.
And let's explain why this
matters and why you care. On the backend, we've got a set
of games services, right? And we also have on their
backend a whole bunch of other API-related stuff. BRUNO OLIVEIRA: And that's
a technical term. TODD KERPELMAN: That's
a technical term.
That's what we call
it, API stuff. So the other API stuff is
generally set up using the Google APIs Developer Console. If you have added any Google
services in the past, generally on the web, but
certainly other devices, you may have seen this Developer
Console. It's at
code.Google.Com/api/console.
Game services is generally
set up-- oh, sorry. And yes, this is generally where
you would set up your OAuth 2.0 Client IDs, you could
review your quotas, you could add other team members
to your project, and so on. The game services are
generally set up and administered through the Google
Play Developer Console. This is the developer console
that you would be used to visiting if you're an Android
developer, but iOS and web guys, you're going to
have to go here too.
At the Game Services Console,
this is where you would set up your leader boards, your
achievements, and then also where you would associate
these leader boards and achievements with the
OAuth 2.0 Client IDs that you set up. So how does this work? In general, the Game Services
Developer Console manages all this for you. I go, I visit the Developer
Console, and I would say I. Want to link an application.
I'm going to link an iOS
application or an Android application or a web
application. When I do that, the Play
Developer Console automatically sets up an OAuth
2.0 Client ID for me. I don't need to go and visit
the Google APIs console. When it sets up that client
ID, it also sets up an association to that client ID
so that when I log in using that client ID, the service
knows, OK, this is associated with the leader boards and
achievements that the developer has created.
If I were to go and visit the
Google APIs Console, because maybe I'm a web developer and
this is what I've done in the past, and I know all about
creating client IDs, I'll be able to create an OAuth 2.0
Client ID, but on the game services side, it has no idea
that I've gone and done this. And so when a user signs in to
this client ID, the system is going to get confused and say,
well, it looks like a valid login, but I have no
idea what set of achievements this goes with. And you'll run into probably
some funky and hard to diagnose errors, which
are my favorite. There's one exception to this
rule, which is if you have created any Google APIs for your
game in the past, when you create a new project, a
brand new project, on the Google Play Developer Console,
it will give you a chance to say, hey, I've already created
some services, maybe using Drive or something,
with this game.
And during creation time, it
will give you a moment to specify that project, and it
will go and create some associations during project
creation time. But this is the only
time that works. If after I create this project,
I then go and visit the Google APIs Console and
create another client, maybe, I'm going to cause confusion. So kind of a confusing subject,
particularly because at some point, you may actually
need to go and visit the Google APIs Console to do
sort of some weird, tweaky things, like you need to change
your OAuth redirect or something, and so it
does get confusing.
But as a general rule, when at
all possible, do everything from the Google Play Developer
Console and forget that that old one exists. DANIEL GALPIN: It was our
opportunity to make things easier, allow you to do
everything all in one interface, and I think for some
people it actually made things more confusing. And one other thing that's
important to know is just understanding how OAuth works
is a little bit helpful in understanding why you have to do
some of the things you have to do in setting up your game
for Play Game services. BRUNO OLIVEIRA: It's important
to notice that if the same feature is available through
the APIs Console and the Developer Console, you should
always prefer to do it from the Developer Console, because
that's going to set up your game in the right way
to use your API.
TODD KERPELMAN: It also doesn't
help that we call the Developer Console the
Developer Console. That sounds very generic. BRUNO OLIVEIRA: And the API
Console the API Console. TODD KERPELMAN: Yeah.
I mean, really, we should be
calling it the Games Console or something. DANIEL GALPIN: Exactly. We've got to have some slick
name for it, like we have for this laptop. TODD KERPELMAN: We'll
work on that.
So our next common mistake that
developers run into is getting throttled. DANIEL GALPIN: That
sounds painful. TODD KERPELMAN: It is. It is very painful So here's the issue.
When you set up your service,
you'll probably notice, if you go and visit the Google APIs
Console-- which you generally, probably shouldn't, because we
just talked about that-- you might notice that your
quota is set to some incredibly high QPD,
Quota Per Day. And so you'll get, hey, look
you've 80 gazillion calls you can make a day. And developer's, like, great,
I'm going to make calls all the time. However, we do throttle similar
calls to a few per minute, so calls of the exact
same type will get throttled.
What does this mean? Well, if you're incrementing
four different achievements at once, that's actually OK. We have different
limits for that. And in general, as long as
you're acting reasonable there, you're OK. However, if you were to try
and increment the same achievement, say, four times
in 10 seconds or 10 times a minute, that's bad, and that
would probably cause about half of your calls to fail.
What's even more interesting is
half your calls will fail, but if you were to go and look
up your quota, it would still say, oh, you're using 0% or 1%
of your quota because that's really talking about your 80
gazillion calls per day and not mentioning the fact
that half of your calls are getting throttled. The only way you would actually
know you're getting throttled is to look for error
messages that get returned by the service and make a note
of those, or log those, or something like that. BRUNO OLIVEIRA: What if I have
a game that it's a game where I have to kill enemies, and
then I have an incremental achievement which is to kill
10 gazillion enemies? And then how do I do that? TODD KERPELMAN: That is a very
good question, and that actually brings us to
our next slide. Hey, look at that! Wow.
It's almost like you knew
what my presentation was going to be about. So we've got our incremental
achievement. That's kill 5,000 enemies. The wrong way to do it, the bad
way to do it, would be to make an achievement.Increment
call every time the player shoots an enemy.
Let's assume this happens pretty
often, and I'm shooting enemies left and right. You don't want to be making
that increment call all the time. The best way to do it would be
wait until the end of a round, or wait until a few seconds have
passed, or something like that, and then make an increment
call based on the number of enemies I've killed
up to that point. So at the end of a round, it
says, oh, look, you've killed 38 enemies, then I can submit
that increment call.
Another mistake I've seen some
developers make is constantly submitting high scores. If you're playing a game, and
throughout the game my score keeps getting higher and higher,
you don't want to be calling, hey, submit new
high score every time my score goes up. Wait until the end of
the game, and then make that one call. It is true that, I suppose,
if my game crashes halfway through, I won't get a chance
to get that partial high score, but in general, I think
you're better off.
Just wait until the end
of the round, submit that final high score. BRUNO OLIVEIRA: Yeah. If you're writing a game, and
you don't expect the game to last for five minutes,
you're pretty much in trouble, I think. DANIEL GALPIN: I would say don't
code around the fact that you expect your game
to crash regularly.
TODD KERPELMAN: Yeah. I supposed you be better off
just making sure your game doesn't crash. DANIEL GALPIN: And just to be
clear, at some point we actually hope to
make it easier. We actually hope to do some of
this packaging up of multiple increment.Achievement calls
so that you don't have to.
BRUNO OLIVEIRA: It looks like
there's room for improvement on our side there. TODD KERPELMAN: There's room for
improvement on our side. We definitely could do a better
job, both in terms of the library helping to mitigate
this, as well as letting developers
know that their calls are being throttled. Right now, unless you're
analyzing the responses that come back, it's pretty
hard for you as a developer to know.
BRUNO OLIVEIRA: One thing to
remember is definitely make sure to submit the high
score when you get an onStop, though. Because when you get an onStop,
it might be that your applicaton's going
to be killed. So in that case, you definitely
do want to make a call to that. DANIEL GALPIN: You really want
to honor the life cycle whenever possible in all these
things, avoid data loss.
But don't just keep incrementing
the high score every time you kill the next
alien, because that's just going to be ridiculous, and our
servers are going to say, down on that. TODD KERPELMAN: Right. By the way, one other issue I've
seen rarely was an issue where a developer was
constantly checking achievements. I believe to actually-- this was sort of as a weird way
of making sure they were submitting the right number of
incremental achievements, is they were constantly pinging
our server to be, like, how much achievement progress
have you made so far? OK, now that I have this number,
now I know the exact right amount to increment.
I think this was kind of a bug
that they forgot to cache the data or something like that. But if you're calling the same
read multiple times, that can be just as bad as a write. DANIEL GALPIN: The thing I
love about working with platforms is that you really
find incredibly creative ways that people tend to
misuse your APIs. So even though this may look
like our mistake, this is actually your mistake.
So do try to avoid doing
these things. TODD KERPELMAN: We're sounding
a little defensive. DANIEL GALPIN: Well, this is
a show about mistakes. We're making plenty
of mistakes.
So mistake one, we're acting
too defensive. BRUNO OLIVEIRA: Let's make
note of our mistakes. DANIEL GALPIN: Exactly, during
the show about mistakes. BRUNO OLIVEIRA: All right,
so onto the next mistake, if you will.
Number four, publishing apk but
not the game services, or vice versa. So this may be a little
counterintuitive, but an application and the game
settings are things that are linked, but they also exist
separately, so you might actually be able to publish
one without the other. If you just publish your app,
what's going to happen is that you're going to have a game
that's published, but your game settings are not. Which means that anytime anybody
tries to use a game API from you game, you're going
to go this weird error because the game settings
are not published.
You might not see the error
because you probably listed yourself as a trusted tester on
your own games where you're going to be able to use
the game's API. But then whenever anybody else
tries to use that, they're going to get an error. So it's important to make sure
that both are published. The other situation
is also possible.
You might just end up publishing
the game settings, but then forgetting to
publish the app. DANIEL GALPIN: But then people
won't see that on Google Play. BRUNO OLIVEIRA: Exactly. It's less serious than
the other scenario, but it's also possible.
So you'll definitely want to
make sure that if you're publishing your game, you want
to publish both the app and the game settings. Just taking a look at what the
screens look like, on this screen, you're publishing
the game setting. So this is the game setting
screen, And you have this Publish Game item over there. So that's publishing
the game settings.
Now this other screen is where
you publish the actual app. So notice that you are in store
listing, and they don't even have the Publish App option
over there, and that causes the actual app
to be published. So you want to make sure to do
both steps to make sure that your game can be used outside
of your company. DANIEL GALPIN: Exactly.
And people may ask, well, why do
you even bother doing this? And the reality is when you look
at the game life cycle, you're actually going to want
to do things like add achievements that your trusted
testers can see before your actual end users can see it. So in order to do that, we
actually like to create those achievements that your trusted
testers can see them immediately, and then once you
actually publish the game services with the game data,
then your real users will be able to see it. BRUNO OLIVEIRA: Exactly. Suppose, for instance, you
have an existing game on Google Play, and then you just
want to start working on the game services, but without
publishing it.
So it makes sense to have the
app published, but not the game settings. And then when you're ready to
launch the game services, then you do that. Next common mistake is signing
in with an account that isn't a tester. TODD KERPELMAN: This is related
to what we were talking about before.
If you have a set of
achievements or leader boards that have not been published,
they are only available to users that are listed
as testers. Now that means that you need
to go here in this little testing section of the Google
Play Developer Console and confirm that the account you're
testing with is, in fact, listed here among
the test accounts. Basically, if this doesn't
happen, you'll get sort of mysterious errors where it'll
sort of be like, yeah, I'm logged in, but I don't see
any game services. I don't know what you're
talking about.
These achievements
don't exist. DANIEL GALPIN: This game
doesn't exist. You'll actually end up getting
back 404-looking errors. BRUNO OLIVEIRA: It's going to
pretend that it doesn't know anything about your game.
Like, your game? Never heard of it. TODD KERPELMAN: Which is
sort of correct, right? Like you don't want random
people to try and submit achievements. BRUNO OLIVEIRA: And
probe your game. TODD KERPELMAN: And
probe your game.
And so, if your set of services,
your achievements, your leader boards are in a
testable but not published state, they can only be accessed
by accounts that you've listed here as testers. BRUNO OLIVEIRA: And notice that
even the developer who published the game settings is
not automatically a tester unless they have an account
on Google+. So if your developer account
doesn't have an account on Google+, you have to also list
yourself as a tester. So just a general rule, just
list yourself as a tester, because that prevents
those corner cases.
TODD KERPELMAN: Basically always
go to that Tester tab, make sure that all the accounts
that you're actually planning on testing with
are listed there. Because chances are, some
of them might not be. DANIEL GALPIN: And that is an
important corner case, though, to note, that if your publisher
account is Plus enabled and you try to use it,
bad things will happen. So do note that.
BRUNO OLIVEIRA: Next is another
common mistake is to mistake your client ID for
your app ID in Android. This is a pretty common one. And it doesn't help that the
Developer Console gives you the client ID because the client
ID is what you need for web and is what you need
for iOS, but for Android, it's different. So if you look at an Android
manifest file, you're going to see that metadata tag that
points to a resource file, and that resource file
has your app ID.
So the app ID that you want to
make sure is there is this numerical portion of
your client ID, so this is only digits. Now it is a mistake to use the .Apps.Googleusercontent.Com there. You only want the numbers
in there. So that's a pretty
common mistake.
DANIEL GALPIN: And the other
thing to note about this is there's a reason we put it
into a string resource. You think, oh, I can just take
that number, and I can paste it right into the metadata
[INAUDIBLE] manifest, and it won't work. BRUNO OLIVEIRA: Because it
needs to be a string. DANIEL GALPIN: Because it
needs to be a string.
And if the XML parser sees
a number in there, it'll actually turn it into
an integer. BRUNO OLIVEIRA: Very
helpfully. DANIEL GALPIN: Very helpfully. And then our services will say,
wait, it's not a string, and will do bad things.
So leave it as a string. And some people are like,
well, I have to make resources for this? But you do, and this is just
part of using it, and it'll make everything really happy. BRUNO OLIVEIRA: Plus it's much
more organized to have this as a separate resource rather than
having it hard coded into your Android manifest. It just looks better.
DANIEL GALPIN: Yeah, right. Right. Absolutely. Because people looking in the
manifest can tell that's the app ID instead of looking at the
manifest data, which also says that it's the app ID.
BRUNO OLIVEIRA: And so,
onto the last mistake we're going to cover. Certainly not the last mistake
that we're going to make. DANIEL GALPIN: No, no. Several, at least, I've
already made in this presentation.
BRUNO OLIVEIRA: So it's
using the wrong certificate in Android. This is actually kind of a deep
topic, so it's useful to have something of an
understanding of how these things actually work. On your device, you
have your game. So like any Android app, your
game has a package name.
Let's suppose it's
com.Example.Yourgame, very creatively. [INAUDIBLE] DANIEL GALPIN: It won't let you
publish that package name. BRUNO OLIVEIRA: No, it won't. DANIEL GALPIN: But this
is just this example.
Don't use this. BRUNO OLIVEIRA: Exactly. And then your game is, of
course, signed by a certain certificate, so let's just
assume that that's the certificate you're
signing with. DANIEL GALPIN: Very short one.
BRUNO OLIVEIRA: Very
short one. And then of course, when you try
to make a game's API call, what's going to happen is that
the server is going to see if this game is actually
authorized to make games API calls. And the way it does that is it's
going to check your list of linked apps in the
Developer Console. So in order for the call to be
authenticated, there needs to be a linked app that exactly
matches that package name and certificate fingerprint in
the Developer Console.
So over here, we see that
there's a match because there's a linked app with
exactly that package name and exactly that certificate
fingerprint, so the games API. Call is going to succeed. Now if there isn't such a thing,
then you're going to see an error. So this is by far the most
common cause of errors.
So to make sure that you're
setting this up right, when you add a linked app,
you see this screen. And then you go Save and
Continue, and then the next step is Authorizing Your App. And then when you click on
Authorize Your App Now, you're going to see this
dialogue box. In this dialogue box, you have
to fill in your package name and the certificate
fingerprint.
Now this is the step where many
people make a mistake. You have to take a certificate
fingerprint from your release certificate that you have
on your machine. You see, there is this example
there, so this is not an example that you should use. It's just here to show you
what it should look like.
DANIEL GALPIN: That's why it
has "example" next to it. BRUNO OLIVEIRA: Exactly. It's an example. DANIEL GALPIN: But
unfortunately, a lot of people will just paste that right in,
and what we should do is we should catch that.
We should say, hey, don't
use the example string. BRUNO OLIVEIRA: But then what
happens if their certificate is actually identical
to the example? DANIEL GALPIN: That's true. Unlikely, but possible. BRUNO OLIVEIRA: Unlikely,
but possible.
Also, you may notice that if you
have an APK that's already published, maybe there's going
to be a certificate suggestion over here. But then you should always make
sure, don't trust that, and make sure that you're
checking that your certificate is actually that one. DANIEL GALPIN: Yeah. If that suggestion is wrong,
that's our mistake, unfortunately.
But if you publish it, people
are going to be confused and not be able to log in. BRUNO OLIVEIRA: It's
always worth checking out if it's right. And to do that, you can use the
keytool command line tool. Essentially to get your debug
certificate fingerprint, this is the command line.
You just go keytool -exportcert,
and the alias option is the name of your
certificate, which for your debug certificate is going
to be androiddebugkey. And then this is a keystore
file, which is usually in .Android/debug.Keystore. So this is how you get your
debug certificate's fingerprint. And then of course, you should
also get your release certificate's fingerprints,
which you can do using this command line.
In this case, you're going to
have to replace your keyname over there and then give the
path to your keystore. Once you have those two
fingerprints, what we recommend is that you have two
different client IDs in the same product with the
same package name. But those two different client
IDs, one of them has your debug certificate fingerprint,
and the other one has your release certificate
fingerprint. And they exist side by side,
and what this means is that you can either sign into your
game using your debug certificate or using your
release certificate.
DANIEL GALPIN: And because we
only allow a limited number of client IDs for each game, you
should consider using that debug certificate for all of
your development devices and for all of your developers. Because otherwise, you're going
to run out of those client IDs very, very quickly. BRUNO OLIVEIRA: And also if
you delete client IDs, remember that it takes a really
long time for them to actually go away. Because after you delete them,
it takes almost a week until they actually disappear.
DANIEL GALPIN: Yeah. This causes a lot of confusion,
and the mistake on our side is that we don't make
it really clear enough that if you delete, the delete doesn't
quite automatically happen. So the best thing to do is
never delete client IDs. BRUNO OLIVEIRA: Always create
one with your debug certificate, one with your
release certificate, and then hopefully, you're never going to
have to touch those again.
TODD KERPELMAN: As the
non-Android guy in the group, why do you need two
certificates in the first place? Why can't I just use my
release certificate everywhere? BRUNO OLIVEIRA: You could, but
then this means that during debugging, you would always have
to sign your app with the release keys. And for some companies,
especially for large companies, they want to keep
their release keys, certificates, in a very secure
way, so only certain people have access to it. This is to prevent somebody from
grabbing a signed APK and uploading it into Google Play. So you might want to safeguard
your release certificate, and then only work with the debug
certificate during debugging.
And then only at the last step,
when you're actually going to launch, you sign it
with your release certificate. DANIEL GALPIN: And it's very,
very easy to take that debug keystore and simply copy it into
every single one of your developer's machines and
just use it there. BRUNO OLIVEIRA: It's just
copying a file. It's easy.
DANIEL GALPIN: Exactly. And so that's definitely
what we recommend. And also really do safeguard
your release certificate because it's really, really
important that you never lose it. And that's a non-gameplay
services kind of developer mistake, but it's a really,
really bad mistake.
BRUNO OLIVEIRA: Exactly. And also, we recommend that
you take a look at our documentation. We have all of our API calls,
we have the concepts, and we also have the step-by-step
troubleshooting guide. So when things go wrong,
you can go into that troubleshooting guide and go
step-by-step, and then hopefully, that's going
to help you figure out what went wrong.
DANIEL GALPIN: And we're not
just saying that because Bruno and Todd wrote large
chunks of that. It actually is really helpful. And you really want to make sure
that when you put a game out, that you're not ending
up getting bad reviews and confused users because of simple
mistakes that you could have corrected early on. And of course, as we see more
things that happen, we're going to try to make the documentation better and better.
BRUNO OLIVEIRA: The whole UI
better and better, to make sure that those mistakes are
more difficult to make. DANIEL GALPIN: Exactly. Because ultimately, these
mistakes are a result of people not understanding
how to implement our code in our examples. We really do want to make sure
that the word gets out there and that things go
very smoothly.
And we've seen a lot of really
excellent implementations already in the market, and
so we want to keep the implementations really, really
high quality and keep the user experience high quality. TODD KERPELMAN: So what
should developers do if they have questions? DANIEL GALPIN: If they have
questions, it really depends on what platform you're
developing on. You can always look at the
Android tag and then look up games or play games services,
as well, when you're on Stack Overflow. And we actually regularly
look at these things.
BRUNO OLIVEIRA: I usually search
the Android tag and then anything that has to do
with games, and then just look at the newest questions there. DANIEL GALPIN: And you're doing
a similar thing on iOS? TODD KERPELMAN: Yea. On iOS, it's hard to look for
iOS in games because there tends to be a lot of stuff that
isn't Google material. So I generally look for the
Google Play game services tag.
I've seen that start to
be used fairly often. And then just look for anything
that doesn't include Android, which tends
to be a little less than the Android stuff. BRUNO OLIVEIRA: And as always,
of course, make sure to ask high quality questions. So include very specific details
about what your setup looks like, what are the error
message that you're seeing.
If possible include logcat and
everything that might make your question easier to
understand and debug. DANIEL GALPIN: Yeah. There's instructions also in
the game services on how to turn on logging. That will help a lot.
Because otherwise, we won't see
anything at all in terms of errors coming
through logcat. So you at least want to turn
on logging when you are submitting questions
to Stack Overflow. BRUNO OLIVEIRA: And I guess
that's pretty much it. DANIEL GALPIN: I think
that's it.
So I hope you've enjoyed
watching our mistakes, and we hope that this helps prevent you
from making the same kind of mistakes that a bunch
of other game developers have made. And thank you for your time. BRUNO OLIVEIRA: Thank
you very much. TODD KERPELMAN: Thanks,
everyone..
Tidak ada komentar:
Posting Komentar