Liberated Pixel Cup Specification

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 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 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.

Download guides


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

  • No pure colors!
  • Vary the hues of your color ramps!
  • Highlighted areas are yellow-ish, shadowed areas are purple-ish.
  • Block your art out first, including shadows, before adding detail.


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!

Process of creating shades

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.

The direction of sublight (yellow arrows)

An example scene in blender with a sun light pointing in the appropriate location:

lighting_direction.pngLeft 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.)

Note how the outline is a darker version of the same color

Props and Objects

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:

Examples of object lighting via a barrel and a bucket

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.

Character Colors

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.

The LPC Revised palette for character skins and cloths
The LPC Revised palette with ramps for tiles and objects

You can find these palettes in, in multiple formats (Asprite, GPL, PNG).


Grid Size

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.

32x32 grid example


The camera angle is top-down, roughly 60 degrees.

Top-down, orthographic projection

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.

Chest perspective example

Tile Authoring

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.

Demonstrating tiles that can be used to make more complex patterns

Edged tiles such as walls and floors should be arranged in a similar manner as the establishing art.

An example scene with the tiles


Perspective and Colors

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.

Object Layers

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.

Separate large object into layers

For example, with the bridge on the left side, the following wouldn't be possible:

Sara walking on bridge


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.

Example of accessorized characters

Build Up

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.

Modular Layers


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.

Demonstrating modularity through multiple layers

You can find one pixel thick shiluettes and guideline sprites in, 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.

For example, the waist guideline shows the standard pantline
Multiple guidelines can be used at once to design and animate new character assets


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:

  • female (feminine)
  • male (masculine)

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.

Example facial expressions


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.

Example hair layer (for the run animation in left to right direction)


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.

Example cloth layer (male shirt for the run animation)


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.

Example tool layer (shovel for the slash animation)


As a general rule, for the tools layer only the movement animations are mandatory and must be drawn to get the LPC-Refined tag.


1 direction

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).

4 directions

For every layer and every animation, four directions must exists. These are vertically sorted into rows in this order:

Example: directions of Sara's slash animation

8 directions

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.

Name #frames Description
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
jump 6 vertical jump


1: has only one direction. "Idle" animation is the first frame of the "walk" animation.


These animations are not required, but nice to have.

Name #frames Description
sit 1 + 1 + 1 sitting, each frame different pose
idle 3 or more idle animation
climb 1 4 climbing

To Do

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

cast female chainarmour.png

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.

sara_full.pngExample all-in-one spritesheet

Sprite Matrix

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.

Body Head Hair Cloth Tools
cast B y y b ?
thrust B y y b ?
walk B y y b y
slash B y y b ?
bowing B y y b ?
hurt 1 B y y b n
climb 2B y y b n
run B y y b y
jump B y y b y


  • y: this animation is required for this layer
  • n: should exists, but not required
  • ?: it is enough if one of these animations is implemented
  • B: requires multiple body variants (female, male, etc.)
  • b: requires at least one of the body variants
  • 1: has only one direction (down / South)
  • 2: has only one direction (up / North) and it is an optional animation


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.

Playing Frames

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.

Playing Order

First, you have 4 options which frame of the animation you display at a given time:

  • play once: the most straightforward, you take one frame after another until the animation finishes.
  • in a loop: same as play once, but when the animation is finished, you start over from the first frame.
  • forth-an-back: you play it once, then again but in reverse order, and then you repeat.
  • any arbitrary frame: for example, you could play the frames 1,1,2,3,3,3,4,5,5,4,4,3,2,2,1 and then repeat.

This is totally up to the game developer, and does not influence the asset's LPC-Refined tag.

Playing Time

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.

Examples at 24 FPS

Idle animation example, played forth-and-back