Creating a style bible for game graphics

Creating a Style Bible for Game Graphics

A style bible is a living document that replaces the art director in their absence. This sounds like an exaggeration, but this is how production works on large teams: not every artist has direct access to the art director, not every outsource contractor understands style nuances without explanation. Bible gives everyone a single source of truth.

The difference from style guidelines is that guidelines are rules, and bible is a system. It includes rules, but also the history of visual decisions, justification for deviations from canon, examples of edge cases, and instructions for updating the document itself.

What's Included in a Complete Style Bible Structure

The content depends on the project, but the core is always the same.

Vision statement. One or two paragraphs—what the game looks like if you describe its visual image for someone who hasn't seen it. Not genre, not mood—concrete images. "Post-apocalypse in 200 years: nature reclaimed cities, rust covered with moss, metal matte with dark oxide, light always through foliage or dust." This is the anchor to return to with any disputed decision.

Color system with usage rules. Not just hex codes—hierarchy: dominant colors (60%), secondary (30%), accent (10%). For 3D—PBR Value Guide: a table of permitted Albedo ranges for each material class. This eliminates physically incorrect textures that break lighting.

Typography and font system. Primary/secondary fonts, scaling rules, spacing. For games—separate rules for diegetic text (writing in the game world) and UI typography.

Rules for each art discipline. 3D modeling (naming convention for meshes, UV layout rules, maximum polygon budget by category), texturing (texel density by asset category, texture atlas resolution, required maps—BaseColor, Normal, ORM or separate R/M/AO), rigging (bone naming convention, IK/FK strategy, BlendShape names), animation (curve style, rules on timing and spacing under visual style).

VFX rules. Particle system: size, lifetime, speed ranges—all under visual style. If the game is stylized—VFX shouldn't be realistic even if technically possible.

Anti-examples. This is the most valuable. Show finished assets that were made "wrong" and explain why. This teaches better than any rule.

Tools for creation: Figma (component system, interactive links between sections), Notion (if team already works there—easier integration), sometimes custom web document for external contractors with search function.

Specifically About Document Updating

Style bible shouldn't be static. Best practice—versioning the document (v1.0, v1.1, etc.) with changelog: what changed, why, which assets need updating per new rules. A document without changelog will contradict itself in half a year.

Update process: who can make changes, how it's coordinated, how the team is notified—this is also part of the document.

Creation Timeline

Cost is calculated individually. If the project already has partial documentation—we start with an audit of existing materials.