Chapter 4: Documentation & Naming that Downstream Teams Love

Created by Sarah Choi (prompt writer using ChatGPT)

Documentation & Naming That Downstream Teams Love for Character Concept Artists

Why documentation and names decide ship dates

Great concept art dies in production when teams can’t find, trust, or reuse it. Documentation and naming are the bridge between intent and implementation—especially in customizable, modular systems where heads, hair, outfits, palettes, and decals combine into thousands of permutations. Your goal is to produce a single source of truth whose file paths, labels, and boards encode constraints (what fits what), affordances (what swaps to what), and budgets (what costs what). Done well, downstream teams can implement without guesswork, scale content, and debug issues by searching for precisely one, predictable string.

Principles: clarity, consistency, and compression

Successful documentation is clear (readable at a glance), consistent (patterned so it can be parsed by humans and tools), and compressed (information‑dense without filler). Favor plain language, short sentences, and standardized tags. Avoid clever names and metaphors; your tags should behave like API contracts. If a rule isn’t visible in the art or spelled out in the doc, it doesn’t exist.

The single source of truth (SSOT)

Organize your handoff so each asset’s truth lives in exactly one place and everything else points to it. On your cover page, state:

  • Owner and date; scope (which slots/variants included); target camera contexts (portrait, gameplay, crowd)
  • Links to Slot Map, Compatibility Matrix, Budget Table, Palette/Decal Specs, and Change Log
  • A one‑paragraph plain‑language contract (e.g., “Hood up disables Hair classes Bob+; Backpack forces Cape_Split; Bulky_Collar requires Slim_Helm rim.”)

Folder structure that mirrors the pipeline

Your structure should reflect how downstream teams think:

/CHAR_<IP>_<FACTION>/CHAR_<name>/01_CONCEPT/

01_Boards/…

02_Orthos/…

03_SlotMaps/…

04_Palette_Decal/…

05_LOD_Perf/…

06_UI_Mockups/…

07_Readme/…

/CHAR_<…>/02_MODEL/

/CHAR_<…>/03_TEXTURES/

/CHAR_<…>/04_TECHART/

/CHAR_<…>/05_MARKETING/

Use the same slot spellings across every folder and board: Head, Hair, FaceCover, Eyewear, Headgear, Chest, Back, Arms, Hands, Legs, Feet, Cape, Harness, Palette, Decals.

Naming taxonomy that scales

Names should be parseable left‑to‑right from general → specific:

<Domain>_<Character>_<Slot>_<Style>_<Fit>_<Variant>_<LOD/Use>_<Colorway>_<Rev>

  • Domain: CHAR (character), PROP, VFX (keeps cross‑team search clean)
  • Character: canonical name or archetype (e.g., RANGER, MEDIC)
  • Slot: Head, Hair, Chest, etc.
  • Style: Formal, Tactical, Rugged, Ceremonial (or a faction code)
  • Fit: Slim, Std, Bulky (predicts compatibility)
  • Variant: A/B/C or a short functional tag (HoodUp, Braid, SplitCape)
  • LOD/Use: LOD0, LOD1, UI, MKT (portrait), GPLAY (gameplay)
  • Colorway: P00 for default palette; P01–Pnn for alternates
  • Rev: r01, r02… increments ONLY when the contract changes

Examples (filenames and layer group names):

  • CHAR_RANGER_Hair_Tactical_Std_Braid_LOD0_P00_r03.psd
  • CHAR_RANGER_Headgear_Tactical_Slim_HelmA_UI_P00_r01.psd
  • CHAR_RANGER_Chest_Rugged_Bulky_VestB_GPLAY_P02_r02.psd Layer group inside the PSD mirrors the file name: Hair>Style:Tactical>Fit:Std>Variant:Braid>LOD:0>Palette:P00.

Versioning and change logs that people actually read

Keep a one‑screen change log near the top of the readme:

  • 2025‑10‑14 r03 – Hair_Braid clearance widened; HoodUp auto‑swap note added.
  • 2025‑10‑12 r02 – VestB material cap reduced to 2; removed glass badge.
  • 2025‑10‑10 r01 – Initial submission. If an entry alters compatibility, tag it ⚠ and update the matrix the same day.

Boards that answer production’s first five questions

Each board should answer: What is this? Where does it go? What does it cost? What does it block/require? How does it fail?

  • Orthos with Slot Outlines: front/back/side with colored outlines per slot; include clearance halos and attachment icons (buckle, snap, sew, rigid socket)
  • Compatibility Matrix: slots vs. fit classes (Slim/Std/Bulky), cells = Allow / Swap(→) / Disallow (—) with specific swap names
  • Budget Box: tris, materials, texture pages, known overdraw risks (hair, cape)
  • Failure Modes: thumbnails showing clipping, z‑fight, occluded reads, with the chosen mitigation (slit, tuck, braid, disable)
  • Camera Ladder: portrait → gameplay → crowd with checkmarks for features that persist

Heads: blendshape and accessory documentation

For heads, include a blendshape envelope sheet: neutral, phoneme ranges, and three expression extremes. Mark zones where accessories must not intrude. Eyewear and face covers receive inner clearance callouts (nose bridge height, cheek pad angle); ear geometry gets earring legal zones with “pendulum envelopes” for motion. Name sets so rigging can bind quickly: Head_BSSetA_UI, Head_BSSetA_Gameplay, FaceCover_RespA_NasalClearanceHigh.

Hair: volume classes and swap rules on the page

Every hairstyle carries tags: VolClass: Buzz/Short/Bob/Shoulder/Long/Extreme, NeighborPolicy: CollarOK/CollarBevel/PauldronSplit, Hood: Allow/AutoSwap/Disable. Show collision silhouettes and the auto‑swap target (e.g., Hair_Long → Hair_Tied when HoodUp). Name files so the rule is encoded: Hair_Long_Autoswap_Tied_HoodUp.

Outfits: anchor topology and interlock notes

Outfit docs specify anchors (belt loops, epaulettes, harness D‑rings) and breaklines (hand‑off seams between garments). Each anchor gets a socket name that matches rig/blueprint terminology: Skt_Spine3_Pack, Skt_Sternum_CapeYoke. Interlocks are sketched with arrows (“Sleeve cuff tucks under Bracer_Std; Bracer_Bulky forces Sleeve_Slim”). The naming reflects control: Chest_VestB_Bulky_Controls:GloveSlim.

Palettes: channels, value rails, and LUT documentation

Treat palettes as data. Provide a channel map legend: CH0 Primary, CH1 Secondary, CH2 Tertiary, CH3 Metal, CH4 Accent, CH5 Skin/Hair (protected). Include value rails (min/max values by channel) and a small palette LUT preview that labels each swatch to channel. Name swaps predictably: Palette_P03_FactionIvy, Palette_P99_EventWinter. If certain materials are color‑locked (medic white, safety orange), mark them as Lock: in the legend and keep them out of LUT application.

Decals: legal zones, blend modes, and typography limits

Decal boards list legal projection zones per slot with UV‑safe shapes, blend modes (Albedo, Albedo+Normal Emboss, Emissive), and wear logic (inherits base wear vs. separate damage mask). Include font policy (families, min size at gameplay camera, outline buffer) and localization rules (character sets supported). Name assets with content and location: Decal_Shoulder_SigilAlpha_Albedo, Decal_Chest_Nameplate_Emissive, Decal_Helm_Serial_NormalEmboss.

Budget tables and caps (so nobody has to ask)

Create a one‑page cap table per character:

  • Head: Tri 12–18k / 1 mat, Hair: Tri 8–14k / 1 masked mat, Chest: Tri 10–20k / ≤2 mats, Cape: 1 masked mat, Decals: Shared 1–2k sheet
  • Textures: Soft Kit Atlas 2k, Hard Kit Atlas 2k, Hair 1k, Decals 1k, Palettes: LUT + 2 masks (512–1k) These numbers are illustrative; replace with project targets and call out platform tiers if you have them.

Readme that behaves like a contract

The readme should be short and executable—a contract anyone can follow. Use three sections:

  1. Rules (compatibility, auto‑swaps, disallows)
  2. Costs (material caps, texture pages, LOD fallbacks)
  3. States (camera ladder, pose pack references, beat flow) If a later board disagrees with the readme, change the readme and bump the revision.

Cross‑team mapping: rig, UI, design, and QA

  • Rig: list socket names and rotation envelopes that your silhouettes rely on; include jaw/neck pitch/yaw arcs when headgear is tight.
  • UI: provide paper‑doll mockups with slot names matching your taxonomy; label disabled states with player‑friendly copy (“Hood disables Long Hair. Auto‑swap to Tied?”).
  • Design: annotate how palettes and decals affect class/faction reads; provide unlock tiers and rarity language if relevant.
  • QA: include a pose pack list (idle, sprint, crouch, climb, sit) and expected outcomes (“Skirt clears knee armor via side slit”).

Searchability and tags

Add a tag block to each board and inside PSD metadata: #Slot:Hair #Fit:Std #Vol:Shoulder #Hood:Autoswap #Faction:Ivy #Palette:P00 #LOD:0 #Decal:None. Downstream tools can parse these to build catalogs and auto‑generate store tiles.

Common pitfalls (and how names prevent them)

  • Ambiguous variants (“Vest A green vs. Vest A winter”): enforce Style + Colorway tags.
  • Incompatibility drift (rules change but names don’t): bump Rev and the matrix together.
  • Folder roulette (multiple “final” folders): one canonical 01_CONCEPT with revisions; never duplicate.
  • Invisible rules (hair auto‑swap exists only in someone’s head): encode it in the name (Hair_Long_Autoswap_Tied_HoodUp) and the readme.

Minimal viable handoff (MVH) checklist

Before you ship a set, ensure the MVH includes:

  • Cover & Readme with scope, owners, rules, costs, states
  • Slot Map orthos with outlines and halos
  • Compatibility Matrix with named swaps
  • Budget Table and per‑slot Budget Boxes
  • Palette LUT + Masks with value rails
  • Decal Legal Zones with blend modes and typographic limits
  • Camera Ladder with feature persistence marks
  • Change Log updated to the day

Closing: names are interfaces

Think of every name and label as an interface contract between your intent and someone else’s toolchain. When your documentation is compact, parseable, and visibly tied to the art, downstream teams can act without clarification pings, and your modular systems—heads, hair, outfits, palettes, decals—scale cleanly across feature sets, platforms, and seasons. Design the information as deliberately as you design the silhouette, and your work will ship faster, safer, and with fewer surprises.