The Hidden Cost of Legacy Infrastructure in Asset-Heavy Game Development

Game developers spend endless engineering hours optimizing shaders, draw calls, and memory footprints. Solutions for runtime performance have advanced dramatically over the last decade, but the production pipeline hasn't kept pace.

While engines like UE5 have revolutionized what we see on screen, the “pipes”, the version control systems (VCS) we use, have remained virtually static for over 20 years. This has created a pipeline performance plateau.

Today, the most critical bottleneck for a studio is no longer at the runtime level of the CPU or GPU; it is in the development pipeline through the operational drag of legacy version control.

The Obvious Choice is Git - or Is It?

For a long time, the consensus was that for standard software engineering, Git is THE go-to tool. Its decentralized nature and branch-based workflows changed how we work and enabled parallel development. But the narrative is shifting. As we move into the agentic era, Git’s decentralized architecture is becoming a fundamental bottleneck for everyone, not just game developers. 

See my recent related LinkedIn post.

Git was built to track text-based source code. In game development, assets are not just text-based (textures, meshes, audio), and this is where Git’s architecture becomes a liability. Why? Because Git tracks every snapshot of every file in the local history. Because binary files can’t be meaningfully diffed or compressed across versions, a 1GB texture updated 10 times results in a 10GB repository. For a modern 3D studio with a 500GB project, downloading a full repository history is a nightmare.

While Git LFS exists as a workaround, it adds configuration overhead, workflow complexity, and significant performance and stability issues. Files of any size should just work, no special setup needed.

The result is that studios often feel forced into a lose-lose choice. They can either adopt Git’s agility (and watch it crumble under asset scale) or stick with legacy centralized systems like Perforce (which handle scale but carry massive operational friction).

What an Operational Drag Looks Like

To understand what I consider the operational drag, let’s take a look at how 90s-era VCS architectures handle data and metadata:

1. The 90s were the era of centralized, monolithic systems. Metadata stored in a single, rigid database has its advantages, but one user’s large "submit" can freeze the entire pipeline, preventing other team members from querying the server, causing a site-wide stall.
2. Game dev is asset heavy and has moved from managing thousands of files to managing millions of assets. Older VCS architectures that were not built for the high demands of modern CI/CD pipelines, fail to handle today’s game-dev-required scale.
3. And lastly, let’s talk about the quite significant hidden cost - the required dedicated VCS administrator or DevOps engineer to "babysit" the server - managing journal files, pruning logs, manually resolving database locks, you name it. 

More Friction Across the Pipeline

The operational and infrastructure drag we just discussed creates friction that burns out teams and slows down creative iteration, not just from a time perspective, but from a psychological and systemic one. How?

Artists are the lifeblood of game dev, but they are almost never CLI experts. Tools designed for engineers, or those requiring complex manual locking, lead to human error. A non-intuitive tool results in corrupted files, overwritten work, and extreme frustration from the need to “burn” time fixing errors. The goal should be a tool that is easy to use and hard to screw up, so that new team members don’t need a VCS expert just to onboard. This creates a culture of risk aversion: when the VCS is hard to use, artists become afraid to experiment or iterate, fearing they’ll "break the build."

In addition, according to our data,  if a 50-person team loses 30 minutes a day per person due to slow syncing or metadata stalls, it’s costing the studio money! For a team of 50, losing 0.5 hours daily over 20 days equals 500 hours of lost productivity per month. That is the equivalent of three full-time senior engineers just sitting and watching progress bars for an entire month!

And if we are really being honest, we all know that a 30-minute sync is never just 30 minutes, because of context switching. Once a developer or artist is pulled out of their work (as they are waiting on the infrastructure), it takes them time to regain their focus. 

Bottom line, when the VCS is slow, the CI/CD pipeline starts later, and bugs that could have been fixed in minutes aren't discovered until the next day.

Many studios try to solve these challenges by using Git for code and a legacy system for assets. But this just doubles the infrastructure complexity and the issues that come with it. 

Game Dev Moving to Modern High-Performance Version Control

Game dev is transitioning to modern VCS, combining the scale of centralized systems with the performance of modern cloud architecture.

Modern VCS separates storage from metadata. By using containerized, stateless backends, the system can scale horizontally, handling millions of assets without the metadata bottlenecks of the past.

Modern VCS uses advanced database technology to allow for concurrent operations. An artist can submit a 10GB environment update without preventing a developer from syncing the latest code changes.

Modern VCS is moving toward selective sync and granular permissions. Instead of cloning a massive repository, teams can sync only what they need, drastically reducing local storage requirements and setup time.

It’s worth noting that systems like Plastic SCM partially address these problems, but studios are increasingly wary of toolchain dependency on a single engine vendor, and many are now de-risking from single-vendor lock-in to maintain flexibility.

VCS as a Competitive Advantage

In a tight gaming market, studios cannot afford to take years to ship. Today, small, highly technical teams are out-shipping giants by using tools that allow for instant branching and rapid environment spin-ups. Furthermore, game dev teams scale up and down. VCS pricing and licensing should flex with them. This is a real pain point in current legacy systems. Modern tools are intuitive for artists, powerful for programmers and enable higher speed-to-market, and that’s starting to sound like a competitive advantage. 

Conclusion

If you are a technical leader or CTO, it is time to look beyond the license fee. To understand your true TCO, examine your pipeline:

1. How long does it take for a new hire to get their first build?
2. How much time does DevOps spend on VCS maintenance versus pipeline automation?
3. Are your artists waiting on the infrastructure, or is the infrastructure waiting on them?

Once you stop and think about these questions, I think it will become very clear what your next VCS steps should be.