Syncing a game build across your team without Perforce

Perforce is the standard, but it is not the only way to keep a game project in sync. Here is how smaller studios handle large asset distribution alongside lightweight version control.

The Perforce problem for smaller studios

Perforce Helix Core is, by most accounts, the best version control system for large game projects. It handles massive binary files well, supports file locking to prevent conflicting edits on assets like scenes and meshes, and scales to repositories measured in terabytes. Most AAA studios rely on it.

It also costs real money, requires dedicated server infrastructure or a managed hosting plan, demands an administrator who understands its configuration, and has a learning curve that trips up artists who are not comfortable with command-line tools or branching workflows. For a team of five to twenty people making an indie or mid-tier game, Perforce can feel like bringing industrial machinery to a job that needs a reliable van.

The question many small and mid-sized studios ask is whether there is a simpler alternative. The short answer is: for code and scene versioning, you still need version control. Git with LFS, Plastic SCM (now Unity Version Control), or a managed Perforce instance are the realistic options for tracking changes to source files, blueprints, and scene assets. That part of the pipeline requires the ability to diff, merge, branch, and roll back, and no file storage platform replaces that.

But version control is only one piece of the puzzle. A large portion of what teams need to sync is not source code or scene files. It is reference art, texture libraries, audio stems, marketing assets, documentation, build archives, and other large binary files that do not benefit from diffing or branching. They just need to be stored somewhere accessible, easy to find, and available to everyone on the team without clogging up the version control system.

What belongs in version control and what does not

A useful mental model is to separate files into two categories. The first category is files that change frequently and where tracking the history of those changes matters: source code, shaders, scene files, animation rigs, material graphs, configuration files, and build scripts. These belong in version control, whether that is Perforce, Git LFS, Plastic SCM, or something else.

The second category is files that are large, relatively stable, and consumed rather than edited by most team members: final texture packs, audio assets after mastering, reference images, concept art archives, exported builds for QA, press kits, and documentation. These files are important, but tracking their line-by-line change history provides little value. What matters is that everyone can find and access the latest version.

Many studios end up stuffing both categories into Perforce, because it is the tool they have. This works, but it inflates the repository size, slows down syncing for team members who only need a subset of files, increases storage costs on the Perforce server, and makes the whole system harder to manage. When a new artist joins the team and needs to sync the repository for the first time, they might be pulling down hundreds of gigabytes of data they will never touch, simply because those files happen to live in the same system as the code and scenes they need.

Using Fabric for the asset distribution layer

Fabric is a cloud drive that streams files on demand. Files stored in Fabric appear on your local machine as if they were local, but they do not consume disk space until you open them. For a game studio, this means you can keep hundreds of gigabytes of assets available to the entire team without requiring each person to download and store a full copy.

This makes Fabric well-suited to the second category of files described above. Your texture libraries, audio assets, reference materials, exported builds, and documentation can live in Fabric, accessible to everyone on the team through the desktop app. When someone needs a specific asset, it streams to their machine. When they are done with it, it does not sit on their SSD taking up space.

To be clear about what Fabric is and is not: Fabric is a file management and cloud storage platform. It is not version control software, not a replacement for Git or Perforce for tracking code changes, and not a game engine integration. It does not do branching, merging, or file locking. What it does is store, organise, search, and share files in a way that removes a significant portion of the friction that small studios deal with when trying to keep everyone working from the same set of assets.

A practical setup for a small studio

A workable setup for a small to mid-sized studio might look like this.

For code and scene files, use Git with LFS, Plastic SCM, or a lightweight Perforce configuration. Keep the repository focused on the files that need version tracking: source code, engine project files, scene assets, and anything that multiple people might edit concurrently.

For everything else, use Fabric as the shared asset library. Texture collections, audio files, reference art, exported builds, marketing materials, and internal documentation all go here. The smart organisation categorises files by content, so you do not need to maintain a rigid folder hierarchy that everyone has to learn and follow.

When an artist finishes a texture set and it is ready for production, they export the final version into the version-controlled project. The working files, reference images, and texture source files stay in Fabric, where anyone on the team can find them using semantic search if they need to revisit or update the material later.

This two-system approach keeps the version control repository lean and fast to sync, while making sure that the broader set of project assets is stored, backed up, and accessible to everyone.

Finding assets without memorising folder structures

One of the recurring frustrations in game studios is the "where is that file?" problem. Asset naming conventions vary between team members. Folder structures that made sense at the start of the project get messy as the project evolves. People save things to their local machines and forget to upload them. A new hire spends their first week learning where everything lives.

Fabric's semantic search addresses this by letting people describe what they are looking for rather than needing to know a filename or folder path. An artist searching for "low-poly tree reference" or "footstep sounds on gravel" can find relevant files across the entire shared library, regardless of how they were named or where they were stored.

The AI assistant extends this further. Team members can ask questions like "do we have any 4K brick textures?" or "where are the audio files from the recording session in March?" and get answers drawn from the actual contents of the shared library. For studios where institutional knowledge tends to live in the heads of a few senior team members, this kind of searchability is a meaningful improvement.

Sharing builds and review materials

Game development involves a lot of sharing. QA testers need access to the latest build. The audio director needs to review a new set of sound effects. The publisher wants to see the latest trailer cut. An outsourcing partner needs the style guide and reference sheets.

Each of these sharing needs is slightly different, and most studios cobble together a mix of Google Drive links, Dropbox shares, WeTransfer uploads, and email attachments. The result is that files end up scattered across multiple services, with no clear record of who has access to what, or whether the recipient has even looked at what was sent.

Fabric's publish feature lets you create shareable pages with selected files. You can put together a build package, a set of reference materials, or a review folder and share it as a single link. Link analytics show whether the recipient has viewed the page, which is useful when you are waiting for feedback and want to know if the delay is because they have not seen it yet or because they are still reviewing.

For internal review workflows, annotations let team members leave feedback directly on images and timestamped comments on video and audio files. An art director can mark up a texture sheet or a rendered frame with specific notes, rather than writing a paragraph of description in a chat message and hoping the artist can figure out which pixel they mean.

Connecting existing storage

Most studios already have files spread across multiple services. There might be concept art in Google Drive, audio stems in Dropbox, and documentation in a shared network folder. Moving everything to a new system in one go is rarely practical, especially during active development.

Fabric's connections let you link existing Google Drive, Dropbox, and other accounts so that files from those services are accessible and searchable within Fabric alongside everything else. You do not have to migrate everything at once. You can start by using Fabric for new assets and builds, then gradually consolidate older materials as time allows.

For studios that work with external contractors or outsourcing partners, this flexibility is especially useful. You can keep your internal assets in Fabric while connecting to the cloud storage services that your partners already use, creating a single searchable view across all of them.

Keeping project documentation alongside assets

Game projects generate a lot of documentation: design documents, technical specifications, art style guides, production schedules, meeting notes, and post-mortems. This documentation is closely tied to the project's assets, but it usually lives in a completely separate system, whether that is Confluence, Notion, Google Docs, or a folder of Word files on a shared drive.

When documentation and assets live in separate systems, cross-referencing between them becomes a manual process. The art style guide references specific textures and materials, but finding those materials means switching to a different tool and searching again. The technical design document describes a particle system, but the reference footage the designer used is stored elsewhere.

Fabric's approach as a general-purpose workspace means project documentation and creative assets can coexist. The same search that finds a texture can also surface the art direction document that describes how that texture should be used. For engineering teams in particular, having technical documentation, build artifacts, and reference materials in one searchable location reduces context-switching.

Security and backup

Game projects represent years of work and significant financial investment. Losing assets to a hard drive failure, a misconfigured server, or an expired cloud storage subscription is the kind of event that can set a project back months.

Fabric provides private and secure storage with built-in backup. Unlike files sitting on a developer's local machine or a self-hosted NAS that nobody has tested a restore on, assets in Fabric are stored with redundancy and accessible from anywhere. For studios that have experienced the pain of a RAID failure or a stolen laptop containing the only copy of certain assets, having a reliable cloud-backed storage layer provides peace of mind.

When you still need Perforce

There are scenarios where Perforce (or an equivalent full-featured version control system) is the right choice for everything, and Fabric would only serve as a supplementary storage layer. If your team routinely needs file locking on binary assets like Unreal Engine .uasset files to prevent conflicting edits, if you require granular branching of your entire project including all assets, or if your studio's pipeline tooling is deeply integrated with Perforce's APIs, then Perforce is the right tool for the job.

The argument here is not that Fabric replaces Perforce. It is that many studios use Perforce (or wish they could afford it) primarily because they need somewhere to put large files that the whole team can access. If you separate the version control concern from the asset distribution concern, you can use a focused version control tool for the former and a cloud-native file platform for the latter. The result is often simpler to manage, cheaper to run, and easier for non-technical team members to use.

For startups and small studios in particular, this split can be the difference between a manageable workflow and an overcomplicated one. You get the version tracking you need for code and scenes, and you get accessible, searchable, cloud-streamed storage for everything else, without the overhead of running Perforce for the entire project.

Frequently asked questions

Can Fabric replace Perforce for game development?

No. Fabric is a file management and cloud storage platform, not version control software. It does not support branching, merging, diffing, or file locking. You would still use Git, Perforce, Plastic SCM, or another version control tool for source code and scene files. Fabric handles the asset storage, distribution, and organisation layer that sits alongside version control.

What types of game files can Fabric store?

Fabric can store any file type. Textures, 3D models, audio files, video, documents, executables, build archives, and anything else your project needs. There are no file format restrictions.

Does Fabric work offline?

Fabric requires an internet connection. Files stream from the cloud on demand, so you need connectivity to access them. If you need offline access to specific files, you would need to download them locally before going offline.

How does Fabric compare to Google Drive or Dropbox for game assets?

Fabric's cloud drive streams files on demand without consuming local storage, which is a significant advantage for large game projects. It also offers semantic search (finding files by description rather than filename), smart organisation, and annotations for reviewing visual and audio assets. You can see detailed comparisons at Fabric vs Google Drive and Fabric vs Dropbox.

Can I share game builds with QA testers through Fabric?

Yes. You can use the publish feature to create a shareable link containing the build files. Link analytics show whether the recipient has accessed the files.

How do I migrate existing assets from Perforce to Fabric?

Fabric connects to services like Google Drive and Dropbox. For files currently in Perforce, you would export or copy them to a location where Fabric can access them, either by uploading directly or through a connected cloud storage service. This can be done incrementally rather than all at once.

Is Fabric secure enough for unreleased game assets?

Fabric provides private and secure storage with built-in backup and redundancy. Your files are protected in transit and at rest. For details on security practices, see the security and privacy page.

Can multiple team members work from the same Fabric library simultaneously?

Yes. Fabric's collaboration features allow multiple team members to access the same files simultaneously. Because files stream from the cloud, each person accesses what they need without downloading the entire library. Changes and new files added by one team member become available to others.

Related pages

• Cloud drive

• Semantic search

• Smart organisation

• Collaboration

• Creative assets

• Digital asset management

• For developers

• Engineering teams

• Startups

• Fabric vs Dropbox