Graphical Content for Android Games

When you play a game on your favourite platform, it is easy to believe that the creation of the graphical content is purely ingenious or that it must require expertise within a team of staff to create such a thing. While this may be true for cutting edge games performing on powerful hardware, just like many industries, it depends purely on the content one wishes to create. In this way, Android offers itself to small development teams, even consisting of 1 or 2 members since mobile games are so compact compared to other platforms such as the PlayStation 3 or Xbox 360. For instance for the game Alkaline Labs has in production at this time one graphic artist will suffice, even though there are many units, models and maps etc to be created.

If you are starting out in the android game/app development world you should ask yourself some questions regarding the graphical content:

2D or 3D
Unless you have created a new dimension, your game will operate on either a 2 dimensional or 3 dimensional field. 2D graphics correlate with x and y coordinates (up and down to simplify), while 3D graphics include an additional z coordinate which deals with "depth" to create a virtual world, arguably with the same visual rules as the Universe we live in. Below is an example of a 2D game, the now classic "Angry Birds", followed by a 3D game for named "Light Racer 3D". Both were developed for Android, amongst other Operating Systems too.

"Angry Birds" by Rovio Mobile.

"Light Racer 3D" by Battery Powered Games.

Detail
Since we're working on mobile phones and tablets, the level of detail can be compromised greatly in comparison with platforms which use larger screens. This is incorporated into the hardware of these devices anyway and therefore a very high level of detail in your graphics will only cause performance problems (which are a huge no no). Games like Angry Birds are highly detailed, incorporating several layers of backgrounds and scenery around the already detailed playable areas. The developer operates on this level of detail since the game lends itself to small maps which keep the game's process concise. They also offer reduced scenery and sound disabling features on the game for less powerful phones.


Total Production Time
Another aspect you must consider is how long you are willing to spend developing said app/game. While one graphics artist may suffice in terms of the skill set required, whether that's you or someone else, you need to consider how long is the task is estimated to take. If time is not much of an issue, or if your game does not have a large demand for graphical content you may stick with one artist, but two or more for larger projects. This of course may not be possible for the vast majority of people, unless you are working in an established team.


 I will only touch upon the 2D graphical specifics from this point onwards as there is simply to much information to engage into with 3D within this post.

Android engineers have derived what are called APIs (Application Programming Interface) to give developers all they need to create their applications/games. Naturally these offer different means of managing your graphical content. Android specifically has a handful of graphics APIs, "Canvas" and "OpenGL ES" being the main two in terms of use and features in the development community. Canvas is appropriate for less demanding graphics in general, while OpenGL ES being the power house which you can rely on for graphically intense applications/games. Games are the main users of OpenGL ES as they often require significant power, while Canvas and other APIs of this nature suit applications which are generally not demanding at all.

Android accepts JPEG and PNG formats for graphical content with the option of 8, 16, 24 and 32 bits for the color storage information. If this sounds like gibberish then I suggest reading up elsewhere on this as it is basic knowledge which is most definitely required. It should be noted that JPEGs are are compression format, and PNGs are a lossless format and therefore it is justified to offer them both to developers. Unless you want to strain your users eyes, I would personally recommend PNGs every time as JPEGs tend to pixelate greatly, which is highly undesirable for games, while not such an issue for general applications. Another benefit of PNGs is that they store the alpha values of pixels in the image file which can be invaluable to overlay graphics over others. JPEGs do not store the alpha values and so only decrease their usefulness.

If you are using OpenGL ES for your graphical needs, you will have to provide it with graphic files with power of 2 dimensions, e.g. 256x128, 1024x512, all in pixels, notably. This is a technical issue and is not a real problem. You do not by any means have to fill the image file with data that you will use, for example you could place 3 maps within the file and specify alpha values of 0 for any unused sections of the file, although since you will not be asking OpenGL ES to render this unused data, you can simply leave it as it if by default. It is a good idea to keep relevant images in these "Texture Atlases" as they are called, for organization and also optimization in your game.
For now, that is all.
Tweet