Another problem is that using the VCS is inherently a manual process. When a designer is working on a level, she'll check it out, perform her work, and eventually check it back in. During that time, no one else can actually work on it. But the designer who has the level checked out is unlikely to be working on it every minute she has it checked out.

There might be long periods of time when she's working on something related. If the designer has to keep track of all the pieces of the level she might want to edit, then she might be tempted to check out large chunks, just to make things easier. In other words, designers will start checking out sections they are not in fact editing.

If instead the check-in and check-out procedures are handled automatically, then in theory you could set up your tools so that as soon as the level designer started to edit a particular piece of the level, then that section would be checked out from the VCS; and as soon as the designer stops editing (for example, the file is saved or successfully viewed in the game), then that piece is checked in.

Various problems obviously arise from using this automated method. Most notably, you're going to end up with people checking in things that are broken, so perhaps it's better to still rely on a manual commit at some point.

Still, checking out sections automatically can work well if the level is fine grained enough that conflicts are minimized. The level designer need not specifically be aware of the parts of the level that he has checked out -- simply that he's made a set of changes and needs to check them in. The tools will keep track of what has been changed, allowing him to simply check in everything with a single click.

The Ideal Process

In designing any toolset, it's useful to imagine the most desirable possible end result, regardless of how practical it seems. Such blue-sky designing can uncover possibilities that might not be considered with a more traditional incremental approach to adding features to an existing tool or process.

With our level-editing problem, we have a two sided problem: edit conflicts and edit bottlenecks. Fixing one problem can mean making the other problem worse, so we end up simply balancing them as best as possible, accepting the inevitable manual resolutions and underutilized resources that come from this.

But in an ideal world, there would be neither conflicts nor bottlenecks. Anyone would be able to edit in any area of the game at any time; nobody would have to wait to start working, and all changes would be merged automatically. In addition, all changes would be visible immediately in the game as they're made, with no delay and no "exporting" of files.

Sure, that would be great, but can we get there? If we can't, then how far can we get in that direction?

Second Life

In some respects, the online virtual world Second Life is already there. Players in the game exist in a large continuous world, which they can edit in real time.

Multiple people can edit in the same area of the world at the same time, and their changes are visible instantly, both to themselves and to others.

They can edit 3D models and scripts simultaneously, editing, testing, and playing all at the same time in a truly collaborative editing environment.

That does sound somewhat like our ideal, but if you've ever edited something in Second Life, you'll see it's not quite perfect. The editing process is based on you editing objects that exist in a remote database. But working over the internet introduces some annoying delays. The tools themselves are rather primitive, which is to be expected.

But the most glaring omission from a game developer's perspective is the lack of version control. When you edit something, that's it. You've edited it. No rolling back to the version from yesterday (or five minutes ago) if you accidentally delete half your script or mess up your UV coordinates.