Plastic Gluon in detail
A detailed explanation of the motivation and internals
Motivation: artists don’t use the version control like programmers
Artists and programmers team up in game development but they don’t use the same tools and processes. Version control is not an exception. Things that are great for programmers (like great branching & merging and distributed development) are irrelevant for artists. Simplicity and avoiding feature creep are what artists care about.
Key requirements
When we started the design of Gluon we focused on the following requirements:
- As an artist I want to decide in which files I want to work, make the changes and submit them easily. I don’t ever want to see a merge. Most likely I don’t want to see branching happening either.
- As an artist I want to lock files so that nobody can work with them at the same time.
- As an artist I can’t download the entire repository because it can involve downloading tons of files of huge sizes.
A very common workflow for an artist
One of the most relevant studio using Plastic shared this with us:
- Find the character he's going to work with today.
- Find all the assets.
- Download just this part, not the entire repo.
- Browse the repo and then decide what to download - they need like a good browser to decide what to download.
Gluon: new UI and new Plastic SCM core adapted to the artist workflow
To create the best possible version control tool for artists we had to develop a new user interface but also an additional “checkin engine” to give them the freedom to checkin and update even when the entire workspace was out-of-sync.
The new UI is all about keeping things as simple as possible. It has a few key components:
- A “workspace explorer” to be able to browse what you have loaded on disk.
- A “configuration mode” to decide what needs to be downloaded to disk (plus a totally new ‘update-engine’ that works differently than the regular one in Plastic).
- A “checkin view” to easily checkin changes.
We removed all the other additional features and options to keep users focused on what they’re really interested.
Keep reading to learn more about the “checkin engine”...
DVCS core vs file-per-file versioning – the design of the Gluon core
All modern distributed version controls (git, mercurial, Plastic SCM) work on a “changeset|commit” basis instead of on a file-per-file basis as previous generations did.
While this change makes a lot of sense for developers, it introduces some restrictions for the game artist workflow.
"Changeset oriented" version control (the basis of DVCS) means the entire repository evolves “together”. There is no such a thing like "download version 3 of foo.c and version 7 of bar.gif". No. Whether you’re on changeset 8, globally, or 10 globally, but you don’t select files one by one.
This is done to keep what we’ll call "changeset coherency". Your workspace is synced with the repo all the time (excluding potential local changes pending to be checkedin and special configurations with cloaked files). This is extremely convenient for code because you minimize broken builds and you think on the project as a whole: you sync to a given changeset and you know the code will work as it did when you submitted it.
While this is extremely good for code, it is a big issue for the “artist workflow” described above. Let us explain why:
Suppose an artist is working on a given file with regular Plastic. He is working on, let’s say, changeset 19 as explained below:
Now the artist might want to get some new files checked in by other artists on changeset 20 and 21 and he faces the first issue with “changeset coherency”:
If he wants to get a newer version of a file, he’ll need to update from changeset 19 to 21, potentially downloading hundreds of files and megabytes.
And while it makes sense for a programmer (you wouldn’t download a source file without making sure all the others are there up-to-date to build) it is can be a pain for an artist.
Gluon versioning engine – ability to work on file per file basis while checking in to a dvcs repo
This is precisely what the new versioning engine solves: it allows the creation of workspaces where files can be updated one by one, breaking “changeset coherency” and still being able to checkin.
Now it is possible to:
- Select the files to be downloaded, one by one, or selecting subtrees of the repo.
- Avoid updating certain files and they’ll be visible as out-of-date when new versions appear, but artists won’t be forced to download unless they really need it.
Checkin changes to the head of the working branch
As explained above, now it is possible to update only parts of the workspace with new contents from the repo, even on a file per file basis.
So it will be possible to have a situation as follows:
and still be able to checkin “only” zombieweapon.3ds to the head of the working branch, without having to merge first as it would happen when working with source code (note that no files need merge, but in “changeset coherency mode” a merge would be needed from 21 to the working copy prior to checkin)
Different workflows, but the same repo
While the way of working on “artists workspaces” and “coder workspaces” will be different, they’ll still be able to checkin to the same repositories. They’ll use different workflows and GUIs, but the repos can be shared among the two, keeping total compatibility.
Restrictions on artists workspaces
Artists workspaces introduce total freedom to version on a file per file basis, but introduce a restriction: merges can’t happen in these workspaces unless they’re converted to “regular ones” running a full update (syncing with a changeset instead of having a out-of-sync status).
Since most artists precisely want to avoid merging and all costs… we think this is not a big price to pay for the new great flexibility.