Plastic Gluon is out – version control for artists

Plastic Gluon is out – version control for artists

Friday, March 06, 2015 Pablo Santos news 6 Comments

We’re happy to introduce Plastic Gluon today, a new Plastic designed with artists in mind. Find all the details here: www.plasticscm.com/gluon.
Gluon doesn’t need extra licensing so if you have Plastic you can start using it today.

What is Gluon about?

As you know Plastic has some features that makes it unique for game developers: Plastic is a distributed version control but unlike Git and Mercurial it can handle huge files with ease, it can do locking for unmergeable files, it can work centralized (working copy and server, no intermediate repo if you don’t want it) and it features super strong branching and merging.
But it is no secret that we designed Plastic with coders in mind. And as new game dev teams started to use Plastic they helped us realize that the artists needed something slightly different. Big files were fine, locking was a must, and they were very pleased with the speed checking in and updating huge files, but usability-wise the GUI and the associated workflow was “slightly” shocking.
Some artists were comfortable with the simplicity of SourceSafe (!) although they hated corruption and slowness. Some loved AlienBrain, others preferred P4 but they all had a few key points in common that made them switch to Plastic: speed and the ability to have developers and artists on the same VCS (but with developers having best of breed branching, merging and dvcs, of course).
So we went back to the drawing board to come up with a new way to use Plastic, this time with artists as first class citizens.

Is Gluon a “new” version control?

The answer is no. Gluon is Plastic, but implements a new GUI and a new workflow. Gluon users and regular Plastic users can still work on the *same* repository, although using totally different workflows.

What are the key ideas behind Gluon?

These are the “user stories” we considered when implementing Gluon:

• As an artist I want to decide in which files I want to work, make 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.

And what about the new workflow?

As you can see there are two key points that are radically different from regular Plastic: for an artist it is good to download just a few files and work on them. This is not something a coder would do. Coders are fine with “changeset consistency”: you download the code to build it, so skipping files and risking consistency doesn’t sound good (ok, you have cloaked, configurable workspaces and so on, but they’re exceptions, definitely not the regular way to use Plastic).
So, since “selecting what you really need” was the first thing to focus on and that’s how “configure workspace” was born:

Exactly selecting what files to download is now straightforward.
The second challenge was related to how you work with art (and it also applies to working with documents, marketing…): suppose you update your workspace here:

Then you work on an image for a few hours.
Now you’re ready to checkin, but since your colleagues were also doing their job, now the repository situation is as follows:

So in regular Plastic, you would need to update from “changeset 20” before being able to checkin your changes, in order to keep your workspace consistent. While this is simply “the way to go” for developers, it is confusing for artists. “A merge is needed? What the hell! I didn’t even touched files from anyone else, we use locks, I don’t need the new files to be downloaded unless I decide to do so!”. I must confess we tried to convince them to follow this path and folks like Digital Legends are now used to it. But we learnt the lesson.
With Gluon you’ll simply checkin and the checkin will be done. Sort of file-per-file version control supported by a “changeset-oriented” one. Two ways of working, a single system.
In fact his workflow is the *key* part in Gluon. We also created a new CLI (cm partial command – a must for studios since they need to integrate it with their own toolset) and a new GUI that removes everything except what really matters for artists. No distractions, no feature-creep, just what matters.
NOTE for DAG-gurus: you know CVS, SVN, P4 and some others version on a file-per-file basis while Git, Hg and Plastic version on a changeset-centric way. Merge tracking is per file in the former and per changeset (commit in Git jargon) in the latter. This changes everything in terms of merge efficiency and speed and also introduces the way in which working copies are handled: in Plastic your workspace is *in* a certain changeset (plus potentially local changes), but you don’t have half of the wk synced with a cset and the other half with another. It simply doesn’t work this way. This is great for coders, but it can be a pain for artists as I explain below.

Is Gluon for game artists only?

Well, while we certainly designed it with artists (and I mean all kind of non-coders) in game project in mind, Gluon can help a wider audience. First artists in other kind of projects, like web devel, will feel at home too. Second it is extremely useful for coders to deal with documentation repositories where you focus more on certain docus and don’t need to download everything.

With great freedom... comes a small restriction

Once you set a workspace in “gluon mode” – which basically means “partial mode” because the entire tree is not downloaded, you can’t merge on this workspace unless you run a full update with the regular GUI.
We were very concerned about this at the very beginning, but we now think it is a small price to pay. Artists won’t miss merging, and developer won’t use Gluon for code.

Supported platforms

Initially Gluon is available on Windows. Good news is that many of the studios we’re working with use Windows for Maya, 3D Studio and so on, and that’s why we went for Windows.
Our goal is to implement a native Mac GUI soon. Please let us know if you’re interested so we can move it up in the roadmap.

Field tested

Gluon wouldn’t have been possible without the help of some great studios. Some used it from day one and sent precious feedback, others shared ideas about usability and helped us focus on keeping things simple.
The folks at TellTale have been using Gluon (code named GameUI :P) for more than 8 months already providing awesome feedback, ideas, support and a great insight on game development. Thank you guys!
So you can feel confident when you start using Gluon on your own projects :)

Next steps

Gluon has just been launched, so expect constant evolution.
One of the pending things is that we still didn’t integrate Gluon with Unity. The Unity Plugin relies on regular Plastic, but most likely having Gluon as an option will be great for many studios, so we’ll work on that real soon.
Enjoy!

Pablo Santos

I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.