14 May 10

Unity, meet SVN. SVN, meet Unity.

Actually, neither app needs to meet the other at all. That’s the nice part about file-based versioning systems like Subversion: You can just lob them at a particular part of your drive and they just work. Most of the time.

Now that we’re starting to focus on building a Unity version of DD, we’re running into a few problems. Firstly, we’re a distributed team, so that means we NEED to have some sort of versioning in place. Frankly, even if we were always in the same office, versioning systems are so useful that there’s no excuse NOT to use one. Game Maker’s been great for prototyping the game so far, but it’s sorely limiting because having multiple people working on one GM project is tricky (and we’re pretty darn good at it). For instance, I built the interface as stand-alone as I could and I still needed to freeze the code for 4 days to merge it all into the version Nandrew was working on.

Anyway, back to Unity. This being the first time we’ve used the package, we’ve found out that it does some things that make it not play nice with versioning systems. Like continuously rewriting needed object metadata in a constantly changing set of random directories. Which is sort of a dick move when you think about it. Apparently the Pro license lets you force Unity to write that metadata as text next to the resources themselves, nixing the random rewriting/renaming and apparently letting SVN do its job as advertised.

We’ll probably switch up to the Pro version of Unity at some point over the next few months, but until then we really needed to get something working so that we could all start taking bites out of the todo list that’s growing alarmingly fast. There are a few posts out there about versioning and Unity, there’s even an official how-to if you’re using Pro. Unfortunately the consensus seems to be that versioning and free Unity is messy at best and non-functional at worst…

We spent some time poking around and brute-forcing limited copies of our embryonic DD in Unity to see the bare minimum that we needed in order to reconstruct the game correctly in the editor. Turns out that all you need is everything under Assets and the Library/Meta directories, the contents of Library itself don’t seem to matter too much. This bears out what people have been saying regarding how Pro handles meta info… But, due to the constant rewriting of the Meta directory (even when you’re not really doing squat in the editor itself), we can’t just point SVN at the dir and let it handle everything – we’d be swimming in hordes of useless/redundant updates and conflicts.

We’ve settled on what appears to be the least hassle so far:  Zip up the entire Library directory, add the zip to the repository and ignore the directory itself. Then, when anyone adds something via the editor (we’re mostly adding elements via code at the moment), they zip up their version of Library and let the repository propagate that out to everyone else. If the zipfile changes, we have to individually unzip it and establish a new “base” that Unity can do its meta info dance on top of as much as it wants. Yes, this means that we can essentially only have one person in charge of major changes via the editor at any particular point, but at least we can all be working on code and have at least semi-normal version control in place…

If anyone has a better way to get the free version of Unity and SVN playing nice, please let us know!

6 Responses to “Unity, meet SVN. SVN, meet Unity.”

  1. Herr_Alien Says:

    Here’s the deal: check in the files in the ‘Library’ folder. Just the files, not the folders inside ‘Library’. Those folders (and their contents) are generated by Unity. if they are missing, the program will just re-import the project and recreate them.

  2. dislekcia Says:

    We tried that, kept getting odd errors on some of the imports. At the moment the zipped Library approach seems to work pretty well, as long as one person is in charge of “library edits” at a time.

  3. Howard Says:

    We’ve been using http://www.dropbox.com/ with limited success. This basically makes people work out of the same constantly syncing directory. It works mostly, and dropbox is smart enough to catch potential merge conflicts, however, the resolution is generally somebody gets rolled back. It WORKS but it isn’t great and it left us with such a bad taste in our mouths we ended up walking away from Unity as a collaborative tool, and instead have left it as a solid prototype engine. Unfortunately until we can be satisfied a game will be successful it’s hard for us to justify the 1500 dollar per SEAT license.

    Hope that helps!

  4. dislekcia Says:

    Our SVN setup has been working really well so far. Merging isn’t a problem and the zipped Library directory solution has been stable. We haven’t had to roll back anything in response to a conflict, but then again we’re mostly working on code at the moment, not doing tons of stuff inside Unity as an editor. Benefit/curse of randomly generating so much content ;)

  5. Ashkan Says:

    It’s really something that people should use to know how much great it is, After that, using unity without svn is impossible for them.

    If someone is a tortoiseSVN user on windows then our small package on asset store might become handy.
    http://u3d.as/content/mind-hammer-games/ez-svn/30X The price is not high enough to worth advertising but i thought it might be useful for people and price a cup of cofee might be nice.

  6. Ashkan Says:

    oh and at the moment you just need to put assets and project settings under svn and enable meta files in Editor/Project Settings/Editor

Copyright © 2014 QCF Design
Powered by WordPress, theme based on one from Themelab.com