How to Enforce a Consistent Pixel Art Palette

#pixelart #cicd #gamedev #aseprite

Without Reviewing Every Sprite

Games dense with pixel art can have hundreds, or even thousands of sprites, and can have layers and animation frames, creating a massive volume of assets to maintain.

Catching art errors manually doesn't scale as the project grows. In order to scale, automating art checks is necessary.

Many common problems can be enforced as policy by automated tools to catch any unwanted changes to palettes, shapes, alignment, borders, animation frames and more.

Palette Drift

A sprite can deviate from the desired palette by a single colour, inside an animation frame on a single pixel. If uncaught, they can lead to a glitchy looking asset in your game and detract from the experience.

Declaring a source of truth for your palette can catch any deviations automatically. Whether you are a team of game devs or a pixel artist publishing asset packs, removing the cognitive load of palette reviews frees up a lot of time.

Spot the difference in the sprites above. It's not immediately apparent but the highlights on the clothing is a darker blue on the left than on the right. It's much easier to automate this than to verify manually.

(Credit to RobLoach for the sprite)

Scaling Sprite Count

Typically sprites are created in a tool like aseprite, and then exported to a sprite sheet. This export loses the original source of the information. A problem that is noticed in the export needs to be updated in the original file.

Finding the source of the problem now involves working backwards:

Exported Sheet -> Source File -> Frame -> Layer

Animated characters can have multiple layers across different frames. Consider the number of sprites that can exist for a project:

Sprites * Layers * Frames

The time spent correlating issues by hand multiplies by every factor. However, a collection of sprites starts to display some patterns. Sprites can share common rules like:

A common palette (ie: by biome)
Consistent borders of 1 black pixel (or no borders)
Using indexed colour mode
A constant size

Step 1 — Palette ground truth

Set up pixelartlint.toml in your project. Start with pixel-art-lint init to create a configuration file based on an asset you have already created, or choose a palette from lospec.

pixelartlint.toml
[tool.pixel_linter]
severity = "error"

[tool.pixel_linter.palette]
colours = ["#112233ff", "#aabbccff"]
include_transparent = true

[tool.pixel_linter.colour_mode]
mode = "indexed"

For a set of assets with a unique colour palette, move them to their own subfolder if they aren't already, and create another config file with an override palette. This can be done quickly by running the init sub command again.

Step 2 — Check assets

Add pixel-art-lint check to a githook for automated checks, or run manually after changing art assets to ensure no unwanted changes have made their way into your art files.

If introducing the linter to an existing project, consider adding an ignore glob to the config file until a config can be created, or the art updated to conform with the rules in your existing config files. Then you can still have the benefit of the linter applied to the files that conform, and they will no longer be prone to palette errors.

For aseprite files, typically in asset packs with limited palettes, an indexed palette is used. Even if the colour palette is not set, apply the colour mode rule in order to prevent mixing and matching of palette styles in a project.

Step 3 — Build Pipeline

Add pixel-art-lint to your build pipeline such as GitHub actions, CircleCI, or Gitlab. The tool will exit with code 1, failing the build on errors. This will prevent any regressions from making it past the pull request step into your trunk branch.