Path Blog: Game Development for Android: A Quick Primer

[This post is by Chris Pruett, an outward-facing Androider who focuses upon the world of games. Tim Bray]

If we attended Google I/O this year, we competence have beheld the large series of diversion developers showing off their stuff in the Android part of the Developer Sandbox. Unity, EA, Com2Us, Polarbit, Laminar Research, as well as multiform others demonstrated high-end games regulating upon Android devices. Part of my role as the Game Developer Advocate for Android is to margin requests for report about Android from diversion developers, as well as in the last six months the series of requests has gone by the roof. Since theres clearly the huge amount of seductiveness in Android diversion development, heres an overview of how Android games work as well as what we as the developer should know.

Step One: Decide upon the Target Device Class

There have been basically dual types of inclination regulating Android which we should consider: lower-end inclination identical to the G1 (which Ill call initial era devices), as well as high-end inclination identical to the Nexus One (second era devices). Though there have been the lot of opposite Android phones upon the market, they fall rsther than neatly in to these dual classes when it comes to CPU as well as graphics performance, which have been the variables which diversion developers customarily caring the most about.

First era inclination have been in all phones with HVGA screens, regulating Android 1.5 or 1.6 (though the couple of have been starting to make their approach to 2.1), typically with an 500mhz CPU as well as hardware accelerated OpenGL ES 1.0 backend. A large series of inclination sport internals identical to the G1 (Qualcomm MSM7K CPU/GPU during ~500mhz), so the G1 is representative of this category (and can be safely considered the low finish of the spectrum). Based upon my tests, these inclination can pull about 5000 textured, colored, dark vertices per await as well as still say thirty frames per second. Using OpenGL ES to draw, we can get only over 250 animating sprites upon the screen during thirty frames per second (at 60 fps we can pull only over 100 sprites per frame). These arent tough numbers; my benchmarks have been sincerely primitive, as well as Im certain which they can be improved (for example, we havent finished tests regulating the GL_OES_point_sprite extension, which the G1 supports). But they should give we an idea of what the initial era category of inclination can do.

Second era inclination in all have WVGA screens, most faster CPUs as well as GPUs, as well as await for OpenGL ES 2.0. The Nexus One as well as Verizon Droid by Motorola have been both good examples of this class. These inclination seem to be about 5x faster than the initial era inclination when it comes to raw OpenGL 1.0 opening (I can get during least 27,000 textured dark colored vertices per await during thirty frames per second upon all of the second era inclination Ive tested). Using OpenGL ES 2.0 can be even faster, as these inclination typically catch the little overhead translating OpenGL ES 1.0 commands to their 2.0-native graphics hardware. However, the large screens upon these inclination often meant which they have been fill-bound: the cost of stuffing the screen with pixels is high sufficient which its often not probable to pull faster than thirty frames per second, regardless of stage complexity.

Since there is the pretty wide opening delta between the initial era category of inclination as well as the second, we should be clever when selecting the target. Based upon the metrics about Android versions, initial era inclination represent over half of all of the Android phones upon the marketplace (as of this writing, anyway; 2.0 inclination have been flourishing very quickly). Those games which have been means to scale between the initial as well as second era inclination have the largest audience.

Step Two: Pick the Language

If youre an Android app programmer whos meditative about getting in to diversion development, chances have been we have been formulation upon writing formula in Java. If youre the diversion growth veteran whos meditative of bringing games to Android, its likely which we prefer to do all in C++.

The side-scrolling action diversion which we wrote, Replica Island, is entirely Java. It uses OpenGL ES 1.0 to pull as well as is backwards concordant to Android 1.5. It runs during the good await rate (close to 60 fps upon the G1) across almost all Android devices. In fact, most of the renouned games upon Android Market were created in Java, so if youre the sort of chairman who finds coding in C++ identical to vocalization in tongues, we can rest easy in the believe which Java upon Android is ideally viable for games.

That said, local formula is the approach to go if your diversion needs to run as quick as possible. Weve only released the fourth rider of the Native Development Kit for Android, as well as it includes the series of improvements which have been particularly utilitarian to diversion developers. Using the NDK, we can accumulate your formula in to the shared library, hang it in the thin Java bombard to conduct submit as well as lifecycle events, as well as do all of the complicated lifting in C++ with regular OpenGL ES APIs. As of Revision 4, we can additionally pull without delay in to Java Bitmap pixel buffers from local code, which should be faster than loading bitmaps as GL textures each await for 2D games which wish to do their own stage compositing. Revision 4 additionally (finally!) includes gdb await for debugging your local formula upon the device.

You should know which when regulating the NDK, we dont have access to Android Framework APIs. Theres no way, for example, to fool around audio from C++ (though we announced during Google I/O the goal to await OpenSL ES in the future). Some developers make make use of of the AudioTrack API to share the direct aegis with local formula which mixes as well as generates the PCM tide upon the fly, as well as most call from C++ in to the Java SoundPool interface. Just be aware which for this sort of work, the jump by JNI back in to Java formula is required.

Step Three: Carefully Design the Best Game Ever

Once we have the target complement spec as well as have motionless upon the growth environment, youre off as well as running. But prior to we get as well deep in to your epic ragdoll physics-based space sea action online RPG with branching endings as well as the morality system, take the minute to consider about your finish users. Specifically, there have been dual areas which need consideration for Android games which we competence not be used to: hardness duplicate as well as submit systems.

Texture duplicate is the approach to (surprise!) compress your hardness data. It can urge pull opening as well as let we container some-more hardness in to vram. The problem with hardness duplicate is which opposite graphics card vendors await opposite hardness formats. The G1 as well as alternative MSM7k inclination await ATIs ATITC duplicate format. The Droid supports PowerVRs PVRTC format. Nvidias Tegra2 height supports the DXT format. The bad headlines is, these formats have been not compatible. The good headlines is, all OpenGL ES 2.0 inclination (including the Snapdragon-based Nexus One, the OMAP3-based Droid, as well as Tegra2 devices) await the common format called ETC1. ETC1 isnt the best hardness format (it lacks await for alpha channels), as well as it isnt upheld upon the initial era devices, though its the most common format upheld (the Android SDK provides the compressor duplicate (see sdk/tools/etc1tool) as well as runtime collection for this format).

The bottom line is which if we compress your textures, youll need to somehow provide opposite versions of those textures compressed with opposite formats. You could do this all in the single apk, or we could download textures from the web site over HTTP, or we could make make use of of ETC1 as well as shorten yourself to only OpenGL ES 2.0 devices. For Replica Island, we only chose not to compress my textures during all as well as had no problems. You can query the GL_EXTENSIONS fibre to see what the device we have been currently regulating upon supports.

String extensions = gl.glGetString(GL10.GL_EXTENSIONS);String chronicle = gl.glGetString(GL10.GL_VERSION);String renderer = gl.glGetString(GL10.GL_RENDERER);boolean isSoftwareRenderer = renderer.contains("PixelFlinger");boolean isOpenGL10 = version.contains("1.0");boolean supportsDrawTexture = extensions.contains("draw_texture"); // seeking for "GL_OES_draw_texture"boolean supportsETC1 = extensions.contains("ETC1"); // seeking for "GL_OES_compressed_ETC1_RGB8_texture"// VBOs have been upon trial in GLES1.1, though they were an prolongation underneath 1.0.// There's no point in regulating VBOs when regulating the program renderer (though they have been supported).boolean supportsVBOs = !isSoftwareRenderer && (!isOpenGL10 || extensions.contains("vertex_buffer_object"));

You should additionally consider delicately about how your diversion will be played. Some phones have the trackball, the little have the directional pad, the little have the hardware keyboard, the little await multitouch screens. Others have none of those things. Per the Compatibility Definition Document, all Android inclination which have Android Market have been required to have the hold screen as well as three-axis accelerometer, so if we can get divided with only lean as well as single touch, we dont need to worry about submit much. If we wish to take value of the assorted submit inclination which these phones await (which, based upon multiform thousand comments upon Android Market about Replica Island, we wholeheartedly recommend), the Android API will package the events up for we in the standard way.

That said, the single of the most dramatic lessons we learned after shipping Replica Island is which users wish customizable controls. Even if we have combined perfect await for each phone, most users will wish to go in as well as tweak it. Or they prefer the hardware set of keys over their phones dpad. Or they prefer lean controls over trackball controls. My advice: plan upon providing customizable controls, both so which we can await phones which have submit configurations which we didnt consider, as well as additionally so which we can concede users to tweak the experience to match their preferences.

Step Four: Profit!

The rest is up to you. But prior to we go, heres the couple of resources which competence come in handy:

HeightMapProfiler. This is the elementary 3D benchmarking apparatus which we wrote. It is the source of the opening numbers in this post. You can additionally make make use of of it to exam how assorted GL state affects opening upon your device (texture size, hardness filtering, mip-mapping, etc).
SpriteMethodTest. Another elementary benchmarking tool, this the single for goddess drawing. This formula is additionally the utilitarian as the 2D diversion skeleton application.
GLSurfaceView. This is the Java category which creates it pardonable to set up an OpenGL ES application. You can make make use of of this formula in combination with the NDK or with Java alone.
Quake Port. The complete source for an Android pier of Quake has been done available by Jack Palevich, an Android group engineer. Its the good sample of how to brew Java as well as local code, how to download textures to the sdcard over HTTP, as well as all kinds of alternative cool stuff (check out his memory-mapped-to-sdcard hardness manager).
Replica Island. Heres the complete source to my game, released underneath Apache2. Use it as the reference, or to make your own games.