Art Bible vs Style Guide vs Design Doc: Which One You Need
Three documents answering three different questions. Most teams write one that tries to be all three, and nobody reads it. What goes in each, which rots fastest, and which ones you actually need.
These three terms get used interchangeably, and in most conversations that is fine. Nobody has ever shipped a worse game because they called a style guide an art bible.
Where it starts to cost you is when one document is trying to be all three at once. That document gets long, gets stale, and gets read by nobody. That is the actual failure, and it is common enough to justify ten minutes of definition.
The short version. They answer three different questions. A vision or design document answers why does this game look like this. A style guide answers what should this look like. A production spec answers how does it get made and delivered without breaking. "Art bible" in common usage means the second and third glued together. Write the ones you need, keep them separate, and put a name on each.
The three documents
The vision document
Question it answers: why does the game look like this at all?
This is the shortest and the most often skipped. It holds the pillars, the two or three statements about the game's look that everything else has to serve, plus a tie-breaker for when they conflict.
The tie-breaker is the part that earns the document. Two good rules will eventually contradict each other, and if nobody decided in advance which one wins, the argument gets had again on every asset. 0 A.D.'s public art document settles it in eight words: "Gameplay trumps Realism when the two topics disagree."
A vision document is a page. If yours is running to five, some of it belongs in one of the other two.
The style guide
Question it answers: what should this look like?
Palette with hex values, line and outline rules, rendering and shading approach, silhouette and shape language, lighting direction, level-of-detail floor. Everything about the appearance of a finished asset.
A style guide is judged by one test: can you hold a finished asset up against it and get a yes or a no? "Palette: warm, gritty" fails that test. "Shadows are #322125 at 60 percent opacity" passes it, which is why the Liberated Pixel Cup guide can coordinate contributors who have never spoken to each other.
Biff, earlier pass183 × 300#F88830Predates the spec
Yuri, earlier pass179 × 300#F8C820Predates the spec
Biff, current302 × 560#6B7D95Yes on both
Yuri, current302 × 560#6B7D95Yes on both
The production spec
Question it answers: how does it get made and delivered without breaking?
Canvas sizes per asset class, file formats and background type, frame budgets, naming conventions, folder structure, engine import settings, what gets retained as source, and the checks an asset passes before it is accepted.
This is the half that gets omitted from most published advice and causes the most rework. It is also the half that is engine-specific, which is why it ages faster than the other two and deserves its own version number.
Side by side
| Vision document | Style guide | Production spec | |
|---|---|---|---|
| Answers | Why this look? | What should it look like? | How is it made and delivered? |
| Typical length | 1 page | 3–10 pages | 3–8 pages |
| Contains | Pillars, tie-breaker, references | Palette, line, light, rendering, detail floor | Canvas, formats, budgets, naming, import, checklist |
| Owner | Creative or art director | Art lead | Art lead with technical art or engineering |
| Written when | Before production | After ~10 assets exist | Before the second asset, revised after the tenth |
| Changes | Almost never | Occasionally, with a changelog | Whenever the engine or pipeline does |
| Read by | Everyone, once | Artists, constantly | Artists and engineers, constantly |
| Fails when | It has no tie-breaker | It contains adjectives instead of values | It is missing entirely |
So what is an art bible?
In practice, a style guide and a production spec bound together, usually with the vision document as its first page.
That bundling is a reasonable default for a small team. One document, one place to look, one owner. The four public art bibles worth reading are all bundles of this kind. 0 A.D.'s runs from artistic theme through to file naming conventions in a single document.
Where the bundle starts working against you is around the point where the engine section needs updating on a different cadence than the palette section. Palette rules are settled once and rarely move. Import settings change with every engine version. When you find yourself reluctant to open the document because a small technical edit means republishing the whole thing, split it.
Three ways conflating them goes wrong
The unreadable bundle
New artists are told to read it, do not, and work from whatever asset they happened to open first. An art bible nobody reads is worse than none, because everyone believes the rules exist.
Vision doc with no numbers
It reads well, everyone agrees with it, and it settles no arguments. The most common shape and the least useful.
Spec with no vision
Canvas sizes and naming and nothing about what the game is supposed to feel like. Technically compliant, no character.
The unreadable bundle. Everything in one file, forty pages, no owner. New artists are told to read it, do not, and work from whatever asset they happened to open first. The document's length is what killed it. An art bible that is not read is worse than no art bible, because everyone believes the rules exist.
The vision document with no numbers. Pillars, mood boards, and adjectives, called an art bible. It reads well, everyone agrees with it, and it settles no arguments because you cannot fail an asset against it. This is the most common shape and the least useful.
The production spec with no vision. Canvas sizes and naming conventions and nothing about what the game is supposed to feel like. The art is technically compliant and has no character. Rarer, but it happens on teams where engineering wrote the document.
Which ones do you need?
| Situation | Write | Skip |
|---|---|---|
| Solo dev, first project | One page of pillars plus a production spec | The formal style guide. Your taste is consistent; your canvas sizes are not |
| Solo dev using generation tools | Style guide, seriously | Nothing. This is the case where the style guide does the most work |
| Two to five people | All three, bundled as one art bible | Splitting them. Not worth the overhead yet |
| Working with freelancers | Style guide and production spec, as separate deliverables | Nothing. A freelancer needs both and should not receive the vision doc as homework |
| Larger team, multiple engines or platforms | All three, separate, separately versioned | The single bundle. It will rot |
Dwell on the second row. A solo developer's taste is naturally consistent, which is what taste is, so a style guide can feel redundant when you are drawing everything yourself. The moment a generator is producing the assets, that stops being true. The generator has no memory of asset one when it makes asset forty, and the style guide becomes the memory. It is the case where the document is least optional and most often skipped.
What about a character bible, or a world bible?
Same three questions, narrower scope. A character bible is a style guide plus production spec for one cast: reserved identity colors, silhouette notes, proportions, the animation set each character needs, what stays constant across all of them.
Worth splitting out once you pass roughly six characters, or once more than one person is making them. Below that it is a section, not a document.
The same test applies. If a line in it cannot be held against a finished asset and answered yes or no, it belongs in the vision document or nowhere.
Keeping them current, which is where most of them die
All three documents fail the same way, and it is not the way people expect. They are rarely wrong when written. They go stale because nothing forces the document to change when the art does.
The art moves first. Somebody makes an asset that breaks a rule, it looks good, it ships. Now the document describes a game that no longer exists, and every subsequent reader learns that the rules are optional. That lesson spreads faster than any rule in the document.
Three things prevent it, and they are cheap.
One named owner
Not a team, not a channel. A person. With no named owner it becomes a wiki page nobody enforces, and the failure stays invisible until you line up forty assets.
A changelog with a reason column
The reason column does the work: it forces you to justify the rule at the moment you write it. A rule whose reason you cannot state is one to delete rather than document.
A stated review trigger
Not a date. A condition. Conditions fire on their own. Calendar reminders get dismissed.
One named owner per document. Not a team, not a channel. A person. An art bible with no named owner becomes a wiki page nobody enforces, and the failure is invisible until you line up forty assets and see the drift. If two documents have different owners, that is fine and often better than one person owning all three.
A changelog with a reason column. Version, what changed, and why. The reason column does the work, because it forces you to justify the rule at the moment you write it. A rule whose reason you cannot state is a rule you should delete rather than document.
A stated review trigger. Not a date. Dates get missed. A condition. "Reviewed whenever the engine minor version changes" for the production spec. "Reviewed when a new asset class is added" for the style guide. Conditions fire on their own; calendar reminders get dismissed.
Which document rots fastest
This is the strongest practical argument for keeping them separate once a team passes a few people. Bundled into one file, the whole document inherits the rot rate of its fastest-moving section, and a spec that needs a small edit every engine update drags a palette section that was correct two years ago into constant republication.
Where each one should live
Format matters less than people think, but location matters a lot, and the rule is the same for all three: the document lives where the work happens.
A production spec belongs in the repository, next to the code, because it changes with the engine and the people who need it are already there. A style guide belongs wherever artists look: a wiki, a shared doc, pinned in the channel they use. A vision document belongs wherever new people are onboarded.
The anti-pattern is a beautifully formatted PDF in a drive folder. It cannot be diffed, it cannot be searched from the place you are working, and updating it requires opening a design tool. Every one of those adds friction to the act of keeping it current, which is the only thing that determines whether the document survives.
Plain text or markdown in the repo beats a polished PDF for anything that changes. Save the polish for the one page you hand to a freelancer.
The test that covers all three
Whatever you call the document, read it back with one question in mind: could a stranger use this to reject my work?
If the answer is no, it is a mood board with headings. That is a legitimate thing to have, and it is not a document anyone can work from.
The fastest way to fix it is mechanical. Go through and find every adjective: warm, gritty, clean, stylized, painterly. Each one is either replaceable with a number, a hex value, a direction, or a pair of images showing pass and fail, or it belongs in the vision document where adjectives are allowed. Nothing survives in the middle.
Our art bible template is a worked example of that pass, filled in for a real project with measured values, and the production spec is the third document split out on its own so you can see where the line falls.
Frequently asked questions
What is the difference between an art bible and a style guide?
A style guide covers what the art should look like: palette, line, lighting, rendering. An art bible in common usage is that plus the production rules around it: canvas sizes, file formats, naming, engine settings and sign-off. In games the two terms are used interchangeably often enough that it is not worth correcting anyone.
Is an art bible the same as a game design document?
No. A game design document covers mechanics, systems, progression and scope. An art bible covers only the visual side. They overlap on a single page. The pillars that state what the game is supposed to feel like.
Which should I write first?
The production spec, because canvas sizes and naming are expensive to change retroactively and cheap to decide up front. Write the style guide after about ten assets exist, so you are describing what you actually made rather than guessing.
How long should each one be?
Vision document: a page. Style guide: three to ten. Production spec: three to eight. If any of them is longer than that, some of it belongs in one of the others, or it contains adjectives that should have been numbers.
Do I need all three as a solo developer?
You need a page of pillars and a production spec. Whether you need a formal style guide depends on how the art gets made, if you are drawing it yourself, your taste supplies the consistency. If a generator is making it, the style guide is the only memory in the system.
What is a character bible?
A style guide and production spec scoped to one cast: reserved colors per character, silhouette notes, proportions, required animation set, and what stays constant across all of them. Worth splitting out past roughly six characters or once more than one person is making them.
