Last updated: August 2026
Quick answer: Game asset management needs two layers. Version control (Git, Perforce Helix Core, Diversion) keeps binary files safe, locked and versioned. A visual DAM sits on top of it so art leads and producers can preview, tag, review and approve assets in a browser without opening Unreal, Unity or Maya. Studios running only the first layer end up approving assets over Slack.
In this guide:
- Why game assets break standard DAM tools
- How does the Unreal Engine asset pipeline handle assets?
- How is the Unity asset pipeline different?
- Where does version control end and visual DAM begin?
- How should you tag game assets?
- How do art leads review and approve assets faster?
- The 8-step setup checklist
- Frequently asked questions
The two layers at a glance
| Version control layer | Visual DAM layer | |
|---|---|---|
| Tools | Git + LFS, Perforce Helix Core, Diversion | Artstash |
| Owns | File integrity, history, locking, merge | Preview, search, review, approval, metadata |
| Answers | “What changed and when?” | “What does it look like, and is it signed off?” |
| Used by | Engineers, technical directors | Art leads, producers, outsource partners |
| Missing it means | Corrupted binaries, lost work | Approvals happen in Slack and nobody can find anything |
Most writing on game asset management starts with version control. Branching strategies, commit hygiene, binary diffs. All of that matters, and your engineers probably have it sorted.
The engineering half of the pipeline is solved. The art half usually is not.
Your artists are still Slacking FBX files. Your art lead is still opening Maya to review a model that should have been approved three days ago. Your producers cannot tell which texture is the approved one without asking someone. The repo is clean; the collaboration layer is chaos.
The structural split: engineers live in Git or Perforce. Artists live in their DCC tools and shared drives. Nothing bridges the two sides visually, so asset decisions happen over Slack, email and memory rather than in a managed system.
This guide is for art leads and technical directors who want to fix that. It covers the Unreal and Unity pipelines specifically, marks the line where version control stops being useful to artists, and ends with an eight-step checklist you can start on today.
Why game assets break standard DAM tools
A marketing team's DAM stores JPEGs, PDFs and MP4s. Game assets are a different category, and the difference explains why off-the-shelf DAM platforms keep failing studios.
For the fundamentals, see our guide to 3D asset management.
Binary files do not diff
Game assets are predominantly binary: FBX, OBJ, GLTF, PSD, PNG spritesheets, WAVs, and engine-native formats like Unreal's .uasset and Unity's .prefab. You cannot open a pull request, read the changes and approve the edit the way you can with a script. Two artists editing the same binary in parallel produce a conflict that gets resolved by picking one version and throwing the other away.
That is why file locking exists in Perforce, and why it matters so much here. Locking prevents the conflict. It still leaves your reviewer with no way to see what changed between version 4 and version 5 of a character mesh short of opening a DCC tool.
The asset tree gets big fast
A mid-sized project routinely runs to tens of thousands of individual assets. A single hero character might carry:
- A base mesh (FBX or OBJ)
- LOD variants, LOD0 through LOD3
- Diffuse, normal, roughness and metallic maps
- Rigging and animation files
- An engine-specific prefab or blueprint
- Material instances and parameter overrides
Managing that as a flat folder hierarchy, which is how nearly every studio starts, breaks down within a few months. Assets get duplicated. LODs get orphaned. Nobody can tell at a glance which texture set is final.
What generic DAM platforms miss
| Challenge | Why standard DAMs fail |
|---|---|
| 3D preview in the browser | No native rendering for FBX, GLTF or .blend |
| Binary versioning | No integration with Git LFS, Perforce or Diversion |
| LOD and variant relationships | No concept of asset hierarchies or parent-child links |
| Engine-native formats | Cannot read or index .uasset or .prefab |
| File locking status | No awareness of who has a file checked out |
So studios end up with a version control system engineers understand and a folder structure artists muddle through, with no shared layer of visibility between the two.
How does the Unreal Engine asset pipeline handle assets?
Unreal has one of the most structured asset pipelines in the industry. That structure is its strength and the source of most of its friction.
Content Browser and the .uasset format
Everything inside Unreal lives in the Content Browser as a .uasset file. When you import an FBX, Unreal converts it to its own binary format, which has two consequences.
First, the source file and the engine file are separate. Your original FBX lives outside the project, ideally in your VCS. The .uasset is what Unreal actually uses. Both need tracking, and they live in different places.
Second, .uasset files are not human-readable. You cannot inspect one without the engine, which is exactly the wall most reviewers hit. Artstash renders .uasset in the browser alongside FBX, OBJ, GLTF, .blend and 53 other formats, so the review does not depend on who has Unreal installed.
Naming conventions matter more than most studios realise
Unreal's Content Browser is hierarchical, but it does not enforce naming. Studios that skip a convention early pay for it later. The widely adopted approach uses prefixes:
| Asset type | Prefix | Example |
|---|---|---|
| Static Mesh | SM_ | SM_RockFormation_01 |
| Skeletal Mesh | SK_ | SK_PlayerCharacter |
| Material | M_ | M_RockSurface_Wet |
| Material Instance | MI_ | MI_RockSurface_Wet_Cave |
| Texture | T_ | T_RockSurface_D |
| Blueprint | BP_ | BP_InteractableDoor |
| Particle System | PS_ | PS_DustCloud |
Consistent prefixes make Content Browser search workable. They also make AI tagging noticeably more accurate when assets are indexed externally, because the filename already carries semantic information.
Redirectors and file size
Move or rename a .uasset and Unreal leaves an asset redirector behind, a pointer from the old path to the new one. Redirectors accumulate silently and slow down cooking. Run “Fix Up Redirectors” on a schedule and treat asset moves as deliberate, tracked operations.
Key takeaway: every rename or move in Unreal needs to reach your external DAM too. A system unaware of redirectors will show stale paths and broken previews.
On size: a mid-sized open-world project can exceed 50GB in its content directory. Standard Git is not built for that. Git LFS is the floor, and plenty of studios move to Perforce for Unreal specifically because of its native binary handling and locking. Dropbox and Google Drive are fine as storage. Used as a substitute for version control, they will eventually hand you a corrupted file.
How is the Unity asset pipeline different?
Unity is more permissive than Unreal, which makes it easier to start and easier to make a mess. The flexibility that helps a five-person indie team ship becomes a liability at forty people without deliberate structure.
.meta files: the thing everyone gets wrong
Every asset in a Unity project has a matching .meta file holding the asset's GUID, import settings and references. Delete it and Unity regenerates it with a new GUID, at which point every prefab or scene referencing the old GUID throws a missing asset error.
The rule: always commit .meta files alongside the assets they describe. Never add *.meta to .gitignore. It is the most common Unity pipeline mistake and one of the most expensive to unpick mid-production.
Addressables add a third identity
Unity's Package Manager keeps engine packages and third-party libraries out of your main asset directory. Addressables matter more for asset management: a runtime loading framework that decouples asset references from the scene hierarchy.
The consequence is that a Unity asset now has three identities. A project path, a GUID in its .meta file, and an Addressable address used at runtime. A complete asset management system tracks all three.
For live-service titles, Addressables also enable remote content delivery, so your asset system needs to handle versioned content bundles as well as individual files.
Git LFS or Perforce for Unity?
| Git LFS | Perforce Helix Core | |
|---|---|---|
| Best for | Teams under 20, indie to mid-size | Mid-size to AAA, heavy simultaneous editing |
| File locking | Supported, manual | Native and enforced |
| Binary handling | Good, if LFS is configured correctly | Purpose-built |
| Cost | Storage only | Per-seat licensing |
| Artist-friendliness | Familiar to engineers, opaque to artists | Requires setup and training |
Our view: if you are under twenty people and shipping in Unity, Git LFS with a hosted provider is the right call and Perforce is overhead you will resent. Past roughly forty people with artists editing the same scenes daily, Perforce earns its licence cost through enforced locking alone.
The actual mistake is using plain Git without LFS on a Unity project full of large textures and audio. Those commits bloat your history permanently, and there is no clean way out without rewriting it.
Where does version control end and visual DAM begin?
This is the gap most studios fall into, so it is worth being precise about where it sits.
Version control handles file history, branching, merging, conflict resolution and access permissions. It answers “what changed and when?” It has nothing to say about “what does this look like?” or “is this approved?”
The gap in practice: an art lead needs to review a character model from an outsource vendor. The file is in the repo. To look at it they pull the latest branch, open Unreal or Maya, import the file and inspect it. Do that across forty assets in a sprint and review becomes the reason assets ship without proper sign-off.
Visual DAM covers the distance between “file is in the repo” and “file is approved and ready to use”:
- Browser-based 3D preview. Reviewers rotate a mesh, check topology and silhouette, without a DCC tool
- Approval workflows with defined states and an audit trail
- AI tagging and search, so a producer can search “armoured knight LOD0 approved” instead of guessing at filenames
- Cross-system visibility across Git, Perforce Helix Core, Diversion, Google Drive, Dropbox, Box and OneDrive at once
- Version-pinned comments, so feedback stays attached to the exact revision it referred to rather than floating in a Slack thread
The two-layer model
Version control is the engineering layer: integrity, history, conflict resolution. Visual DAM is the art and production layer: discoverability, review, approval, metadata.
They are complementary. Artstash connects to the VCS your studio already runs and indexes what is there. Your files do not move, your engineers do not change how they work, and your artists and producers get a visual interface into the pipeline without touching the repo. Every plan includes unlimited users, because a review layer that charges per seat stops being a review layer the moment someone decides the outsource vendor does not need a login.
Switching your VCS will not solve the collaboration problem. Adding a visual layer on top of it will.
For how these layers map to production stages, see our guide to game asset workflow stages.
How should you tag game assets?
Metadata is what makes a large library searchable. Without it, finding the right asset means knowing the exact filename or asking someone. Neither scales past a few thousand files.
A practical schema covers five dimensions:
| Dimension | Example values |
|---|---|
| Asset type | Character, environment prop, UI element, VFX, audio |
| Production status | Draft, in review, approved, deprecated |
| Engine target | Unreal, Unity, both |
| LOD level | LOD0, LOD1, LOD2, LOD3, hero mesh |
| Content tags | Biome, faction, theme, material type |
The goal is to answer the question a producer actually asks: “show me all approved forest props at LOD1 ready for Unreal.” A filename cannot answer that.
AI tagging in practice
Manual tagging at scale is fantasy. A studio might import 500 new assets in a single sprint, and asking artists to tag each one guarantees both friction and inconsistency.
AI tagging reads the asset visually and generates tags from geometry, colour, material and context. The art lead's job shifts from entering tags to correcting them, which is an order of magnitude faster, and the corrections compound as the model picks up your taxonomy.
Search can go further than tags. The Artstash Search Agent trains on your game's design documents and lore, so a search for a named character or faction returns the right asset even when nobody ever tagged it that way.
Here is where it pays off. An outsource vendor delivers 200 environment assets. Instead of a producer spending two days cataloguing them by hand, the library ingests, previews and tags the batch automatically, and the art lead approves or flags each one in the browser without opening the engine.
How do art leads review and approve assets faster?
Review is the most consistent bottleneck in game production. Assets queue for sign-off because reviewing requires the right software, the right file and the right context, all at the same moment.
Browser-based review deletes the software dependency. The art lead opens the asset, inspects the model, then approves it or leaves comments pinned to that version. The artist gets the feedback, makes the change, resubmits. The cycle carries a timestamp and an audit trail.
The four states worth having
- Draft. Submitted by artist or vendor, not yet reviewed.
- In review. An art lead or TD has it open.
- Approved. Meets quality and technical standards, safe to use in engine.
- Rework required. Specific feedback attached, returned to the artist.
The point is that “approved” acquires a real meaning: passed visual review, within polygon budget, correct texture resolution, correctly named and tagged. Without a formal state, approved only ever means nobody has complained yet.
Why this matters beyond the art team
We have watched the cost of a slow art pipeline land somewhere unexpected. When we ran a Golden Week push for Left to Survive built on Japan-specific creative, it moved results by roughly 10% over the window. That kind of seasonal, regional variant work is entirely dependent on turnaround. Miss Golden Week by a week and the campaign is worth nothing. What usually causes the miss is rarely the artists; it is the four days an approval spent sitting in a Slack thread.
We built Artstash because our own asset library was the pile.
8-step checklist: setting up game asset management
Work through it in order. Each step assumes the one before it.
- Establish your VCS foundation. Pick Git LFS or Perforce Helix Core based on team size and budget, and configure file locking for binaries before anyone commits a mesh.
- Define and enforce a naming convention. Document the prefix system. Make it a written standard, not tribal knowledge. A new artist should name a file correctly on day one without asking.
- Separate source files from engine files. Keep original FBX, OBJ and PSD files in a source directory tracked separately from the engine project. That gives you engine-agnostic assets you can reimport later.
- Set your folder hierarchy before importing anything. In Unreal: Content/Characters/, Content/Environment/, Content/UI/. Mirror it under Assets/ in Unity. Reorganising later generates redirectors or GUID conflicts.
- Connect a visual DAM to your storage. Index your asset directories somewhere that previews 3D files in the browser and connects to what you already use, with no migration.
- Define your metadata taxonomy before ingesting, so tags are consistent from the first import.
- Enable AI tagging, then review the first batch by hand. This trains the taxonomy and surfaces naming inconsistencies while they are still cheap.
- Implement the four-state approval workflow, and make it policy that nothing enters the engine without an approved status. This one change ends most “which version is final?” conversations.
For a tool-by-tool comparison, see our guide to choosing a 3D asset management tool.
The bottom line
Game asset management is not a version control problem. It is a collaboration and visibility problem.
Your engineers have Git or Perforce sorted. Your artists need somewhere to find, review, approve and tag assets without opening Maya every time. Two problems, two layers.
Version control keeps your files safe. Visual DAM keeps your team aligned.
If your studio still settles asset questions over Slack, start with the checklist. The investment is smaller than it looks, because nothing moves and nothing migrates.
Frequently asked questions
What is game asset management?
Game asset management is the practice of storing, versioning, tagging, reviewing and approving the 3D models, textures, animations, audio and engine files that make up a game project. It combines a version control system for file integrity with a visual asset management layer for discovery and sign-off.
Does Artstash work with Unreal Engine and Unity?
Yes. Artstash previews Unreal .uasset files, plus FBX, OBJ, GLTF, .blend and 58 formats in total, directly in the browser. It connects to Git, Perforce Helix Core, Diversion, Google Drive, Dropbox, Box and OneDrive, so assets stay where they already live.
Do I still need Perforce or Git if I use a DAM?
Yes. A visual DAM does not replace version control. Version control handles file integrity, history and locking; the DAM handles preview, search, review and approval on top of it. Artstash indexes your existing repository rather than asking you to migrate out of it.
What is the best version control for a Unity project?
Under about twenty people, Git LFS with a hosted provider is usually the better choice: cheaper, familiar to engineers and enough for most binary workloads. Above that, especially with artists editing the same scenes simultaneously, Perforce Helix Core earns its per-seat cost through enforced file locking.
Why do standard DAM tools fail for game studios?
They cannot render 3D or engine-native formats in the browser, they have no concept of LOD hierarchies or asset variants, and they do not integrate with Git LFS or Perforce. A game DAM needs to preview an FBX, understand that four LODs belong to one asset, and know who has a file checked out.
How much does Artstash cost?
Studio Lite is $249/month, Studio is $799/month and Studio Plus is $2,499/month, with annual billing saving 10%. Every plan includes unlimited users, so adding producers, reviewers and outsource partners does not change the price.
See your studio's assets in one place. Talk to us about Artstash.
