Version Uncontrol?

The problem of not having version control in an editing environment such as Second Life could obviously be addressed by incorporating some kind of VCS directly into the project. But this again raises the issues we had earlier of potential bottlenecks: how to divide things into files, and the manual burden of checking things out and back in again.

Take a step back and ask the sacrilegious question: Do we need version control?

The immediate and emphatic answer is, "Of course," especially if you remember the dark days of early game development when all code was manually merged on Fridays, nobody had the right version of anything, and programmers lost days of work if they accidentally overwrote a file. Version control is an invaluable part of the game development process that is impossible to discard.

But consider what you use version control for, especially with game assets. You use it to prevent edit conflicts, to distribute the latest versions, to back up files, and to create branched versions of the game.

Now on a daily basis, the vast majority of what a VCS is used for is the first two; preventing edit conflicts and distributing the latest version. Developers check out or "open for edit" some files, do their work, and then check in or "submit" those files.

They then "get" or "sync" the latest version of the project and tools. The backup aspect is a necessary part of version control but is used relatively infrequently. The branching is used even more infrequently and is a high-level task performed by very few team members.

Consider now how this works in Second Life. We don't need to ever get the latest version, as we always have the latest version. We are in the latest version. We don't need to check things in or out, as we simply start editing them, and they get locked. Then we stop editing them, and they are unlocked. We don't actually need the conflict prevention and version distribution of a VCS.

But what about backups? You'll note that backups are what you really miss about the lack of a VCS in Second Life -- and remember, the backup functionality is one of the least used functions in VCSs.

We still obviously need it, but we might now want to perform a little paradigm split and separate the VCS into two separate function groups, one being the file ownership and distribution system and the other the file backup and history system.

Since they have been so closely linked in the past, it has been natural to treat them as being the same thing. When you check in a version of a file, it becomes the file that gets backed up.

Yet the real utility of a backup system would be the ability to undo your changes to an arbitrary point. If you've been editing a file for a while without checking it in, then you might have made a lot of changes that you might want to undo. Designers often save multiple numbered iterations of a file locally before checking in.

Programmers who keep a file checked out for a long time frequently get nervous and make local backups, or even check-in with changes (hopefully) stubbed out, just to have the security of that VCS backup. Here the act of checking in a file is a useful label in the backup process, but it should not be the sole method of backing up a file.

Edit conflicts, bottlenecks, file distribution, and backups are, to some degree, historical problems, forced upon us by the constraints of a simple file-based editing system. Files are large, which means you get edit conflicts or bottlenecks, and that it's expensive to back up every single change.

But if we transition to a game editing process more like that found in Second Life, we are no longer editing files, but are editing much smaller objects within the world, which are stored on a shared database which needs no distribution.

Here it would be quite possible to back up every single change and every single edit to each object, essentially giving the developers both infinite "undo" capability and the confidence to make bold changes knowing they can safely return. Branching is also quite possible within such a scheme.

I think it is inevitable that some aspects of game development will move to using this collaborative model. It will require a rethinking of the way version control is handled, and even the way version control is viewed -- a perhaps violent division of the functionality of file locking, distribution, and backups, that will allow each separate area of functionality to develop unfettered with new and powerful tools and processes.

[EDITOR'S NOTE: This article was independently published by Gamasutra's editors, since it was deemed of value to the community. Its publishing has been made possible by Intel, as a platform and vendor-agnostic part of Intel's Visual Computing microsite.]