Game projects, no matter the size, tend to follow a predictable pattern in their development.  At first, work is slow, and you’re happy if you can get anything up on the screen (at Flagship Studios, there was a photograph that somebody took of the first triangle displayed with the engine).  At that stage, a lot of the work that the artists are creating is either completely throwaway temp art, or is experimental, trying to figure out what the real art should look like.  After a while, you’ve got enough of the core technology in place and you’ve figured out what file formats to use and how to export them and import them and set them up that you can start to get a bunch of content in the game very quickly.  Then, toward the end, it slows down a lot as you start putting together the polish and the finishing touches.

When you’re a small videogame startup with grand visions and no money coming in, the most important thing is to get up and running as fast as possible.  The less time you spend in that first stage the better, at least for the first few projects.  As we were getting started, we evaluated a whole slew of game engines: Vision, Unity, Unreal, Crytek, and many more.  The engine that had the best cost (free) and got us up and running the quickest was Unity, so we decided to go with that and see where it took us.  We managed to build our gameplay demo for Remnant with Unity, and decided to use it for our first game, Ace Attack.  Having gone through the process of finishing Ace Attack, we’re finding that we have outgrown Unity.  Unity has been good to us, but the right technical decision for us is to move away from it in favor of other technologies.  I’ll be writing about that in a future post, but this week I want to talk about Unity.  We’ve learned a lot about the best way to work with the free version of Unity (and a little bit with Unity iPhone Basic) in a small team with no budget, and, as we prepare to bid goodbye to Unity, we’d like to share our experience, so that others can learn from it.

The first thing that we’re going to talk about is source control.  Unity will be happy to sell you an Asset Server that is fully integrated with Unity for $500 a seat, but that’s a bit pricey.  Depending on the size of your team, there are plenty of alternative options out there.  We decided to use Subversion, since it met our needs very nicely, and is capable of growing with us.  No matter which source control software you use, though, you need to figure out what to put in it.

A standard Unity project is a directory containg an Assets folder and a Library folder.  The Unity editor also generates obj and Temp directories, and, if you’re using Visual Studio, it generates .sln and .csproj files, and Visual Studio will generate a .suo file.  The general rule is that you don’t want to put anything into source control that Unity can generate on its own.  So, definitely mark the obj and Temp directories as not being in source control.  You can also mark all of the Visual Studio files, because Unity can regenerate those without any trouble.  Now, for the actual content, you can get away with just putting the entire contents of the Assets and Library directories into source control, but that will give you grief, especially with Subversion or any other source control that stores its metadata in parallel with the files.

The first problem is that Unity is constantly recompiling scripts.  Every time you change anything, it gets recompiled automatically into a DLL that Unity puts into the Library/ScriptAssemblies directory.  The problem is that Unity also has a habit of blowing that directory away completely, and regenerating it, which means that the .svn directory gets clobbered.  But it’s something that is being auto-generated by Unity anyway!  Why keep it in source control if it can be regenerated?  So, Library/ScriptAssemblies goes out of source control.

The second issue is that blindly putting everything into source control will waste lots of space in your source control repository.  Remember that we’re not putting anything into source control that Unity can regenerate.  It turns out that Unity is perfectly happy to generate the Library/cache directory on its own, so that one also doesn’t get source controlled.  You do need the contents of the metadata directory, so put all of that in source control.  The last piece is the default resources.  In the Library directory there are a couple of files: “unity default resources” and “unity editor resources”.  These are copied from the install directory, and Unity is happy to re-copy them when you open the project if they don’t exist.

So, here’s what you’re putting in source control:
- Assets/* – These are all of your source assets, and must live in source control.
- Library/metadata/* – Unity’s metadata about files in the Assets directory
- All files in Library except for the resources files – These are your project metadata files

Now, if you check that in, and check it out to a new directory or a new computer, Unity will perform some big one-time import process, and then let you work on your merry way.

But that’s not the end of the story.  Unity (at least the free version) has lots and lots of binary files all over the place: scenes, materials, prefabs, project metadata assets, and the giant directory of metadata files, just to name a few.  There is no way to cleanly merge these files, and that creates workflow issues.  Next time I’ll talk about the workflow and how best to manage it.