Archiving graphics source files and game project files

Archiving Graphics Source Files and Game Project Files

A game studio closed a project three years ago. Now they need to return: develop DLC, port to a new platform, or simply answer "why does this character have that topology on the legs?" They open the NAS — a folder art_final_FINAL_v2_use_this_one with 12,000 files without dates and no connection between source files and what ended up in the game. Substance Painter opens a .spp file and reports that linked textures are not found. A Photoshop file weighs 2 GB, half the layers have no names.

This is a standard situation for studios that didn't do archiving during production.

What to preserve and in what form

A graphics archive is not simply "put everything in ZIP". It's a structured repository with reproducible state: open a file in two years — get the same result.

Substance Painter sources (.spp). The most problematic category: the file references base materials from Substance's Smart Materials library. If the library updates — old materials may look different. Correct archiving: .spp + exported folder with Baked Textures + .sbsar files of used materials from the library.

Photoshop (.psd). Embedded smart objects may reference external .psb files. During archiving: File > Package does not exist in PS — you need to manually flatten linked or collect into a folder nearby. Fonts: if a non-standard font is used, include it in the archive or specify exact name + version.

Blender (.blend). File > External Data > Pack Resources packs all external textures inside the file — archiving one .blend is sufficient. But it will then weigh significantly more.

Maya (.ma/.mb). File > Optimize Scene Size + File > Archive Scene — creates a zip with all dependencies. .ma (ASCII) is preferable to .mb (binary) for long-term storage — readable with a text editor even without Maya.

Archive structure

Bad archive: art/, 5000 files inside in alphabetical order.

Working archive:

project_name/
  characters/
    hero/
      sources/          # .psd, .spp, .blend
      exports/          # .fbx, .png, .tga — what went into the engine
      references/       # reference images, concepts
      VERSIONS.md       # brief change history: date, author, what changed
  environments/
  ui/
  vfx/
  README.md             # engine version, tool versions, author contacts

VERSIONS.md at each asset level sounds excessive, but it's the only way to understand a year later "why the character texture was redone three times".

Technical requirements for long-term storage formats

Closed formats tied to software are a risk. Preferred formats:

FBX is not the ideal format (proprietary Autodesk), but de facto standard. glTF 2.0 as a supplement for mesh data — open standard, supported by Blender, Unity, Unreal.

Tools for audit before archiving

Before archiving: check broken references (Substance: File > Check Baked Maps Links), clean unused layers in PSD, verify all textures in .spp are baked and exported.

Custom Python script for inventory: traverses folder tree, collects list of files with size, date, extension → CSV. This allows finding duplicates (one texture in three places with different names), outdated versions (file _old, _backup), overly large files for optimization candidates.

Timeline

Cost is calculated after initial audit of materials volume and condition.