Feb03
2014

By: Elyse                Categories: BooksGames

Version control has two faces. For the individual artist, it provides a safety net: no matter how badly you mess up a particular file, you can always get back to the last version. For the team, it’s a way of keeping a project’s resources up to date—you only need to sync up to the server to be certain that you have the latest version of everyone else’s work.

But if misused, version control can turn on you very quickly. If team members aren’t disciplined about making sure the assets they check in are functional, every morning becomes a nail-biting rollercoaster ride as you wait to fi nd out what has been broken this time. And once shared assets turn ugly on a regular basis, more people will start avoiding the version-control system.

This keeps the staff working—but now they’re working in little private universes disconnected from the flow of the production. They make esthetic decisions based on assets that have already changed, and technical decisions based on features that are no longer there. This leads to even more breakages when they submit their own work, and the whole production spirals down into a vicious cycle of mistrust and recrimination. The artists don’t trust the pipeline, the tools team is sick of hunting down bugs caused by out-of-date files, and nobody is getting anything done.

Since this is a social problem, the solution is also social. Every team needs to create a culture in which people are serious about their responsibilities to their teammates, and take whatever steps are needed to make sure they aren’t undermining the production out of haste or carelessness.

For artists, these responsibilities are straightforward. Make sure that you have the latest version of other people’s work, and are using the latest version of the tools. Visually verify that your work is good before checking it in, and make sure all your dependencies are added to the system.

For technical artists and programmers, being responsible is more complex. Good discipline is still key, but it’s also important to have a solid build process that ensures that tools used by the rest of the team are reliable and always available. When you’re supporting hundreds of artists, the costs of catching bugs late mount up quickly—and this is doubly true for tools like 3ds Max and Maya plug-ins which can leave bad data inside art files long after the original issue is fixed.

Bugs are inevitable, but an aggressive testing program—complete with real, live testers, whether these are QA folks or volunteers from the art staff —goes a long way towards easing the pain. Formal build and test procedures do increase the time it takes to address feature requests and minor fixes, but the benefits in terms of tool quality and reliability—and therefore, in trust between the tools team and the content team—are more than enough to make up.

The further you get into a project—and in games, the closer you get to a demo or milestone—the more drastic the consequences of breaking the build become. In situations like this, programmers often use “code buddies” to review their work prior to check-in. Code buddies don’t always literally check one another’s work: often, the process of talking your buddy through the changes you’ve made is enough to make you realize you’ve done something wrong. Artists can do the same thing. It’s not necessarily practical in the early days to grab somebody and review every little change you’ve made, but when you are finalling, peer reviews become critical.

While professional courtesy is the core of good version control, there are also ways in which the pipeline itself can help people to be good citizens. One common problem for teams with poor version control discipline is overwrites: Artist A works on a local copy of a fi le for a long time but does not assert “ownership” of it by checking it out. In the meantime, Artist B checks out the fi le, makes a small change, and checks it back in. When Artist A finishes, he checks out the fi le, saves his local copy and checks it back in—destroying Artist B’s work. This problem can be minimized using a script in Max or Maya that automatically grabs the latest version of a fi le every time you open it, and warns you if there is a version mismatch. Similarly, the system can warn a user who wants to work on a fi le currently being used by someone else.

Another common problem is created by dependencies: artists frequently forget to check in all of the files needed to make a new asset work. Here, the version-control software can run a check every time a new fi le is submitted to see if it requires any files that aren’t already in the system.

Finally, tools can be designed to auto-update themselves across the network—although this places a heavy burden on the development team: to ensure that all of the tools are working, all of the time.

Click here for Top 5 Tips for creating a solid production pipeline.

Excerpt from Production Pipeline Fundamentals for Film and Games by Renee Dunlop © 2014 Taylor & Francis Group. All Rights Reserved.

_____________________________________________________

About the Book

Walk through the foundational layers of the production pipeline, including IT infrastructure, software development practices and deployment policies, asset management, shot management, and rendering management. Production Pipeline Fundamentals for Film and Games will teach you how to direct limited resources to the right technological initiatives, getting the most for every dollar spent.

No Comments

No Comments

Tell us what you think!