One Naming System for Assets Across Projects

If you’ve ever opened an old project and thought “what on earth is this file for?”, you already know why naming matters. A single, repeatable asset naming and folder convention keeps references understandable when you start a new project, when you revisit an old one, and when multiple people (or multiple months) touch the same library.

This guide walks you through building a convention you can apply in one sitting: decide the structure, define the tokens, and migrate your first batch so the system starts paying off immediately.

Step 1: Choose a stable folder structure

Start with folders that reflect how you use assets, not how they were created. You want a layout that stays sensible even as your pipeline changes.

Use this baseline structure:

• Art/
  • Sprites/
  • UI/
  • VFX/
  • Icons/
  • Tiles/
  • Parallax/
• Audio/
  • SFX/
  • Music/
  • Vo/
• 3D/
  • Characters/
  • Props/
  • Environment/
  • Animations/
  • Materials/
• Data/
  • Items/
  • Levels/
  • Quests/
  • Dialogue/
• Docs/ (optional, but useful)
• Temp/ (optional, but keep it empty as often as you can)

Two rules make this work across projects:

1. One “home” per asset type. If something is a UI icon, it always lives under Art/UI/ (or Art/Icons/), never “wherever it fits today”.
2. No project-specific names inside core folders. Your project name belongs in the asset name token (or a top-level project folder), not in the folder taxonomy.

If you already have a library, keep your existing top-level folders and just align the deeper structure to the same intent: art versus audio versus data, and then type.

Step 2: Define a single naming pattern

Now decide what every asset name means. The trick is to include enough tokens to be searchable, but not so many that you stop using it.

Use a pattern like:

[assetType]_[subject]_[variant]_[state]_[descriptor]

Not every token is needed every time; the key is consistency in what you do include.

Here’s how to pick tokens in practice:

• assetType: what it is (e.g., SPR, UI, SFX, MUS, TILE, VFX, ICON, GLB, ANIM, MAT, DIA, ITEM, LVL)
• subject: what it belongs to (e.g., POTION, SWORD, BANDIT, FOREST, MAINMENU)
• variant: the versioning that matters (e.g., A, B, 01, 02, HD, LO, ALT)
• state (optional): how it’s used (e.g., IDLE, ATTACK, HIT, OPEN, CLOSED)
• descriptor (optional): extra qualifiers (e.g., NORTH, ISO, LOOP, ONE_SHOT, SMALL, MED, LARGE)

A few concrete examples:

• SPR_BANDIT_IDLE_01
• SPR_BANDIT_ATTACK_02
• UI_BTN_MAINMENU_DEFAULT
• ICON_POTION_HEALTH_01
• SFX_FOOTSTEP_STONE_02
• MUS_MENU_AMBIENT_LOOP
• VFX_SPELL_FIREBALL_IMPACT_01
• TILE_GRASSLAND_01
• GLB_PROP_CHAIR_OAK_01
• ANIM_HERO_WALK_01
• DIA_NPC_MERCHANT_GREETING_01

Notice what’s missing: no “final”, no “new”, no “v3_please_work”. Those are useful during production, but they don’t help future-you understand purpose.

Step 3: Pick token vocabularies (and stick to them)

Naming systems fail when “variant” becomes a free-for-all. Before you migrate anything, create a tiny vocabulary sheet and reuse it.

Asset type codes

Pick short, uppercase codes you’ll remember:

• SPR (sprites)
• UI (UI panels and elements)
• ICON (icons)
• TILE (tile textures / tilesets)
• VFX (VFX sprite sheets)
• SFX (sound effects)
• MUS (music)
• VO (voice lines)
• GLB (3D models)
• MAT (materials)
• ANIM (animation clips)
• DIA (dialogue trees / dialogue data)
• ITEM (items / item data)
• LVL (levels / level data)

Variant conventions

Choose one of these approaches and apply it everywhere:

• Index variants: _01, _02, _03 for “same thing, different take”
• Named variants: _ALB, _COLD, _HOT, _DAMAGED if the difference is meaningful
• Resolution/quality: _LO, _HD only when you truly ship variants

If you use indices, keep them numeric and zero-padded when you can (e.g., 01 to 09) so lists sort correctly.

State conventions

States should be comparable across characters and systems. For example:

• IDLE, WALK, RUN, JUMP, ATTACK, HIT, DEATH
• OPEN, CLOSED, HOVER, PRESSED for UI

Step 4: Apply the system to your first batch

Don’t rename everything at once. Rename a slice that proves the system works: one character, one UI screen, one environment tile set, and a handful of audio clips.

Work in this order:

1. Create the folders (even if they’re empty for now).
2. Rename assets in place for the slice you’re actively using.
3. Update references in your project for those assets only.
4. Leave a breadcrumb in your Docs/ folder: a plain text note listing your pattern and vocabularies.

When you rename, aim for these outcomes:

• You can guess the asset’s purpose from the name.
• You can sort assets and see them grouped logically.
• You can find “everything related to BANDIT” by searching for BANDIT.

Step 5: Lock it in as a reusable library habit

To keep a reusable asset library across several projects, treat naming as part of your intake process.

When you bring in new assets:

• Put them in the correct folder immediately.
• Name them immediately using the pattern.
• Only then integrate them into scenes, UI, or data.

When you generate derived assets (like animation frames, sprite sheets, or trimmed variants), keep the naming aligned:

• If it’s the same character action, keep the same subject and state.
• Put the difference into variant or descriptor (e.g., direction, loop, or size).

A practical example: suppose you have a character action you’ll reuse across projects.

• Base action: SPR_BANDIT_ATTACK_01
• Directional variant (if you have multiple angles): SPR_BANDIT_ATTACK_01_NORTH / _SOUTH (or _DIRN, _DIRS—pick a style and keep it)
• UI version (if you later crop it for an icon): ICON_BANDIT_ATTACK_01

The point isn’t perfection—it’s that your future reference workflow stays consistent.

Step 6: Handle “messy” assets without breaking the rules

Some assets don’t fit neatly. You still need them named so they don’t become unfindable.

Use these tactics:

• If you don’t know the state yet, omit state rather than inventing one. Example: SPR_BANDIT_ATTACK_01 instead of SPR_BANDIT_ATTACK_TODO.
• If it’s a one-off prop, keep subject specific: GLB_PROP_WAGON_01.
• If it’s experimental, put it in Temp/ until it has a purpose worth naming.
• If it’s a placeholder (e.g., a temporary UI button), name it clearly as placeholder: UI_BTN_TEMP_MAINMENU_01. Don’t hide it; just keep it quarantined.

That quarantine is what preserves the library. You’re not trying to make every file “production-ready”; you’re trying to stop the library from becoming a landfill.

Step 7: Make it easy to follow

Finally, reduce decision fatigue. Put your pattern and token vocabularies somewhere you’ll see them while working, and make a habit of doing it before you export or import.

A quick checklist for every new asset:

• Folder matches the asset type.
• Name starts with the right assetType code.
• subject is stable and meaningful.
• Variant uses your chosen scheme (01, 02, or named).
• State/descriptor are included only when they help you identify usage later.

Next, take one existing asset set you’ve already used—pick a character or a UI screen—and rename it fully into the new convention, then update just the references for that set.