Hello there and welcome back to another installment of the Blightmare Development Blog. Today’s post is going to be a quick look into some of the more technical bits that go into getting sprites – static images – into the editor and game. At first thought, this might seem like something that doesn’t require much thought, but as we will see, there are some specific areas that require some planning and ironing out.
What is a Sprite?
I mentioned in the introduction paragraph that a sprite is a static image. This is true, but it doesn’t offer a very precise definition. In games, there is often a distinction between source assets and runtime assets. Source assets are the ones that an artist exports directly out of their creation tool – such as Photoshop. Runtime assets are what the game actually loads while it is running. These may vary for a number of reasons: some formats may not be supported in the engine, some formats may not be supported on a platform, some formats may be more efficient, or some source assets may be packed together to form a single runtime asset – just to name a few. In Blightmare, our source images are all PNGs. This gives us a highly portable (that’s the P in PNG!) format that is lossless and supports transparency. Our runtime assets are automatically managed by Unity and in this case, they are compressed DXT5. Without going too far into the weeds, the DXT (or S3) family of formats are lossy, block based formats that typically have hardware support on graphics cards which makes them an extremely efficient format for use in games because they do not need to be decoded or decompressed or transformed in any way before being sent over to the GPU for rendering.
What kind of planning do we need to do?
Outside of any normal planning that someone might do for any piece of art – which I have no knowledge of – assets for use in game have some specific guidelines that help keep things consistent and make integration simpler. In Blightmare, we use a grid based system for mechanic alignment and level building which makes sure that we have consistent object placements and mechanics that react like a player expects. For example, Blissa is 1 unit wide and 3 units tall. From this basis, we can build out a map of the grid footprint that each mechanic should have logically. From there, we know how much space on screen the visual asset for a mechanic should take. In most cases, we have a constant camera zoom level which then allows us to estimate how many pixels a unit should normally be. We want to make sure that the assets are pretty close to this size to prevent any artifacts from scaling. As a complete example then, consider a ground cocoon. The logical size of this mechanic is 2 x 2. To make the math easy, we will say that we determined a unit should be 100 pixels. That means that a ground cocoon asset should be about 200 x 200 pixels.
In practice, that 200×200 box is really more of a guideline that the art should take into account. Most of our assets are larger than their logical boxes because it typically looks much nicer to have art that blends in smoothly with the surroundings, and in the case of the cocoon, it would look rather odd if the player was bouncing off the edge where there was no art at all.
Alignments and integration
Once we have a piece of art that is properly proportioned, it is time to integrate it into the game. This usually comes with a manual alignment step. There are a couple of reasons for this, but the most important one is that we want to minimize the actual size of our assets. This often means that the sprites themselves are various rectangular shapes with sizes that don’t align to our grid. This is where alignment comes into play. In Unity, this is called a pivot, and it is a vector2 that specifies the normalized position within the image where the “origin” should be. If you were to draw the image logically at 0, 0 for example, where would the bottom left point of the image actually be? This process is done manually in Blightmare, but in a larger game there might be metadata exported with the art that allowed for an automated process to be run. A sprite is added to a logical mechanic rig and then the pivot is adjusted until it looks just right. This allows us to get the exact same results in the editor preview as we do in the game object which is very important to make sure the editor works properly. I’ve nearly completed a pass over all the mechanics in Blightmare for this purpose during the final stages of the editor refactor. It should be a worthwhile improvement for efficiency and consistency.
Thanks for stopping by and reading to the end! If you like what you see, please head over to Steam and add Blightmare to your wishlist. To make sure you get all the latest news and updates about Blightmare, please follow us on Twitter. Have a great week!