LPC is an awesome initiative to create Free and Open Source game assets. When it was started, nobody anticipated how successful it's going to be, so it wasn't very well-defined. As it gained popularity and people started to use it in real games, it become apparent some features are missing, so over the years lots and lots of contributions were made. Unfortunately in lack of well-defined guides, those contributions turned out to be incomplete or incompatible with each other. But
This specification is here to the rescue! It aims to clearify things and provide detailed guides.
You can list all submissions fulfilling the requirements of this specification on OpenGameArt.org easily. These are guaranteed to be compatible with each other and work together well, furthermore you can be sure they contain everything needed for a fully featured game.
The terms must, must not, should, should not and may are to be interpreted as described by RFC 2119.
LPC submissions created using these guides and fulfilling the requirements of this specification should be tagged with LPC-Refined (Liberated Pixel Cup Refined) on OpenGameArt.org. We trust the designers to do self-verification when submitting on OGA, but moderators can also check.
We put our trust in the Open Source community, because it is everyone's best interest to be honest about being LPC-Refined: designers should be proud if their submission earns this tag, and game makers will prefer these easier to use, compatible submissions without a doubt. It might result a little bit more work at first, but it's a win-win on the long run for everyone.
The users of a submission might find some incompatibilities and point those out in a comment on OGA. Asset creators should read the comments and address those issues for the community's sake. When there are complaints and the creators aren't fixing those, then the OGA moderators should take away the LPC-Refined tag from the submission. There's no central authority, this is the main process of how verficiation and certification of the LPC-Refined comformity is done.
The original LPC style guide is pretty good, but unfortunately incomplete. This updated style guide and cleared up set of rules tries to incorporate all the accumulated know-how and best practices over the years, and to present all of that in one place.
But more than just a text to clearify the set of rules, it also provides ready to use guides for designers to ease working with LPC assets and to help to fight incompatibility issues. All the guides can be downloaded as an attachment, including an all-in-one XCF file, an all-in-one PSD file as well as individual PNG images.
Note that this specification must keep the original style guide's goal and most importantly, style. It does not want to alter those in any way, we believe that LPC is a very good asset set. The sole purpose is to clearify technical details, to help the collaboration between designers working on different submissions and to help game creators.
This specification is not cut in stone. It should reflect the best practices actively used by the community. As such, if customs change, all OGA members are welcome to discuss the required changes and improve it for the benefit of all.
Things that are important enough to be worth repeating
Roughly a “toon style rendering” with medium-low levels of texturing. We want some detail, but not so much that things are so ornate that it might make collaboration difficult. We don’t want things to be “noisy” either. But detail is good. Texturing should have a toon-style; this is accomplished with medium to low amounts of texturing. Details should be used sparsely, so make them count!
Shade in blocks. Begin drawing by blocking out the object first, paying attention to its volume. Lines should be added afterward, and generally only around the edges and with very important details. Details should mostly be implied by form and color, not by outlines.
Lighting should primarily come from above. If there is any side directionality, it should come from the left, but not by much: keep it mostly center.
An example scene in blender with a sun light pointing in the appropriate location:
Left example shows from the “top-facing” camera used in this style; right example shows a sideview. Yellow “sun” with ray is the light source, big orange triangle on right is the camera.
Your light to dark color ramps should never all have the same hue. Vary the hue and saturation a bit as you go from light to dark, or your objects will look flat.
To create shadows or lowlights, once you have the main color the shade you want it to be move the hue (hsv selector) slightly towards the closest purple. To create highlight color, do the same but instead of purple and shade move the hue slightly towards the closest yellow and lighten it up. Adjust as necessary until it looks “right”.
Inside, things will be cooler in overall color, with slightly less contrast. This is doubly true for things like basements, caves and other underground areas.
All drop shadows should be done with the color #322125 at 60 percent opacity. If it makes sense, one may also provide a combined version of two tiles, so only one layer is needed to, say, put a house on a grass background.
Dithering should be used sparingly if at all. None of the base artwork has dithering.
Outlines should be a darker version of the current color, or a dark color generally, not black. (Extreme circumstances obviously may have exceptions.)
Props should be colored so that they don’t blend in with the surrounding background tiles (vary color, brightness, and saturation to provide contrast).
There’s should be a large difference in lighting between the sides and the top of objects. Look at these objects as example:
Props should have shadows, or they will appear not to be part of the scene. Shadows should follow the same transparency blending rules as mentioned in the “lighting“ and “shadows” sections above.
Characters should have their own color palettes so that they stand out from the background. Drop shadows should follow the same rule as the tiles, #322125 at 60% opacity.
There’s no specific palette required for Liberated Pixel Cup asset conformance, but it’s generally best to try to match to the colors used in the base set. So that said, here’s a palette that may be useful in producing matching assets.
You can find these palettes in lpc-guides.zip, in multiple formats (Asprite, GPL, PNG).
The general tile grid is 32x32 with (possible) sub tiles at 16x16. The rationale being that the basic size of a square object (eg a chair or a character) is a 32x32 area. All base assets are designed to work at 32x32 tiling, and it’s recommended that you build yours to be so as well. However, for versatility tiling can happen at 16x16 resolution.
The camera angle is top-down, roughly 60 degrees.
Rendering should be orthographic, which means there is no perspective... things do not get smaller as they move into the distance. If you’re using perspective techniques on your props or tiles, that’s wrong.
Details are simplistic. There are more details on the edges, and the center tile should be either one color or a very subtle pattern.
Occasional detail tiles should be thrown in to break the monotony of having a single repeating tile.
Edged tiles such as walls and floors should be arranged in a similar manner as the establishing art.
There are not much to say about objects, because they have minimal compatibility requirements. Keep in mind that objects have orthograpic (top-down) perspective, and you must choose the colors for props and objects carefully so that they nicely fit with the tiles.
When you're creating bigger objects, always keep in mind that players might walk inside. That's only possible if you create multiple layers of an object.
For example, with the bridge on the left side, the following wouldn't be possible:
This is the most complex chapter, and the bottleneck where the original LPC style guide really fall short, causing most of the incompatibilites.
Characters are squashed, roundish, and not realistically proportioned. Bases are approximately two and a half heads tall and in the same perspective as the tiles. The base should fit in a 32x48 space and the clothing should fit in 48x64 space. The outlines should be black or near black, no selective outlining.
Characters are built along 3 independent dimensions (do not confuse with space dimensions):
Modular layers are always stored in separate image files. Puting these layers one on top of another creates the character.
Directions are stored within an image file up to down, vertically sorted into rows in this order: back, left, front, right.
Animations have multiple frames, stored left to right, horizontally sorted into coloumns in the same row for a direction.
Sometimes each animation has its own image file, but for submissions it is pretty common to pack multiple animations into a single image, sorted up to down.
In every spritesheet, each sprite represents one layer of the character, in a specific direction and at a specific frame of an animation. Ideally all sprites should exist, but in reality only some are required. See sprite matrix for which one can be omitted.
Not all layers must have all the animation sprites, some can be omitted, see the sprite matrix for the required minimum.
For modular NPCs only the tools layer has to be compatible, all the other layers could be merged into a single layer which does not follow any of the guides except hand positions. It is also possible that an NPC isn't modular at all, but those NPC submissions are not the concern of this specification.
Characters are made up of multiple, strictly-positioned layers. This means that in LPC the characters are modular, you can select different spritesheets to create a player or NPC character of your liking. It is also possible to create a game where the users can dynamically generate any character they wish.
You can find one pixel thick shiluettes and guideline sprites in lpc-guides.zip, which you can load as a background in your pixel editor to help you with the positioning. There are guides for all animations in every directions.
The first and most important layer is the body, which consist of a torso, arms and legs but no head. There must be at least two variations of it:
For both, the positions of the head and the hands are fixed, they must be at the same spot for every frame, depending on the animation and the direction. This also means that for example the right hand must be drawn at the same position for both female and male characters.
You can find more variants in LPC submissions, for example body-builder masculine, pregnant women, however these need their own set of cloth assets, because their guides are differently positioned, but they can be still certified if they are compatible with the tools layer. Child variant cannot be certified with the LPC-Refined tag, simply because it is not compatible with any other layer.
Next is the head, which is separate from the body, because it might have multiple facial expressions. Both female and male heads are the same size, positioned at the same spot and completely interchangable. There could be female-only or male-only faces, however those must only differ in their styles, but not in size and position.
Using facial expressions is not a requirement, and only optional. It is enough if a submission has one (neutral) head to get the LPC-Refined tag.
This layer could actually mean multiple layers. One for the hair, one for the mustache and beard, another one for sunglasses or pirate eye-patches, etc.
Just like hair, this could mean multiple layers, depending on the accessory's requirements. A full-body armour typically needs one, while a modern day outfit would probably need at least three.
Since a cloth asset is using the same guides as the body layer, there should be multiple variations of it as well (female, male, pregnant, body-builder etc.), but unlike the body layer, it is okay if only one of the variations exists for clothes.
Everything that has to be positioned in the character's hands. Includes weapons, magic staff, torch etc. too. This is the most relaxed layer for animation requirement: idle, walk, run, jump is typically always needed, however usually only one usage animation is drawn for each. For example bows need a bowing animation but no slash, and bowing, thrust isn't needed for a hammer only slash.
Tools layer typically consist of one single layer. But it might be split into two: one behind all the other layers and one on top of the other layers. This is needed if the tool has a long handle, like a scite for example.
As a general rule, for the tools layer only the movement animations are mandatory and must be drawn to get the LPC-Refined tag.
There are two special animations, "hurt" (mandatory, down / South) and "climb" (optional, up / North) which has only one direction. All the other animations are expected to have all directions (either 4 or 8).
For every layer and every animation, four directions must exists. These are vertically sorted into rows in this order:
Some submissions might have diagonal directions two, giving the total of 8 directions. These are really nice to have, but not required to get the LPC-Refined tag. If all 8 direction exists, then the sorting order of the rows is as follows: North, North-West, West, South-West, South, South-East, East, North-East.
All of the following animations must be drawn for an asset to get the LPC-Refined tag, with some exceptions. See the sprite matrix for details. NPCs have no restrictions at all (it is okay if an enemy NPC only has walking, slash and hurt animations for example), in other words, these animations are mandatory for user playable character bases and their assets.
Defining a set of must have animations is important for game engines. These are the character movement and tool usage animations, and if even one of these is missing then the entire asset is unusable in the game engine because it's not complete.
|cast||7||casting a magic spell|
|thrust||8||melee attack with spear|
|walk||1 + 8||idle and walking|
|slash||6||melee attack with sword|
|bowing||13||ranged attack firing a bow|
|hurt 1||6||out of HP, death|
|run||8||similar to walk, but faster movement|
1: has only one direction. "Idle" animation is the first frame of the "walk" animation.
These animations are not required, but nice to have.
|sit||1 + 1 + 1||sitting, each frame different pose|
|idle||3 or more||idle animation|
push, grab, lift, carry, block attack, take damage. specify these.
The names of the animations are important, as people are referring to the animations by these names in the forum discussions. Submissions which store each animation in a separate image must use these names as part of the file name. For example
xxxxx_slash.png cast female chainarmour.png ...etc.
A spritesheet for each animation must have 4 rows, one for each directions (or optionally with diagonals, 8 rows). There's one exception to this rule, the "hurt" animation, which only has a single down (front, South) direction (and "climb", but that's an optional animation).
But most typically submissions are using one spritesheet. In that case these animations must be listed vertically, up to down on the image in exactly the order as listed above. Optional animations are preferably added to the right, in the empty spaces.
Example all-in-one spritesheet
In an ideal world, for an asset all sprites in all possible combinations of animations would exists. But that would be an insane amount of srites, so for a LPC asset submission to get the LPC-Refined tag, only some are required. This appendix summarizes these minimum requirements.
In the coloumns there are the asset's modular layers. Each submission should contain the sprites for their corresponding layer type. For example, a submission which adds orc character base should contain the animations in the body and head columns. For a leather armour asset submission take a look at the cloth column. For a rapier the tools column would apply, etc.
In the rows there are the animations which must be drawn for that layer.
NPCs are allowed to have exceptions, for example for a skeleton bower it is enough to have walk, hurt and bowing animations; and it may also have the body, head, hair and cloth layers merged into a single layer.
The animations typically have 6 - 13 frames, but your game is going to use 24, 30 or 60 FPS (frames per second). This means you can't use the animation frames as-is.
First, you have 4 options which frame of the animation you display at a given time:
This is totally up to the game developer, and does not influence the asset's LPC-Refined tag.
Second, you have to decide for how long you display each frame. For example, assuming your game's main loop executed 24 times every second (24 FPS), and the animation you want to play contains 6 frames, then in order for the animation to be played for 1 second, you'll have to display each frame for 4 main loops.
Again, this is totally up to the game developer, and does not influence the asset's LPC-Refined tag.