Unity is becoming the game engine of choice for an increasingly large portion of the industry; in fact, it’s used to make a lot more than just games.  As a longtime Unity developer, I’ve seen it develop as a product, but I’ve noticed that Version Control has posed an ongoing problem, and has seen some very interesting solutions.  As of version 4.3, Unity has PlasticSCM integration built-in, which makes Plastic a very compelling option, even for people like me who hadn’t heard of Plastic before Unity.  I’ll be working through my thought process in considering PlasticSCM on Unity projects, and what is important to my team: what does it cost us in time/money, how can we share and collaborate, how does it deal with the kind of files we use, what is it like to work with, and specifically how do you make it play nice with Unity?

Some Backstory

The first thing I want to make clear is that I researched and wrote this article at the request of Codice Software (makers of PlasticSCM), who paid me for my time.  My goal was to be as objective as possible, and I think readers will find that I’m not “taking sides.”  But I’m a human being and therefore I’m subject to bias.  That said, my interest in this project isn’t primarily financial.  I’ve been barking up the Unity + Source Control tree for many years, and I’ve had great interest in Plastic ever since I first saw their offering on the Asset Store.  In terms of my direct experience, I’ve worked on projects ranging from a team of one to medium-sized teams (~15 people) with other engineers, artists, and producers.  I’ve even created some Unity version control tools of my own.  The first was called AssetCloud and is now defunct, but the second, UniMerge, for merging Unity scenes and prefabs, is available on the Asset Store.  And yes, it works with PlasticSCM 🙂

I’ve been on both sides of the source control problem.  I’m a developer working on projects, as well as our de-facto CTO, in charge of choosing and setting up our infrastructure.  We primarily use Unity, Maya, and Photoshop in-house, and use Git with TortoiseGit on Windows to track our projects (and SourceTree on OS X, if we find ourselves on a Mac).  In terms of hosting, we started out with a shared hosting account, which served our website and eventually some git repositories over SSH and Trac instances for each project.  Trac has a nice repo browser plug-in, but overall, we found Trac to be barebones and a little tough to work with.  We’ve since migrated to Jira, which we host on an AWS account, which we use for web experiments that require more control than our shared host allows.  I’ll be trying to see if Plastic fits anywhere in this equation (i.e. can Plastic replace Git and any associated tools).

Start-up costs

I’m talking both time and money when I say “cost.”  As with any tool, a learning period is required.  Codice Software, Unity Technologies, and their communities have provided a number of guides for how to get started with Plastic and Unity.  There is certainly good logic to sticking to what you know, which will always factor into the choices you make when starting a new project.  If you’re new to version control entirely, starting with Plastic would be a great way to go.  Plastic is a distributed system (which is all the rage these days), and has a similar workflow to git, Perforce, Mercurial, and many other popular choices. Thankfully, even if you’re not starting fresh, Plastic is still an option.  The git sync feature allows you to import your history from a bare git repository, and populate your Plastic workspace with files already committed to git.  You could even continue using Plastic and git side-by-side if you weren’t sure you wanted to make the switch.  As a note, git submodules can throw a wrench into the works, so be prepared to do some extra research if you want to git sync a project with submodules.

Setting up Plastic couldn’t be easier.  Hopefully most of the set-up can be supervised by savvy team members, but once the project is up and running, all team members should be able to figure out the GUI and check in their work.  As a programmer, I can’t speak to the experience of a non-technical user learning how to use Plastic SCM, but by my assessment, it doesn’t make things any more complicated than they need to be.

I also want to point out that if you want to use PlasticSCM on personal Unity projects without the Unity Editor controls for your workspace, you can use the community license of PlasticSCM and Unity free (even without Team license on Unity 4 and below).  In other words, while there are some licenses to buy for the “full experience,” you can still take advantage of PlasticSCM on your personal Unity projects for free! As it turns out, Unity changed around their licensing structure with the release of Unity 5.  Since a lot of teams are still “stuck” on Unity 4, I want to explain everything, though it gets a little complicated.  While for versions 4 and below, users had to pay $500 (on top of owning the Pro version) for access to the version control plugin, it is now included in all versions of Unity 5.  The team licence also includes Cache Server, which basically fixes Unity so that it only has to import any asset once; it was once worth the cost by itself. On top of the team license (if you’re not using Unity 5), you’ll need to pay for PlasticSCM.  You can either pay for a Team License from Plastic (different from Unity’s Team License) for $99 or $9.95/mo or a perpetual Enterprise License for $595 or $279/yr. All of these prices are per-user, meaning that they scale with your team size and/or the number of machines running Plastic and Unity.  You can also buy PlasticSCM through the Unity Asset Store.  It should come as no surprise that small, bootstrapped teams will want to avoid such a price tag, but it shouldn’t be a problem for large teams with deep pockets.  For my needs, git wins this round, but on a larger team, Plastic can save a lot of time for whoever is in charge of infrastructure.  As a note for perpetual licenses vs. subscriptions, if you want to control wide access to your repositories, you’ll be paying some kind of monthly hosting fee, so take that into account.  One final note: all of this pricing information might change after posting so please consult the Unity and Plastic pricing pages for current information.

 

Files, files, and more files

Game projects are a unique combination of software and digital art.  Thankfully, Unity makes it very simple to integrate everything.  One folder contains all of the code, libraries, and art assets needed to build your game, and none of the engine code need be involved.  That said, Unity being a closed system, the user is not meant to understand or manipulate the metadata which the software uses to tie everything together.  You can think of a Unity project as having three types of files: software files, art assets, and metadata.  I use the word “software” to include code files and binary plugins, etc., basically anything that is involved in building the game that isn’t art or files generated by Unity.

The problem with doing SCM on a Unity (or other game engine) project is that those three types of file are changed in very different ways by very different people.  Furthermore, while art assets (models, textures, music/sound, etc.) are almost all binary files and can be quite large, they may not be very numerous or change very often.  It’s impossible to merge most art assets, so a locking feature is invaluable on teams where more than one artist is responsible for a single asset.  Software files tend to be very small, and everything is text-based except for a compiled library here or there.  They change often but in the branchey, mergey way that programmers need to work.  Ideally they shouldn’t have to suffer the consequences of, say, an epic 1GB art push slowing down their workflow.  Finally, there’s metadata, which is generated by Unity, and really shouldn’t be anybody’s job.

While I can’t speak to the experience of using Unity with Perforce, I know that git has fundamental problems with large binary files.  The major sticking point is that the compression step (which happens during many operations) can run out of memory processing large files, and processes like displaying diffs or logs can get bogged down by large repositories and changesets.  Some teams resort to “segregating” the art and code into two repositories. Git manages the code, and something else (SVN, in my experience) handles art.  On the other hand, Plastic has been designed to tackle these issues, and sets itself apart in this regard.  Finally, the Unity plugin automatically handles all Unity metadata which can be tracked for you.  Granted, this is also true of Perforce and AssetServer, but these three are the only solutions that work with Unity out of the box.

My studio takes a less drastic approach, but we make a point of keeping layered PSD textures, and a couple of other types of unnecessarily large files out of the repo.  Until we switched to Stash, we would often bump into the issue of our git process getting killed by our shared host for taking too much memory, which was a sneaky little mystery at first.  I once had to prune out a 500MB PSD (4K texture with many layers) which was accidentally committed and made it so that we couldn’t push or pull that branch.  These issues would never have bothered us with Plastic, but I also probably wouldn’t want that file in the history anyway, since it takes time to transfer and eats up storage.  Regardless, I would love to be more permissive about what can and can’t be tracked.  We’re such a small team that locking (in other words, marking a file as “do not touch”) isn’t really an issue for us, but as I mentioned above, if you’re on a team where more than one person is responsible for an art asset which can’t be merged, locking is a must.

 

Access

Half of the purpose of SCM is to backup the history of your project.  The other half is about sharing the development process with others. This won’t work if no one can connect to your SCM server.  Beyond just “can connect,” it’s also nice to let your colleagues browse the code online without cloning the whole repository.  This feature can be especially important for public projects, like 2048.  As far as I know, the only front-end for Plastic is the Plastic GUI.  That said, you can use the GUI on any server, local or remote.  It turns out that this means that there’s no need for something like Stash or the Trac git browser, as long as your collaborators can install Plastic.  Since there are clients for Windows, Linux, and OS X, this shouldn’t be too much of a problem, and the free community license is sufficient to sync the files and replicate the project.  All you need is a publicly accessible computer running PlasticSCM server (also available for Windows, Linux, and OS X). I found that cheap (a.k.a. linux based) servers that run plastic are kind of hard to configure. Luckily, there is a guide on the Codice Software blog about how to get a public Plastic server running with Docker. I had never heard of Docker before this article, but it’s pretty cool!

I should also point out that Plastic integrates with all sorts of task and issue tracking software, so the Jira + Stash integration has a Plastic counterpart.  I haven’t tried it yet, so I can’t exactly say how they compare.

 

GUI

First off, let’s talk about what a Unity team does, and what they need out of their SCM software.  Let’s talk roles: there are artists (2D/3D), programmers, sound designers, UI designers, game designers, build engineers, QA engineers, and of course people who wear more than one of those hats at the same time.  There are also producers, community managers, and all sorts of other ancillary roles that might be interested in change logs, pull requests, and code reviews for administrative purposes.  Can we get all of these people on the same page about version control?  Since many of them probably aren’t familiar with a development team, ease-of-use is vital, and the Plastic GUI does a great job of being accessible.

Unity is designed to be accessible.  This means that the target user base is as broad as possible.  Nothing has to be scripted or command-line executed, and everything has a nice, friendly, stable GUI.  PlasticSCM follows the same principles.  Whereas tools like git and SVN remain primarily command-line tools, albeit with nice, mature GUI extensions, Plastic has been built from the ground up as a GUI application. The server is headless, and runs silently as a service, but the client is a first-party cross platform application which singularly handles every feature of the product.  This is something that many SCM tools lack.  If CL is your style, then you’re probably perfectly happy with your existing SCM tools (of course, Plastic also features command-line access, too).  Speaking to my experience in the git world, the GUI extensions have stabilized nicely, but this wasn’t the case a few years ago.  The current pain points with git are pretty minor, but the one feature that, in my opinion, Plastic nails better than other tools is the Branch Explorer.

 

Here’s how a couple of different Git tools visualize the same history (sorry for the jerky scrolling):

SourceTree–TortoiseGit–Git Gui

And check out the same history in the PlasticSCM branch explorer (courtesy of git sync)

Instead of just listing the changesets with that little vertical graph on the left, this is a view that I can zoom and pan freely which really visualizes what’s going on.  It’s showing me pretty much the same information, but in a much more informative way.  This feature alone might be worth the switch.

Recently, Codice released a new GUI called Gluon, which is focused on a simplified experience for artists and non-technical people.  To be honest, I haven’t worked much with it, but it does a pretty good job of focusing just on files, locking, and checking in/out.  You might try Gluon for certain team members who have trouble with the regular GUI or are prone to making mistakes with complicated software.

 

Unity Integration

PlasticSCM and Unity have put out a fair amount of information about how the integration works, and what it looks like.  Why do you want it?  A few reasons.  For one thing, it handles all of Unity’s metadata automagically.  Instead of having to commit meta files and project metadata, and come up with your own ignore list, the plugin takes care of those things for you. All you have to do is add your files from within Unity, do a submit, and your changes are tracked.  It’s nice to see the status of your files within Unity, and be able to do practically everything (except merging and dealing with branches) from within Unity itself.  There’s nothing particularly special about Plastic here, since it’s one implementation of a larger Version Control feature.  Plastic, Perforce, and Unity’s Asset Server are supported first-party, and there are a number of other extensions for git or other systems.

Another, less obvious, benefit of the Unity integration is that Unity exposes part of the Version Control integration API to you through editor scripts, and you can query state and execute version control tasks in your own extensions.  While, again, it is possible to work with Perforce or even Git in this way, it helps that Plastic and Perforce are supported by Unity Technologies.

 

Conclusions

If you’re trying to decide whether or not to use PlasticSCM, my best advice is “give it a try.”  You can get pretty far for free, and while you might be stuck on Unity 4 or something, you can still see it in action on the web, and figure out if the benefits are worth the price.  It wouldn’t be a wise choice to switch my team over to PlasticSCM at this point.  We’ve sunk a fair amount of time into getting comfortable with our workflow, and it serves our purposes.  In a perfect world, I think we might see some upside from picking Plastic for new projects down the road, since I can see benefits to their way of doing things.  On the other hand, if I were about to engage on a large-scale Unity project with a healthy budget, PlasticSCM would be a no-brainer.  It’s a simple, straightforward, elegant version control system which specifically supports Unity.  What more do you need?

~ by Schoen on October 6, 2015.

Posted in Code, UniMerge, Unity, Version Control