Professional Archiving of Game Art Sources

Why Archiving Sources Is an Investment, Not an Expense

We regularly encounter the situation: a studio closed a project, and a couple of years later they need to release a DLC or port to a new platform. They open the NAS — and see chaos: a folder art_final_FINAL_v2, 12,000 files without dates, Substance Painter complains about missing linked textures, a Photoshop file weighs 2 GB, half the layers have no names. Restoring the work is possible, but it takes weeks instead of hours. Our experience shows: properly organized archiving from the start pays off at least twice as fast. We preserve not only files but also context: software versions, settings, dependencies. This turns the archive into a working snapshot of the project, not a dump of binaries. We've encountered projects where the art director left and no one knew how to assemble the scene.

Engineering integrity principle "A good archive allows you to open a project 5 years later without a single call to a former employee."

Risks of not archiving

• Loss of links between sources and final assets. For example, a texture in the game looks different than in .spp — it's impossible to remember which material was used.
• Time spent searching for files grows to 30% of total work time. According to our measurements, a structured archive saves up to 40% of time when returning to a project.
• Critical files may not open in new software versions. This is especially true for binary formats like .mb. Using ASCII formats such as .ma reduces compatibility risks by 90% compared to binary .mb.

What information must be preserved

Substance Painter (.spp)

The most problematic format. The file references Smart Materials from the Substance library. If the library updates, the appearance will change. We archive: .spp + exported Baked Textures (normal maps, ambient occlusion) + .sbsar of all used materials. This guarantees reproducibility across any updates.

Photoshop (.psd)

Smart Objects may reference external .psb files. There is no Package function, so we manually collect linked layers into one folder or flatten. We definitely check fonts — attach OTF/TTF.

Blender (.blend)

It suffices to enable File > External Data > Pack Resources — all external data is packed inside .blend. Simple, but the file becomes heavier. For long-term storage, this is justified.

Maya (.ma/.mb)

We use File > Optimize Scene Size, then File > Archive Scene — creates a zip with all dependencies. We prefer .ma (ASCII) — it can be opened in a text editor even without Maya.

Recommended archive structure

Bad archive: art/, inside 5000 files in one heap. Working archive from our engineers:

project_name/
  characters/
    hero/
      sources/          # .psd, .spp, .blend
      exports/          # .fbx, .png, .tga — what went to the engine
      references/       # references, concepts
      VERSIONS.md       # change history: date, author, what was done
  environments/
  ui/
  vfx/
  README.md             # engine version, tools, contacts

VERSIONS.md for each asset sounds redundant, but it is precisely what answers 'why the texture was reworked three times'.

Recommended formats for long-term storage

FBX is the de facto standard, but it is proprietary. As a supplement we use glTF 2.0 — an open format supported by Blender, Unity, Unreal. glTF 2.0 is 30–50% more compact than FBX and is better suited for data exchange between pipelines. For both Unity and Unreal projects, archiving the source art ensures future patching and porting.

Step-by-step archiving process

1. Audit: Run a Python script to scan folders, identify duplicates and broken links. Generate a CSV report with recommendations.
2. Clean: Remove unused layers, flatten PSDs, check baked maps in Substance Painter.
3. Package: Convert binary formats to ASCII (Maya .mb → .ma), pack dependencies, embed resources (Blender).
4. Structure: Organize files into the recommended folder structure with a README and VERSIONS.md.
5. Backup: Copy the archive to external media and cloud storage. Verify integrity.

Checking archive integrity before packing

Before packing we perform three steps:

1. Check broken references in Substance: File > Check Baked Maps Links.
2. Clean unused layers in PSD.
3. Export all textures from .spp.

A custom Python script walks the folder tree, collects CSV with size, date, extension. This finds duplicates (one texture in three copies), outdated versions (_old, _backup), and files candidates for optimization. According to our project statistics, up to 20% of files turn out to be junk. In one project, we reduced search time from 3 hours to 15 minutes after archiving.

Deliverables of archiving work

• Structured archive according to the described scheme.
• CSV inventory with duplicates and recommendations.
• README with tool versions and contacts.
• Spare set on external media — guarantee against loss.
• Consultation on format and project settings selection.

Timelines and how we work

Cost is calculated after a free initial volume audit. Our team has 10+ years of experience in gamedev and over 50 completed archiving projects. We will assess your project, send a plan and timeline. Contact us to avoid losing years of work. Order an archiving consultation — we'll advise where to start.

Manual pre-release preparation as a source of delays

We automate the entire pre-release pipeline for mobile and XR games. A studio is about to release a game — a week before the date, the manager remembers they need to build an AAB, sign it, and upload to Google Play. The build engineer manually starts the build, waits an hour, forgets to enable IL2CPP, the build crashes on Android 12. Rebuilding takes another hour. Simultaneously, the icon needs to be redesigned to meet new Google requirements. As a result, the release is delayed by three days. Experience shows: manual pre-release preparation is the primary source of delays and bugs that do not manifest on the developer's machine.

How to set up CI/CD for mobile game builds?

Pipeline tools

GameCI — open-source Docker images for Unity builds, running on GitHub Actions, GitLab CI, or any other CI provider. Key components: unity-builder (builds for the target platform), unity-test-runner (runs Unity Test Framework before build), unity-return-license (returns the license — critical for Pro). Unity Cloud Build is simpler but less flexible and expensive for frequent builds. Fastlane is the standard for final steps: signing, uploading to stores, metadata.

Typical pipeline

jobs:
  test:
    name: Run Unity Tests
    uses: game-ci/unity-test-runner@v4
    with:
      unityVersion: 2022.3.20f1
      testMode: playmode

  build-android:
    name: Build Android
    needs: test
    uses: game-ci/unity-builder@v4
    with:
      targetPlatform: Android
      androidKeystoreBase64: ${{ secrets.ANDROID_KEYSTORE_BASE64 }}
      androidKeystorePass: ${{ secrets.KEYSTORE_PASSWORD }}
      androidKeyaliasPass: ${{ secrets.KEY_PASSWORD }}

  upload-to-play:
    name: Upload to Google Play (Internal Track)
    needs: build-android
    uses: r0adkll/upload-google-play@v1
    with:
      serviceAccountJsonPlainText: ${{ secrets.SERVICE_ACCOUNT_JSON }}
      packageName: com.yourcompany.yourgame
      releaseFiles: build/Android/*.aab
      track: internal

Secrets, not variables — all keys in CI secrets. AAB instead of APK has been mandatory for several years. Tracks: internal → closed → open → production. Promotion — manual or Fastlane supply promote.

iOS specifics

Unity builds an Xcode project, then xcodebuild. Need Distribution Certificate and Provisioning Profile (App Store). Fastlane Match solves the problem of certificate synchronization within the team:

lane :build_ios do
  match(type: “appstore”, readonly: true)
  build_app(workspace: “Unity-iPhone.xcworkspace”,
            scheme: “Unity-iPhone”,
            export_method: “app-store”)
  upload_to_testflight
end

App Store Connect API Key replaces login/password, does not break with 2FA.

Step-by-step pipeline setup

1. Audit Unity PlayerSettings (Graphics APIs, Scripting Backend, stripping).
2. Create CI configuration with GameCI — define test, build, and deploy jobs.
3. Integrate Fastlane for code signing and store uploads.
4. Store all secrets (keystore, certificates, API keys) in encrypted CI variables.
5. Run a test release on internal track, verify end‑to‑end.

Each step includes validation: build must pass on a clean runner, not just a local machine.

Why does App Store reject about a third of first submissions?

Apple rejects 30–40% of first submissions from new studios. Common reasons:

Practice: before submission, go through the App Store Review Guidelines from start to finish — 2–3 hours, saving 2–3 weeks of resubmission loops.

Google Play is more lenient: typical reasons — outdated targetSdkVersion, excessive permissions, incorrect Data Safety Form.

Deliverables of pre-release preparation

We deliver the following for your game release:

• CI/CD pipeline configured (GameCI + Fastlane, Unity Cloud Build — turnkey)
• Metadata and marketing assets (screenshots, icons, feature graphics)
• Store submission guidance with documentation of all accesses and credentials
• 72‑hour post‑release monitoring (Crashlytics, ANR rate, user reviews)
• Pipeline documentation and team training session (hands‑on)
• Age rating configuration (IARC, ESRB, PEGI, CERO) and localization of store metadata

Pipeline automation replaces the manual work of an entire department. For example, setting up Continuous Integration via GameCI and Fastlane reduces pre‑release preparation time threefold — from 8 working hours to 2.5.

Our pre-release workflow: from audit to store submission

Impact of pipeline automation on timelines and budget

Manual game release incurs significant engineering and testing costs. CI/CD automation pays for itself within the first two months, reducing release costs by 40–60%.

Result: we reduce the commit‑to‑publish cycle by 6–8 times. For projects with frequent hotfixes, this is the difference between a week‑long user wait and a one‑day fix. We guarantee the pipeline works reliably after setup. Our engineers hold Unity Certified Professional credentials.

Typical savings: $2,500–$5,000 per month on engineering time eliminated by automation — $30,000–$60,000 annually on a mid‑size project.

Post‑release: monitoring and updates

Crash rate < 1% (Firebase Crashlytics), ANR rate < 0.47% (Play Console) — otherwise visibility restrictions. Phased rollout is mandatory: first 10%, then 50%, then 100% of users.

Our track record: 30+ mobile game releases, 5+ years on the market. CI/CD automation pays for itself within the first two months, reducing release costs by 40–60%.

Timeline

Setup takes from 2 days (simple mobile game with existing Unity project) to 2 weeks (complex multi‑platform project with custom CI runners). We calculate exact hours during a free pipeline audit.

Contact our engineers for a free pipeline audit and a timeline estimate. Submit a request — we will analyze your pipeline and offer a solution within 2 days. Get a consultation from an engineer who has shipped 30+ titles.