Getting Started in Android Game Development

If you're interested in developing a game for the Android platform, there is a lot you need to know.  I'm the developer of Light Racer, Light Racer 3D, Antigen, Deadly Chambers and Wixel, which are currently available on the Android Market. I've also been involved with the development of about 5 other games for Android and iOS and am co-author of Beginning Android Games 2nd Edition.  I've developed games before but the original Light Racer was my first Android application and I learned quite a bit about writing Android games that I'd like to share with everyone.  I even wrote an online book detailing the development of Light Racer 3D, which is full of how-tos and useful code snippets. If you have previous experience with game development, moving over to the mobile platform won't be all that difficult.  You will mostly just need to learn the architecture and API.  If you're new to game development, I have assembled a list of must-knows for getting started.  They apply to many different types of games, including action, strategy, simulation and puzzle.

Android is a Java-based environment.  This is nice for new developers as Java is widely accepted as a much easier language to get started in than C++, which is the norm for mobile development and is what I use now.  Google has also done an excellent job with documenting the API and providing examples to use.  There is an example to show functionality for almost 100% of the API, called API Demos.  If you're familiar with Java and have already used Eclipse, getting your first app working should be fairly simple.  If you've never coded anything in your life before, you will have a lot to absorb as you move forward, but don't get discouraged. If you have some experience and are wanting to develop a cross-platform game or high-performance Android game in C++, check out BatteryTech, which is a platform I wrote and am currently using for game development.

Get the SDK

The first step in getting started with the Android platform is to get the Android SDK (Software Development Kit).  The SDK has the core libraries, an emulator, tools and sample code.  I highly recommend using Eclipse and the android eclipse plugin.  Eclipse IDE for Java Developers is fine if you are just doing Android.  If this is your first Java development project, you will want to download the full Java SE Development Kit (JDK) as it contains tools you will need for signing and deploying your application.

Learn the application architecture

As tempting as it may seem to just dive right in, it's very important to understand the android application architecture.  If you don't learn it, you may design things in such a way that will make it very difficult to fix problems with your game down the line.  You will want to understand Applications, Activities, Intents and how they are all related to each other.  Google has provided good information on the architecture here.  The really important thing is to understand why your game may need to consist of more than one Activity and what that means to designing a game with good user experience.  This is where things tie in to the Activity lifecycle.

Learn the activity lifecycle

The activity lifecycle is managed by the Android OS.  Your activity will be created, resumed, paused and destroyed as the OS dictates.  Handling these events correctly is very important to having an application that behaves well and does what the user perceives as correct.  It's very good to know how all of this works before you start designing your game because you will save yourself debugging time and costly redesign time later on.  For most applications, the default settings will work but for games, you may want to consider turning the SingleInstance flag on.  When set as default, android will create new instances of the activity as it sees fit.  For a game, you may only want to have 1 instance of the game activity.  This has some implications for how you need to manage the state of things but for me it solved some resource management issues and it should be considered.

The main loop

Depending on what type of game you are writing, you may or may not have a main loop.  If your game is not time-dependent or if it only responds to what the user does and will wait forever for user input without making any kind of visual changes, you may not need a main loop.  If you are writing an action game or a game that has animations, timers or any kind of automation, you should seriously consider using a main loop.

The main loop of a game is the part that "ticks" sub systems in a specific order and usually as many times per second as possible.  Your main loop will need to run on its own thread.  The reason for this is that Android has a main UI thread and if you don't run your own thread, the UI thread will be blocked by your game which will cause the Android OS to not be able to handle any of its normal update tasks. The order of execution is usually as follows:  State, Input, AI, Physics, Animation, Sound and Video. 

Updating State means to manage state transitions, such as a game over, character select or next level.  Often times you will want to wait a few seconds on a state and the State management is the part that should handle this delay and setting the next state after the time has passed.

Input is any key, scroll or touch from the user.  It's important to handle this before processing Physics because often times input will affect the physics so processing input first will make the game more responsive.  In Android, the input events come in from the main UI thread and so you must code to buffer the input so that your main loop can pick it up when the time comes.  This is not a difficult task.  Defining a field for the next user input and having the onKeyPressed or onTouchEvent set the next user action into that field is all that will be required.  All the Input update needs to do at that point is determine if it is valid input given the state of the game and let the Physics side handle responding to it. 

The AI update is analagous to a user deciding what they are going to "press" next.  Learning how to write AI is out of the scope of this article but the general idea is that the AI will press buttons just like the user does.  This will also be picked up and responded to by the Physics update.

The Physics update may or may not be actual physics.  For action games, the point of it is to take into account the last time it was updated, the current time it is being updated at, the user input and the AI input and determine where everything needs to be and whether any collisions have occured.  For a game where you visually grab pieces and slide them around, it will be the part that is sliding the piece or letting it drop into place.  For a trivia game, it would be the part deciding if the answer is right or wrong.  You may name yours something else, but every game has a part that is the red meat of the game engine and for this article, I'm referring to it as Physics.

Animations aren't as simple as just putting an animated gif into your game.  You will need to have the game draw each frame at the right time.  It's not as difficult as it sounds.  Keeping state fields like isDancing, danceFrame and lastDanceFrameTime allows for the Animation update to determine if its time to switch to the next frame.  That's all the animation update really does.  Actually displaying the change of animation is handled by the video update.
The Sound update handles triggering sounds, stopping sounds, changing volumes and changing the pitch of sounds.  Normally when writing a game, the sound update would actually produce a stream of bytes to be delivered to the sound buffer but Android manages its own sounds so your options for games are to use SoundPool or MediaPlayer.  They are both a little sensitive but know that because of some low level implementation details, small, low bitrate OGGs will yield the best performance results and the best stability.

The Video update takes into account the state of the game, the positions of players, scores, statuses, etc and draws everything to screen.  If using a main loop, you will want to use the SurfaceView and do a "push" draw.  With other views, the view itself will call the draw operation and the main loop won't have to do it.  SurfaceView gives the highest frames per second and is the most appropriate for games with animation or moving parts on screen.  All the video update should do is take the state of the game and draw it for this instance in time.  Any other automation is better handled by a different update task.

What's this code look like?  Here's an example.

public void run() {
    while (isRunning) {
        while (isPaused && isRunning) {

private void update() {

3D or 2D?

Before you start on your game, you need to decide if you're going to go 3D or 2D.  2D games have a much lower learning curve and generally are easier to get good performance on.  3D games require much more in-depth math skills and may have performance issues if you are not very careful.  They also require the ability to use modeling tools like 3D Studio and Maya if you intend to have shapes more complex than Boxes and Circles.  Android supports OpenGL for 3D programming and there are many good tutorials on OpenGL that one can find to learn it.

Build simple, high quality methods

When getting started, make sure that you avoid writing one big long monolithic method that is "the game."  If you follow the main loop pattern that I described above, this should be fairly easy.  Each method you write should accomplish one very specific task and it should do so error-free.  For example, if you need to shuffle a deck of cards, you should have a method called "shuffleCards" and that should be all it does. 

This is a coding practice that applies to all software development but it's particularly important in game development.  Debugging can get very difficult in a stateful, real-time system.  Keep your methods small and the general rule of thumb is that each method should have 1 and only 1 purpose.  If you're going to programatically draw a background for a scene, you may want a method called "drawBackground."  Things like that will make it so that you develop your game in terms of building blocks and you will continue to be able to add what you need without making it too complex to understand.
It's all about efficiency!

Performance is a major issue for any game.  The goal is to make the game as responsive as possible and to also look as smooth as possible.  Certain methods like Canvas.drawLine are going to be slow.  Also drawing an entire screen-sized bitmap onto the main canvas every frame will also be costly.  Balancing things like that is necessary to achieve the best performance.  Make sure to manage your resources well and use tricks to use the least amount of CPU to achieve your task.  Even the best game will not be very fun if it can't perform well.  People in general have little tolerance for choppiness or poor response.

Tips and Tricks

Take a look at the example for LunarLander in the SDK.  It uses a SurfaceView and that would be the appropriate view to use for a game that needs the highest number of frames per second possible.  If you're going 3D, take a look at GLSurfaceView. It takes care of the OpenGL device initialization and provides a mechanism for rendering.  For LightRacer, I had to optimize the way I have everything drawn or else the framerate would be drastically lower.  I drew the background to a Bitmap only once which was when the view is initialized.  The light trails are in their own bitmap which gets updated as the racers move.  Those two bitmaps are drawn to the main canvas every frame with the racers drawn on top and then finally an explosion.  This technique made the game run at a playable rate.

It's also a good practice to have your bitmaps be the exact size you intend to draw them on screen, if applicable.  This makes it so that no scaling is needed and will save some CPU.

Use a consistent Bitmap Configuration (like RGBA8888) throughout the game.  This will save the graphics library CPU in having to translate the different formats.

If you're determined to develop a 3D game but have no 3D knowledge, you will want to pick up a book or two on 3D game programming and study up on linear algebra.  At a bare minimum, you must understand dot products, cross products, vectors, unit vectors, normals, matrixes and translation.  The best book I have come across for this math is called Mathematics for 3D Game Programming and Computer Graphics.

Keep the sound small and at a low bitrate.  The less there is to load, the faster loading times will be and the less memory the game will use.

Use OGGs for sound, PNGs for graphics.

Make sure to release all media players and null out all of your resources when the activity is destroyed.  This will ensure that the garbage collector gets to everything and that you don't have any memory leaks between launches of the game.

Join the Android Google group and find community support.  There will be people that can help you along the way.

Above all, spend time testing and retesting and making sure that every little thing works exactly the way you would expect it to.  Polishing the game up is the longest and hardest part of development.  If you rush it out to market, you will probably have a disappointed crowd and you may feel that all your hard work is wasted.  It's not possible to have 100% of people love what you write but you should at least try to put out the highest quality work that you can.

Google has excellent documentation for getting started here.

Find working game code samples and how-tos in the Light Racer 3D Development Journal

Need a book recommendation? Try Beginning Android Games 2nd Edition by Mario Zechner and Myself (Author of libgdx and friend of mine).

Finally, Battery Powered Games offers pro Android (and iOS) game development consulting services so if your company has a need to contract out mobile game development, that's the place to go!


Post a comment here or discuss this and other topics in the forums

I use updateState as kind of

I use updateState as kind of a state-machine game script.

if (state == STATE_RUNNING) {
// if player has died switch to STATE_CONTINUE_PROMPT
// show continue prompt, wait for input

updateInput processes input and sets values in the world to reflect it.
updateAI in some of my games runs path finding algorithms and makes decisions
updatePhysics moves and collides everything based on input and AI
updateAnimations changes the visible animations
updateSound plays any sounds that should be triggered, started or stopped

You can do it however you want and my update sequence is a little different for every game I do.

Meaning of Gameloop

Hi Robert,

That was a very good article, it has helped me tremendously in understanding the principles of games development. I am bit stuck though with what each section within the game loop actually does. For example what does updateState() do etc etc. I would be greatful if you could shed some light on this or point me to a place where it is clarified. Information on the below would be amazing, also if there additional methods I could/would need to call.



thanks so much

Thank you so much for this article.


Did you tried Angle?

Check it:

It's very easy to use and you can create great games with it.

Good call.

I was building my game around this Handler principle for a while, but I found animations were bogging down, so I'm gonna switch to a SurfaceView multi-thread process to animate my game. It'll be a lot of work; I hope it'll see some good results. I think dividing the UI thread and the game engine will be good for code separation as well.

Thank you!

This article is extremely helpful for me. Thank you very much.

Thankyou, that was a great

Thankyou, that was a great help.

Hi Robert, Thanks for

Hi Robert,
Thanks for your Great Article..

Each menu screen is an

Each menu screen is an activity and that is all standard Android UI. The text box in-game is a textured quad. I upload the texture every time the text changes, but in my new engine, I have a character atlas and so I can draw out whatever text I need to without uploading anything.

Thank you

Thanks a lot for your article... It has helped me out with a few issues i had..

Title screens

Very interesting, especially the videos showing how things come together.

I've a question about the 3D version. How are you doing the menus? Is each 'page' a separate Activity with standard Android UI widgets on or are you drawing it all by hand?

And during the game, how are you drawing the 'Game over' box that appears?

I'm making my own game and I was thinking about just drawing all that stuff using textured shapes, but it seems there should be a better way.

Thank you so much for the

Thank you so much for the feedback...will be performing some tests later based on your comments

Greg, A drawable is a


A drawable is a resource that is exactly that - drawable. It is a bitmap or a gradient or a 9-patch, color.. stuff like that. In games you use bitmaps. If someone is using a drawable, it's because of a matter of convenience. Perhaps they only needed to do a simple draw and never actually needed the bitmap data. That's fine.

I load everything into Bitmaps because I use canvas.drawBitmap for 2D stuff. Actually I do everything in OpenGL now but if I were to keep doing canvas-based 2D, it would be that.

For having a large, scrollable background, I recommend using tiles. You can either use micro tiles and have a level editor to place them or you can use macro tiles (big chunks of land) and just know the arrangement of them. When I say micro tiles, I mean like Super Mario Brothers style, where you have a tile for bricks, a tile for ground, etc.. Macro is like if you have an image that is 640x1920 that you want to scroll through, you can break it up into 320x480 tiles and only draw the current 2-4 tiles that you need to see a 320x480 screen of image. You can obviously go smaller than that and draw 160x160 tiles or something which would work nicely for those dimensions.

Tiles are nice because they are less bytes that you have to work with at a time and you can make larger maps with them if you're clever and reuse some. I don't know what would be causing your jitter. If you're working with really large bitmaps, it could be that. You'd need to debug a little further to figure it out - IE, try it without the background drawing code in.

Drawable Vs Bitmap?

Thanks for this great information, it has been very useful as an overarching conceptual guide to programming a game for a beginner. I have a very specific question though...

There seems to be many ways to do a particular thing. For example, in the Lunar Lander example, the Background is drawn as a Bitmap and the image of the spacecraft is of type "Drawable." I haven't found any clear documentation as to what a Drawable is and how it differs from a Bitmap. Why not just draw the image of the spacecraft as a bitmap? When should Drawables be used vs bitmaps from an efficiency standpoint?

I am asking this because I have an action type game with a background that is bigger than the canvas size so I allow users to scroll around to reach all parts of the background. I also have maybe 15 other objects (3K-5K each or so) that I am drawing as bitmaps fixed on this background. When the user scrolls a jitter effect occurs as the objects are redrawn from what I am assuming is the delay between drawing the new background view and the new location of the objects. Would drawables be more appropriate for these objects? Or some other approach entirely?

I am redrawing the background by using the canvas.drawBitmap (bitmap, RectSrc, RectDst, paint) function and having the RectSrc be the canvas size and RectDst the Rect surrounding the new bounds of the background that should be case this could be the culprit.

Thanks again for this great article!


I was referring to the Kube and other 3D examples that were provided with Android 1.1. One of those had a class called GLView in them. I now recommend using 1.5's GLSurfaceView. The text has been updated to reflect this.

good 3D tutorial

"If you're going 3D, there is a GLView in the examples that handles a lot of initialization required to get a 3D display."

i don't see a GLView in the sdk's examples.

G8 article. I m new 2 game

G8 article. I m new 2 game development. Its inspiring . Hope it will help us.


Excellent Article

That works though I believe

That works though I believe that using a thread offers a little less CPU overhead and a little more control for you. Effectively what your code does is it has the UI thread drive your game. This is fine but if the UI thread gets busy for more than 100ms, you'll definitely see the result.

ticks without main loop and thread

When I programmed a TETRIS, and I was thinking a long time on how to avoid a thread.
Here is my result:

import android.os.Handler;
public class Tetris extends Activity implements OnClickListener {
class TickHandler extends Handler {
public void handleMessage(Message msg) {
... // do your update() here
public void Trigger() {
sendMessageDelayed(obtainMessage(0), TickTime);

The Hander goes into the same queue as the OnClickListener and the Activity's onKeyDown.

Excellent Sir.. thank you so

Excellent Sir.. thank you so much for being selfless..

Great Article

This helped me a lot. I am just a beginner to game development.

New to This

Hi :)

Great article and information! It would be nice to have complete code to show how it all comes together.
I am particulary interested in developing simple apps to start allowing the user to select from various custom wallpaper images I create.
I am becoming familiar with java and have Eclipse and all the SDK's installed and working.
My talent lies mostly in 3d but is there simple code to create a basic wallpaper app? or would you be willing to share some insight and tips :)

Thank you!!

Great article

Great article, thanks for all the start off points. Im an iphone developer and im moving into the android field, because I have some hunch that the phone will become more popular that the iPhone. Google just has too much money to mess this up. Cant wait to see what happens!

Sorry, Light Racer is not

Sorry, Light Racer is not an open source game. I'm supporting myself by developing games derived from that codebase and while my newest engine is very far away from where Light Racer was, I still can not afford to release that code. I hope I gave enough snippets to help people out with the general game development issues. If not, go ahead and ask for anything specific and I'll see what I can do.

where is the code of this game...

please share the code of atleast Light Racer 2D, so that we can understand more...
BTW great article and very clear.


thank you

thanks for this great intro.

Android will surpass the iPhone

Great article. There needs to be information on how to developer android based applications, because in my opinion it is the next wave for mobile phone development. With the nexus one coming out in 2010 and the Firefox mobile viewer, it should be easier than ever to create apps. Oh and did I mention? Firefox mobile will not be available on the iPhone, but rather the android and blackberry!

Great article!

This is one of the best intros I've read(and I've read a lot).

I'm not new to game programming, but I'm just starting out on Android and still learning my way around the SDK.

Your tips on best practices are very helpful. I'm glad to see people like you in the Android community and I have great hopes for Android's future.


This is really good one :D,

This is really good one :D, and hi everyone I'm newbie in Android also, nice to meet yall