A Sprite Sheet is convenient method of storing collections of sprites for use in the development of video games. MFGG accepts sprite sheets on its main site, as they are considered an essential tool for making 2D games. MFGG's earlier submissions were in the form of "Klik Libraries", which are pre-assembled sprite sheets for clickteam environments.
Sprite sheets were first seen in their purest form in the early 1980s, when the concept of sprites fell into widespread use. Graphical data is extracted from the game and placed in RAM, ready to be drawn onto screen. During the 1980s and 1990s all computer graphics were typically made up of 8x8 tiles, which were then placed together by the game's code and given the appropriate palette to form bigger images. Tiles were arranged as efficiently as possible in order to save space inside the ROM, which was often limited.
By the mid-1990s and the introduction of CD-based media, space became less of an issue, and so artists and programmers became more relaxed about how graphical data should be stored. One of the results of this process was the concept of sprite sheets, which are designed to house a number of 2D sprites or tiles but organised in such a way that they are easier for humans to comprehend.
Some big differences between sprite sheets and, say, those Super Mario Bros. 3 tiles above are:
- Palettes are usually applied in advance and housed on the sheet itself.
- Animations are pieced together by hand in advance. This can lead to duplicate tiles (in Super Mario Bros. 3 for example, the 8x8 tile for Mario's head is recycled for a number of animations but only stored in memory once - on a sprite sheet, this tile may be seen numerous times).
- Similar graphics are grouped together, e.g. the Mario animations are stored separately from the Koopa Troopas.
- The concept of "tiles" is often eliminated. The user simply deals with big blocks made up of tiles, a.k.a. "sprites".
Even though the need to store graphics in a specific way is often removed in the development of more modern games, it is still wise for sprite sheets to be aligned properly for ease of use. Good sprite sheets conform to a "grid", typically in multiples of 8, so code can then be written to draw graphics based on where the sprite lies on the grid. It is more efficient to use a square based grid, however rectangular grids are sometimes used also.
If all sprite sheets a grid, they can be swapped at will without the need to calibrate the renderer. Misaligned sprites requires code to draw each frame of animation individually, given offsets and dimensions. It can also lead to erroneous results when it comes to animation - the renderer may not know how the next frame should be positioned relative to the last.
Sprite sheets are tools. A collection of artwork, not artwork themselves. A good sprite sheet keeps wasted space to a minimum and is not clogged up with unneeded graphics. MFGG has received thousands of submissions which have failed to understand this concept.
It is often seen as better to split graphics into multiple sprite sheets. For example, if a user wants to use background objects from Super Mario World, it is unwise to group those objects with sprites of playable characters or enemies. If the user is conscious about wasting space in his or her game, they may have to edit the sprite sheet themselves to remove unneeded content.
Authors and contributors to the sprite sheet are sometimes listed in messages known as "credits tags", a clear way of identifying ownership of graphics. MFGG recommends small tags which take up as little room as possible.
Sprite sheets typically pick a background colour for "transparency" not found within the game. For example, bright magenta or green, as these can easily be removed in an image editor without fear of damaging the sheet's contents. This is opposed to colours such as white or black which may be used on the sprites themselves. It is becoming more common practise to use actual transparent colours (#xxxxxx00) for sprite sheets, and if a sheet contains partial transparent sections alpha transparency is essential to maintain image quality.
Sprite sheets are typically saved as PNGs or in worst case scenarios, BMPs. The 256-colour cap on the GIF standard can make the format inappropriate for newer games, and JPEGs will ruin the sprite sheet completely due to the format's compression algorithm. Within the video game industry graphics are likely to be saved as other formats, such as lossless TGA or DDS, neither are suitable for internet usage.
Sprite sheets are typically unsuitable for 3D graphics, though textures for 3D objects are often stored in a similar format (i.e. all the information surrounding that object's texture is held together in the same image file). It is typically unwise to mix textures and sprites as this could cause complications with 3D renderers.
Next to audio, graphical assets tend to take up the most room in a game, so it is always wise to optimise sprite sheets accordingly. Utilities such as PNGOut can optimse PNG images, in some case reducing the size by over 50% without sacrificing image quality. Optimisation also helps with server bandwidth, so if a sheet was hosted on MFGG for example, the smaller file size will help not only the server, but the user, as he/she will not have to wait as long for an image to load.
Keeping the palette to a minimum and cropping out wasted space are the two best methods of helping this process. Small palettes are useful as this can help users recolour sheets quickly and efficiently. In the industry, images may be compressed further through a variety of methods, often to protect the integrity of the game.