By Matt Attaway
Issue: Volume 38 Issue 1: (Jan/Feb 2015)


When you ask artists what tools they need to start a 3D project, you'll hear the usual list of suspects: their modeling tool of choice, Photoshop, and if it's a game project, an engine of some sort. But what you usually won't hear is "version control," and that's a shame. Small teams often think their projects are too small to need a versioning system or the complexity it can introduce. But when properly used, a versioning system can save you blood, sweat, tears, and, most importantly for a small team, money.


Revision-control software, such as Perforce, can save headaches and production costs.

It Worked Last Week

As a developer, I probably lean on Maya Embedded Language (MEL) and MAXScript more than most animators. Nevertheless, it's increasingly true that more and more behavior is scripted, and the moment you introduce scripting, you get all the fun bugs and oddities that can only come from code.

In a lot of other industries, the art assets for a project and the source code are loosely related; if your HTML references an image that doesn't exist, most Web apps will stumble along. But that isn't true in the animation world. Our script files frequently have expectations of the rigs and will fail catastrophically if those needs are not met.

It's critical that art and code live together in a version-control system. That's because version-control tools operate using the concept of changesets; files can be committed as a group, and the tool tracks the files that were changed together. This makes it easy to go back in time to a specific commit to see what the scripts and models looked like. If you're finding that a rig is misbehaving when it worked fine the week before, version control makes it easy to track all the necessary files as of a certain point in time, so you can see what has changed. Once you've debugged a problem with proper version control, you'll wonder how you ever lived without it. Have you ever seen a file like that? It turns out that even when we aren't using a versioning system, we tend to think in terms of versions and create our own systems by hand. I guarantee any team that works this way will have moments where people are out of sync and using the wrong file versions. Version-control systems let the computer handle all that juggling for you, carefully storing the contents of each change and letting you attach a description to the version so your future self can remember what your past self was trying to do.

Folder copying is also a popular way to fake versioning, and it works in a pinch. However, it is horribly error-prone, and one bad folder copy can wipe out a lot of data. I consulted for a popular gaming company that used a network shared drive and folder copy for all its versioning on a 100-person project. They shipped, but they shipped six months late and millions of dollars over budget, all because of a constant stream of data loss from their error-prone versioning system.

What's One to Do?

File-sharing tools make sharing easy, but they don't do much in the way of helping to figure out what other people are working on. If your team has only one artist, this isn't much of a concern. But as you add artists, you will find that you don't always know who is working on what. Version-control systems frequently support locking so that an artist can claim a file as theirs. It makes it easy for every­one else on the team to see at a glance who is working on what, and it also helps to make sure that two people don't try to change the same file at the same time.

One of the worst things that can happen to you as an indie artist is finding success and getting caught unprepared. If you've watched Indie Game: The Movie, you've seen that success brings all sorts of folks out of the woodwork to try to get their piece of the pie. In the thick of creation, it can be hard to prepare for success. Thankfully, version-control systems can actually help with some of the problems success can bring.

Here's an example: A common problem occurs when people make intellectual property claims against your work. They will say that your character designs, dialog, or story is a derivative of their work and that you owe them compensation. Without proper documentation, the court case can be messy, as each side tries to prove it had the idea first. This is where version control can be your savior.

By having a system that stores the date and time of each unique change, you have a digital trail showing the evolution of your assets. For this reason, you should be committing everything that is part of your project - design documents, scripts, models, textures…the works. Many large companies actually digitize and version sketchbooks and pictures of sculpts so they have a history of the evolution of their characters. I have worked with a number of companies that have submitted version-control histories as evidence for IP cases and won, in part, because of the digital trail those histories provided.

If you don't choose to digitize and version your sketches, it is a good habit for artists to sign and date all the pages in their sketchbooks. This can provide some additional ammo for your case should you be pulled into court.

So, where do I get me some version control?

We're fortunate to be digital artists today. I recall a professor of mine sharing war stories of hand-generating textures for a football title he worked on, using comma-separated integers in a text file to "color" the jerseys. Today, there's a vast array of tools at our disposal. A number of companies make version-control tools targeted at 3D artists and game developers, and almost all of them give away a full-powered version that is free for small teams.

Whether you're working on a 24-hour game-jam project or the next Wall-E, version control should be a critical part of your tool box. And while there are unique strengths and weaknesses to various version-management tools, the most important thing is to pick one and start using it!

Matt Attaway (@mataway) is the director of community support at Perforce Software. Over the course of his career, he's worked as a designer, developer, researcher, tester, and DevOps engineer.