This page explains the technical aspects related to the creation of artwork for Allacrost. This discussion covers two types of information. First, we discuss issues such as which image file formats to use and how to properly align your artwork within these images to fit in with the game's expectations. Second, we cover the game's graphical capabilities, in layman's terms, as it applies to the artist. This includes common visual effects such as lighting, fog, rain, snow, reflections, and particles.
Hero of Allacrost uses two image file formats to produce all of the game content: PNG (.png) and JPEG (.jpg) files. PNG images are used for the majority of the artwork that makes up the world of Allacrost, including tiles, sprites, icons, and effects. JPEG images are used for images that are large in size, full of detail (high color count), and do not require any transparency. The PNG file format has a native alpha channel (that is, transparency) that Allacrost makes use of. Unlike some other games, Allacrost does not achieve transparency by color keying (a technique where a specific color is selected to act as transparent).
Due to the large number of small images, such as tiles or sprite animation frames, many image files in Allacrost contain multiple images embedded within the image. For example, a 512x512 pixel tileset image can contain up to 256 32x32 pixel tiles. All of the frames that are used to produce an animation for a sprite are typically contained within a single image as well, called a sprite sheet. The artist does not need to worry about the technical details of how art is organized and stored in these types of aggregate image files, as it has no effect nor limitation on the creative design process. This information is purely provided here for educational purposes.
Many images will contain some amount of transparency, such as the scorpion sprite on the right. When creating artwork like sprites or map tiles that represent an object with some amount of transparency surrounding the image, you always want to align the image to the bottom center of the canvas. One reason for this is that when the game is drawing objects on the screen, it calculates their positions and draws the screen from the top down. So a sprite at the top of the screen gets drawn before a sprite at the bottom. This allows sprites and other objects to partially or fully obscure another. For example, a sprite can walk behind the top of a tree or behind a building. But the main reason why this alignment is used is because the game defines an invisible "collision box" for each sprite or other object. When the game is running, it makes sure that two collision boxes do not overlap one another, as doing so generally causes objects to appear as if they were drawn right on top of one another.
Take a look at the image below that shows two sprites on a forest map. The green, red, and blue shaded areas all represent collision boxes for different objects on the map. The green boxes are the collision areas for the tree. Sprites can not walk onto the areas occupied by the tree trunks, but they can walk behind the tops of the trees. The blue collision box is for the character sprite that the player is controlling. The red collision box belongs to the slime enemy as it slithers it's way across the map and tries to approach the character sprite. Collisions between two collision boxes can also trigger certain events to appear. When the character's blue collision box collides with the slime's red collision box, this will trigger a battle to occur. Just to reiterate, these collision boxes are not viewable to the player in the game. The boxes in this example image were drawn visible through a special debug option in the software to make it easier for game designers to test out their maps.
Finally, as an artist you should know that collision boxes can be defined to be any size at all, including sizes that are greater than the image itself (which may be useful for certain circumstances like an invisible force field). Collision boxes can be re-sized dynamically while the game is running, though typically they remain the same size. Collision boxes for any object can also be turned on or off at will, essentially allowing a sprite or other object to travel through anything. As an artist, you usually do not need to concern yourself with collision boxes for the sprites and other art that you create. Just know that they are there, but this knowledge should not have any effect or cause any sort of limitation on your designs.
The default screen resolution of the game is 1024x768. The game runs in other resolutions as well, but the graphics are scaled accordingly so that the view area is the same regardless of the screen resolution. This is the reason why, for example, backdrop images are 1024x768 pixels, so that they take up the entire area of the screen. Pixel art is either drawn at their native image sizes (such as 32x64 pixels for a normal sized sprite) or at a scale factor of 4x (the same sprite becomes 64x128 pixels). Because pixel art is a precise artwork type where every pixel matters, this art does not scale well unless done by powers of two (doubling or halving both width and height of the image).
The reason why the artist needs to know this information is so that they can create their artwork at an appropriate size. For example, if designing a large tree that is intended to be completely visible on the screen, the artist would want to make sure that they do not create it larger than the size of the visible area on a map.
By default, maps are seen at a 4x scale factor. That means that all 32x32 pixel tiles get scaled to 64x64 pixels on the screen. Thus, screens fit a view area of 16 tiles wide and 12 tiles high (1024/64 = 16, 768/64 = 12). The reason that maps are seen from this view is because through our early play testing, having map artwork displayed at the native 1x scale (32x24 tile view area of maps) felt like the player was too distant from the characters on the screen. It also made it more difficult to appreciate the fine details of the pixel art. Support may be added into the game in the future to allow us to toggle between the 4x and 1x scale factors so that we can "zoom out" when we want to show a larger view area, but this should not affect how you create or design your artwork.
Design your artwork under the assumption that the viewable area of maps will always be 16x12 map tiles, and size your structures and other map features accordingly.
Many different types of artwork can be animated. The most common two types of animations are map tiles and sprites (in fact, a sprite that is not animated can hardly be called a sprite at all). An animation requires two things to come alive: image frames and a timing sequence. Image frames are simply static images that show a "snapshot" of the animation. The timing sequence is a set of instructions that tells the game (1) which image frame to display next, and (2) how long to display that image frame before moving on to the next frame in the sequence. The timing data must be specified in number of milliseconds, as one millisecond is the smallest unit of time that the game is able to process. Usually you want frames to be no shorter than 50-100 milliseconds. Any faster, and the player's brain won't be able to process the visual change fast enough. For more information on the human brain's ability to process visual data, please refer to this site.
As an artist creating an animation, you need to only create each image frame and then state what the timing sequence is. A programmer or game designer will then take this information and do the small amount of technical work required to implement your animation into the game. You can test out your timings using an image editor. It's also acceptable to produce an animated GIF (.gif) image to share with others. Sharing a GIF of your animation makes it much easier for others to comment on your work and provide accurate feedback. Frame images may be repeated any number of times in the image sequence. Observe the example image below.
There is one last important design requirement that artists must remember. All image frames in an animation must be the same size. So make the size of all of your image frames as large as you need your largest frame to be, and fill the empty space with transparency. And remember to keep all of your images aligned to the bottom center of the canvas. This is especially important with animations, as if you fail to align all of your frames properly, the object will appear to make sudden jumps or unnatural movements as the animation cycles between the frames.
The graphics engine supports many features to enable realistic lighting. Thus, generally you want to create all of your artwork as it were to be shown on a bright and sunny day. The maps, battles, or other areas of the game that use your artwork may then apply lighting effects to it and surrounding objects. This allows us to support multiple lighting scenarios (daytime, nighttime, dusk, dark interiors, and so o) without requiring any effort on the part of the artist to create alternative images of their work to be used in different lighting scenarios. We can add light sources to objects as well, like torches or lanterns, to make their effect really come alive. Observe the example image to the right to see a demonstration of our lighting capabilities in action.
That isn't to say that artists can or should completely forget about lighting, however. There may be certain areas where it is preferable to have custom art to demonstrate lighting. Take for example the screen shot from the game Chrono Trigger below. The tile lighting of the church windows provides a really nice effect. Feel free to be creative with any custom lighting that you wish to add to your artwork. But remember that many common lighting functions are already available to use, and they exist to help make your life easier.
TODO: discuss snow, rain, fog, particles, distortion, and so on.
TODO: provide a concise bullet point list of all of the important information on this page.