Over the years, the little game studios have slowly turned into a big industry with a lot of high budget products. And despite some infamous AAA titles day-one patches and ridiculous bugs (yes, Cyberpunk, I’m looking at you), it’s impressive to see how much of this software works really well.

Because video games are demanding and complex artworks that involve bringing together coders and artists. You have to ship a robust project, that is maintainable and upgradable while working on as many platforms as possible; you have to write whole stories, prepare hundreds of scenes, code complex behaviours for your AIs or create stunning visuals that can run on six-years old consoles.

All of that requires some minimal level of organisation. And, most notably, a tool to clearly track the progression and history of your game, step-by-step, and file by file.

That’s usually where version control comes in; after all, the whole goal is to keep an eye on the evolution of files, compare differences, help with teamwork by handling branches and merges, and get a backup of your latest working release. (Yes, you know: the one from before you added this new boss that crashes the entire level.)

Except that there’s a catch. For now, most of those versioning tools are mostly made for code. Meaning that they’re good at tracking basic text files like scripts, but they struggle with large assets; and that they don’t always have the most user-friendly interface.

So… what about artists? How can they keep track of their work on assets?

Why “coder-oriented” versioning tools rarely work for artists

These days, there are a fair amount of version control systems - but the most famous ones come from the dev community, and are thus primarily designed for code versioning.

The well-known Git, the old SVN, or the quite popular PlasticSCM and Perforce - those are all common tools for versioning. Yet artists are often having a hard time using them, because of various common problems.

Complexity & user-unfriendliness

The first culprit is the complexity of those tools.

Git and SVN are probably the worst in that regard. Although they both offer a few GUI clients, they’re filled with big concepts that aren’t that easy to grasp, and make versioning a real challenge in itself. Using branches properly can be very complex, and solving merge conflicts is nearly impossible when dealing with binary files like images or 3D models.

Now, to be fair: PlasticSCM or Perforce offer way clearer interfaces, and GUI clients that make them fairly easy to use.

Still, the moment you start to dive into more advanced stuff, you’re gonna have to know the tool really well in order to not inadvertently overwrite your colleague’s work, or erase last week’s progress.

In particular, there is virtually no visual differencing in those tools. At best, the system will tell you that “your image file has changed”, which is far from informative. In other words, artists can’t really see what’s changed between the two versions, and they’ll basically need to keep both copies on their computer and open them side-by-side if they want to compare.

Another thorn in the side of game artists who want to use these versioning tools is that the traditional game art workflows don’t often combine well; you then need to force artists to comply to the VCS’s rules, or develop in-house ad-hoc intermediary solutions to bridge everyone’s comfort zones… which is time-consuming and not very scalable!

Handling large asset files

Of course, another major problem of those “coder-oriented” systems is that they’re not designed to manage massive files like art assets. By comparison, scripts are extremely small files.

So most of those tools don’t expect files to weigh more than a few hundred KBs - while this is just on the low-end for images, audio files or movies!

PlasticSCM and Perforce are currently the best solution in this domain: they are both able to handle mid- and large-sized assets, and that’s why they’re now the standard solution for many game studios. But the pretty steep storage cost of PlasticSCM, or the licence fees and server maintenance requirements of Perforce, can discourage little teams, and because they’re not as famous as Git for example, they have a smaller user-base and less documentation.

Git has a well-known command-line extension called Git LFS (for “Git Large File Storage”) to manage large files better, but it’s complex to set up and can severely hinder the day-to-day usage of the VCS, in particular for small projects.

Limited metadata editing

Moreover, game assets often require additional metadata such as tags, descriptions, or other information to help artists and developers update and integrate them effectively.

However, common versioning tools don’t have much in terms of metadata. Usually, you have your files on one side and your commit history on the other - and these commits hold metadata on the tasks and the updates, rather than the files themselves.

This means that unless all your metadata is embedded in the assets, it might be “lost in translation” when sharing the file with the rest of the team via a typical version control system.

Merge conflicts management

Art assets are typically files that are edited by several members of the team - more often than not, a main game asset like a character or a big environment requires several people to combine their skills and create a model, a rig, an animation, materials and textures, hair and cloth simulation…

This naturally implies that one asset file might be edited by two people at once and, if this file is versioned, you’ll then have to merge both results into a logical single output.

This is the problem of merge conflict and, again, a lot of “coder-oriented” VCS don’t do it well for binary files. Basically, that’s because tools like Git or SVN for example are designed for text files that can be compared line by line; but, in a JPEG image, it’s not possible to do such a comparison.

That being said, SVN and Perforce for example have a “lock” mechanic that lets you take over the file during your work session and prevent any other changes, which is a basic way of avoiding conflicts. That’s already very cool, and it solves a lot of daily issues - but it can be tricky because you need to remember to lock the file before starting your work, and unlock it afterwards so that other teammates can edit it further.

Ideally, this conflict prevention should be handled automatically by the system, especially if it’s cloud-based and therefore has access to previous and current data at the same time.

Are there versioning tools for artists?

All of this highlights how, at the moment, the classic VCS tools like Git, SVN or even Perforce aren’t totally suited for game artists.

Still, you need to track those art assets so that you know what was made when, by who, and for what - so you have to find tools to version those files as well as code.

But - can’t we use Google Drive? Or Dropbox? Or emails?

That’s actually a very common solution to this problem. As discussed in this study we conducted a while back, many game teams decide to use some external storage system for their non-code assets.

The problem is that those tools are not real versioning systems: you often end up sending your team files with “_v2”, “_v3”, “_final” suffixes. Plus, you have to spend a lot of time managing shared folders that get cluttered with backup or temporary files, because art software (such as Photoshop, Maya, Blender…) are very good at creating plenty of files “around” your main one.

To put it simply - using Google Drive or emails is easy but also risky, because you don’t have a reliable single source of truth, you don’t have a centralised history of changes and you don’t have any specific security for your data. Most notably, separating your code from your assets by maintaining two storage/versioning systems is really cumbersome - especially for video games that intimately tie the two!

Picking a versioning tool made for artists

Solutions like Alienbrain, PlasticSCM or Perforce’s designer-oriented Helix Sync are trying to shift the mindset on version control and integrate artists better. Be it by creating more accessible interfaces to the tool, simplifying the options to get a more approachable system or ensuring direct connections with typical art creation software, they aim at giving artists adapted tools to keep track of their files.

For example, Alienbrain offers a visual differentiation tool that directly highlights the modifications on the file:

(Screenshot from: https://www.alienbrain.com/)

And it also integrates seamlessly with many game creation tools (Unreal Engine, Maya, Photoshop…), so that you can access your version control system from within each of those applications without having to switch windows.

Sounds great, right?

Well - that actually comes at a high price that basically blocks any indie studio from using it. It's a minimum €120 per year per team member… and that’s for a coder! ‘Cause yeah, Alienbrain has a fairly strange pricing system where you can have a coder subscription, an artist subscription or an “advanced” subscription that combines the two. For example, someone with a coder account won’t be able to get image previews, or track progress and manage the project at all.

This highlights how, because of the challenges of versioning large binary files, current solutions have to make their products expensive to cover their storage costs, and how this directly impacts users.

Moreover, the “easy integrations” that Alienbrain advertises on its homepage are mostly for art software… the only code editor they support natively is Microsoft Visual Studio, which is just one of the solutions used by devs. Overall, the steep learning curve and high complexity of the software put a huge overhead on the coders’ daily workflow.

(Plus, while the code-centric features such as branches, merging and conflict solving have improved, some reviews still say that the check-in/check-out and code merge features aren’t as well-designed as in other tools…)

So… does this mean that we have to pick either coder-oriented and perhaps free VCS that don’t work well for artists, or buy very pricey artist-oriented VCS that are unusable by coders? Or are we condemned to maintain two version control systems at the same time on every game project to combine the best of both worlds… which also means painfully re-merging those two worlds afterwards to get our final game?

Exploring modern versioning tools

This industry-wide question is becoming more and more of a problem, because video game studios are growing fast and exploring ever new workflows. To try and solve this conundrum, many people have started to work on more modern and multi-usage version control systems.

Diversion is one of those new versioning solutions. It is a cloud-native tool, currently in beta, that aims at bridging the gap and providing a VCS built both for developers and artists.

One of their main goals is to handle large binary files and small code sources alike, in a seamless and user-friendly workflow that everyone can understand. So they’re looking for the best trade-off between providing many features and a scalable solution, and keeping it easy-to-use with a clear interface.

And another very cool thing is that Diversion is actively working on an automatic conflict prevention tool to help teams collaborate on large projects safely - without risking unwanted overwrites, and also without having to “lock/unlock” files manually.

To do this, they take advantage of their cloud setup to continuously keep local files in sync with the remote version, and then notify users working on the same file at the same time that it is already being edited. You even have some info on the other teammates who are currently changing the file, and when was the last modification.

Of course, Diversion is still in beta and there are a lot of features that need to be added; but as is, this solution already looks interesting, and it’s definitely dedicated to creating a good user experience for both coders and artists.

Conclusion

In the complex world of video game creation, finding the perfect version control system is hard. Having something that is tailored for the needs of coders and artists is difficult, because they typically rely on very different workflows and software. And yet, having tools that accommodate both and can thus be shared across an entire game studio (instead of juxtaposing several profile-specific solutions) could be extremely nice in terms of setup, maintenance and team collaboration.

Traditional versioning tools like Git and SVN, while robust for source code management, often struggle with handling large game assets - plus, artists are often blocked by the complexity of those coder-oriented VCS. Conversely, artist-friendly systems are often very expensive, and they might not be suited for developers.

That being said, the industry is witnessing a wave of innovative solutions that are meant to solve this exact problem. Tools like PlasticSCM and Perforce have recognized the need for artist-friendly version control and have implemented interesting features such as visual diffs and large binary asset support.

Diversion is another solution that tackles this challenge. It aims at providing creators with a scalable and easy-to-use tool - and it might not be as pricey and difficult to manage as PlasticSCM and Perforce! Plus, they’re currently developing a conflict prevention feature to simplify collaborative work and make the best out of their cloud-based solution. So if you’re curious about this alternative solution and you want to learn more, check out Diversion here!