you

Chris Pruett:
Okay, hello, everybody. Thank you for coming.
I’d like to get started. I’m supposed to reiterate
the point about not sitting
in this room. We have a Fire Marshal issue, so if you can please
find a seat. If there aren’t any seats,
please stand. We don’t want to get
shut down. The other point
that I wanted to make before we get started here is we’re really looking
for feedback. There is a site that I’ve now
just hidden with my slides, but I’ll put it up
at the very end. It’s haveasec.com/io and it…we’re, you know,
accumulating feedback about the talks here today. Please take a moment
to fill out your feedback about this talk and about all
the other talks you see here. Thank you. Okay, so this is Writing
Real-Time Games for Android. This is the opposite of
the Saving Battery Life talk. [laughter]
and the… I’ve a lot of stuff
to talk about today, and it’s kind of a lot of
like random, unrelated– seemingly unrelated topics, so I’m gonna try to go through
them as logically as I can. Hopefully, it’ll make sense. Did you see that awesome fade?
That slide totally faded in. I don’t think I’ve ever
had like a… a thing that has like
a slide presentation that has fades
and moving stuff before, so this is like
a new experience for me. Right, so my name’s Chris. I’m a Developer Advocate
for Android. I work in Japan. My job is to advocate
Android development, so please make something. I can help, maybe. If you’re in Japan…
[speaking Japanese] Before that,
I was an engineer on Lively. I worked on animation code,
collision detection, service stuff,
all kinds of stuff. Lively was
our rather short-lived but very cool 3D online world. And before I started at Google
in 2007, I worked for about six years
in the game industry. Shipped about ten titles
for GBA, PlayStation Portable, PlayStation 2, Wii. So I have some experience
making games that are on other platforms. And today I want to talk about my experience making games
for Android. So, I mean, obviously
Android’s a cool platform, and making games is awesome, so the two together have just
gotta be awesome squared, right? But it’s really easy
to say that, and especially from,
you know, my perspective,
as like an employee of Google, it’s really easy to say, hey,
make games for Android. It’ll be great! Without ever knowing if it’s,
really, you know, feasible. And I don’t know how many
people in the audience are game developers here, but game developers will tell
you that games are weird, right? They don’t really fit into regular application
development models very easily. They push your hardware in ways that your other applications
will not. So I wanted to…
in my position as an advocate, I wanted to be able
to advocate, you know, development of video games. But to do that with confidence, I need to be able to know that,
you know, the platform’s actually
capable. So I made a game, and I’ll talk a little bit about
the game today that I made. It’s basically
a learning exercise, but I was also able
to make a fun game. I’ll release it
when it’s done, hopefully in a month or two. And I’ll release all the source, and hopefully, people
can use that to, you know, build their own games
for Android. So what I’m gonna talk
to you about today is, you know,
who cares about games? Who cares about games
on Android? Why don’t we just write like Awesome Friend Feed Connect
Facebook Apps or something, right? Like isn’t that where
we’re all going? But we’ll talk about games
in a little bit. I’ll talk a little bit about
game engine architecture. This isn’t really
Android-specific, but I figure that
a lot of people in this room, and there’s quite
a lot of you today, are interested in writing games but don’t have a lot of
experience doing so. And like I said, game architecture
from a code point of view is very strange, so I just want to…
a couple of slides about how I go about,
you know, architecting games that I build
and how I, very specifically, which sort of architecture that I found
worked well on Android. And then talk a little bit
about writing Java code that’s fast,
like really, actually fast… on Android, using
the Dalvik virtual machine. And then some rendering stuff, drawing efficiently
and then some tips and tricks. We’ll get to that. So who cares about games
on mobile devices? Well, everybody,
apparently, right? iPhone where–App Store, like number one category of
download applications is games, and 79% of people
have downloaded a game once. You know, 100 million
Nintendo DSes in the world. 200 million Game Boy Advances
and original Game Boys, right? And these are sold
to an audience that is not necessarily
just traditional gamers, right? I mean, you can find
a lot of people who have a Game Boy Advance or
a Nintendo DS in their pocket that, you know, would never
consider buying an Xbox 360 or a PlayStation 3
or something like that. So there’s a huge interest
in mobile games. And up until now, games on cell phones
have not been, you know, a really valuable proposition. And that’s because before,
you know, say, the iPhone, cell phones were really not
very well designed for games, like the aspect ratio
was wrong, maybe headphones that,
for the longest time, couldn’t read more than one,
you know, button input or only had like a 92-color
palette or some crap like that. So right now we’re getting into
systems that are portable, they’re high-powered,
they’re able to host real games, and by real I mean like
modern game design kind of games that people want to make
and play today, not, you know, games
that were popular 30 years ago. And we also, I think,
are seeing a convergence of people who are interested
in, you know, having a cool phone
and also playing games, even if they’re not
what we would consider the, you know, traditional
hardcore gamer market. I’m not gonna use the word
casual in this talk. So as I said before,
game tech is really specific. Another reason to do games
on Android and on any platform, I think,
is a stress test. If you can support games and you can support a lot of
different types of games, then I think that your API
is probably gonna be able to support all kinds of
other media applications. So why games on Android,
right? This is the one slide
I’m gonna spend on this. I have this really long,
involved rant, like invective-filled spew
that I would like to give to you about what’s wrong
with the current game industry. But I’m not gonna do that. I’m just gonna give the little
30-second one slide version, and that’s that basically the traditional game industry
has been built, especially in the last, say,
ten years, around marketing games towards
a very specific audience, and that audience
is an audience that really appreciates
advances in technology. It’s also an audience that has
a lot of disposable income. So we’ve seen games
that sell well also being correlated
with games that have really nice
graphics tech or have really impressive
technical features. But what has happened,
because of that, is that that audience
has become the only viable audience in the minds
of a lot of game developers. And so we have, you know,
consoles now that are extremely
powerful computers and cost, you know,
200, 300, $400 when they launch, or more. And, you know, they do produce
fantastic games. I don’t have anything bad
to say about those games. I love them myself too. But, you know, you could make
a PlayStation game for $5 million,
a PlayStation 2 game, $5 million. And, you know, you make
a PlayStation 3 game or an Xbox 360 game nowadays, and you’re talking about, what,
20, 30, $40 million, right? I mean, we’re very carefully– or very quickly
moving into a space where the platform
is becoming less and less able to support itself
on its one market base, which is sort of
the hardcore gamer, right? And we do have
alternatives, right? We’ve got
like Xbox Live Arcade and we have Nintendo Wii
and the DS and the iPhone showing that there are–
there is a market for games that are not about, you know,
muscle-bound like space marines who have amnesia
or a mysterious past, right? [laughter]
Like, um… if you are into muscle-bound
space marines with a mysterious past and you really like, you know,
guns that are also chainsaws, there’s tons of games
for you, right? That’s great.
You’re the target audience. But there’s a lot of other
people out there who, you know, might like
a game about something else. And the gaming industry doesn’t really make games
for them anymore. They used to,
but now it’s too expensive. I mean,
$50 million on a video game, you’re gonna
not do anything new, right? You’re gonna do whatever
sold last time because you spent $50 million and there’s no way
you’re gonna take any risk. So what we see is
a contraption of viable genres. And that’s not good, right? I mean, games are awesome. They should be enjoyed
by everybody, and we should be able
to make whatever we want. Right now, the current
marketing conditions mean that 10% of, you know,
professional game developers make a profit and everybody
else goes out of business. So I think that–
and this is, like I said, the end of my little
side rant here about this. Mobile games in particular,
games that are being distributed over digital
distribution services like Android and like iPhone
and Xbox Live Arcade and those types of systems can solve this problem,
right? Because we can give developers a means to develop games
that are much, much lower risk to developers. And lower risk means more
interesting and diverse content because you can, you know,
you can take a risk. You can, you know, do something
that’s experimental, do something that
you’d never be able to do in a $15 million game. So I think that Android’s
particularly well-positioned from this point of view because we have
an audience of people who want a cool phone and also want to be able to play
games that do things on it, as we saw
in the previous slide. You know, portable games
are a big deal, and all of you are here, and they put me
in the really big room because clearly people
care about games, right? But on the other hand, we also have always-on
internet connection, and we have an internet-savvy
audience, and that’s a combination
of things that we haven’t actually seen
very much of in the past. iPhone’s certainly
doing it too. I think that Android
can be right up there in this sort of sea change
of allowing you… or maybe…previously retired
gamers to come back. So, um…advance. So what kind of game
did I make, and why did I choose
to make that game? I had three goals
when I started out, and I have to tell you, I worked on Lively until
about October of last year. I moved to Japan
in October of last year, and I started working on this
in like very late in November. And this is a 20% project
for me. I work on it one day a week. So this is not
my full-time job. So I needed a game
that I could actually complete in a good amount of time
that I think I could make fun. I don’t see any reason
to make a game if you’re not gonna
make it fun, right? So my first,
my number one goal is to make a fun game in the sort of time
that I had and with the constraints
that I had. My number two goal,
as I mentioned, was to produce open source. I think that a lot of people
would make more games if they knew where to start, and if I can provide
some code or some framework or some documents
or some blog posts or something saying, like,
here’s how I did it, you know, maybe that’s
a jumping-off point. And even better,
down the road, if other people
could take that code and make new games
out of it and release their source
as well, then I think we could have a really pretty awesome
community. And then like,
as I said before, I want to stress
this platform. So I went for an orthodox
2D side-scroller. I’m assuming everybody
knows what that is, but just in case that’s,
you know, Super Mario Brothers,
Sonic the Hedgehog, games like that. We have, basically,
multiple layers of images that are scrolling
at different speeds. It’s called parallax scrolling. They’re built out of tiles. We have little small images
that get put next to each other to build the world, so it’s pretty traditional, very, very popular
in the mid, early ’90s genre. Recently under-served,
I think. Nice thing about
this particular genre is I felt I could do it
in six months. I made a bunch of side-scrollers when I was working
on Game Boy Advance games. I have some experience
with them, and I quite enjoy
the genre myself. So it felt like something
that’d be fun to make, something that I thought
the people would enjoy and also the correct skill. It also pushed the right buttons
technically. I need to know how to do input
systems correctly and sound, and I need to be able to draw
with OpenGL or Canvas or whatever it is I’m gonna do that any game is gonna know–
have to know how to do, whether or not it’s 2D or 3D. So then the stuff
I’m gonna talk about today is a little bit focused on 2D, ’cause that’s the kind of
game that I made. I suspect
that a lot of it will be completely applicable
to 3D games as well, especially the stuff about
using OpenGL quickly. So please don’t
take this as being absolutely
just for 2D games. I want to talk about games
in a general purpose case, but I’m gonna use
the 2D game that I built. Okay, so let’s talk about
some game engine architecture. Before that, I had a picture of a guy holding
a chainsaw gun here, but… legal made me take it out. [laughter]
Sorry. I just put the little text in
instead. I didn’t really, you know,
own the license, I guess, so they were right. So I just wanna have
a really quick demo here. This is the game
that I’m working on. It’s called Replica Island. It’s getting close
to being done, and it’s probably
about an Alpha. I have a very low-quality
video to show you. It’s really hard
to shoot video on the Android device
that I have. So I apologize. And it’s also quite difficult
to play a video game while shooting video
on an Android device and keep the screen
from getting screwed up. So I just have
a very short clip, and it’s not really
representative of the entire game, but it’ll give you an idea
of what I’m talking about, an idea of what the scope is
that I’m working on, and hopefully,
you’ll think it looks cool too. Let’s see if I can
make that play here. I think I have to click again. There we go. [laughter] So we got, you know… the Android robot,
and he’s blowing some guys up and crushing some robots. And he’s gonna take
this robot over here with this little red ball. Now he’s possessed him. Now I can walk over here. This is a test level, so there’s not really
anything to do in this level, but the robot can walk
over here and then self-destruct to go back to Android. So the goal is to collect
the three gems in each level. You can get coins
and things like that. There’s some power-ups
to acquire and a lot of robots to crush, people to talk to,
things like that. And it’s pretty traditional
side-scroll. [laughter] Oh, and here’s a character
we can talk to. But I think we’re just gonna
run by her instead. And you can kind of see,
you know, that there’s a couple
of layers of background that are scrolling
at different speeds. That’s the parallax
we talked about. We’ll talk about that in a bit. Okay,
so there’s the third gem. Hooray,
we completed the level. So that’s Replica Island. [applause] Thanks. I hope you guys
enjoy it when it comes out. I’d like to hear
your feedback. So I want to talk a little bit
about how I build games just generally. And this sort of general
architecture is the architecture
I used to build Replica Island. It’s also very similar
to the architecture that I used to build
a Spider-Man game on PlayStation 2. So I believe that it scales
pretty well. My approach is to– you know, we have like
the same kind of problems that we have to solve
in all games, and that’s that you have
this sort of world full of objects
that need to be simulated with time, right? We got, you know,
the character moving around and there’s other things,
and they’re gonna collide, and they’re gonna pick up stuff
and hit the ground and bounce. And then they’re gonna have
velocities that need to be calculated and also animations
that need to be updated. These are all sort of
taking a time step, a simulation step,
and then updating and then figuring out
the results. That’s sort of the basic
problem that most games face. So what I do is
I have a game graph. Basically we have a–
you can think of it as a tree. It’s technically a graph, but you can think of it
as a tree for most cases, where the root node
is the main loop. And all the child nodes
under that root are things that get updated
every frame by the main loop. And those things
can have their children, and those things can be
updated every frame as well. And, you know, halfway
through the tree it’s okay if we start adjusting
the way the things below in that particular sub-graph
get updated. For example, we could have a main loop
that has a game object child and a game object–
I’m sorry, manager as a child. And that manager
is gonna be the thing that manages all, say, like the sprites for bad guys
on the screen. And the thing about
bad guys on the screen is you don’t really care
about what they’re doing when they get far enough
away from the camera, right? In fact, you’d like to stop
processing them completely when they get far enough
away from the camera because, you know,
they’re gonna slow stuff down. You got a huge level and there’s like 500 guys
in there, but there’s only three
that are actually close to actually being able
to interact with the player, and you only want to update
those three, right? So…in the game-graph context, the game manager node can sort
its children by visibility and only visit the children that it thinks are close
to being visible. That’s kind of how that
concept fits into the graph. The game objects themselves which are, you know,
“an enemy” or “an explosion,” or “the player”, those things are sub-graphs
of the game graph as well. You know, the sort of
initial implementation that I started out,
sort of the naive implementation when I first, you know,
joined the game industry was to take…you know,
make a game object class and then derive that to make
visible game object class and implement
the rendering part. And then derive that and make
a moving game object class and implement, you know,
velocity calculations. And then derive that
and make, you know, the rendering–
or, I’m sorry– the collision detection
game object and then derive that
and make the player out of that. And that actually works
for a while, and then eventually
you’ll get into a case where you need, you know,
functionality from step A and functionality from step C, but you don’t want
the class in the middle. And then you’re sort of
screwed, right? So what I’ve been doing
for the last couple of years is sort of an aggregate
object model where I have a game object that is just
a list of other components. And each component is a single
piece of functionality. It updates
like a single update loop that says
I’m gonna do something like move the player
or render the player or take the input
from the device and then decide
how to adjust velocities. And it only does one thing. And the nice thing
about that approach is you only insert the components
into the object as they need it. So the player happens
to need to know how to read the input, but the enemies,
until they get possessed, don’t need to actually
read the input ever, so they don’t have to have
the input component. And if I decide
to possess an enemy and then suddenly
I want him to respond to the input component, I can just stick
a new component into his game object
at runtime, and it suddenly
starts working. So this is actually
an important point, and the reason
I’m sort of belaboring it is that also
it’s very helpful because it helps you not
execute code that you don’t need to do. And not doing extra work is gonna be a recurring
theme in this talk. Because optimization
is gonna become a big problem for us
when we start to write games. So, um…
let’s go to the graph and see… This would be like
the top level view of like a very simple game graph
where we have a main loop and then we have some other
systems as children that get updated every frame. I just wanna give you an idea
of how I do this. This isn’t the only way
to do this. This is just the way
I do it. So here’s an example
with two objects and the game object’s
just in there. Background object
was the thing that’s drawing the backgrounds
and the layers, and then the player object
would be like the player itself. And you can kind of see how
they’re made up of components where they sort of–they look
like children in the graph ’cause that’s what they are. So for the background,
there’s like three layers. There’s the, I think–
you saw it in the demo just now. There’s like
the blue static background and then there was
a mid-ground layer and there’s a foreground layer
as well. So for each of those layers, there’s a scroller component
and a render component. Scroller component figures out how much it’s supposed
to be scrolled, based on the current
camera position. And then the render
component says okay, now go render this
as frame. And then the player’s made
of a bunch of stuff like physics and animation
and rendering and gravity, movement,
things like that. So this is actually
pretty close to the way that
Replica Island works right now. It’s a little bit
of a simplification. But…you can see
that every frame, if we wanna update this game
and produce a new frame showing one more
simulation step of the game, all we have to do
is traverse this graph. And the order in which
we traverse these things, you know,
is sort of important, so just sort of say
breadth-first, left to right. Anyway, that’s how I do it.
You can do it however you want. But I wanted to sort of…
just sort of say, you know, think about this kind of stuff when you start
writing video games because if you don’t, it will come back
and bite you later. It bit me on production games that I did in my previous job
several times until I stopped doing it
that way and started doing it
this way. An important point about this
is that the graph takes time, like the delta from the previous
frame, as its input. Its output is a bunch of things
to draw for the render system, but its input is time. And the reason
that that’s important is that any sort of
temporal logic that you’re gonna do
in a game for a system like Android
needs to be scaled by time. So that means velocity
calculations, animation duration
calculations. Anything that’s related to time
has to be scaled by real time and not like, say,
frame counts. It’s really easy to say, “Oh, I’m gonna add five
to my velocity, or I’m gonna, you know,
wait for three frames and then play
this other animation.” And the reason you don’t
ever wanna do that is you don’t know what
the duration of each frame is. You might think, well,
I’m running at 60 hertz, but Android
is a multiprocessing OS. You have no idea
what’s going on in the CPU. You have to plan
for a variable framerate. And what happens when you don’t
plan for a variable framerate is when your framerate’s
really low, your game kind of falls apart
and slows way down. And you also start to experience
sort of temporal anomalies as the framerate fluctuate. Like your collision detection
will cease to work and things like that. So very important point
is that– and that a lot of people
would not maybe think about if they’ve not written
a game before– is to take time and do all
the calculations you need to do related to time with real-time. It’s okay if you buy us
some time. You want to have
a slowed downMatrixeffect? Sure. Go for it. Just don’t use frame counts
as your… The other important point
is that the traversal
of the game graph doesn’t actually draw anything
on the screen. It just produces
a list of things that we might draw
sometime in the future. And that’s important
because of the way that– it’s particularly important
in kind of all kinds of games, but for Android it’s important because of the way
that rendering works. And this is true
whether or not you use OpenGL
or you use the Canvas system to be doing your drawing. You’re gonna hit a point
at which the rendering threat is gonna block on hardware. And the reason
that that happens is that the hardware may not be done
drawing the previous frame. If the hardware’s not done
drawing the previous frame, it’s not gonna let you do
anything until it’s finished. So if you’re using OpenGL ES
and you call EGLSwapBuffers, that’s gonna block, and it can block for like
16 milliseconds, right? And the CPU’s not really
doing anything when that thread is blocked. But it means that your game
is not proceeding, right? So it’s important to split
the game logic from the rendering layer. And the way that I did it
for Replica Island is I have three main threads. The main activity
is what I call the UI thread. It’s just that when you make
an Android application, you make an activity and it comes up
and it produces your views, and then it can receive
input events. That’s pretty much
all it does. That thread’s mostly dormant. It bootstraps the game,
then it’s pretty much done. Excuse me. I have a game thread which
is where the game graph lives. It gets updated, you know,
as often as I plan, and it produces
a list of drawable things to hand off
to the rendering thread. The rendering thread
is basically a SurfaceHolder. If you look at any of
the OpenGL examples that are shipped
with API demos– 0r in a few minutes, I’ll talk about
a sample that I wrote that you can look at as well– you’ll see classes
like GL SurfaceView, which was part of API demos
in previous versions south, part of the API in Android 1.5, but it implements
a separate rendering thread separate from the main thread that just sits there and talks
to OpenGL as quickly as it can. So basically we have
this game thread producing a list of things
to draw, every frame, and then the rendering thread
consuming this every frame. And the nice thing
about this is that means that the framerates of these
two threads are decoupled. If the rendering thread
slows way down because I just threw
a hundred sprites at it, then as it’s chugging on drawing
those hundred sprites, the game thread can continue
to run at 30 hertz or 60 hertz or whatever. If there’s a…backlog
of the other direction, like the rendering thread
is starved, it’ll just re-render the frame
that it had previously. Which is not ideal. you don’t want to drop a frame
if you can ever avoid it. But, you know,
the screen doesn’t go black. Nothing blows up. You can pause the game just by turning off
the game thread, and the rendering pedals
still continue to draw stuff on the screen,
whatever it had last. So I’m sure there are
other ways to do this. This is how I did it
on Replica Island, and it worked out pretty well. Okay. So let’s talk
a little bit about writing Java code that’s fast. Before I start talking
about this, I’m gonna offend all of the Java
engineers in the room, and I apologize for that. Also when I say Java,
I mean Java on Android running
the Dalvik virtual machine, not any other kind of Java. So please don’t kill me. Basically,
I’m a C++ engineer. In fact, I never wrote
a line of Java in my entire life
before I started this game. So you should probably take everything I have to say
about Java applications with a kind of gigantic
grain of salt. But, you know, I also think
that most Java applications don’t really need to do– be optimized to the sort of
level that I’ve been working. Because, you know,
for the most part, you have this language that provides a bunch of awesome
services for you. It provides an awesome
standard library, you’ve got memory referencing
and all this other stuff that you don’t get in languages
like C++. and that’s why writing
Java applications is easy and cool, right? And then maybe, you know,
I’m sure that everybody does sort of macro level
optimization of their algorithms and not doing an order
N-squared, you know, search when you can do a…and log N
search and stuff like that. But I’m gonna talk about
optimizations that are a little bit
more low level than that, and I think that might be
something that Java engineers don’t generally
have to worry about. So hopefully this will be
some useful information here for you. There’s one bullet point that says writing
real-time games in an exercise in finding
the perfect balance between flexibility
and performance. That’s like a whole talk
in itself, that topic. But basically, what I want
to say real briefly is that at some point
you’re going to have to choose between absolute performance and the ability
to make the game. And making games is about
duration, right? What you’re gonna do,
if you sit down and make a game, is you’re gonna have an idea,
and you’re gonna make it, and you’ll write it
and it’ll be great, and then you’ll give it
to somebody else, and they’ll have no idea
how to do it or they will not find it
fun at all, and you realize
that there’ll be all these usability problems
with it, so you’ll iterate. And that’s how games are made. And the games
that are really good are the ones that iterated
for a really long time. That’s for the general rule. In order to iterate, you need
to have your code flexible. You need to be able to go in
and make changes without injecting bugs. You need to be able to swap out
one piece for another. You need to be able to write
tools that can generate data that the game will use. You need to have a bunch
of infrastructure. But infrastructure often comes with a cost of performance,
right? As soon as you have all your
games serialized in XML, then you have to actually
load the XML and walk through
all those objects, and that’s not
really fast, right? So at some point,
you’re gonna have to choose between flexibility
and performance. And basically, I always err
on the side of flexibility until the game
starts to slow down and then I have to go back
into performance tuning. And the reason is that… if you can’t tune the game,
it’s not gonna be fun. And there’s no point in making
a game that’s not fun. The corollary to that
is if you make a fun game that runs at one frame
per second, nobody’s gonna play it. So it’s not all one
or the other. But if you have to choose, my general advice
is to stay on the side of flexibility
and then, you know, go back to performance
when you need it. And to enable that, my approach here,
which has served me very well, it to just implement everything
as simple as possible for the first iteration but keep all the hooks there
for swapping things out. So it’s okay to do that
order N-search the first time and when that order N-search
shows up on your profiler, then it might be
a pretty good time to go back and replace it
with something smarter. And when you wrote that
order N-search, hopefully you wrote it in such a way
that it’s very easy to replace without the calling code
knowing anything about it. So then that leads me to
the last point about this topic, and that’s profile early
and constantly. And we have a bunch of profiling
tools I’ll touch on in a little bit later, but if you make like a thing that accumulates
the amount of time that you’re spending per frame and spits it out
every three seconds to log, that’s fantastic,
that’s all you need. I mean, you can write that
in about an hour. And you can hook it up into all your game systems
really early, and you should do that, and you should have
a constant understanding of where you are
in your game framerate. Because if you want until
the last minute to go look at why your game’s
not fast enough, then you’re gonna be screwed. It may be the case that you
have just one, you know, system that’s like, oh, a repeat
from 1 to 1,000. But it may also be the case that it’s a death
from a thousand cuts, right, and that you don’t have any one
system that you can optimize. And that’s a really difficult
position to be in. So I said, you know, print
your profile out really early and keep looking at it
and keep understanding, you know, what you’re doing. One comment that I would
like to make about this point before I go on is that don’t print your profile
to the screen. I see a lot of developers
make this mistake. Because it’s really easy,
especially in Java, I think, to mess up
printing to the screen in a way that will
actually affect the output. Like you can very easily hurt
your framerate by printing it on the screen. And also,
it’s not information that you really need to see
all the time. A heartbeat every three seconds
is sufficient. I had one guy that
I worked with who, you know, had been working on improving
his framerate for his game and it had gotten progressively
faster and faster and faster. Then he hit a wall, and he
couldn’t figure out what it was. And when he went
and looked at it, it turned out that
all the string calculations he was doing to print the frames
per second counter out on the screen were causing all these allocations
to be created which was causing the GC to fire
all the time, which was slowing him down. So just a point of caution. Okay, so let’s talk about ways to use Java that are not
very flexible but are very fast. Given that I gave you
the flexibility talk. Don’t every allocate memory. Okay, you can allocate memory,
but don’t release it. That’s a little extreme,
right, but what’s gonna happen is
when you allocate memory, every time you allocate memory,
the GC gets a chance to run. And the GC right now,
under Android 1.5, can take 100 to 300
milliseconds, even if there’s nothing
to actually do. And it has to walk
the whole object map, right? So 300 milliseconds
at a 60 hertz game– I mean, the user’s
gonna feel that. That’s 1/3 of a second,
right? The user’s gonna know
that the game just stopped, and that’s absolute death
for real-time games. If you remember the video
I just showed you, if the robot’s
jumping over a pit, and the game stops,
and then he falls into the pit, you know,
that’s a bad game, right? The player’s gonna stop
at that point. So you don’t ever
really want the GC to fire. So, okay, go a little bit
less extreme. Allocate all your memory
up front. Allocate all your memory at a time when gameplay
is not going on. And don’t allocate
and don’t release while gameplay
is actually running. And memory pools
are your friend. This is not actually
a very hard problem to solve, and non-Java languages, we have to solve this
all the time anyway, so just, you know, make your memory pools. Pre-allocate all your objects. Reuse them. Don’t actually
release the references. And when you are at a point
that you know you can pause, like in between level load or at a pause screen or sometime when the game is not running a simulation
at full tilt, that’s when you should
manually invoke the GC. There’s a command. I think
it’s System.getRunTime, invokeGC,
or something like that. And it will just– You can cause it to run
whenever you want. Otherwise you don’t know
when the GCs gonna run, right? You can’t really predict if it’s based on whatever
parameters it uses and how often
you allocate memory. So beware of memory allocation. Also, we have this
pretty fantastic tool that ships
with the Android SDK called DDMS. And it’ll allow you
to track allocations pretty much in real-time
as your application runs. So you can run your game on your device
and have it plugged in, and you can boot up DDMS. Actually,
there’s a tab in Eclipse for it now even. And you can hit
“start tracking allocations,” and when you hit stop, you’ll get a list
of all the allocations that occurred, you know, in between those two
buttons clicks, right? And what you’re gonna find out is that Java
allocates memory all the time in places
you would never expect. At least I never expected. Like you ask for the array
for an enum, like enum.values(), yeah, that allocates memory. And you’re gonna use
a HashMap or an Iterator or anything from collections, that allocates memory. Arrays.sort(), really fast, but duplicates
the data it works on. Any kind of, like,
system library function where they want to give you back
an immutable reference, but there’s no such thing as
an immutable reference in Java, so they have to copy it. You can really easily find out that you made a lot of mistakes. I had to go back and rewrite
a bunch of my code after I started using DDMS, so DDMS is fantastic. What you can do, is you can reduce
all the allocations that you do yourself
in your own code. Some of the stuff
that Java is doing is not gonna be avoidable,
and that’s okay. We don’t actually need to
get rid of 100% of allocations. We just want to get rid of,
like, 90% of them. So having a little bit
of, like, say, StringCchCat, or, you know,
a little bit of stuff that you can’t stop anyway,
is fine. It’s fine. You don’t have
to worry about it. What you want to do
is keep the GC from running frequently. You know, if it runs once
every five minutes, that’s still much better than running randomly
every 30 seconds or something like that. So my approach is basically
to treat Java like C++. And this is the point where I said I was gonna
offend everybody. This is–completely flies in
the face of the language design, which I completely understand and I sympathize with. But if you want
to make a fun game, making a fun game and having it
actually be fun to play is more important, I think,
than language security. So you can’t really
use collections. You can’t really use enums. They’re a really bad idea anyway
for a lot of different reasons. Like I said, Arrays.sort()
allocates memory. Stuff like
Reflection.getClassNames, things like that. You can use these functions, but not as the game
is running, and not– And it’s not like you have
to completely ban them, but what you have
to understand is that every time you allocate memory or any time one of these
functions allocate memory, the GCs getting a chance,
right? So I just avoid them completely. And actually,
once you’re cognizant of this particular problem, it’s pretty easy to avoid. As far as I know, I’ve not gotten the GC to run
duringReplica Islandgameplay in about five months. So…I kind of have
these slides here just to let you know sort of
the extent of the problems that when you go
to write your games, you can, you know,
code appropriately. But absolutely use DDMS as your tool to find out where
allocations are coming from, ’cause it’s fantastic for that. Also, like I said,
I’m not really a Java engineer. I just sort of play one on TV, so I’m sure the rest of you could come up with much better
solutions than I did, you know,
like replacing implementations from the standard libraries with ones that don’t
do allocations at runtime or come out of a pool, and those might, you know, allow you to go back
and use some of those standard library things without, you know,
having to rewrite everything. I don’t actually
know how to do that. Okay, so step two,
don’t call functions. Well, okay,
you can call functions, but you have to understand
that functions are not free. They kind of
don’t teach you in school, at least when I went to school, they didn’t really ever
touch on the fact that, you know,
functions might be expensive. And, in fact, in Java,
they’re pretty expensive depending on what kind of
function you’re calling, right? Don’t ever call
interface functions. Those are really slow. Like, you call a function
through an interface, it has to go through an extra
lookup or something. It’s 30% overhead. At least that’s about
what I calculated. Your mileage may vary. But, like,
Accessors and Mutators, my “bestest” friends in C++, don’t really belong
in your inner loop in Java, because you want to avoid– Any time you’re in
a time-critical piece of code, you want to cut down the number of functions
that you’re calling. So if that means
calling something once and assigning it
to a local variable and then using that for
the remainder of the function, that’s great. If you can assign that local
variable at Bootstrap and then never
call that function again, that’s even better, right? This is what I was talking about
when I said “death by a thousand cuts.” If you architect your game
in a way that you would architect
any other sort of regular application, you’d probably end up
with a lot of, you know, general function calls. “Get this, set this,
put this over here,” right? Yeah, you call those things a
couple 100,000 times per frame, and that’s the end
of your frame rate. And then what
are you gonna do, right? It’s not very easy to go back and change
all your functions, right? So beware. You also have to be
a little bit wary of JNI functions. JNI is the Java mechanism
for calling in to native code. And, actually,
the nice thing about it is, you know,
you’re executing native code. Native code’s really fast. So the contents of the function
are really fast, but actually calling it
is actually kind of slow. There’s some pretty significant
overhead that occurs when you actually need
to invoke a native function. So in particular, like,
if you’re calling OpenGL stuff
from inside of Java, you know,
all those gl.glXX() functions, all of those
are JNI functions, right? And it’s really easy to get up
to several hundred OpenGL calls a frame
for a pretty simple scene, so this is something
you should be cognizant of. And one thing that
you may end up having to do that I’ve had to do
in a couple of cases, which,
as a sort of programmer, it really offends me, is just make fields public. And, like, that goes against
every, you know, kind of grain in my body, because I want to be
a defensive programmer, and I don’t want to,
you know, write code that is susceptible
to easily ejectable bugs, but on the other hand, gameplay’s king, right? I mean, there’s no point
in making a game if it’s not gonna be fun. And if you find, you know, you run your profiler
like I told you to and you find out
that accessing this one field, like, the position
of the player, for example, is happening, you know,
100,000 times a frame, then you could, you know, you might be able to get
some pretty serious time back by just making
that field public. Here’s a graph. It’s not a very scientific test, so I didn’t put any numbers
on the graph, but I think that the sort of
relative costs of these types of functions
is correct. Basically, what this means
is you call a local function or you call a function
from a derived class or you call
a virtual function of Java, it’s all kind of the same cost. You can an interface class, you all of a sudden incur
this sort of 30% overhead. And then you call through JNI
that overhead’s even higher. Just to illustrate
what I already said. Okay, so a couple
of other tips about Java, and then
I’ll shut up about it. Local variables
are your friend. Even better than member
variables are local variables. Use the final keyword
anywhere you can. That’s, like, you know,
I think CS 101, but I thought
I’d reiterate it anyway. You know, the G1 and other
Android hardware devices at the moment don’t have an FPU, so if you do any kind
of float math, that’s gonna be done in software by an FPU emulator. So if you’re really interested
in absolute performance, you could consider
using fixed-point math. I actually
don’t care this much. This is a point
where I chose flexibility over absolute performance. I just go ahead
and do the float math, and it’s really hard to gauge
how much that costs me in terms of my frame rate, but I don’t believe it
to be very high. Another point that’s just
sort of unique to Android, is that the regular
Java print mechanism, System.out.print(), I guess, is actually fairly slow, and you should use Log.d()
or Log.e() or one of these
other log equivalents that we give you
to print out the log caps, ’cause it’s way faster. And that’s another example of where you could
unintentionally sort of screw your frame rate, but you’re just trying
to produce logs. And then use Traceview. I mean,
this is the best part. We ship a pretty
full-fledged profiler with the Android SDK, and, even better, you can turn profiling
on and off with just this little
function call, so you can make,
like, a menu item in your little menu
that pops up that says, you know,
“toggle method profiling,” and that will let you go
to some little spot in your game that you notice
appears to be slow, and turn on, you know, method tracing
right at that spot, and as soon as you
turn on method tracing, your frame rate’s
gonna fall through the floor ’cause that’s really expensive. But you can, you know,
generate this trace file just in the area
that you’re interested in, and then go back
and look at it in Traceview. And the numbers for, like,
how long it actually took to call a function, you should probably
just ignore those, because method tracing goes on, and the actual,
you know, seconds value is probably not very useful, but the number of times that
a particular function was called and who its parents were
and who its children were, and what percentage
of the total time they were, that’s super valuable. And you get
these cool graphs too, right? So absolutely use this tool. The fact that we
actually have this tool is really great. Usually we write this stuff
ourselves, right? Okay, so let’s talk
about rendering. This is a screenshot
from the sample that I wrote. I alluded to it earlier. Called SpriteMethodTest, and what it does is, it just tries to draw sprites
on the screen really fast, and it sort of animates them
and bounces them around. And what it does is, it lets you choose– There’s a bunch of different
rendering mechanisms in Android that I’m
gonna cover in a minute, and it lets you choose
each of them, or a subset of them, and run the same test with pretty much
the same output, and then compare the results
to see, you know, what’s faster. So this is what it looks like if you run with a thousand
sprites on the screen and you use the
draw_texture OpenGL extension, which is available on the G1. And with a thousand sprites
on the screen and a background, it runs about
ten frames a second on the G1. So, and, you know, I’ll put the URL up for that, so you can test it yourself on your new devices
at the end of this part. So, basically, you have two
methods for drawing on Android. The first is Canvas, which is a very slick,
very easy to use software-based
drawing mechanism, which is how most
of the Android UI is drawn. It’s pretty easy
to get into Canvas and start drawing lines
and making things and, you know,
copying images in there and rotating them. And, actually, considering
that it’s all done on the CPU, it’s pretty fast. If you don’t have a lot
of drawing to do, like, for example,
in the SpriteMethodTest case, under about ten sprites, easily hit 60 hertz, just using the software
implementation. Don’t have to worry
about OpenGL stuff. And Canvas is by far the easier
of the two mechanisms to use. It’s easy to set up.
It’s easy to tear down. There’s already, you know,
hooks for it in the main thread if you don’t want to make
a rendering thread, although I recommend you do. So, you know, if you’re making
aBejeweledclone… I mean,
you can make something more interesting
thanBejeweled,right? But if you’re making
aBejeweledclone, you know, Canvas will probably
meet all of your needs. Then the other option
is OpenGL ES. So, obviously, you can use
OpenGL for 3D drawing. You can also use it
for 2D drawing. It’s accelerated on platforms
that have hardware acceleration, like the G1. And other platforms
in the future, if they don’t have
hardware acceleration, like for example,
you run in the emulator, then there’s a software renderer that is supplied. It does scale to much more
complicated scenes than Canvas. Because the actual
composition of the frame is done in hardware, and the hardware’s pretty good
at doing that. So you can get 1,000, you know,
sprites on the screen at ten frames per second. In OpenGL, there’s no way
you could get anywhere close to that speed
in Canvas. It’s considerably
more complicated to use. There’s some setup
and tear-down. You’ve got to copy your textures
into video memory, and you have to watch out
for the case where your video memory
got trashed because another application
came up in front of yours, and then you have
to reload your textures. Things like that. There’s a little bit
of work to do for the setup, but then once
it’s up and running, the actual API to draw things is not
that much more complicated. So with OpenGL, we get actually
a lot of different ways we can draw things in 2D. The easy, most,
you know, basic case, is just to make,
like, a 2D quad, just a square of verts, and, you know,
put a texture on it, and just draw that using
an orthographic projection. And that’s like the OpenGL 1.0, or, like, 101 type of approach
to drawing sprites. And that works, you know. The other way is we could
use vertex buffer objects, which are basically
exactly the same thing, except you take
that vertex buffer that describes
your little square, and you throw it
in video memory. And then it doesn’t have to get
sent down the bus every frame, and the card
just has it in memory, and it’s already
in a native format, and they can draw it faster. Thing about VBOs is that
they’re not actually supported as part of OpenGL ES 1.0, and Android guarantees
OpenGL ES 1.0, but not anything above that. So if you want to use
that type of extension, it’s available on the G1. You need to check to see
if that extension exists, because you could be running
on some future device that we don’t know about yet that doesn’t actually support
that extension. And how do we choose
which extensions are supported? Well, we don’t. The people who write the OpenGL
driver for the specific device get to choose, right? So the G1’s, you know,
extensions that it supports, it actually supports
quite a number of extensions, are all based on what the driver
that Qualcomm supplied us– supports, right? So whenever you use
any kind of extension, with VBOs–
I’m gonna talk about draw_texture
in a minute as well– you need to test the… I think it’s
glGetString(GL_EXTENSIONS). I have that in the next slide,
I think. That will just be a string of the extensions
that are supported, and you need to,
like, grep that, to make sure
that the functionality you want to use
is actually available in the device you’re running on. If you don’t do that,
and you run on a device that doesn’t have that thing, your game’s gonna crash, right? Fortunately, for something
like VBOs and quads, the actual interface
is so similar that it’s pretty easy
to write your code such that you can fall back
on the 1.0 implementation, if the, you know,
1.1 one doesn’t exist. And then there’s
the draw_texture extension, which is another extension that
you have to check existence for. And what it does is, it sort of just blits textures
to the screen. It’s very fast. The disadvantage
to the draw_texture extension is it can’t do rotation,
I think. So here’s a graph
of the relative speeds of these drawing mechanisms. This is basically
straight output from that SpriteMethodTest. At ten, what we have
on the left side is the number of Sprites
that it’s drawing, and on the bottom axis is the number
of milliseconds it took. And keep in mind that 16 milliseconds
is where you have to be in order to get 60 hertz. 32 milliseconds is where you
need to be to give you 30 hertz. So anything slower
than 32 milliseconds is probably gonna be an
unplayable real-time game, unless you’re making a game that
isn’t really that real-time. So, you know,
faster is better, right? So if we look at ten sprites, all of them
are pretty much the same. And the reason
they’re all the same is that,
like I said before, the hardware’s gonna block
on the page flip, right? On the previous frame
completing drawing. So with ten sprites, all of these methods, draw_texture and VBOs
and the Basic Quads and Canvas, can actually generate the frame in probably less than
60 milliseconds, and then the remainder
of the time it comes from
the hardware blocking. When we get up to 50 sprites, you can already see that Canvas
is starting to take off, right? It’s already starting
to slow down. And you can see,
real dramatically, as we get up to, like,
you know, 1,000 sprites, that Canvas is totally host. Actually,
the Basic Quads approach is totally host too. This is on the G1. It might be different
on other platforms. But for the G1, you know, that’s almost
as slow as Canvas, even though it’s
hardware-accelerated. VBOs actually hang in there
pretty good. They’re, you know,
easily twice as fast as the non-VBO version
of the same quads. And the draw_texture
just totally kicks ass. It does, you know,
slow down. “Oh, you’ve dropped down
to ten frames a second when they have a thousand
sprites on the screen.” But ten frames a second
is only 90 milliseconds. Way better than
362 milliseconds for Canvas. So, short answer is
you should use draw_texture, right? Especially if you’re making
a game that’s 2D. ForReplica Island,I used draw_texture for all
of the sprites on the screen, and, actually, I talk about
how I rendered the background. I experimented with draw_texture
for that as well. And here’s that thing
I already said. You must check this
glGetString(GL10.GL_EXTENSIONS) before you start
using these extensions, otherwise you won’t
be future-proof. However, like I said,
Canvas is really easy to use, and it might be
a total win for you if you don’t have
to update things every frame, or you have a type of game where you have very few things
to draw every frame. Because for small data sets, it’s more than capable. So this is the URL
for the SpriteMethodTests that I made. If you got a version of it
before about yesterday, it actually contained a bug
that I’m gonna talk about at the end of this talk, so you should grab
the source again. But it’s up on
code.google.com, and you can download it,
and you can look at it. It kind of provides
a framework, also, for how you might build
a 2D game. It’s very similar to what
I ended up writing forReplica Island.But it let’s you, you know, sort of generate an activity, then just swap out the rendering
mechanism pretty easily using the same
sort of simulation code. Okay, so I want to talk
a little bit about how I drew the backgrounds
forReplica Island.And the reason that I want
to talk about this is that background drawing
ends up being the most expensive operation in drawing by frame. It’s more expensive
than drawing with sprites. It’s more expensive than
calculating collision detection. It’s costly. So the wayReplica Islandworks is there’s actually
three parallax layers. One of them’s just
a static bitmap. It’s actually slightly larger
than the screen, so it scrolls, but very slowly. The second is a mid-ground layer that scrolls at some speed
slower than the main camera to sort of give
the illusion of depth, and then the foreground layer
is kind of what the character is standing on. It would be nice to have
more layers, right? Because then
I could have, like, a layer in front
of the character, like, a shadow layer, or some trees
that go in front of you, or something like that. But at this point, the game is not
quite fast enough for me to increase
the number of layers without having to decrease
something else. So if I decided to trade
the number of enemies I’m gonna put on the screen
for another layer, I could do that. But given the sort of
game fidelity that I want, I decided to cap it
at three layers. So each layer besides
the very background one, is drawn out of tiles, these little, small,
32×32 pixel squares, right? And those are reusable, and the reason
to do it that way is that then you can have
levels of any size. Your level just ends up
being this big array of tile and indexes, and all you have to do to draw is figure out which part
of that array you’re looking at given the camera, and then just go draw those
textures in the right spot, so you’re not limited
by the size of VRAM, you’re not limited
by the size of main memory. I guess you are,
but the actual tile map is very small. And the actual level maps
end up being very small, like 4k. So you can make levels
of pretty much any size. The bad part about this is that if you’re gonna
draw a layer that is completely full
of tiles, that means you’re gonna make,
like, 150 calls to this, like,
draw_texture extension, or whatever method
you choose to use, because each one of those tiles has to get drawn. And 150 calls to OpenGL, just right there,
based on the previous side, you should know that those
are all JNI calls, and no matter what
they actually do under the hood, I’m incurring some costs
to call those functions 150 times per layer, and I have two layers
that are like this, so you know, that’s 300 calls
per frame, right? That might be pretty costly. The other thing that I
actually did not run into but you could run into
on this sort of thing is that, you know,
some GL implementations have a fixed amount
of command buffer size, and if you overflow that, then it’s gonna start drawing
before you’re finished. Actually, I never hit that, but having that many GL calls for my sort of
rather simple frame seemed kind of wrong. So I tried a bunch
of different ways. Here’s what
those layers look like. There’s the background image, and then there’s the mid-ground, and there’s the foreground,
right? I tried to render this
a bunch of different ways, because it’s pretty slow,
and I wanted to make it better. And this is what they look like
when they get composited right. So I started out with
a really simple approach, and that was just to take this
thing called an atlas texture, which is just a texture that contains
all of the possible tiles in this particular level, and then use this
draw_texture extension to draw all the tiles
individually. And what I was gonna do is I was gonna select tiles out of this texture map by using
the glParameter() function, which allows you to set cropping on the texture, right? So I just, you know,
bind the texture once, and then set the crop and draw, and then
set the crop and draw, set the crop and draw, right? This is a terrible idea. It totally worked.
I mean, like, you know, it produced the output
that I expected, but it was really,
really slow. And I should have guessed that it was gonna be
really, really slow, because it turns out
that glTextureParameter() is a pretty slow function
to call, and that this produces
a lot of state change, and if you ever worked
on fixed-function hardware like this is, state change
is expensive. Any kind of state change
that you’re gonna apply. I mean, binding texture
can be expensive, right? So you want to, you know, avoid as much state change
as possible, and this is a huge amount
of state change, right? So, boy, this did not work. I mean, it looked all right, but it was really slow. So then I decided, well, instead of using
this atlas texture thing, I’ll cut it up
into individual, 32×32 textures, and then I’ll just call
draw_texture for those things, and I won’t ever have to change
the state of the texture itself once I’ve loaded it. Actually,
this works pretty well. You know, I have to make some adjustments
to the way that you draw, because if you’re gonna,
you know– If you have a loop
that’s walking over, like, a 2D array, in order to find all
the tiles that you need to draw, and you’re gonna iterate
over that array, like, 400 times per frame, that’s actually kind of slow
just right there. So I like sort of RLEing
the tile map and things like that, so that I can get through that
particular operation faster. But once those sort of
easy optimizations are out of the way, this actually works
pretty well. You still are calling,
you know, in the worst case especially, a lot of OpenGL calls. But it does draw,
and it does draw pretty fast in this sparse case. The nice thing
about this approach is that if
your tile map is sparse like those layers
that I just showed you were, you know, it doesn’t actually
have to do a lot of work. It kind of has to do some work to figure out
which tiles to draw, but the actual
number of draw calls is fairly small. So that was good. The problem is the worst case
from this is really bad. You know, you go up to, like,
9 to 13 milliseconds just to make the calls, and then, like, 19 to 23
milliseconds to draw, which is completely unacceptable
for a game like this. When both layers
are totally full of tiles, then you make, you know,
a huge number of draw calls, and it gets, like, really slow. So then I went back
to the meta-tile approach, but instead of drawing
with draw_texture, I decided to use VBOs, which I know are technically
slightly slower than draw_texture, but I figured
maybe in this case I could, you know, come up
with a way to use them that is a little bit faster. And what I ended up doing is I ended up
splitting the level into what I call
these meta tiles, which are basically just these,
like, regular grid of tiles that I defined with verts. And then I just UV
the atlas texture to them, so that they look correct for whatever the level says
they’re supposed to be there, and I split them such
that they’re about– I mean, in that level,
they’re probably about five tiles wide
by five tiles tall. I just want to get about
four of them on the screen. So there’s a pretty simple
algorithm for taking
the size of the screen and taking the size of the level
and cutting it up into these meta tiles. And then the nice thing
about that is that you only make, like,
four draw calls per frame, right? You’re only drawing
four meta tiles. And it just happens
that they’re larger than the regular tiles. The other good thing is that you only have to call
BindTexture() once for each of your layers, because,
like I said before, state change is slow, but you’re just gonna bind
those [indistinct]. It does take up more VRAM, but actually, you have
quite a lot of VRAM to work with on the G1, so it hasn’t been
a problem at all. The issue with this is, it’s actually not quite as fast as the draw_texture solution
in the previous slide in the average case, because being a sparse map doesn’t give it any advantage. In a case where there’s
no tiles at all in an entire meta tile, I could throw that
entire meta tile away, but in most of the cases, there’s, you know,
it’s pretty common that you’d be in a situation where there are, you know,
one or two tiles in there, and then you have to draw
the entire meta tile. So the worst case and the average case
are actually the same, which means it’s a huge
improvement for the worst case, but it means the average case
is a little bit slower. Still, it’s fast enough that I could probably get
to 60 hertz from here. I’m only about five milliseconds
away, at this point, so this is what
I ended up going with. Another way to do this
would have been to maybe pre-render the level into, like, a Canvas bitmap, and then cut that up
into different textures, and then assign those
to just very Basic Quads, and use that. The problem with that is that
it takes a lot of main memory. It takes a lot of VRAM, and the OpenGL
startup and shutdown that I talked about before would become really problematic, so I haven’t even
tried that yet. It would probably render
real fast, though. So I’m running out of time, but real quick, tips and tricks. You’re making a game,
you might have noticed that if you touch the screen
your frame rate drops. That’s because when you
touch the screen on Android, your application gets flooded
with MotionEvents. And the real easy solution to– We should probably solve this
in the API, but for now, the real solution is to sleep in the callback, because that will pause the thing
that’s generating the events and sending them to you long enough that your thread won’t context switch so much, and you won’t
get totally killed. There’s a balance
here too, right? Because if you sleep for too long
on your input callback, then you’re gonna start
dropping input events, and your control’s
not gonna feel as tight. But I think you’d probably
get away with 60 milliseconds, 32 milliseconds no problem, and that will pretty much
solve that problem. You will no longer see
a frame rate effect of just touching the screen. If you’re making a painting
application or something, you might not be able to sleep
for that long of time. The mechanics,
like I said before, of loading OpenGL memory up and reloading it up
when the contents are lost are fairly complicated, but fortunately there’s this
GLSurfaceView class that’s in the API right now that does all this for you. So use that as a reference, or just build your game
on top of that. I built my game
on a modified version of that. This is just a real quick point, but ATITC texture compression is available on the G1, but you wouldn’t know that unless you checked
the GL extension string. That’s why you should check it. And you have to sort of find what the GL enum
parameter numbers are and insert them yourself, but I’ve heard that because
we’re sort of bus-limited in a lot of cases, this can be
a huge improvement. So if you’re doing stuff
with a lot of texture, and you want to, you know,
increase the amount of texture you can push
over the bus every frame, you can look
at ATITC compression. And then this is the bug
that I talked about that SpriteMethodTest
suffered from before I fixed it yesterday. And that’s that up unt–
including Cupcake, we failed to throw an exception when you use indirect buffers
with OpenGL, which is actually against
the OpenGL spec, and what can happen
if you use indirect buffers is that the GC can move
your memory around and the OpenGL won’t know it. So just use direct buffers. The API’s
almost exactly the same. It’s pretty easy,
and it will fix the problem. But in Cupcake even right now, if you use indirect buffers, there’s no particular
error thrown. You might just get,
like, a random crash. In doughnuts,
it will throw an exception. Okay,
so game design tips. This is just
Android-specific advice for making a popular game. Keep it small, right? When people go to, you know,
delete stuff off their phone because they’re
running out of space, the applications get listed
in order of size. That game that I just
showed you,Replica Island,has, like,
a bunch of different enemies. It’s got five different,
like, world maps, and it’s gonna have,
like, 40 levels, and it clocks in at,
like, three megs. So you can very easily,
you know, if you choose the right
kind of art style, you choose data
that’s easy to compress, you can make a game
that is very small. You know,Super Mario World
runs on 512k. So you should try to optimize
the size of your application, because it’ll increase
your longevity. Make good games, right? The key to Android right now on the market is quality. You know, if you want to get
in that Featured Apps section, there’s no way to do it other than making something
that’s really cool, that we at Google like, but also
that all the users like. There’s no way
to pay your way in, or have a certain number of
downloads and then you get in, something like that. Just make something that
all the users like. I highly recommend that you
put some time in to polish, and to making something that’s really highly competent. And if you do that,
you’ll be ahead of the pack. Because there’s a lot of people who just like to, you know,
throw something up there that they wrote
in an evening, right? And the users
are really, really picky. They’ll really prefer something that looks like it has
a level of polish on it, or has nice art style,
or something like that, so I highly recommend that you focus
even a little bit on quality. It’ll set you apart. And then the last thing
I just wanted to say, although I’m doing this
out of order, is that not all devices
are gonna have the same input systems, and you should just be
cognizant of that. I’m using a trackball
for my game. I don’t know exactly how
it’s going to work when the Samsung,
you know, i7500 comes out, ’cause that has a D-pad. Probably you should just support
all of the input systems, because they’re already in the
framework for getting events, but if you don’t do that, you may have a game– Like, say you relied on the
hardware keyboard for your game, it’s not gonna be playable
on the Sapphire, right? So that’s something else
to be aware of. And that is pretty much my talk. Thank you very much
for coming today. [applause]
Thank you for listening, and I’m happy to answer
any questions. Please use the microphone. Oh, I’m sorry. Okay, I’m gonna answer
one question, and then I’m out of time,
because I ran long. So I think you’re up.
What’s up? man:
My question was about C++, whether game development
on Android can be done in C++… Pruett: Yes. man:
And how easy is that to do, and whether there will be
any sample apps for that platform. Pruett: Yes. Can you use C++
for your game development? Right now it’s really hard. Very soon we will ship something
called the NDK, which will allow you
to build C++ native components to your applications and then
call into them from Java, and then you can absolutely
use C++ to build your games. If you do that, though, you’re gonna tie your games to
whatever particular architecture you compiled that code for, which means
that you’re gonna lose a lot of the interoperability that Android sort of promises. So if you’re willing
to make that change or you’re willing to compile
from multiple architectures, then absolutely. And, in fact, we have games
up on market right now that are built that way, but as of right now,
it’s kind of a pain in the butt. Couple–Give us a little bit
of time to build it in. Okay, thank you very much. [no audio] Sorry. Sorry, just as you leave, if we can switch
to this machine… Oh, I have it here, don’t I? Here’s the feedback link. Please go give your feedback
about this talk and every other talk, ’cause we’d really
appreciate it. Thank you very much.