Chapter 4: Documentation & Naming that Downstream Teams Love

Created by Sarah Choi (prompt writer using ChatGPT)

Documentation & Naming That Downstream Teams Love

For Costume Concept Artists Working in Customization, Modularity & Systems

When you work on costumes in a modern game pipeline, you’re not just painting cool outfits—you’re designing pieces of a system. Slots, dependencies, palettes, decals, rarity tiers, monetization paths, UI hooks, animation and VFX triggers: all of these rely on the way you name, group, and document your work.

Good documentation and naming aren’t glamorous, but downstream teams will love you for them. Clear systems save hours of guesswork, reduce bugs, and make your ideas survive the long journey from pitch to shipped game. This article is written equally for:

  • Concept‑side costume artists (ideation, blue-sky, key art, variant exploration)
  • Production‑side costume artists (finals, callouts, breakdowns, vendor packs, LOD thinking)

We’ll focus on how documentation and naming support Customization, Modularity & Systems, especially around:

  • Slots (what goes where, and how pieces mix‑and‑match)
  • Dependencies (what requires or forbids what)
  • Palettes (how color and material systems are named and reused)
  • Decals (logos, patterns, markings, and how they plug into the system)

By the end, you’ll have a practical mental model for documentation and naming that character art, tech art, UI, animation, VFX, design, and QA will all be happy to work with.

1. Why Documentation & Naming Matter So Much in Modular Costumes

In a single‑hero, hand‑crafted pipeline, messy naming is annoying but survivable. In a customization‑heavy, modular costume system, it becomes a production hazard.

Your costume work is:

  • Broken into slots (Head, Chest, Legs, Hands, Feet, Back, Face, etc.)
  • Split into multiple variants (common/rare/legendary; starter/elite; faction A/B; seasonal skins)
  • Shared across bodies and skeletons (male/female, heavy/light, races/species)
  • Extended by multiple teams and vendors over time

Every piece will live in:

  • Asset databases
  • Build scripts
  • Localization strings
  • UI menus
  • Analytics dashboards

If names are vague, inconsistent, or duplicated, you get:

  • Wrong asset hooked to the wrong slot
  • UI labels that don’t match the art
  • Designers and engineers guessing at what something is
  • VFX or sound hooks wired to the wrong costume
  • QA bug lists where no one can tell what “New Robe v3” refers to

Good naming and documentation turn your costume into a clean, searchable system, not a pile of mystery files.

2. Know Your Downstream Teams & What They Need From You

Before we dive into naming patterns, it helps to think in terms of “What question is this team trying to answer when they open my files?”

2.1 Character Art & Outsource Vendors

They want to know:

  • Which parts belong to which slots
  • How pieces layer and attach
  • Which variants share base meshes or textures
  • What materials and palettes to use
  • Where decals, trims, and accessories go

They love:

  • Clear slot tags in filenames
  • Consistent naming for shared bases and variants
  • Callout sheets that match names in folders

2.2 Tech Art & Rigging

They need to know:

  • Which pieces interact with bones, physics, cloth, IK, or special rigs
  • Which parts are rig‑sensitive (skirts, capes, belts, dangling chains)
  • Where anchors and attachment points live

They love:

  • Explicit tags for cloth/physics (e.g., _cloth, _rigA)
  • Notes about collision risk and forbidden combos
  • Clean grouping of pieces that share a rig behavior

2.3 Animation & Gameplay Design

They want:

  • Clarity on how costume pieces read in motion
  • Which parts are gameplay‑critical (team color, class identity, weak points)

They love:

  • Clear tags for gameplay‑critical markings (_team, _role, _hitHighlight)
  • Documentation about how pieces behave in silhouette and extreme poses

2.4 UI/UX & Systems Design

They need to:

  • Display names and icons that map cleanly to internal IDs
  • Group items by slot, rarity, set, and theme
  • Build filters, sorting, and loadout systems around your naming

They love:

  • Slot, set, and rarity encoded in the internal name
  • A 1:1 mapping between internal name, concept callouts, and UI label

2.5 VFX, Audio & Narrative

They care about:

  • Which costume parts emit, glow, burn, crackle, chime
  • Narrative significance (holy relic, cursed gloves, unique banners)

They love:

  • Clear tags for VFX hooks (_fxFire, _fxLightning, _fxTrail)
  • Notes on narrative/cinematic importance in your docs

2.6 QA & Live Ops

They need to:

  • Log bugs against specific assets
  • Track which cosmetics are in which season, battle pass, event, or store tier

They love:

  • Names that include set, season, and slot
  • A simple way to see which variant is which without opening every file

If you design your documentation and naming with these teams in mind, you’re already halfway to a lovable costume system.

3. Naming Principles for Costume Systems

Before getting into slot‑specific patterns, let’s define some high‑level naming principles.

3.1 Be Predictable, Not Clever

Downstream teams don’t need poetic titles in your filenames. They need names that:

  • Sort logically in a list
  • Are easy to type from memory
  • Look familiar across sets and updates

Your creative naming lives in the UI display name (the name players see). Your internal naming should be functional, boring, and machine‑friendly.

3.2 Use a Stable Order of Components

Pick a fixed order of naming components and stick to it. For example:

[Project][Character/Body][Set/Theme][Slot][Variant][Rarity][Tags]

Example:

  • PRJ_Hero01_PaladinChest_Chest_V01_Rare_fxHoly_teamBlue

Once people learn your pattern, they can guess names they haven’t even seen yet.

3.3 Avoid Special Characters & Random Spaces

Safe characters:

  • Letters, numbers
  • Underscore _

Avoid:

  • Spaces, accented characters, punctuation beyond _

Why?

  • Some tools break on spaces
  • Scripting and search become simpler

3.4 Keep Variants Tight & Ordered

When you create multiple variants, name them so they line up in a natural order:

  • V01, V02, V03 (not v1, versionFinal, finalFINAL)
  • Or T1, T2, T3 for tiered rarity (Tier 1, Tier 2, Tier 3)

You can also encode function into variants:

  • _Base, _ColorA, _ColorB
  • _Season01, _Season02

3.5 Don’t Encode Everything in the Filename

Use filenames for high‑signal, frequently referenced information:

  • Project, character, set, slot, variant, rarity, tags like team, fx, cloth

Use metadata and documentation for lower‑frequency information:

  • Story notes, cinematic requirements, unique one‑off rig setups

Your filenames should be readable at a glance in a narrow asset‑browser pane.

4. Slots: Naming for Modular Pieces

Slots are the backbone of your customization system. Good slot naming makes it obvious where a piece belongs and how it layers.

4.1 Define a Slot Taxonomy

At minimum, write down and share your slot list. For example:

  • HEAD
  • HAIR
  • FACE (masks, glasses)
  • CHEST (torso armor, jackets)
  • LEGS (pants, skirts)
  • HANDS (gloves, gauntlets)
  • FEET (boots, shoes)
  • BACK (capes, backpacks)
  • WAIST (belts, hip pouches)
  • ACCESSORY (earrings, necklaces, badges)

Then decide on exact slot tokens you’ll embed into filenames. For example:

  • _SlotHead, _SlotChest, _SlotLegs, _SlotHands, _SlotFeet, _SlotBack

Keep them consistent and descriptive. Don’t mix Head and Helmet if they’re the same slot.

4.2 Example Slot‑Friendly Filenames

Using the pattern:

[Project]_[Character]_[Set]_[SlotToken]_[Variant]_[Rarity]_[Tags]

Examples:

  • PRJ_Hero01_Paladin_Chest_SlotChest_V01_Rare_fxHoly_teamBlue
  • PRJ_Hero01_Paladin_Helm_SlotHead_V01_Rare_teamBlue
  • PRJ_Hero01_Paladin_Cape_SlotBack_V01_Rare_clothLong
  • PRJ_Hero01_Paladin_Greaves_SlotLegs_V01_Rare

From the filename alone, downstream teams know:

  • Which character this is for
  • Which set it belongs to
  • Which slot it occupies
  • Which variant and rarity it is

4.3 Layers Within a Slot

Sometimes a single slot has multiple visual layers:

  • Inner shirt + outer jacket (both CHEST)
  • Under‑armor + plate armor

Decide how you’ll denote that:

  • _LayerBase, _LayerOver, _LayerUnder
  • Or _Inner, _Outer

Example:

  • PRJ_Hero02_Smuggler_TopInner_SlotChest_LayerBase_V01_Common
  • PRJ_Hero02_Smuggler_Jacket_SlotChest_LayerOver_V01_Rare

Documentation should diagram the layering order so tech art and design understand how to handle clipping and dependencies.

5. Dependencies: What Requires or Forbids What

A modular costume system isn’t just mix‑and‑match freedom; it’s also a web of dependencies and exclusions:

  • A long coat might forbid certain capes
  • A heavy backpack might force a specific harness
  • A special helmet may require a specific VFX

It’s not safe to keep this information “in your head.” It needs to be encoded and documented.

5.1 Naming Tags for Dependencies

You can’t define all logic in filenames, but you can hint at relationships using tags like:

  • _reqHarnessA (requires harness A)
  • _forbidCapeLong (forbids long capes)
  • _setPaladin (belongs to Paladin set)

Example:

  • PRJ_Hero01_Paladin_Cape_SlotBack_V01_Rare_clothLong_forbidBackpackHeavy
  • PRJ_Hero01_Paladin_BackpackHeavy_SlotBack_V01_Epic_reqHarnessA

Tech art and design can then use these tags as clues when building the actual logic tables.

5.2 Dependency Charts in Documentation

Alongside your files, maintain a simple dependency chart. As a concept artist, this can be a page in the costume pack that uses clear language and diagrams.

You might include:

  • Per slot notes:
    • “Paladin Cape V01 cannot be used with Heavy Backpack V01 (clipping risk).”
  • Set‑level logic:
    • “Paladin Helm V01 requires Paladin Class or above.”
  • Gameplay constraints:
    • “Team color on shoulder pad must always be visible; don’t pair with cloaks that fully cover shoulders.”

Present this visually when you can:

  • Small matrix tables
  • Color‑coded diagrams showing allowed and forbidden combos

5.3 System‑Friendly Language

Use language that designers and engineers can translate into rules:

  • Use words like “requires,” “forbids,” “overrides,” “shares base with”
  • Avoid vague phrasing like “probably don’t pair with”; be explicit

Example from documentation:

Rule: Paladin_Cape_V01 forbids all back slot items tagged _BackpackHeavy.

Rule: Paladin_Helm_V01 requires Paladin_Set in at least 3 other slots (Chest, Legs, Hands).

When your documentation reads like this, systems designers can build the logic without hunting you down for clarification.

6. Palettes: Color & Material Systems That Scale

In customizable costumes, palettes are not just “colors.” They’re reusable systems of color slots and material types that appear across multiple sets and characters.

6.1 Name Palettes by Function, Not Just Color

Instead of naming a palette BlueGold01, think in terms of function roles:

  • Base, Trim, Accent, Emissive, Metal, Cloth, Leather, etc.

A palette name might include:

  • Palette collection (e.g., Core, FactionA, EventWinter)
  • Role (e.g., Base, Trim, Accent)
  • Variant ID

Example:

  • Palette_Core_Paladin_Base_V01
  • Palette_Core_Paladin_Trim_V01
  • Palette_Core_Paladin_Accent_V01

The actual colors inside each palette can shift, but the roles stay consistent.

6.2 Document Palette Roles & Slots Clearly

In your costume documentation, explicitly define:

  • Which material zones in the costume map to which palette roles
  • Any non‑negotiable roles (e.g., team color, emissive danger color)

Example callout text on a sheet:

  • Zone A (chest plate): Base color from Paladin palette
  • Zone B (edging/trim): Trim color from Paladin palette
  • Zone C (gems/emissive): Accent color from Paladin palette

And in text:

All Paladin armor sets use Palette_Core_Paladin_*. The team color resides in Accent slot and must remain fully visible from front and back at mid‑camera distance.

6.3 Seasonal & Event Palettes

For seasonal or event variants, encode both the event and role:

  • Palette_Event_Winter24_Base_V01
  • Palette_Event_Winter24_Accent_TeamBlue_V01

On your variant concept sheets, annotate:

  • Which palettes map to which visual look
  • Which palettes are shared across multiple sets (e.g., all “Winter 24” cosmetics)

This helps UI, monetization, and live ops understand how to group items and what to reuse.

6.4 Material Tags Inside Names

Materials matter for both visuals and performance. Tag them when it’s helpful:

  • _matCloth, _matLeather, _matMetal, _matHologram

Example:

  • PRJ_Hero01_Paladin_Chest_SlotChest_V01_Rare_matMetalCloth

This isn’t a full physical description, but it gives tech art and shaders a quick filter.

7. Decals: Logos, Patterns & Markings That Plug In Cleanly

Decals are often where costumes carry identity: faction logos, team colors, kill counts, sponsor badges, religious symbols, etc. In modular systems, decals need especially clear naming and documentation.

7.1 Decal Naming Structure

A useful pattern:

[Project]_[DecalType]_[Faction/Team/Theme]_[UsageSlot]_[Variant]_[Tags]

Where:

  • DecalType = Logo, Pattern, Number, Text, Stripe, etc.
  • UsageSlot = Shoulder, Back, Chest, Helmet, Legs, Cape

Examples:

  • PRJ_Decal_Logo_FactionA_Shoulder_V01_teamA
  • PRJ_Decal_Pattern_Snowflake_Legs_V02_eventWinter
  • PRJ_Decal_Number_Team_Chest_V01_sports

Now downstream teams can immediately see:

  • What kind of decal this is
  • Where it’s typically applied
  • Which team/faction/event it belongs to

7.2 Decal Libraries & Sheets

In your documentation package, include decal sheets:

  • A page grouping decals by faction/set/event
  • Labels that exactly match the internal decal names

For each decal, note:

  • Recommended scale range (Small, Medium, Large)
  • Safe placement zones
  • Any forbidden uses (e.g., overlapping team colors, readability issues)

7.3 Layering & Priority

In some systems, multiple decals can stack on the same mesh:

  • Base pattern + faction logo + damage/wear decals

Document expected layer order:

  1. Pattern (underlay)
  2. Logo or Symbol (primary read)
  3. Damage/Wear (overlay)

Indicate this in your notes and, if helpful, in naming tags:

  • _LayerUnder, _LayerPrimary, _LayerOver

Example:

  • PRJ_Decal_Pattern_Camo_Chest_V01_LayerUnder
  • PRJ_Decal_Logo_FactionA_Chest_V01_LayerPrimary
  • PRJ_Decal_Damage_Scratches_Chest_V01_LayerOver

When VFX and shaders know the intended order, they can avoid visual noise and ensure key identity marks stay visible.

8. Documentation Formats: How to Package Information for Downstream Teams

Naming is one half of the equation. The other half is how you package your documentation.

Concept artists often think of “docs” as walls of text, but in production, the best documentation is often visual, and each page answers a specific question.

8.1 The Core Costume Pack Structure

A practical costume documentation pack might include:

  1. Overview page
    • High‑level concept
    • Set/theme name
    • Rarity banding
    • Characters supported
  2. Slot overview & mannequin map
    • Front/back view of mannequin
    • Each slot color‑coded and labeled (HEAD, CHEST, etc.)
    • List of all planned pieces
  3. Slot breakdown pages
    • One page per slot (e.g., “Chest Pieces”, “Back Pieces”)
    • Turnarounds and layer breakdowns
    • Callouts for materials, palette roles, decals, and dependencies
  4. Palette sheet
    • Swatches for each palette role
    • Notes on team color, emissive, metallic vs matte
  5. Decal library page
    • All decals used in the set
    • Names, IDs, and usage notes
  6. Dependency & rules page
    • Simple matrix or bullet list of allowed and forbidden combos
    • Any special rig or VFX requirements

These pages don’t need to be hyper‑polished art pieces. They just need to be legible, consistent, and directly tied to your naming.

8.2 Make Docs Searchable & Cross‑Referenced

Downstream teams will often skim your docs in a rush. Help them by:

  • Using the same exact internal name in your pages that appears in the filenames
  • Adding a small “ID” label under each concept (e.g., ID: PRJ_Hero01_Paladin_Cape_SlotBack_V01)
  • Using page titles that match slot names and sets (e.g., Hero01 Paladin – Chest Pieces)

When someone sees a bug like “Paladin Cape V01 flickers at extreme angles”, they can search for that ID and find both the asset and the concept page.

8.3 Documentation for Concept‑Side vs Production‑Side Artists

  • Concept‑side artists can start with rough but structurally accurate docs: slot maps, palette role definitions, decal concepts, and dependency intentions.
  • Production‑side artists refine those into final callout sheets and naming once constraints are locked.

Both sides should speak the same naming language so early docs evolve into final, production‑ready versions.

9. PSD & File Layer Naming: Help the Next Artist in Line

Your source files (PSDs, CLIPs, etc.) are also a form of documentation. A clean file can be the difference between a smooth handoff and a nightmare.

9.1 Group by Slot & Layer Role

Within your PSD, group layers in a way that mirrors your slots and palette roles:

  • CHEST_Base
  • CHEST_Trim
  • CHEST_Decals
  • CHEST_Shadow
  • CHEST_Highlight

For multi‑slot sheets, you might have top‑level groups:

  • Slot_Chest
  • Slot_Legs
  • Slot_Back

Inside each, keep consistent subgroups:

  • LineArt
  • BaseColor
  • MaterialNotes
  • Decals
  • FX_Mockup

9.2 Annotate Layers With Notes

Most painting tools allow you to name layers with short notes. Use these to communicate intent:

  • TeamColor (Accent palette slot – must stay visible)
  • EmissiveLines (hook to fx lightning)

This helps character art and tech art understand what’s negotiable (changeable embellishment) and what’s critical (gameplay or brand identity).

9.3 Keep “Exploration” Separate From “Final”

Exploration PSDs can be messy; that’s fine. But once you get to handoff, create a clean version:

  • Flatten exploratory layers into a few clear groups
  • Remove idle thumbnails, failed attempts, and irrelevant references
  • Name the handoff file clearly: PRJ_Hero01_Paladin_Set01_ConceptFinal_V03

The goal: downstream teams can open your file and immediately understand what’s final and what’s not.

10. Examples: Turning Messy Names Into System‑Friendly Ones

Let’s run a few transformations to make the idea concrete.

10.1 Example 1 – Chest Armor

Messy version:

  • PaladinArmor_final.psd
  • Paladin_armor_new2.fbx

System‑friendly version:

  • PRJ_Hero01_Paladin_Chest_SlotChest_V01_Epic_matMetalCloth_teamBlue
  • PSD: PRJ_Hero01_Paladin_Set01_Chest_ConceptFinal_V01.psd

Documentation callout:

ID: PRJ_Hero01_Paladin_Chest_SlotChest_V01_Epic_matMetalCloth_teamBlue

Notes: Uses Palette_Core_Paladin_*. Team color is Accent slot applied to shoulder stripe. Emissive is gem only.

10.2 Example 2 – Event Variant with Decals

Messy version:

  • paladin_xmas_final3.psd
  • paladin_chest_xmasV2_uplight.fbx

System‑friendly version:

  • PRJ_Hero01_Paladin_Chest_SlotChest_V02_Rare_eventWinter24_matClothLeather
  • PRJ_Decal_Pattern_Snowflake_Chest_V01_eventWinter24

Documentation notes:

Winter 24 variant uses Palette_Event_Winter24_*. Snowflake pattern is PRJ_Decal_Pattern_Snowflake_Chest_V01_eventWinter24, LayerUnder. Team color remains on shoulder trim (Accent palette slot).

11. Collaboration Habits That Make Your Docs Loved, Not Ignored

Even perfect naming conventions fail if no one follows or discovers them. As a concept artist, you can nurture habits that make documentation living, useful, and appreciated.

11.1 Check In With Downstream Teams Early

When you start on a new modular costume set:

  • Ask character art and tech art what naming patterns already exist
  • Align on slot tokens, set naming, and palette role names
  • Show them a draft of your mannequin/slot map

This avoids creating yet another scheme they’ll have to translate.

11.2 Reuse, Don’t Reinvent

If the project already has:

  • Slot names
  • Palette role names
  • Decal type tags

Use them. You’re contributing to a shared system, not inventing a new one per set.

11.3 Maintain a Simple “Costume Naming Cheat Sheet”

Create a one‑page cheat sheet that lives in your team’s shared drive, including:

  • Standard naming pattern template
  • Slot tokens list
  • Palette role names
  • Common tags (_team, _fx, _cloth, _matMetal, _forbidCapeLong, etc.)

Update it as the project evolves. New hires and vendors will silently thank you.

11.4 Treat Docs as Part of the Art, Not a Chore

Docs and naming are extensions of your design thinking:

  • When you define clear slot boundaries, you’re clarifying how the costume modularizes
  • When you specify palette roles, you’re clarifying what can change and what must stay
  • When you mark dependencies, you’re clarifying how the costume behaves in the system

Thinking this way makes documentation feel less like paperwork and more like systems‑level costume design.

12. For Concept‑Side vs Production‑Side Costume Artists

12.1 Concept‑Side Artists

Your goals:

  • Propose clear, modular structures for slots, palettes, decals, and dependencies
  • Use consistent internal IDs on sketches and exploration pages
  • Set up a naming pattern that production can extend, not replace

You don’t have to know every final engine constraint, but you should:

  • Avoid totally arbitrary names
  • Think about how pieces will mix‑and‑match
  • Communicate dependencies even in early passes

12.2 Production‑Side Artists

Your goals:

  • Lock documentation and naming to actual engine and tool constraints
  • Maintain consistency across the growing library of costumes
  • Ensure that callout sheets, filenames, and internal IDs match

You’re the last line of defense before costumes hit character art, tech art, and vendors. Your clarity can save dozens of hours across the pipeline.

13. Final Thoughts: Think Like a Systems Designer

Modular, customizable costumes live at the intersection of:

  • Art (shape language, style, narrative)
  • Systems (slots, palettes, dependencies)
  • Tools & Tech (engines, rigs, data pipelines)

Documentation and naming are where those worlds meet. When you:

  • Use predictable names with clear slot, set, and variant info
  • Document dependencies in a rule‑friendly way
  • Define palettes in terms of roles, not just colors
  • Organize decals as reusable, well‑labeled building blocks

…you’re not just being “organized.” You’re designing a costume system that downstream teams can trust and extend.

That trust—earned through clarity and consistency—is what turns your concept art from a beautiful picture on a page into a robust, shippable customization ecosystem that can grow over seasons, events, and expansions without collapsing under its own weight.