My personal experience with version control started on the creative
side, working in VFX studios, when I began doing some code scripting using Python to help automate around a few common workflows and responsibilities I had as an artist. At one point, we brought in a developer who was surprised we were not using version control for the type of work we were doing, because he viewed it as a mainstay of how game developers work. Curious, I took a closer look, and started to see how it could automate
and replace the ways I (like many people) used to keep track of files and work, such as manually copying files and folders as backups, renaming files for each update, sending complicated network file paths, or delivering files with consumer-grade cloud storage systems like Dropbox (all labour-intensive and error-prone processes not optimal for versioning with collaborators). I also discovered I could easily undo changes and had an automatic safety net. The first time I used version control to restore a project that had been corrupted irreparably, I was fully convinced it was worth learning. However, back then, most version control tools were designed for
code, not creative files, limiting my initial use. Even with tools that were able to handle binary files, the ease-of-use barrier meant that it would be hard to get my fellow artists to use version control, so it did not stray outside the programming teams. So, art teams were not sharing that single source of truth, which, in turn, meant a lack of organisation- wide visibility, impaired collaboration, and worst of all, they still had to manually share files on network storage with error-prone renaming and very limited ability to go back to previous versions of individual files. As the industry has evolved, finding a way to remove that developer-
creative divide has become imperative, which is why version control had to evolve in a new direction. The result is a new generation of version control technology designed to be accessible for creatives, enabling them to work alongside their developer colleagues. Artists crave visual tools and intuitive interfaces for saving versions of their files and they want control over when others can see their changes. They also need a system that combines local speed with shared server collaboration that treats binary files as a first-class citizen. On a senior management level, heads of studios and similar job
roles, use version control to help teams operate, simplify organisation, automate workflows, make processes repeatable, reduce error, and ensure enterprise-wide visibility while still allowing users to stay in their preferred environments. Leaders also use version control to support collaboration across remotely located teams or individual contributors or contractors. Your IP isn’t a mere collection of the individual assets your team produces. It’s the built-in file history and records that let you maintain a project’s security and relevance. A good version control system will do that for you. Game projects today often involve multiple companies and require
global collaboration. The system they choose to facilitate this type of collaboration is critical. Studio working heavily with third parties, often own all the version control environments to create a common ground for all contributors, or use version control to exchange assets across a variety of disparate systems. When sharing IP with other companies or contributors, it is essential to use a version control system that allows
August/September 2025 MCV/DEVELOP | 49
customized permissions per file or folder for different users and groups, so that a third party only has access to the files they need.
BUSTING MYTHS Despite version control’s development, I still see a few common misconceptions: • Myth 1: Version control (or source code management) is only for large studios. This is no longer true today, especially given how quickly the size, complexity, and variety of files grows for even the most simplistic games or the smallest teams. This is why I often see many start-ups – staffed by experienced leaders or game devs –embed version control into their workflows from day one. • Myth 2: Version control is too complicated to use. I argue that many people use far more challenging tools daily, including Unreal Engine itself. Don’t underestimate the productivity losses connected to manual file tracking and error-prone collaboration systems. • Myth 3: Version control is just for coders, not for artists. Anyone with experience at a large organisation, knows that siloed teams are inefficient. Studios today must bring games to market faster and more efficiently to survive, and a version control system that unifies the team across departments can play a transformational role in removing barriers for growth. Version control is increasingly being found in other industries using
game technologies and know-how to create new workflows, such as what we are now seeing in the automotive, architecture, and media and entertainment spaces. This is why I have also been hearing more and more stories about professionals leveraging their game technology experience to transfer into some of these markets. Game technology, including version control and source code
management tools, have evolved greatly over the years. While helping programmers track code is still a major part of its job, these days version control supports creatives and designers, helps disparate teams collaborate, and gives leaders a continuous view of a project’s progress across departments. So, for anyone who is new to version control or has not looked at it
recently, now could be a good time to take another look, master the fundamentals, organise files and collaborate better. Perforce has various training resources, some of them free, available at:
https://training.perforce.com/learn
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56
