One of the most important characteristics of a sprite image is transparency (also called the alpha channel). The image must be combined with underlying graphics (with backgrounds or other sprites) at the game screen, creating an appearance of a solid picture. Some decades ago, when computers had no such advanced calculating power, the sprites were small, and the simplest form of transparency was used. Each pixel could be turned on or off, so the images featured so called hard edges ; there was no soft transition between a transparent pixel and an opaque one. To mark a zone in the image which would be transparent, a special color was used; usually, it was a color never featured in the drawn artwork, for example, magenta (sometimes developers called it magic pink ). The sprites with such transparency had sharp contour and worked well only on graphic video systems with a small resolution.

Nowadays, most platforms, including mobile devices, support a more complex type of transparency called alpha channel that supports shades of opacity. With this, smooth transitions and translucent elements can be displayed. In most cases, the PNG file format is used for sprites. It is lossless, no pixels will be lost after exporting the image, and by default, the image editing tools create PNGs with a straight (non-premultiplied) alpha channel. The term straight means that pixels have no precalculated data for compositing, the only information is the exact RGB value and the alpha channel (colors and alpha are not interconnected; a value of transparency cannot distort values in color channels). On the other hand, premultiplied type of transparency (color and alpha channels are interconnected and by changing alpha information you also change the RGB values) is in demand, because of its efficiency, natural behavior, and being compression friendly, but PNG by default cannot work with it. This is why some developers try to choose TGA or TIFF, which support both types of alpha channels, or try to find third-party tools to convert the straight alpha channel type of transparency in PNG to premultiplied. Besides normal transparency, game engines can also offer some additional modes when creating the final scene is a bit more complex, which let us create interesting visual effects. For instance, the Multiply mode, where dark pixels of foreground images are added to the background but white ones are ignored, helps to create shadows. A Screen mode is the opposite of Multiply; it lets us light up some elements, creating the illusion of reflections, hotspots, and so on.

iOS devices also support a specific type of texture compression called PowerVR Texture Compression (PVRTC), created especially for effective storing and using of raster images; the files themselves are frequently referred to simply as PVRs. The file format is native for the PowerVR GPU used in iOS devices (and some other platforms, so the format is pretty universal), so it is accurately optimized for graphic hardware and uses advanced methods of data compression (up to 8:1).

PVRTC does not required software-based decompression, images take less volume of memory, there are lesser amounts of data to be transferred, and is managed by the hardware; therefore, the files are rendered much faster than traditional PNG. The performance and thrifty usage of memory resources are the main advantages of the format. But there some disadvantages; first of all, the compression algorithm is lossy, so some portion of graphical information is lost and there can be some visual artifacts. This can be critical for elements that require some pixel accuracy, for instance, UI elements. In this connection, it is wise to strike a compromise and use PNG for static elements with a lot of small fragments but PVRTC for texturing fast objects where the ideal quality is not an issue.

Another problem with PVRTC is some lack of support from popular graphics software; there is no native support for it by default; special plug-ins are needed. Nevertheless, the issue can be solved by compressing tools with the official cross-platform software suite PVRTexTool (http://www.imgtec.com/powervr/insider/powervr-pvrtextool.asp). There are also some specific requirements for images: they should be square and their dimensions must be in the power of two, but in most cases that is not onerous at all. The following screenshot shows the tile sheet from a puzzle game Rail Maze developed by Spooky House Studios UG (haftungsbeschränkt):

The sprites and tiles are not usually stored as single images because there are dozens of sprites in games and the content folder would be crowded with image files. It is more convenient to collate them in special graphic sheets stored in large image files. The sprite sheet (alternatively, texture atlas) is divided into small fragments in which each sprite fits. The size of the fragment depends on the game ; usually, sprite width and height are multiples of eight—something like 64 x 64 pixels or 128 x 64 pixels, 128 x 128 pixels, and so on. The sprite sheets in turn are much larger; their maximum dimensions depend on the specifications of a device as shown in the following table:

To calculate how much space a sprite sheet in PNG format will occupy in graphics memory, a simple formula can be constructed. Standard bitmaps are used in uncompressed form, so the content is irrelevant; only dimensions matter. It is known that there are four channels in PNG, colors and alpha, each one is described by a byte of data. The formula is as follows:

(Height x Width x 4)/(1024 x 1024) = space in megabytes

For example, a texture of 512 x 512 pixels occupies 1 MB of memory, 1024 x 1024 pixels in turn occupies 4 MB, and so on. To get an idea of hardware resources, including the amount of RAM for iOS devices, it is good to look at the special table published at http://docs.unity3d.com/Documentation/Manual/iphone-Hardware.html.

There are special applications that can help to create and manage sprite sheets, for instance, a very popular tool Texture Packer (http://www.codeandweb.com/texturepacker) designed by Andreas Löw. It supports many compression algorithms, including PVRTC, and works with many actual game engines, such as Cocos 2d, Corona SDK, Sparrow, Unity, and so on. Texture Packer also features a handy drag-and-drop interface, as well as a bunch of various settings for texture sheets, letting us tune them deeply. The great advantage of this application is the ability to convert default PNGs into their analogs with a premultiplied alpha channel.

Alternatively, sheets can be developed in standard graphics editors, such as Adobe Illustrator. The only point to note is that some routine operations are performed manually. According to my experience, it is better to draw and export the sprites (or tiles) one-by-one, and then collect the exported images in the sheet file. In other words, you need to have some files only for drawing sprites (let's call them canvases ) and one file to organize the final illustration in the sheet (let's call it a sprite collector ). First of all, this speeds up the exporting routine: if the source file for the sprite sheet consisted not of linked raster files but real vector illustrations, it would make exporting the final file a much longer process. Secondly, it offers protection from shadow artifacts: images are the sprite sheets that stay tight, so some elements of one illustration would overlap the illustration nearby a little bit for sure. Usually, the edges of soft shadows lean out of the sprite's frames; as a result, some sprites or tiles get unnecessary dark lines. In the sprite collector, there won't be such a problem, because each sprite is already an exported image and has appropriate dimensions.

The dimensions and position of tiles inside sprite sheets should be chosen properly; otherwise, there is some risk of visual artifacts such as thin faded lines at edges caused by compression. They look ugly and are easy noticeable even on Retina displays. Remember that OpenGL likes fours—sizes of texture elements should be multiples of four to achieve better results (this is because, at the time of encoding, an image is split into blocks of 4 x 4 pixels). Some examples of the sizes of texture elements are 64, 128, 256, and so on. It is obligatory to have a grid system in the sheet file. It will help you to determine the exact position and borders of each sprite. The grid should be made of translucent rectangles arranged in chess-board order. This is a much more precise way than a grid based on guides. The rectangles must be placed on a separate layer; this lets you to switch them on and off. One of the advantages of this type of grid is an opportunity to export it with the sprites for testing purposes; for example, to check how the game engine cuts out the sprites from the sprite sheet or how the graphic proportions work in the application. Tools such as Texture Packer successfully automate such procedures.

The basic design rules of good sprites are simple: the illustration should be contrasting and perceptible, and its details should express the element's functions in an unambiguous manner. The player should not have to conjecture what is in front of him. If an element has few states—for example, it is a switch—that means that each state should be thoroughly indicated. The artwork must be most descriptive; don't be afraid to over-describe. The following screenshot shows the grid system used in the Rail Maze game; it helps to determine the borders of tiles and to connect central parts of the tiles properly: