One of the challenges facing any team is making sure everyone’s on the same page. This is doubly so for teams working together entirely virtually, as is the Guys from Andromeda team working on SpaceVenture. We have people collaborating from around the world trying to accomplish tasks, and trying to accomplish everything using e-mail, phone, or chat would be daunting. Fortunately, the Internet has provided us with a number of ways to work together, some of which have worked better for our team than others. In this article, I’ll talk about what’s worked for us and what hasn’t. This might turn into a bit of a rant, but hopefully it will be less technical than last week’s.
The early days
We started out using Google Drive for collaboration. Mark and Scott used it extensively to work up the overarching SpaceVenture plot, as well as breaking down each section into scenes. Spreadsheets on Google Drive were also used for the first version of the narrative. The tools available through Google Drive made it possible to restrict access to the files while ensuring we would be able to work together on them and see edits in real time. While the narrative branched out into different tools, the plot document still has its home on Google Drive, and a few other (mainly text-based) documents are shared there.
Dropbox was used early on for sharing of larger files such as images, and later Unity builds. We still use Dropbox for sharing out internal builds for team members that don’t have Unity as well as in-progress art or audio files, but Unity scenes and the project itself are now stored separately in its own dedicated version control.
Unity and version control
We started off trying to figure out the best way to share Unity files. Several methods were tried (including Dropbox at first) but we eventually settled on Unity’s built-in Asset Server. This worked great for a long time. It had the benefit of being built-in to Unity, so there wasn’t a lot of requirements on the developers to shuffle another program to get situated. Updates were pretty easy and file conflicts were pretty simply handled.
One early problem was the inability to ignore certain files that didn’t need to be committed (for example, a plugin that integrates Unity with Visual Studio causes issues for other developers so I had to leave that uncommitted). But overall the asset server worked great. The problems with it started surfacing towards the end of last year. The server crashed, and while I was able to recover all of the data and rebuild, there was a lingering sporadic error that kept popping up when one of us would try to commit. In researching it I ascertained that Unity isn’t really supporting the Asset Server anymore (…great) and is instead pushing developers off onto other solutions.
Well, okay. I felt we had some time. The asset server was still working fine (minus the errors), it just lacked some of the robustness of real version control software. For the rest of 2014 I looked around for solutions. One of the problems with Unity is the lack of built-in support for version control besides a select few – there are plugins for others on the Asset Store, but they seemed dubious at best. In the end I decided to go with Bitbucket’s hosted solution – I felt they had a good reputation and their SourceTree software package was one of the most friendly – yet robust – version control tools I had seen. Plus, it integrated with JIRA (being made by the same people). So we went with that.
Bitbucket
As I mentioned, Unity doesn’t play very well with external version control systems – if you want to do that, you have to turn on meta files, which basically store information about the import settings of the file. When a person adds, changes, or deletes a file and tries to commit that change, they need to commit the change to the pertinent meta file as well. This seems fairly straightforward, but if you think that commits often involve a large number of files across a number of directories, they can sometimes get overlooked. Then, when another person retrieves the commit from the server, their copy of Unity will assume it to be a new file and create its own meta file. This would be OK in most cases if the default settings were all that was stored, but the meta file also incorporates a GUID which makes that new copy of the meta file completely unique from the original one. So reconciling everything quickly becomes a headache.
Subsequently, I started to notice a bunch of empty directories popping up. Huh. Apparently with this configuration Unity also makes meta files for directories, even if they’re empty…but empty directories don’t show up in SourceTree (or many other version control tools, for that matter). When someone pulls down a folder meta file for a directory that doesn’t exist, Unity will actually create that directory, instead of just deleting the meta file. Thus, the problem can snowball pretty quickly.
We eventually worked around these issues through a Unity editor script that automatically deleted empty directories (after a while, so you wouldn’t just create a directory and have it deleted) as well as using branches to avoid constant meta file collisions. This too, worked for awhile. But then Bitbucket informed me that our repository size was nearing 2GB and they were going to shut off commit access when it hit the 2GB point. Oh, fantastic…
Right, moving on…
The main culprit behind the repository size is the large binary assets (art/audio) which can’t be differentiated line-by-line like the text assets (scripts, narrative, etc). This means that every revision where the binary assets were changed stores an entirely new version of the file, no matter if the whole image changed or just one pixel. With an artist like Mark Crowe plus a sound designer like Ken Allen working behind the scenes these assets build up quickly. More research into the matter showed that this is becoming increasingly common with large game projects and their high-fidelity assets.
I found that Git itself starts to become unstable as a repository goes over 1 GB. We were seeing this too – operations were timing out and refreshing the repository was slow. Solutions included splitting off the art assets into a solution like Dropbox – which is difficult with a set up like Unity where the code and art is all in one folder. You could have sub-folders for each under the main Unity assets folder but this starts to get dicey and information could be lost or people may not have the latest versions of all the assets. Plus with Dropbox you essentially lose many abilities of version control – being able to go back to a previous version, etc. There are solutions to automate this but they are not built into the base Git design so they feel a bit flaky themselves.
Perforce
Another option for us was to switch version control systems yet again. A bit more research led me back to something I had dismissed previously – Perforce. While it has been used a long time by game development companies, Perforce also has a bit more overhead as far as setting it up goes. Each computer being used with it needs its own mapping to the repository – called a “workspace” when set up – and takes a bit more effort on the part of each developer to get established. So I had dismissed it in favor of the easy to use SourceTree. But now I looked at it a bit more closely. Perforce is one of those systems that integrates directly with Unity, meaning the meta file problem would not be a factor anymore. Plus, when I mentioned it, Mark and Ken both said they had experience with it in the past (it being basically an industry standard and all), so it seemed more and more like a better option. Also, Perforce comes from a background of a repository design that is more centralized; while Git or Mercurial are distributed systems, Perforce is closer to SVN or CVS in that the server is the authoritative version and each client works within that single repository. This makes version conflict resolution closer to the Unity Asset Server.
That’s about where we are now. Perforce has been working pretty well. The familiarity some of us have had with it made the transition less painful than I’d have expected. We switched over to the P4Connect Unity plugin (designed by Perforce) rather than the functions that come with Unity – the plugin seems to catch file changes better and checks them out on open so that they show up on your to-submit list, making committing later a lot easier.
Next time, fulfilling an old request, “Dos and Don’ts of Adventure Game Programming in Unity”.
Leave a Reply