Asset naming and folder conventions

Unglamorous, and the thing that decides whether a project is navigable at asset number two thousand.

Naming is the cheapest discipline in game development and the one most often skipped, because its cost only appears later.

A workable scheme

Prefix by type, then subject, then variant, then suffix by role:

  • `SM_Crate_Wooden_01` — static mesh
  • `SK_Character_Guard` — skeletal mesh
  • `T_Crate_Wooden_BC` — texture, base colour
  • `T_Crate_Wooden_N` — texture, normal
  • `M_Crate_Wooden` — material
  • `MI_Crate_Wooden_Damaged` — material instance

The specific letters matter far less than using the same ones everywhere.

Why prefixes beat folders alone

Search. Typing `T_Crate` finds every texture for that prop regardless of where it lives; browsing folders does not, and assets move between folders as projects reorganise.

Rules worth enforcing

  • No spaces. They break command-line tooling and some engines' asset references.
  • No version numbers in shipping names. `Crate_final_v3_FINAL` is a source-control failure, not a naming scheme.
  • Zero-pad indices. `01` sorts correctly next to `10`; `1` does not.
  • Consistent case. Some filesystems are case-insensitive and some are not, and a project that works on Windows and fails on Linux usually fails here.

Generated assets specifically

They arrive with machine names — a hash, a job id, a prompt fragment. Renaming on import is the moment to do it. A library of forty generated props all called `generated_mesh` is unusable within a week, and the cost of fixing it grows with every reference.