As an academic adventure, a few of us at Coveros decided to come up with a toy software development project we could do to learn more about programming in C# while doing something fun and different. We voted, then two of us ram-rodded our choice down everyone else’s throats and decided on building a game using Unity-3D.

Being a nerdy DevOps software engineer, I immediately started thinking about how we were going to version control the project, build it on a Jenkins server, and distribute runable packages for people to use. So … why not blog about it. Maybe someone else will find it interesting.

For anyone getting started with Unity, I highly recommend starting on the Tutorials page: https://unity3d.com/learn/tutorials. I started with the Roller-Ball game and it was very helpful to start working with the UI and building stuff.

Step 1: How do we version control this thing.

I’m going to assume you know how to use version control. In my case, I’m using Git and pushing to a Github repository.

Creating a Unity project generates a crap-load of files, even for simple stuff. According to a few web sites, the primary directories you care about are the Assets and ProjectSettings which hold everything you need to know about Unity projects. There are also a few other directories that seem interesting. Example: “Library” with lots of stuff. Apparently, this is just a cache directory that gets regenerated on demand. Certainly files like “obj” and “Temp” are obvious choices to ignore.

This page has a lot of good information on what those files are and why you might want to care about them:

http://developers.nravo.com/mastering-unity-project-folder-structure-level-0-vcs/#.VrK5krIrKM9

However, there are lots of other generated files that /look/ interesting such as *.sln (VS solution files) and other .csproj Visual Studio project files. Normally, I would version control these files since they tell us what makes up the code base. Apparently, Unity doesn’t need these and re-generates them whenever you need them.

Create a .gitignore file as listed on the page that ignores all the other junk you don’t need.

You also have to set Unity so that it knows it is being version controlled. In my case, I’m using Unity 5.3, so it’s a little different than what the 4.3 settings tell you to do.

First, check Edit > Preferences: External tools according to the instructions. Nothing useful there.

Next, check Edit > Project Settings: Editor. This allows you to choose:

  • Version Control > Mode: Visual Meta Files
  • Asset Serialization Mode: Force Text. This creates assets that have a better chance of being merged, I assume.

Once you have all that set, you should be able to commit/push your Unity project.

To test whether this worked, do the following:

  • Clone your project into some alternate directory.
  • Start unity, select “Open” to open a project
  • Browse to the directory, hit O.k. This loads the project.
  • Select File > Open Scene, then pick a scene (e.g., Minigame.unity)
  • Make some changes, commit and push your changes.

That’s it. Make some changes, commit, push, and pull back to your other copy. You should see the right stuff.

Open item: after telling Unity to do “text” files, are there any binary assets that don’t lend themselves to merging well. Certainly image files such as PNG cannot be merged. What happens if multiple people modify them? Sounds like a good follow-up topic.

 

Leave a comment

Your email address will not be published. Required fields are marked *

X