Unity3D for teams of 6 people or more

I’ve done this rant live to various people, but I thought it was time to write it down.

First of all: I like Unity3D. I sincerely think Unity3D existing makes the games industry a better place.

But, basically, I don’t see how it can be used for efficient, professional game development, with teams of 6 people or more all actually using Unity. I’m sure people are doing this, but I’d like to know how.

This rant is based on my experiences on a project that used Unity 3.5. Maybe Unity 4 is better. It was our first Unity3D project, but to be honest we spoke to a lot of other Unity developers and if there were any major rookie mistakes we made I don’t know what they are.

Final caveat: It’s been a while since I’ve gotten my hands dirty on this, plus I wasn’t the one who set up the project, so I might get some details wrong.

We used Unity3D with Perforce, with a team of 6 to 8 people, most of whom had to work within Unity itself, as opposed to just making bitmaps or something. The daily workflow for pretty much everyone on the team was:

  • Check out everything in the Unity folder in Perforce. Not ‘get latest’. Check out.
  • Open Unity3D.
  • Do your work and test it.
  • Save, then quit Unity3D. You must do this.
  • Go into Perforce, reverse unchanged files, then try and guess if any files, particularly all of those tiny .meta files, have been added or removed and tell Perforce about those.
  • Repeat.

Unless you want to change a scene, then you must yell through the office that you’re going to change a scene, lock the scene file, then do all of the above. So this was pretty much like not having a repository. We had things set up so scenes and other data are text files, but to be honest, just because it’s now YAML doesn’t mean you can just merge scenes – all those internal references don’t necessarily match up.

That’s a pretty sucky workflow, and it took us a while to get it through everyone’s heads that they really, really had to do all this. I personally suspect – I never investigated this – that we had to quit Unity because of one plugin that saves important files on exit. But to be honest if that’s the case I still see that as a design flaw in Unity.

So, internet: what did we do wrong? What are your experiences with Unity3D and teams of more than a couple of people? We did not use the Team License – could that have solved our problems, and if so how?

Comments 15

  1. Andy Durdin wrote:

    I can’t speak for using Unity in a team—but I have been using Unity (3.5 mostly, but now 4) with version control and lots of branching. I tend to do exploratory work in several branches, and then merge them together. I’ve been using git, not Perforce.

    I never had to quit Unity for things to work; even when checking out other branches, it would reload things sensibly.

    When committing changes, “git add -A” picks up all deleted, edited, and newly created files easily, so don’t have to hunt down .meta files in general. On the occasions where I didn’t want to commit everything, I’d selectively add or selectively unstage files before committing.

    Merging prefab changes is easier than scenes—changes to them are smaller in scope and they change less often anyway. So I use lots of prefabs for things shared between scenes.

    Merging scenes is pretty much impossible. So instead of changing a scene in a branch, I generally create a new one for that branch and make changes to it. When it comes time to merge a branch, I make sure that the bits I want are in a prefab, and I can add that prefab into the master scene. This would kinda work for multiple people too, but it would still be very inconvenient at best.

    Posted 23 May 2013 at 18:33
  2. Kent Quirk wrote:

    Unity is seductive in that it wants to do a lot of things automatically. You need to resist.

    I just ended a 2-year project that had 17 engineers working in Unity. Our solution? Don’t do all the things Unity does for free.

    Basically, we built a text-driven system to describe a UI and a UI framework. We built an external asset pipeline and a system for loading assets at runtime. And we built most of our code into DLLs that were built separately. The only thing we actually did in Unity was debug.

    All that stuff with the IDE — seductive, but doesn’t scale. Neither does Team License.

    Posted 23 May 2013 at 18:45
  3. Trevor Fountain wrote:

    I will be very interested to hear what sort of responses you get to this — we’re fixing to start two Unity projects in parallel, each with a team of 4-6 working off a shared core.

    Horror stories like yours make me want to re-think this plan…

    Posted 23 May 2013 at 19:04
  4. bleh wrote:

    Do you happen to know which asset serialization mode you’re using? You can check this by going to Edit -> Project Settings -> Editor -> Asset Serialization. If you are using text asset serialization, then your .unity scene files, .mat files, etc should all be in plain text YAML format.

    Plain text asset serialization mode will not necessarily address the specific issues you’re running into, but it does help reduce the chance of conflicts when e.g. two people check in changes to the same scene file. (The chance of conflicts with binary assets in that case is probably close to 100%.)

    Even if there is a conflict, with YAML files you at least have a chance in hell of fixing it without just reverting someone’s work because you can see and resolve the conflicts with a regular text editor. It might just be that one section of the YAML file needs to be moved or a choice has to be made between a some simple numeric values. The files really aren’t that difficult to figure out, especially if you’ve had occasion to use YAML before.

    Maybe something to try, if you haven’t already.

    Posted 23 May 2013 at 23:22
  5. bleh wrote:

    Oops. Sorry, you *specifically* addressed how YAML wasn’t actually a big help. Nice reading comprehension on my part there. (Crawls back under rock.)

    Posted 23 May 2013 at 23:26
  6. Jurie wrote:

    Come back! Comments are good! :)

    Most of the time we didn’t bother trying to fix conflicts – most of the time one of the involved parties was a non-programmer.

    It’s human-readable, but not quite human-understandable, especially once the structures get more complex. You’re basically hacking raw Unity data.

    Some of the feedback I’ve gotten on Twitter suggests to me we’re not the only ones taking that approach. A friend suggested making smaller changes before checking in, but that already smells of a limiting workaround to me.

    Posted 24 May 2013 at 0:20
  7. fluffy wrote:

    Hm, from your description of the workflow it sounds like you’d be better off using git.

    Also, in perforce you can set a client ‘revertunchanged’ which cuts out half of step 5, at least.

    But yeah perforce’s checkout-to-edit model doesn’t do it any favors in this situation. git behaves more like a filesystem snapshot, which makes this sort of workflow MUCH simpler.

    Posted 24 May 2013 at 0:51
  8. Matt Attaway wrote:

    Warning: Perforce shill here.

    Checking out in Perforce is optional; if you set your client to “allwrite” all files will be left writable. Then you can use p4 status to the actual adds/edits/deletes. It’s the way I work with Perforce most of the time. You just need to make sure to use “p4 update” to sync(does an MD5 check to make sure it doesn’t clobber files), or make sure to always run status before syncing.

    Posted 24 May 2013 at 1:07
  9. Jurie wrote:

    @Fluffy: Much as I have learned to appreciate Git and use it for my private projects, I don’t think it’s the best solution for pro (read: lots of binary assets) game development :) And we’ve invested in Perforce, everything is in there, people know how to use it, etc. So switching would be painful.

    You’re right about the Revert Unchanged flag, it’s more a personal thing that I like to do that manually. I like to see what’s in my changelist before I submit.

    Posted 24 May 2013 at 9:33
  10. Jurie wrote:

    @Matt: Thanks. I wonder if we might be relying on non-checked-out files being not writable, and whether that might be causing problems elsewhere. But that might be an option.

    p4 status and p4 update are CLI commands, right? So we couldn’t do this through P4V?

    Posted 24 May 2013 at 9:35
  11. Tobi wrote:

    > all those internal references don’t
    > necessarily match up.
    .meta files need to be checked in together with scene changes. Unity generates a unique id as the internal reference at the time it creates the .meta file for an asset.
    If the .meta file is not checked in, every machine will create its own local .meta file for an asset it just got from the repository – so a scene file that references this asset will be different, too.
    .meta file/unique id mismatches also cause referenced assets to vanish from the scene.

    You are not bound to checkout-to-edit with Perforce or P4V. One way to use sync/update mechanics is “Reconcile offline work”.
    It also helps a lot to set up filters in the Perforce workspace to exclude Unity’s Library and Temp folders.

    Posted 24 May 2013 at 11:03
  12. Matt Attaway wrote:

    @jurie: from P4V you would use “Reconcile offline work”. It runs the same commands. p4 update is tricker; with the next server version it will automatically use the safe sync (p4 update) with allwrite clients. Until then you will want to use “Reconcile Offline Work” before syncing if you think there may be collisions. Failing that you could use a custom tool to run “p4 update”.

    Posted 24 May 2013 at 21:35
  13. jarlostensen wrote:

    @matt – thanks for the tip; the “allwrite” approach works. Haven’t tried to scale it up beyond my 2-client test environment yet and with big projects it might be a bit slow (the diff takes a while) but at least it works!

    Posted 01 Oct 2013 at 9:33
  14. Matt Attaway wrote:

    Glad to hear it worked! Just to let you know the 13.2 server with the built-in safe sync option is live. You should then be able to work through P4V without any problems. To enable it you need to set “alllwrite” and “noclobber” as options in your workspace.

    As you noted it’s definitely slower; calculating all the hashes is pricey. It’s one of the reasons we generally beat SVN senseless on performance. I suspect with the “team package” for Unity their integration would allow you to run with file locks enabled for the speed boost.

    In P4V or from the command line you can run either sync or reconcile on just a folder; selecting the subset where you think changes happened will cut down on the scans by quite a bit.

    Posted 02 Oct 2013 at 17:12
  15. Moifa wrote:

    Thanks to you guys, you save the marriage between Unity3D and Perforce. They were close to divorce. Specially Matt for your expert advice.

    Posted 15 Oct 2013 at 0:07