Skip to main content

Raw Art Asset Foldering & File Naming Convention

Status: Draft

Owner: FSKU Art Department

Audience: Art Teams (Internal & External)

Last Updated: 20260123

1. Purpose & Principles

Repository & Version Control Context

Agate uses SVN (Subversion) repository to manage all raw assets for live projects.

SVN is used as the source-of-truth versioning system for raw art assets, providing:

  • Historical version tracking
  • Change traceability per asset
  • Controlled collaboration between internal teams and external vendors

This document is designed to work in conjunction with SVN and does not replace SVN version history. Instead, it defines human-readable structure and naming to make SVN usage predictable, reviewable, and scalable for art production.

This document defines a standard folder structure and file naming convention for managing raw art assets in Agate.

Goals

  • Ensure consistency across projects and teams
  • Make assets easy to find, review, and hand over
  • Reduce miscommunication between artists, leads, tech, and production
  • Support scalability for outsourcing and multi-project workflows

Core Principles

  • Clarity over cleverness – names should be readable without context
  • Predictable structure – same logic across all projects
  • Tool-agnostic – works for DCCs (Blender, ZBrush, Substance, Photoshop, CSP, etc.)
  • Version-safe – avoids overwriting and ambiguity

2. Scope

Included

  • Raw production files (e.g. .blend, .zpr, .psd, .spp, .toolbag)
  • Work-in-progress (WIP) assets
  • Assets created by internal and external artists

Excluded (Handled by Other Docs)

  • Engine/exported assets
  • Build/package files
  • Version control system rules (Git)

3. High-Level Folder Structure

/[PROJECT_CODE]/
  /[ASSET_TYPE]/
    /[ASSET_NAME]/

Placeholder Definitions

  • PROJECT_CODE → Project identifier (e.g. BOM, RED)
  • ASSET_TYPE → Characters, Props, Environments, UIs, Cinematics, Marketings
  • ASSET_NAME → Unique, human-readable asset identifier

(We will refine and lock these values later)

4. Asset-Type Folder Breakdown

4.1 Characters

/Character/
  /CHR_[CharacterName1]/
  /CHR_[CharacterName2]/

4.2 Props

/Prop/
  /Interactive_PRP_[PropName]/
  /Weapon_PRP_[PropName]/
  /Armor_PRP_[PropName]/
  /[PropContext]_PRP_[PropName/

4.3 Environments

Environment art-related props should be placed here

/Environment/
  /Biome/ -> raw terrain data, lookdev data, or anything high level regarding env assets
  	/ENV_[BiomeName]/
  /ModularKit/ -> raw assets for modular prop for certain biome/context
  	/ENV_KIT_[ModularKitSetName]/
  /Hero/ -> hero prop for environment assets
  	/ENV_HERO_[HeroEnvObjectName]/

4.4 UIs

/UI/
  /UI_Screen_[ScreenName]/
  /UI_IconKit_[IconKitName]/

4.5 Cinematics

/Cinematic/
  /CUTSCENE_[CutsceneName1]/
  /CUTSCENE_[CutsceneName2]/

4.6 Marketings

/Marketings/
  /SteamStoreCapsule/
  /CinamaticTrailer/
  /MarketingReadyImages/
  /MarketingReadyVideos/
  /[MarketingArtContexts]/

(Tech Art handled as supporting discipline, not top-level asset type)

5. Context Code (Locked Vocabulary)

To keep file names readable while aligning with industry-recognized shorthand (including Unreal Engine standards), the following context vocabularies and codes are locked.

Context PrefixCode Meaning
CONCEPT CPT Concept art, visual exploration
STATIC 2D 2DS Static Illustration/2D
ANIMATION 2D 2DA Skeletal 2D or flippbook 2D animation
STATIC 3D SM Static mesh development (model, sculpt, textures), Static image (illustration, icon)
ANIMATION 3D SK Skeletal mesh, rigging, skinning, animation clips
TEXTURES T Texture files, intended to be used for 3D model with specific UV
VFX VFX Asset-specific visual effects
STORYBOARD BRD Storyboard asset, related to cinematic/cutscene
ANIMATIC AMT Pre-visualization of cinematic/cutscene, before locking timing, shots, & asset production
PUBLISH PUB Approved, signed-off handoff files

Rationale

  • CPT is more recognizable than CON and avoids collision with config/console shorthand.
  • SM / SK follow Unreal Engine conventions and are immediately readable by tech art and engineers.
  • Folder names remain semantic; codes are optimized for filenames and engine adjacency.

6. Stage Applicability Matrix

This matrix defines which development stages are applicable per ASSET_TYPE. Stages not listed should not be created unless explicitly approved.

ASSET_TYPE _brief CONCEPT STATIC ANIMATION VFX
Characters ✓ ✓ ✓ ✓ ✓
Props ✓ ✓ ✓ △ △
Environments ✓ ✓ ✓ △ ✓
UIs ✓ ✓ ✓ △ △
Cinematics ✓ ✓ ✓ ✓ ✓
Marketings ✓ ✓ ✓ △ △

Legend

  • ✓ = Standard / expected stage
  • △ = Optional, asset-dependent
  • ✕ = Not applicable

7. Asset-Level Folder Structure

/[ASSET_NAME]/
	/_brief/
	/_reviews/
	/_wip/
	/01_CONCEPT/ -> PSD, CSP, etc
	/02_STATIC/ -> ZPR, BLEND, FBX, TOOLBAG, PAINTER, PSD, CSP, etc
	/03_ANIMATION/ -> BLEND, FBX, SPINE, etc
	/04_VFX/ -> PSD, HIP/HDA, FBX, BLEND, etc
	/05_PUBLISH/ -> FBX, SKEL, TEXTURES, etc game ready

Folder Intent

  • _brief → Briefs, initial sketches from directors/leads, moodboards, external refs
  • _reviews → Time-based progress previews and feedback records ****
  • _wip → Misc WIP, temporary or cross-stage files
  • 01_CONCEPT → Concept art, exploration, silhouettes, color keys
  • 02_STATIC → Static asset development (model, sculpt, textures)
  • 03_ANIMATION → Rig, skinning, animation data
  • 04_VFX → Asset-specific visual effects (if applicable)
  • 05_PUBLISH → Approved handoff files per stage

(We will refine the folder/stage matrix for each asset type as we go)

7.1 Reviews Folder Structure & Rules

Progress updates and feedback must be stored under the REVIEWS folder to ensure clear historical tracking and auditability.

/_reviews/
  /[YYYYMMDD]_[STAGECODE]_update/
  /[YYYYMMDD]_[STAGECODE]_feedback/

Naming Rules

  • YYYYMMDD uses calendar date of the review or submission
  • STAGECODE must match the asset stage being reviewed (CPT / SM / SK / VFX)
  • One update folder may have multiple preview files (screenshots, playblasts, turntables)
  • Feedback folders may contain:
    • Annotated images/videos
    • Written feedback (PDF, TXT, MD)
    • Call notes or screenshots from review tools

Example

/_reviews/
  /20260120_SM_update/
    VA6_HeroKnight_SM_turntable.mp4
    VA6_HeroKnight_SM_view01.png
  /20260121_SM_feedback/
    VA6_HeroKnight_SM_feedback_v01.pdf

Feedback File Naming Hint (Recommended)

[PROJECT]_[ASSET]_[STAGECODE]_feedback_v##.[ext]

Additional Notes:

  • Use one update folder per daily check-in
  • Feedback should always reference the corresponding update date and stage
  • Do not overwrite previous update or feedback folders
  • If multiple review cycles happen in one day, append an index:
    • VA6_HeroKnight_SM_view01
    • VA6_HeroKnight_SM_view02

8. File Naming Convention (General Format)

[PROJECTCODE]_[ASSETTYPE]_[AssetName]_[STAGECODE]_[Suffix].[Filetype]

Example

ASTRA_CHR_HeroKnight_SM_Model.blend -> static model file
ASTRA_CHR_HeroKnight_SK_RIG.blend -> rig file
ASTRA_CHR_HeroKnight_SK_AnimationSet.blend -> animation file

Field Definitions

  • PROJECTCODE → Project code
  • ASSET → Asset name (matches folder name)
  • ASSET_TYPE → Characters / Environments / Props / UIs / Cinematics / Marketings
  • DESC → Purpose or content (Model, Sculpt, Rig, Tex, Blockout)
  • STAGECODE → Code for the stage following context code table on 5. Context Code
  • SUFFIX → Additional context, like N (Normal Map), ORM (Occlusion/Roughness/Metalness Map) for Textures

(Exact abbreviations to be finalized)

9 Publish Folder – Approval & Sign-off Rules

The PUBLISH folder represents an official, approved state of the asset. Files placed here are considered production-valid.

Rules

  • Only approved versions may exist in PUBLISH
  • Each published file must match an approved review cycle in /_reviews

Authority

  • Assets may only be moved or copied into PUBLISH by:
    • Art Lead / Art Director
    • Or delegated PIC defined per project

Non-Rules

  • PUBLISH is not a backup folder
  • PUBLISH is not a place for iteration or WIP

Approval Traceability (Recommended)

For every published asset, at least one of the following must exist:

  • A corresponding [YYYYMMDD]_[STAGECODE]_feedback folder indicating approval
  • A signed-off feedback file (PDF or annotated image)

If it’s not in _reviews, it’s not approved.

10. Common Do & Don’t

Do

  • Match file name with asset folder name
  • Use English, no spaces, use _underscores_between_naming_codes.
  • Use UPPERCASE or PascalCase or consistently

Don’t

  • Use personal initials in file names
  • Use ambiguous terms ("test", "new", "fix")
  • Store final work only in WIP folder
  • Bloat WIP folder

No Comments
Back to top