Plastic SCM Source Control for game development

This is part of a series of posts on source control for game development. Read more in the Blog.

Plastic SCM is a lesser-known source control solution for game development. In fact, I expect that a lot of the readers will be hearing about it for the first time. I personally discovered it only a few years ago. So why is it worth an article in this series?

Well, Plastic SCM promises a lot: Plastic SCM brands itself as "the version control for games", and promises to deliver all the benefits of Git, as well as all the speed and power of Perforce, enterprise-grade features and support, unparalleled user experience, and unique features on top of that!

In fact, I was so excited by the product that I decided to evaluate it when I started Darewise, and back then I was very impressed. So let's jump right in and see how it looks like today!

Background and History

According to wikipedia, Codice Software, the company behind Plastic SCM, started in 2005 to create a commercial version control system that would be better than SVN, a benchmark at the time. The first version of Plastic SCM was released in October 2006, and several major versions have been released since.

One of the notable points to note from the history of Plastic SCM is that Plastic SCM 4.0 changed the source control model from a per-file model to a per-changeset model. This is interesting for us because, as we have noted previously, the per-file model is usually preferred for games, at least when it comes to not enforcing the entire workspace to be up to date before being allowed to commit.

Plastic SCM 4.0 is also the version that allowed Plastic SCM to better interoperate with Git, as well as a notable focus of the product on game development.

Another big focus of Plastic SCM and its side products is the focus on better diff and merge tools. One of the major axis of improvement is the ability to understand the code better and track methods as they are moved within a file or from a file to another. This should raise a few eyebrows for programmers as better diff and merge tools are always a great addition to our toolset.

Finally, the current version of Plastic is version 8.0.x which receives several updates every month. Plastic SCM is clearly being actively maintained and improved, and that can only be a good sign.

As you can see if you dig through the website and the release notes, Codice employs a cheeky tone in their communication which is refreshing, and this makes the product all the more appealing to me. It feels like a tool by devs, for devs, and a dream come true when looking at the list of features.

Features

Before you dig deeper, or if you want the short story, here is a SCM comparison matrix from Plastic SCM showing its strengths, but also drawing a fairly good picture. Perhaps I'll make a matrix of my own at the end of this series.

Distributed and centralized

Plastic SCM is the only source control that is truly both distributed and centralized. Plastic SCM is architectured around a client-server model, and each installation of the Plastic SCM client is paired with a local server. The beauty of this model is that there is virtually no difference in behavior or workflow when working against the local server or a remote server.

Here are the typical use cases you may perform:

• Create repositories on your local server and work on them as easily as you would on any distributed SCM such as Git.
• Work on a repository located on a remote server.
• "Pull" from a remote repository, which transfers public branches of that repository to your local server, allowing you to work locally on your own copy of the repository.
• Maintain private branches and history of your own changes on your local copy of the remote repository.
• "Push" your changes or a branch from your local server to the remote server.

As discussed in previous articles, game development is a centralized effort, and it is most important that your version control is optimized for a centralized workflow. In this instance, Plastic SCM's primary model is always client-server, and therefore the centralized workflow is seamless and very efficient. You are also not required to use your local server at all, and you may avoid storing any redundant information locally, avoiding the typical Git issues and saving hard-drive space and download time.

You can easily combine distributed and centralized workflow in creative ways depending on your needs. Typically, programmers will enjoy the benefits of a distributed workflow to allow them to have private branches and history they do not wish to share. Less technical people will work directly against the central server, which is used as the single source of truth.

In fact, all of the common game development scenarios are covered: common repository for the engine but separate game projects, fully centralized or fully distributed, The combination of distributed and centralized setups elegantly solves most of the common collaboration issues, but everyone must be using Plastic SCM. If you're working with third-party companies, this is still unlikely.

Ideally, you will need to automate the pushes and pulls from the replicas to the master to achieve seamless multi-site setups. Plastic SCM also provides proxy servers for multi-site teams, but recommend using the distributed workflow instead, which doesn't suffer if the connection between the sites is interrupted. Where Perforce provides specific products to solve multi-site issues, Plastic SCM's distributed model appears like a more elegant solution and allows you to truly set up a multi-site infrastructure easily by using familiar elements of your regular workflow.

Changeset model

Plastic SCM changed its history model to a per-changeset model. This is closer to how Git presents the history. Each changeset is a collection of file changes, and changesets are presented in a tree-like hierarchy. Unlike Git, changesets are identified by an incremental number, and this makes it much more understandable.

While this is more modern than the older-generation per-file model, for us it could be an issue as we pointed out in our evaluation of Git. We do not want to have to download all the latest changes to submit a single file. Fortunately, Plastic SCM allows you to filter which files you are downloading using the cloaked files list. The other option is their Gluon tool, and we'll see how well it integrates into a typical game development workflow later in the article.

One of the main advantages of this approach is extremely easy branching, but also faster merging. And talking about the merge engine, Plastic SCM's is very good. While they claim it's better than Git at merging complex cases, the reality is that this is hard to test and you may find that it works better or worse depending on your merge cases. I certainly didn't have many issues and most complex merges seemed to resolve beautifully. This means time gained both in raw performance but also manual work for merges. In this aspect, Plastic SCM wins over Perforce in both speed and reliability of the merge engine.

User experience

Setup and administration

Plastic SCM's first-time user experience is very pleasant. Download and install like a regular program, and it just works! The documentation is very complete and will guide even the most non-technical users through all the steps.

Administrating the server is done through a mix of a web interface, configuration files, and executing commands from the GUI client or the command line. Again, it is surprisingly straightforward and doesn't involve a steep learning curve.

Even advanced administration procedures that can be scary in other systems seem to be simpler here. For backup, simply stop the server and backup a specific set of files, copy them back for restore. Although the initial setup is as simple as it gets, there is a wealth of configuration available to fine-tune the behavior, performance, access, and automation that you would expect from an enterprise version control system.

When evaluating Plastic SCM for the first time, I was blown away by the experience. After you register for evaluation, you are immediately offered a very thorough evaluation guide complete with test repositories to play with. On top of that, you are invited to a free webinar with one of the developers who will personally show you how to use the software and answer your questions. You even get a free t-shirt if you complete the guide, although I didn't apply for it in the end, so I can't confirm it actually works!

What I can remember though, is the impressive amount of support I received during and after the evaluation, as a non-paying customer. All of my emails and questions were answered quickly by the development team, and when I challenged certain design decisions or explained the reasoning behind us choosing Perforce, they became very eager to understand and hear my thoughts. Several very productive exchanges ensued via e-mail, conference call and discussions at game conferences. All I can say is: the devs behind Plastic SCM are truly interested in our user stories and solving our real-life problems, and it shows throughout the entire product.

Command-line

Version control always starts at the command-line, and Plastic SCM is no exception. The command-line tools are well-designed and well documented. There are in total less than 30 commands that provide enough options, alongside a concise syntax. The result is a very intuitive and fairly powerful command-line utility. The find command is a good example of an elegant and powerful command, which beats Git log in every way.

During my evaluation time, I didn't find any operation that would be difficult or impossible to perform using the command-line. Perhaps more surprisingly, I didn't find myself using the command-line as much as I expected, and that is thanks to all the graphical tools provided, where Plastic SCM really shines.

Graphical User Interface

Plastic SCM clearly aims to be user-friendly. It provides not one, but two graphical applications in order to solve the learning curve problem of version control. The main tool Plastic GUI, is fully featured, while the other, Gluon, is specifically tailored for game development artists and their specific workflow. Both tools are supported on Windows, Mac and Linux for maximum compatibility.

The main Plastic GUI is comparable to P4V and is similarly featured. You can perform all the operations from there without using the command-line. The main panels are a file browser, a view of the pending changes (detected automatically much like Git), and the ability to browse the history, labels, and shelves at the click of a button. You can also perform all of the administrative commands on your repositories from the client.

On top of this, Plastic provides a full suite of powerful tools you may have come to expect. There is a very graphical branch explorer to visualize the branching and merge history of the repository. This is extra powerful as you can use this view on a single file or directory, allowing you to filter and visualize the history in the most visual and intuitive way.

The annotate view, which is similar to git blame, allows you to see who last changed a particular line. A time-lapse view would have been excellent, but this will do.

Overall the Plastic GUI is great. There are still reports of some minor bugs and the occasional crash, but it hasn't been an issue for me.

The most annoying thing, in my opinion, is its tab and window management. There are things that only open as windows that you would rather have as tabs and vice versa. It also creates a new tab for almost every view, rather than reusing them. Again this has both pros and cons, but the result is that working on a repository will quickly end up with way more tabs than you can manage. I'd love for them to improve on that front by adding, for instance, the ability to pin tabs, to force certain tools to always populate the same tab, and to detach and dock tabs and windows freely.

Finally, as a power user, I'd love to have a log window much like P4V, where I can track all the commands issued by the GUI and the resulting console output. This helps you by keeping a history of your recent actions and comes very handy when debugging source control related issues.

Code review tool

Plastic SCM comes bundled with a full code review suite! Without having to install and configure an extra tool, you can review changes and even establish complex workflow rules out of the box.

The review tool is fairly well featured, but you may find that you require more control and configuration as you scale. It allows you to review changesets that have been shared on the central server. In other words, reviews happen post-commit. This is fairly typical in distributed workflow with per-task branches, but an option to be able to review shelves would have been nice. Reviews can also easily be tied to automation, for instance, a completed review may be automatically merged into the common branch.

While not perfect, it is very impressive to have it included at no extra cost.

Semantic Diff and Merge tools

Naturally, Plastic SCM provides a diff tool and a three-way merge tool. However, there is more than meets the eye here.

In parallel, Codice is working on a standalone product called Semantic Merge, which doesn't simply analyze text differences. It performs additional static analysis which allows you to track changes not just as lines added and removed, but as functions moved, symbols renamed, and follow changes even across multiple files.

In my eyes, this is a true breakthrough in programming tools. Using this, it is much easier to visualize what happened during a refactor, rather than deduce it from textual difference. The semantic engine is already very powerful, and hopefully will get better over time, as more and more diff tools take this direction.

Lately, Plastic SCM has been bundled with the semantic diff and merge capabilities, so that every diff view within the main Plastic GUI benefits from this engine. You don't need to buy a license for Semantic Merge separately anymore. This is simply amazing!

Semantic diff and merge are available for selected programming languages. There is official support for C++, C, C#, Java, and PHP, with the ability to create custom parsers to support more languages.

Gluon

Gluon is a tool designed for users working on a single branch on binary files that can't be merged, using exclusive locking. It also allows you to choose and download only the files you require, as well as share your changes on one file at a time. Thanks to exclusive locking, you will never have to deal with merging or conflicts. This is exactly what's needed for the bulk of game development. It seems Gluon was developed in close collaboration with Telltale and the result is impressive.

Gluon has a very simplified user interface. After creating your workspace, you can perform the following operations:

• Configure which files and folders you want to work on
• Update to the latest changes
• Checkout and exclusively lock one or multiple files
• Checkin changes
• View file history and diff between revisions

And that's it! Gluon is exactly what the artists and less technical people need. It has all the features you would find in a basic file explorer integration, yet it also adds the necessary features of day to day workflow, without adding complexity. It is very easy to learn as there are only a few buttons and options. The main selling point is that it lifts the restrictions on having to download all the changes to check in a single file. This is great when working on very large art repositories where you are only likely to work on a few files at a time.

As a matter of fact, I'd love to see a Gluon equivalent for Perforce, and while GitCentral is essentially the same for Git, it's only accessible from within Unreal Engine and not as a standalone application.

There are some edge cases in which Gluon gets stuck. You generally have to discard your changes, or perform a manual operation with Plastic GUI to resolve the issue. It shouldn't happen often but it's worth noting.

Useability for game development

Handling large projects

Plastic SCM was famously used by Telltale Games, which should reassure you that shipping world-class game projects with Plastic SCM is possible. Codice Software has been using Telltale as its main showcase for game studios before Telltale tragically closed doors. Besides that, there are only a few game studios using Plastic SCM that I know of. At the very least, even if there is not widespread adoption, Plastic SCM has proven to work for a number of studios, which warrants our interest and pushes us to dig deeper. Therefore, let's examine the features of Plastic SCM that support large-scale projects.

Performance is clearly a focus of the development teams. There are numerous blog articles and benchmarks available which focus on the optimization of a particular feature, sometimes with comparison to competing products. Some recent client optimization around multithreading and process management allowed them to push the performance even further, as they shared some numbers privately with me.

Adding to that, the database backing Plastic SCM can be configured to fit your needs. Interestingly, the Jet storage is a special-purpose storage built for Plastic SCM, and now the default. It supposedly performs 3 to 5 times better than any of the other SQL backends offered, but you may still confirm that by yourself. Jet also has a "high scalability" mode that further increases performance for large repositories, but this is only available in the Enterprise version.

Finally, for enterprise networks and intercontinental data transfer, Plastic SCM supports a specific network protocol based on UDP which performs much better than TCP. I've seen studios build custom data transfer tools for this reason, so this should be very interesting for large publishers.

There are also some advanced features that really shine in larger organizations. Component-based development using Xlinks is almost essential and very well integrated. There more configuration and automation of the workspace than you would expect. You may achieve remarkably advanced tricks such as moving, renaming mounting directories locally while keeping the repository structure intact.

Access control and Security

Access control and permissions are very easy to configure through the web interface and the Plastic GUI client. The permissions are granular enough to allow almost everything you could want. You can create group permissions to easily manage a large number of users. You can also integrate with LDAP or Active Directory as you'd expect from an enterprise product.

Security is enabled through SSL connections and file encryption. As a bonus, you can easily audit your server where errors and destructive actions leave a paper trail.

File-locking

Plastic SCM provides file-locking out of the box. You can configure which files must be locked, as well as who can perform the operation.

It's simple and straightforward until you start working with branches. A file is locked globally on the repository, and not on a per-branch level. This makes it impractical to use in typical scenarios. For example, when you stabilize a build, you usually create a separate branch in which more fixes can be committed. However, if someone works on the same file in the development branch, you won't be able to lock the file in the stabilization branch. In this case, since you probably did not intend to merge back, you would have never had a conflict, and this workflow should be allowed. The only workaround available is to create a separate repository for stabilization, which is of course, not ideal.

Full and partial workspaces

Now, there is one caveat of Plastic SCM that I always have some trouble with. There are two GUIs, there are two sets of commands, and there are in fact two types of workspaces. A regular Plastic SCM workspace functions similarly to a Git workspace. It is synchronized with a specific changeset and may contain some local changes. A partial workspace is a Gluon workspace, in which you choose the files that are downloaded, and each file may be synchronized at a different changeset and may be committed individually.

This might seem logical, but becomes a problem in practice. Artists and designers will almost exclusively use Gluon and will be fine. Programmers and technical users, however, will require Plastic GUI and its advanced features. This doesn't mean they necessarily want to forego the per-file workflow when dealing with large binary assets such as the content of a game project.

It's not as bad as it sounds. Plastic GUI and Gluon will happily open a workspace and make the best of its current state. Gluon can mostly deal with Plastic workspaces, as they contain more information than the partial workspace would. In the worst case, you can resolve any blockers by discarding your changes. However, the Plastic GUI will require you to update your workspace to a changeset before being able to commit again. This may involve conflict resolution.

This forces programmers to stick to the Plastic GUI (per-changeset) workflow and avoid using Gluon altogether. For other team members, such as technical artists, it may not be so simple, as their usage of Plastic SCM is usually occasional.

It is an annoyance, but not a dealbreaker. Ideally, both workspace types would be fully compatible with one another. As a second choice, you could configure files and folders in a repository to be restricted to the per-file workflow. This, in fact, would solve the issue entirely. I tried several tricks using two repositories and mounting one workspace inside another to achieve this result, but I could not work around all the issues. It seems clear from the recent updates of Plastic SCM that "mixed-mode" workspace support is high on the priority list. Let's hope to hear some good news in the near future.

Ecosystem

Naturally, we expect Plastic SCM to have a smaller ecosystem than the major solutions such as Git of Perforce. However, when taking a closer look, Plastic SCM seems to have everything you need.

Integrations

You can find a list of official integrations on the website. The most notable integrations are:

• Project management tools, in particular, the popular tools of Atlassian as well as Mantis.
• Developer tools, especially Visual Studio which everyone is likely to be using for games.
• Continuous Integrations tools, such as Jenkins and TeamCity.
• Communication tools are not mentioned on the page, but an example of Slack integration is shared on GitHub.

On top of that, there are deep integrations in major commercial game engines. The Unity plugin is available with paid editions of Plastic SCM. The Unreal Plugin was developed by a coworker and friend of mine, in collaboration with Epic and Codice. It is now bundled with Unreal Engine by default. During my time evaluating Plastic SCM I tried using the Unreal integration and for the most part, it was functional and well integrated. There are definitely some edge cases especially as a programmer who plays with both Gluon and Plastic GUI. The Unreal integration seems to work with Plastic workspaces in most simple scenarios, but it works best using Gluon workspaces, as Unreal's workflow is almost identical to Gluon's.

For continuous integration, Plastic SCM features the mergebots which enable deeper integration and automation with external systems. For instance, you can use mergebots to automate merging a feature branch when the code review has been completed, or create merge queues to avoid the competing merge issues that can famously arise on graph-based source control. Think of mergebots as a powerful server-side trigger system to allow you to create and customize your workflow to your needs, and remove manual steps, especially manual merge actions which can be complex and time-consuming.

Interoperability

Plastic SCM interoperates natively with Git, Perforce and TFS. However, there is a definite focus on the Git interoperability through various key features:

• Git Server: Every Plastic SCM server is also a Git server to which git clients can connect. When enabled, Plastic SCM repositories can be accessed as if they were Git repositories using a Git client.
• Git Sync: A protocol allowing to perform distributed workflow operations (push/pull) against a Git repository not hosted on the Plastic server. For instance, you could use Git Sync to work seamlessly on a Git repository hosted on GitHub. This is great if you find Git's user experience complex, as Plastic is much more artist-friendly.
• Plastic SCM now supports the Git fast-import format which is the de-facto standard for source control import and export. This allows for easy migration from another version control system to Plastic SCM.

This remarkable Git interoperability is not without its caveats. Plastic SCM does not have an equivalent to the Git rebase which allows you to rewrite your history in a more coherent form before sharing it. Rebase and fast-forward merges are therefore prohibited. It also relies on specific naming conventions and other little gimmicks which should be fine as long as you use it mostly as a read-only replica of the central Plastic SCM server.

The bigger issue remains, Git's properties still make it unwieldy for game projects filled with large binary files. To my knowledge, GitSync does not implement Git-LFS. The GitSync replicated repositories will need to contain the entire history of the binary files, which pretty much prevents using it on a large project. The same goes for cloaked files in Plastic SCM, which do not have equivalent in Git. If you use Plastic SCM primarily, you will probably fare better by avoiding the Git interoperability features unless they are required. That being said, it can have one very practical application: you can use Plastic SCM as your central repository even when contributing to external GitHub projects, which are commonplace nowadays even when collaborating with proprietary software.

Hosting

Codice provides an option for cloud hosting of Plastic SCM repositories with all of the different versions of the software. There is a specific cloud edition priced at $6.95/user/month which includes 5 GB storage space but is limited to teams of 15 members.

Here is the full pricing breakdown when increasing storage space. A 100 GB server will cost you $19.95/user/month on top of the basic license fee if you are using the Team or Enterprise edition. As you scale, it may be worth considering moving to your own hosting solutions.

Plastic SCM is, of course, made to be self-hosted on beefy hardware for enterprise needs. In this case, you will have to factor in the cost of purchasing and maintaining the hardware over time, which can be significant. Another option is to use public cloud instances to host your Plastic SCM server. This gives you more control over the hardware and the storage space, but also requires technical knowledge to set up, administer, and has an operational cost that may not be easy to forecast for novices.

While Plastic SCM doesn't have as many cloud hosting providers as Git does, the cloud edition is fairly priced and serves as a good starting point. It is assumed that, as your needs and budgets grow, you will move into more enterprise-like hosting solutions, and Plastic SCM comes with all the necessary features to support it.

Pricing

Plastic SCM is commercial software and therefore must be licensed. There is a tiered pricing model that targets different types of teams with different offerings. We already discussed the cost of data storage on cloud-hosted servers, so let's focus here on the licensing costs.

• Plastic SCM is free for open-source software and non-profit. It is also free for individuals and hobbyists. Those versions come with a limited feature set focusing on the core source control. In particular, you may not use the Gluon GUI or the Unity plugin.
• For small teams that don't fit in the above category, there is a cutoff at 15 users. You can choose between the cloud-hosted version ($6.95/user/month + storage costs) or the self-hosted version ($9.95/user/month).
• Finally, the enterprise version allows you to scale above 15 users and adds the enterprise features such as LDAP/Active Directory integration and the high-performance storage and network features you are likely to need on very large projects. The full version is priced at $23.25/user/month, which makes it quite affordable overall, and certainly more affordable than its main enterprise competitor: Perforce.

Thanks to this tiered pricing, Plastic SCM can be affordable for many types of teams. When comparing the feature set with its competitors and taking the price into account, it is a very compelling offer. In particular, smaller teams with lower budgets may find that Plastic SCM has all of the features they need for a fraction of the budget and favor Plastic SCM over Perforce. Price was, in fact, the main reason why I evaluated Plastic SCM against Perforce when starting Darewise.

Conclusion

Plastic SCM is an amazing suite of tools, backed by an impressive and dedicated team at Codice Software. I would like to personally congratulate them for a great product.

There is a lot to love here: a huge and complete list of features, great UX and performance, one of the best Git interoperability, enterprise features ... but perhaps the thing that stands out the most is the amazing team behind Plastic SCM and the support that they are eager to provide. I would like to thank them again for their availability and openness during all of my interactions with them.

I've evaluated Plastic SCM twice now: once when starting Darewise, once again today. I was expecting to write the same notes as previously, but instead, it's amazing how much more there is to say, two years later. Most of my original points have been addressed, or are on the right track. There is a long list of new features and improvements at every level. Plastic SCM seems more viable than ever, supporting both Programmer and Artist workflow elegantly and providing solutions to all the typical situations you will find yourself in as a game developer, no matter your profile. It tries to combine the best features of Git and Perforce in one coherent solution, and it's not far from hitting the mark!

For enterprise users, Plastic SCM is more affordable than its main competitor, Perforce, but the choice is still not clear-cut and it will be up to every team to decide. I encourage every game studio to evaluate Plastic SCM hands-on, as they may be pleasantly surprised. While it is expensive to migrate ongoing projects, it could be a very reasonable option for upcoming ones. Old habits die hard and it may be a long road before game developers widely adopt a new tool, especially of such importance as version control. I've heard of a few studios trying Plastic SCM only to switch back to Perforce recently, and it's hard to know what were their reasons. Others, who came from Git and SVN are adopting Plastic SCM to overcome their hurdles. As for me, I am impressed but there are a few remaining obstacles. I would like to see resolved before seriously considering it for my professional projects.

For smaller and newer teams, it's a very different story. Plastic definitely beats Git and other free solutions for game development and should be within their financial reach. The time gain alone will be well worth the price, as non-technical team members will be operational in minutes and rarely get stuck.

I'd love to hear more testimonials of developers with Plastic SCM, whether good or bad, as I expect this article will need revision in the coming years.

In the next article, we will take a look back at an open-source source control that used to be the gold standard and still stands the test of time, I'm talking of course about SVN.