Sarah Clarity Studios

Chapter 4: Documentation & Naming that Downstream Teams Love

Created by Sarah Choi (prompt writer using ChatGPT)

Documentation & Naming Downstream Teams Love for Creature Concept Artists

The fastest way to earn trust across a studio is not just to design great creatures—it’s to deliver packages that downstream teams can use immediately without guessing. When you’re designing variants, families, and spawn pools, documentation becomes even more important because everyone is juggling relationships: what is shared, what is unique, what is cosmetic, what is functional, and what must stay consistent so the player’s reads remain fair.

This article is written equally for concepting and production creature concept artists. For concepting artists, it focuses on writing and organizing information so design and production can greenlight a family confidently. For production artists, it focuses on naming conventions, file structure, and handoff details that keep modeling, rigging, animation, VFX, audio, UI, and gameplay from burning time on clarification.

Why downstream teams “love” certain documentation

Downstream teams love documentation that reduces ambiguity. Most pipeline friction comes from the same few pain points: unclear intent, inconsistent naming, missing scale references, and variants that look similar but behave differently without clear tells. Great documentation creates a shared mental model. It answers, in one place, what the creature is, what it does, how it differs from siblings, and what is safe to reuse.

The goal is not to write more text. The goal is to write the right text, placed where people will actually see it, in a form that can survive asset tracking systems and versioning.

Think like a library, not a folder

Creature families are content libraries. If you design them like one-offs, your handoffs become scavenger hunts. The simplest shift is to adopt a library mindset: every family has a “home,” every asset has a predictable name, and every variant can be found without opening files.

A useful organizing principle is: Family → Size Class → Role → Region → Skin/Color Morph. Not every project uses every level, but if you keep this hierarchy consistent, everyone can infer meaning from a filename.

The two documents you always need

Most families can be supported by two core documents that live beside the art.

The first is a Family Spec Sheet. This is the one-page summary of identity invariants, role set, and the gameplay intent. The second is a Variant Matrix that lists each variant, what changes visually, what changes behaviorally, and what it reuses technically.

If your studio uses a wiki, these can be wiki pages. If your studio uses shotgrid/jira/production trackers, these can be attached PDFs. The format matters less than consistency and discoverability.

Naming: build meaning into the string

Naming should carry meaning without becoming a novel. You want a name that lets someone guess three things: family, role, and size class. Everything else can be a suffix.

A practical naming structure looks like: [Project][Family][Size][Role][Region][Variant][Version].

For example, a medium ranged volcanic variant might be something like: PROJ_Crownback_M_RNG_VOL_A_v03. If your studio prefers words instead of abbreviations, keep the order the same and shorten only where necessary.

The key is that the order never changes. Order is what makes sorting and searching work.

Abbreviations: keep a small, shared dictionary

Abbreviations are only helpful if everyone shares them. Create a small dictionary and put it at the top of the Family Spec Sheet.

Size classes might be S/M/L/XL. Roles might be BAS (baseline), TNK (tank), RNG (ranged), SUP (support), AMB (ambush), ELT (elite). Regions might be DES (desert), SWP (swamp), ALP (alpine), VOL (volcanic). Color morphs might be C1/C2/C3 or named skins.

If your studio already has conventions, match them. If not, propose a minimal set and stick to it. Downstream teams appreciate stability more than cleverness.

Distinguish “cosmetic” from “functional” everywhere

Variants can differ cosmetically, functionally, or both. This distinction should be visible in filenames, tables, and callouts.

A cosmetic-only color morph might use a suffix like SKN or COS, while functional variants use role codes. A table can include a column called “Gameplay Delta” that is either “None” or lists the mechanic changes.

This prevents one of the worst production problems: someone assuming a recolor is “free” when it actually implies different VFX, audio, resistances, or behaviors.

The Family Spec Sheet: what it contains

A family spec sheet should be readable in under two minutes. It is not a lore document; it is a production-and-design alignment page.

It should contain a short paragraph describing the family identity and silhouette invariants. It should include scale notes and comparison silhouettes (human, player, common props). It should state the core locomotion and the “signature tell” language: where weak points are, how charge-up looks, what the audio motif is.

It should also include the “allowed variation palette”: what can change safely (horn sets, plating density, pattern masks) and what should not change (spine gesture, head silhouette, weak-point zone).

The Variant Matrix: the table everyone actually uses

A variant matrix is where downstream teams spend their time. Even if you don’t present it as a literal table, the information should behave like one.

Each variant entry should include: the variant name, size class, role, region, color morph (if any), silhouette changes, surface/material changes, and gameplay changes.

Then include a “Reuse/Dependency” section: rig (shared/new), animation (shared/new/layered), mesh (shared/modular/unique), textures (shared/new), shader features (shared/new), VFX (shared/new), audio (shared/new), behavior (shared/new states).

This is the heart of “downstream teams love you” documentation because it lets every department estimate work quickly.

Visual callouts: label what matters, not everything

Good callouts are selective. Label the decisions that affect production and gameplay, not the obvious anatomy.

Examples of high-value callouts include: socket locations for VFX, deformation risk zones (membranes, heavy plates near joints), breakable armor sections, weak-point materials, and interaction points (mount points, grapple points, targetable sacs).

For variants, call out what changes and why: “RNG variant has throat sac mesh + VFX socket here,” “SUP variant has antennae with emissive pulses—reserve this color family,” “ELT has reinforced crown plates—breakable in sequence.”

Naming layers: creature name vs asset name vs encounter name

Studios often have three naming layers, and confusion happens when they are mixed.

The creature name is what the player sees (localized, marketing-friendly). The asset name is what production uses (stable, sortable, often abbreviated). The encounter name is what designers use in spawn pools (often a prefab or archetype name).

Document the mapping between them. Put it in the variant matrix. “Crownback Warden” might be the creature name, while the asset is Crownback_XL_BOSS, and the encounter prefab is CB_Warden_Phase2.

When these mappings are explicit, everyone stops arguing about words and starts shipping.

Regional palettes: document value structure and reserved colors

Regional palettes must be documented as rules, not vibes. Downstream teams need to know what is fixed.

Provide swatches with value guidance: not just hue chips, but notes like “body midtones stay within this value band,” “weak points always use this accent family,” “emissive reserved for charge state only,” “avoid matching background value in this region.”

For color morphs, state whether the morph is cosmetic or functional. If functional, define the code: “blue = frost attacks,” and ensure UI/VFX/audio align.

Size classes: document scale, collision expectations, and LOD intent

Size classes should include scale callouts and practical expectations.

Include height/length ranges, shoulder height, and a comparison silhouette. Include notes like “L class must read at 50m; simplify pattern frequency,” or “S class often appears in swarms; silhouette must remain simple and role marker must be high-contrast.”

If you can, note whether size classes are intended to share rigs or require new skeletons. Even an early “likely shared” versus “likely unique” helps production plan.

Roles: document the one-second read and the gameplay delta

For each role variant, include a short paragraph that states what the player should notice immediately and what changes in gameplay.

For example: “RNG: forward throat sac silhouette + audible gurgle charge; launches arcing projectiles; weak point is sac seam.” Or “SUP: antennae broadcast pulses; buffs nearby units; prioritize targeting.”

This is especially important in spawn pools, where designers need clarity on what the role does, and VFX/audio need consistency in tell language.

Spawn pools: document typical mixes and teaching order

Concept art rarely includes spawn pool documentation, but it should—at least at a high level—when you’re working on families.

Provide a short paragraph describing typical group composition: “Standard pack is 1 TNK + 2 BAS + 1 RNG,” or “Late-game mix adds 1 SUP.” Provide progression notes: which variants appear early, mid, late, and which are rare.

This helps designers and encounter teams use your creatures correctly. It also helps you test silhouette compositions: whether the boss remains readable with minions present.

Versioning: make iteration visible and safe

Downstream teams hate “final_final2.” Use explicit versioning.

Put versions in filenames (v01, v02). If your studio uses source control or asset tracking, match its conventions. Maintain a short changelog on the Family Spec Sheet: “v03: moved weak point from back to chest; added role marker horns for TNK.”

This protects everyone from outdated assumptions. It also helps outsourcing, where old references can linger.

File packages: what a clean handoff looks like

A clean handoff package is predictable.

At minimum, include: a hero sheet, orthos for base and silhouette-changing variants, a material ID sheet, a role marker sheet, a regional palette sheet, and the two documents (spec + matrix).

If your studio supports it, include layered PSDs with named groups that match variants, plus flattened exports in a consistent size. Include a thumbnail set for quick browsing in trackers.

Layer naming inside PSDs: small effort, huge payoff

Naming inside files is part of documentation. A downstream artist opening your PSD should not have to guess what “Layer 57 copy” means.

Use group names that match the asset naming hierarchy: FAMILY → SIZE → ROLE → REGION → VARIANT. Name callout layers clearly: “VFX_SOCKET,” “WEAKPOINT_ZONE,” “DEFORM_RISK.” Keep a “NOTES” layer for quick read.

This is one of the easiest ways to make your work loved.

Cross-team collaboration: write for your readers

Different teams look for different things.

Modeling needs orthos, proportion callouts, and modular breakdowns. Rigging needs joint range notes, deformation risks, and consistent anatomy rules. Animation needs silhouette keys, gait intent, and clear attack reads. VFX needs socket placement, reserved colors, and “do not obscure silhouette” guidance. Audio needs motif notes and state triggers. Design needs role definitions, spawn pool intent, and fairness cues.

You don’t need to write separate documents for each team. You need to place the right information where they can find it quickly.

Common documentation mistakes that create production pain

One mistake is inconsistent naming between sheets, folders, and tracker entries. Another is unclear differences between variants: “This one is more aggressive” without any role marker or gameplay delta. Another is missing scale references, leading to rigs and collisions that don’t match intent.

A final common mistake is over-documenting trivial details while missing key technical constraints. If you label every tooth but forget to call out a membrane that needs special rigging, you’ve documented the wrong thing.

A simple “downstream love” test

Before you hand off, ask yourself: could a new teammate understand this family without a meeting? Could they find the correct file in under 30 seconds? Could they tell which variants are cosmetic versus functional? Could they identify the role marker and weak point language from a thumbnail?

If the answer is yes, your documentation is doing its job.

Closing: documentation is part of the design

In creature families and spawn pools, documentation is not administrative overhead. It is part of the creature system. Naming is gameplay communication. Matrices are scope control. Palette sheets are fairness.

When you build predictable names, clear variant matrices, and short, high-value callouts that map to role, region, size class, and reuse, downstream teams stop asking for clarification and start building. And that is what it means to make documentation and naming that teams love.