Game Art Bible Template: Filled In With a Real Game

We didn't write this art bible and then make the art for it. We used Makko like a living mood board to create the art first, all of it inside a single Makko collection, which binds the game's look, feel and style together for consistency. Afterwards we measured what we had and wrote it down.

That order is worth stating. Building a mood board is usually the first thing an artist does before writing an art bible, and Makko is where we did that exploration. We had 123 finished assets before anyone wrote a word, so nothing below is a guess. Every number here describes art that already exists. There's a blank version at the bottom if you want to do the same for your own game.

If you want the reasoning behind the rules rather than a finished example, that's the companion piece: how to write a game art bible.

Most art bible templates fail the same way. They give you the right headings and then let you write adjectives underneath them. "Palette: warm, gritty." "Level of detail: medium." You can't hold either of those up against a finished asset and get an answer out of it. A rule you can't check is really just a preference, and preferences don't survive a second artist, a freelancer, or a model that renders your character another forty times.

See the pipeline first

An art bible describes what the art has to be. The video below shows how it actually gets made: concept art, reference sheet, animations, baked sprite sheet, then the character running in a game. Watch it if you want the production context. Skip it if you're here for the template.

How the numbers in this document were produced

Saturation and value figures below were measured, not estimated. Each asset was decoded, downsampled to 192×192, converted to HSV, and averaged across every pixel above 200 alpha. Character measurements exclude the white studio background. Palette hexes come from a 16-step quantization of the same images, ranked by pixel share.

It matters because there's a real difference between telling someone "the characters should pop" and giving them a number they can hit. If you build your own from the template below, measure your own art rather than borrowing ours. The method is the part worth copying.

0. Ownership and version

An art bible with no named owner turns into a wiki page nobody enforces. Fill this row in first.

1. The visual target

Three pillars. Each is phrased so an asset can fail it.

That tie-breaker line does a lot of work and almost no template asks for one. 0 A.D.'s Art Design Document handles it in eight words: "Gameplay trumps Realism when the two topics disagree."

The rule of thumb: if a control already sets it, don't say it again in words. A prompt that repeats a dropdown is a prompt arguing with the tool, and the tool is also expanding your prompt behind the scenes with detail you didn't write. Overriding that with your own phrasing throws away the part you didn't have to do.

This is the difference between a bible that helps and a bible that gets in the way. The document exists so a human can check work and brief other people. It is not a script to be pasted.

2. The non-negotiables

These six are repeats from further down. They're up here because they're the ones people break. Read this section before every asset. The rest you only need once.

1. Crew are roughly twice as saturated as everything else. Characters land near 50% mean saturation; rooms, ships and props near 24%.
2. The suit carries the identity. The face never does. Every face plate is #c080e0 purple with glossy eyes.
3. Every asset has a black outline that survives to the smallest size it ships at.
4. Canvas size is set by asset class. 1024×1024 crew, 512×512 props and ships, 1920×1080 rooms.
5. Rooms sit below the crew in value and saturation. Always. The room is scenery.
6. Nothing in the sector is new. If it doesn't read as used, it isn't finished.

3. Canvas, scale and framing

4. The color system

4.1 The saturation contract

Everything else on this page leans on this one. Two things are worth keeping apart, though: what we measured, and what you should aim at.

Those are measurements, not targets. Nobody set out to hit 49.5%. The collection produced it and we measured it afterwards. What is worth copying is the gap, not the figures.

The second half matters more than the first. When a character disappears into a background the instinct is to push the character, and if you keep doing that you end up with a cast of neon fighting itself. Pull the room down instead. There's far more headroom at the bottom of the saturation range than at the top.

4.2 Crew identity colors

Each crew member owns a suit hue. At small sizes it's the only thing telling them apart, so treat it as reserved. Two crew members can't share one.

Crew — identity huesSector Scavengers · Signal & Salvage

Plate 03 · v1.1
Owner: Tony Valcarcel, art lead
Hues measured off shipped art

The rule

One hue per crew member, never shared. The face plate is the constant — it never carries identity, which is what frees the suit to be loud.

The cast

Ruby

#d03020 · 5.5°

Roger

#d05030 · 12.0°

Lucas

#f09040 · 27.3°

Marge

#904050 · 348.0°

NEW

Biff

#3090f0 · 208.0°

NEW

Yuri

#7070d0 · 240.0°

Where they sit on the wheel

Marge 348°Ruby 5.5°Roger 12°Lucas 27.3°Biff 208°Yuri 240°

Ruby 5.5° · Roger 12° · Lucas 27.3° · Biff 208° · Yuri 240° · Marge 348°

Four crew were packed into 39° of warm, and Biff sat 0.5° from Lucas — a shared hue by any honest reading. The two replacements went into the widest empty arcs: 32° apart from each other, and clear of brass, mint, signal cyan and the HUD blue.

Retired — Biff v1, Yuri v1

Both wore blue #60c0f0 face plates with flat cartoon eyes while the other four wore purple plates with glossy eyes. Two treatments meant the face was quietly carrying identity after all. Blue plates are out of the palette: every crew member is #c080e0, glossy.

Every color on this plate comes from the palette it documents. Signal cyan appears exactly once, per its own rule.Plate 03

That one constraint does more than it looks like it does. Because nobody is using the face to tell characters apart, the suits are free to be as loud as they want without the cast splitting into six unrelated designs. Drop it and every crew member turns into a separate color study.

4.3 World and UI palette

The sector is mauve, plum and brass. The crew is warm and saturated. Those two ranges don't trade places.

Three different components, one chassis language: mauve plate, brass corner bolts, mint inner bevel, scratched gray inset. That didn't come out of careful prompting. It came out of writing the role table down first.

5. Line, edge and rendering

The detail-floor rule is borrowed straight from 0 A.D., which says nothing smaller than a human hand gets modeled. It gets textured instead. Ported to 2D, it's the fastest way to stop someone spending an hour on rivets nobody will ever see.

6. Light and shadow

Three rooms, three brightness levels, one saturation band. The corridor and mess hall are bright, the bridge is dim, and all three sit well below the crew in saturation. That's why a character reads instantly in any of them without the rooms needing to look alike.

7. Crew specification

8. Ships, salvage and props

One thing we only noticed afterwards: across the shipped derelicts, the silhouette gets more angular as rarity rises. Rounded at common, winged at rare, hard-edged and military at epic. A player can learn that ladder without reading a single label. Right now it's an accident of three assets, which is a thin sample, but it's the kind of accident worth writing down before it stops being true.

9. Room backgrounds

10. UI, HUD and cards

Most art bibles skip this section, and it causes more rework than any other. Interface art runs into gameplay art constantly. Put a HUD in the crew's saturation band and it'll fight the crew for the rest of the project.

The no-pure-values rule is lifted from Riot's public VFX style guide for League of Legends, which advises avoiding the extremes of 0 and 100 and leaning on the mid-range, so an effect always has somewhere left to go when it needs to read louder than the one beside it. It looks like a color rule but it's really a systems rule, and it shows up in far fewer art bibles than it should.

11. Animation

12. Readability tests

Three procedures with pass conditions. Run all three before an asset is accepted.

The in-situ test is the one that catches saturation failures. Run it against your two extremes rather than some mid-tone room, since anything that holds up at both ends will hold up everywhere in between.

13. Do and don't

Name your failure modes and reviewers can point at them in one word. The Minecraft community style guide is good at this, with its own vocabulary for shading mistakes: banding, pillow shading, pancake shading, mixels. Build your own list as you catch things. It's much easier to fix a mistake that has a name.

14. Files and naming

15. Review checklist

Every line here is answerable without opening the rest of the document, which is why this is the part that actually gets used.

• Correct canvas size for the asset class?
• Correct background — white for crew, transparent for props, opaque for rooms?
• Saturation inside the band for its layer?
• If it's a crew member: reserved suit hue, and a #c080e0 face plate with glossy eyes?
• Closed black outline, heavier than every interior line?
• Four tones or fewer per material region?
• Key light upper left, from the artist's point of view?
• No baked shadow on a character?
• Wear present on every hull and prop?
• No pure black or pure white in UI?
• At most one signal-cyan element on screen?
• Passes the silhouette test?
• Passes the ship-size test?
• Passes the in-situ test against the darkest and brightest rooms?
• Named to the convention?
• Source concept art and reference sheet retained?

16. Changelog

Without a changelog the document quietly drifts away from the art it's supposed to describe. One line per change, and always include the reason.

The blank template

Copy the block below into whatever your team already uses. A doc, a wiki page, a README, it doesn't matter. Fill it in against art you've already made rather than art you're planning to make. The rules that hold up are the ones you can point at.

# [GAME NAME] — Art Bible v0.1

## 0. Ownership
Owner:              [one named person]
Master files:       [where the source art lives]
Last reviewed:      [date] against [n] shipped assets

## 1. Visual target
Pillar 1:           [statement an asset can fail]
Pillar 2:           [statement an asset can fail]
Pillar 3:           [statement an asset can fail]
Tie-breaker:        When two pillars disagree, [X] wins.

## 2. Non-negotiables  (fill in LAST, from the rules people keep breaking)
1. 
2. 
3. 
4. 
5. 

## 3. Canvas, scale and framing
| Asset class | Canvas | Background | Framing |
|---|---|---|---|
| Character   | [px]   | [color/alpha] | [angle, pose, margin] |
| Prop        | [px]   |               |                       |
| Background  | [px]   |               |                       |
| UI          | [px]   |               |                       |
Real-world scale:   [n] px = [n] meters / [n] feet

## 4. Color
Measured saturation and value, per layer:
| Layer      | Mean saturation | Mean value | Measured on |
|---|---|---|---|
| Characters |  |  |  |
| Props      |  |  |  |
| Backgrounds|  |  |  |
Separation rule:    [e.g. characters carry 2x the saturation of backgrounds]

Color roles:
| Role | Hex | May appear | May NOT appear |
|---|---|---|---|
| Primary        | # |  |  |
| Attention      | # |  |  |
| UI chassis     | # |  |  |
| Shadow         | # |  |  |
Forbidden:          [e.g. no pure black, no pure white, no unshifted grays]

Per-character reserved colors:
| Character | Identity color | Constant element | Silhouette note |
|---|---|---|---|
|  |  |  |  |

## 5. Line, edge and rendering
Outline color:      [hex]
Outline weight:     [px, and how it scales by canvas]
Interior lines:     [lighter / same / absent]
Tones per material: [max n]
Detail floor:       Anything smaller than [real object] is color, not shape.

## 6. Light and shadow
Key light:          [direction], from the ARTIST'S point of view
Shadow color:       [hex] at [n]% opacity
Baked shadows:      [yes / no — and why]
What may emit:      [list]

## 7. Per-class specs  (one block per asset class)
### [Class]
Canvas:             
Pose / angle:       
Budget:             [frames / colors / px]
Rules unique to this class:
  - 
  - 

## 8. Animation
Source of truth:    [reference sheet / rig / other]
Required set:       [idle, walk, run, ...]
Frame budget:       [n per loop, n per action]
Loop rule:          [first frame = last, except ...]
Mirror safety:      [symmetrical hardware required? yes/no]

## 9. Readability tests
Silhouette test:    Fill 100% black. Pass = [condition]
Ship-size test:     Scale to [px]. Pass = [condition]
In-situ test:       Composite on [lightest] and [darkest]. Pass = [condition]

## 10. UI
Chassis:            
Typography:         [font per role]
Attention color:    [hex], [n] element(s) per screen
Value limits:       
Nine-slice:         [which regions may stretch]

## 11. Do / Don't
| Do | Don't |
|---|---|
|  |  |
Named failure modes: [your team's one-word vocabulary for recurring mistakes]

## 12. Files and naming
Format:             
Naming convention:  
Folder structure:   
Source retention:   

## 13. Review checklist
[ ] 
[ ] 
[ ] 

## 14. Changelog
| Version | Change | Reason |
|---|---|---|
| 0.1 | Created |  |

Real art bibles worth reading

Almost nobody publishes theirs. These are the ones that are actually public, actually detailed, and worth an hour of your time. Every rule above owes something to one of them.

Frequently asked questions

What is a game art bible?
A single document that pins down the checkable visual rules of a game: canvas sizes, color roles and hex values, line and lighting rules, specs per asset class, and the tests an asset has to pass before it ships. Its job is keeping work made weeks apart, or by different people, looking like it belongs in one game.

Can you show me an example of a filled-in art bible?
The whole first half of this page is one, for Sector Scavengers: Signal & Salvage. Real hex values, measured saturation bands, real canvas sizes, and the art each rule was written against. The blank version is further down if you'd rather fill in your own.

What's the difference between an art bible and a style guide?
In games the two get used interchangeably and it isn't worth arguing about. Where people do draw a line, a style guide covers the look and an art bible adds the production rules around it: canvas sizes, budgets, naming, delivery format, and who signs off. This one is the second kind.

What should a game art bible include?
At minimum: ownership and version, a visual target with a tie-breaker, canvas and scale by asset class, a color role table with hex values, line and lighting rules, one spec block per asset class, animation rules, readability tests, a do-and-don't section, file naming, and a review checklist. Sections that only contain adjectives are worse than absent.

Do indie teams and solo devs need one?
A solo dev needs one more than a studio does, just a much shorter one. A studio has an art director enforcing consistency in review. A solo dev has memory, which is worse. The version of you making asset forty has forgotten what the version making asset one decided. Two pages is plenty.

How long should an art bible be?
Short enough that people read it. Eight filled sections beat sixteen half-empty ones, and an unfilled heading in a shipped document teaches everyone that the whole thing is optional.

When should I write one?
After roughly your first ten assets and before your fortieth. Any earlier and you're guessing at the rules. Much later and you're writing a document that contradicts art you've already shipped. Write it by measuring what you've made so far, then work out which parts were accidents.

Why do art bibles drift out of date?
Because nothing forces the document to change when the art does. Two fixes: name one owner, and keep a changelog with a reason column. If you can't state the reason for a rule, delete the rule.

Does an art bible still matter if the art is AI-generated?
It matters more. A generator will happily give you forty plausible versions of your character, each one internally consistent and none of them agreeing with the others. Written rules are what turn that pile into a decision you can actually make: which sheet to keep, which room to desaturate, which canvas to bake at.

Every asset in this document was made in Makko. Collections handle the consistency part for you. Set the style once and the characters, props, backgrounds and animations made inside it inherit it. The art bible handles the rest, which is writing the decisions down so they're still there at asset forty.

Try Makko free →