Game Asset Library Management & Graphics Version Control

The art director asks to revert a character version "as it was three weeks ago, before the artist reworked the armor." Git stores only .unity and .prefab files, while Photoshop and Substance Painter sources sit in a shared folder on a NAS—no version history. This isn't rare. We've faced it dozens of times in studios of all sizes. Experience shows: without a solid asset management process from day one, such problems are guaranteed. Let's break down how to fix this systematically.

Why Git Doesn't Solve the Asset Problem

Git works with text. A 80 MB binary FBX or 200 MB PSD—diff is unreadable and delta doesn't compress. A repo with art assets without LFS swells to gigabytes in months and becomes uncloneable. In a project with 5000+ assets, finding a needed file takes up to 15 minutes.

Git LFS solves storage but not versioning from the artist's perspective. Tracking *.psd *.fbx *.png via .gitattributes is the minimum. Problem: LFS doesn't show revision previews without git lfs fetch, and artists aren't used to git checkout to view previous texture versions.

The professional alternative is Perforce Helix Core or Plastic SCM (now Unity DevOps Version Control). Plastic SCM integrates natively into the Unity Editor, shows visual diff for .unity and .prefab files, supports file locking for binary assets (an artist "locks" a file, preventing parallel edits). Perforce, in turn, provides centralized storage with performance surpassing Git LFS in tasks with thousands of assets.

How to Choose VCS for Graphics?

Perforce processes commits with large files 5 times faster than Git LFS. For small teams up to 10, Git LFS with discipline may suffice. But for projects with 50+ artists, Perforce is the industry standard used by AAA studios.

How to Organize the Asset Library?

A chaotic folder structure in Assets/ wastes team time. Finding a texture in a project with 3000+ files without a proper hierarchy takes 10–15 minutes. The right structure depends on game type, but the basic principle: group by feature, not by type.

Bad:

Assets/Textures/characters/hero_diffuse.png
Assets/Models/characters/hero.fbx
Assets/Materials/hero_material.mat

Good:

Assets/Characters/Hero/Textures/hero_diffuse.png
Assets/Characters/Hero/Models/hero.fbx
Assets/Characters/Hero/Materials/hero_material.mat

When removing a feature, you delete one entire folder. When searching, everything is in one place.

For texture atlases: a clear naming system with suffixes _D (diffuse/albedo), _N (normal), _M (metallic), _R (roughness), _AO (ambient occlusion) is critical for proper import into Unity. TextureImporter automatically detects type by suffix when configured correctly.

Where to Store Asset Sources?

Source files (.psd, .spp Substance, .blend, .ma) are not part of the Unity project. Their storage is a separate task. Options:

• Artefactory/Nexus as binary storage with metadata—suitable for large studios. Each source has a version, release tag, link to a Jira task.
• Google Drive / SharePoint with strict naming conventions—hero_armor_v003.psd—works for small teams. Cheap but requires discipline.
• Git LFS with a separate repo for sources—a middle ground. Splitting engine and art repos reduces performance issues.

For any option, you need a process: artist finishes an iteration → exports the final asset in the required format (PNG/TGA for textures, FBX for meshes) → places it in the Unity project → commits the source version with a tag. The gap between source and exported asset is the main reason for the question "where did this texture come from?" a year later.

What's Included in Audit and Implementation?

• Audit of the current library: inventory, duplicate search (typical: 10–15% duplicates), volume assessment.
• Selection and setup of VCS (Plastic SCM/Perforce/Git LFS) with structure rules.
• Migration of assets to the new system with history preservation where possible.
• Setup of CI pipeline to check for broken assets and unused files.
• Team training: file locking, commit messages, working with previews.
• Documentation of the asset management process.
• One month of post-release support.

How Does the Audit Unfold?

We start with an inventory: how many assets, current volume, any duplicates (same texture in three places with different names—typical). Tools: Find References in Unity plus a custom Editor script to find unused assets via AssetDatabase.FindAssets. Then migration to the chosen VCS, configuration of .gitattributes or Plastic SCM rules, team training on file locking. The entire process takes 1–3 weeks depending on volume. Contact us for an audit—we'll propose an optimal plan.

How Long Does Implementation Take?

The cost is calculated after auditing the current repository state and asset volume. Get a consultation to discuss details.

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.