Unity3D At Home Project - Day 5 - Unity Update & Version Control

So wow, it's been a few weeks since my last update. Let's see, first I am pretty much swamped at work, and unfortunately things are only going to get more swamped. And there was a trip to Boston for three days to attend the Unity Unite conference. But that was a good thing, because coming back from Unite I feel re-invigorated about Unity development in general, and had a host of even more things that I wanted to try and do.

So let's refresh. Currently, our At Home project is still mind numbingly simple. We have a brain dead camera controller, we have a character controller, and an animated bipedal humanoid. We've created some terrain, set up a skybox, and laid down some grass & trees.  It looks like something, but it's far from being a multiplayer robot-shooter, as promised! So along those lines, the next step I think is to set up multiplayer for the project. Support for multiplayer is going to create an entirely new infrastructure layer for the entire project, and just about everything else we do will sit on top of it. So it's best to get it in and set up early, and the start building on top of that.

But before we even go that far, I had a little prep work to do. I needed to do two things - one was upgrade to the latest version of Unity, and the other was to set up some sort of revision control.

Unity Upgrade
So why upgrade? This is actually a bit of a departure for what you would do in a commercial project, so I can't necessarily recommend it for your own work. Typically in a project, you might upgrade once or twice during the early stages of development, but pretty soon you want to lock in on a specific version, and stay with that. Why? Because each time you upgrade the engine, you introduce the possibility of new errors, new changes to the way things behave, and in general it's a level of instability that you have to deal with. So you have to weigh the cost of dealing with whatever instability the upgrade brings against the value of whatever features it provides. And as you get further into your project and get closer to shipping, the cost of any instability, no matter how slight, is usually not worth the risk.

Unity's Cloud Services

But because this is an experimental project, and the whole point of this project is to learn about and play with some of Unity's most recent features, I've decided that for this project, with each new major version they release, I would I turn, upgrade to it and roll it in. So as I was currently at 5.1, and they'd already released 5.2, I needed to upgrade. And 5.2 brought a whole host of fun new things, most notably the integration of all of their cloud services directly into the editor. So things like Analytics, Cloud Builds, and yes, even some of the multiplayer stuff, can all be accessed directly from within the editor.

Remember what I said about Upgrades?
So yes, even though this was an upgrade of only a single sub-version, and my project  literally consists of only stock assets from Unity, after upgrading to 5.2, there were issues. All of the trees in my terrain suddenly had blocky leaves, and I was getting errors from SpeedTree about invalid materials. Now these are just stock assets, I  didn't set them up, and I don't know jack about how they work. So a little bit of google-fu later, I learned that all I needed to do was revisit each material in turn, and click the "Regenerate Material" button for each asset, and resave the scene. That did, in fact fix the problem, and shortly our project was back to normal, and now running under Unity 5.2. But just tracking that problem down and getting it fixed took the better part of an evening. So caveat emptor - do not take any engine upgrade lightly.

Version Control
I'm not going to dedicate much time in this blog to describing what version control software is, or why you need it. There are a ton of guides out there, and every piece of software has it's own collection of beginner's tutorials. Linked below is a very nice overview and introduction, if you're not terribly familiar with the concept. I will though add this thought. Even if you're a one person team, working on only a single game - you need version control. It shouldn't be considered an option, or a nicety. It should be considered mandatory. And here is why.

Even if you're a single person working on a project, version control software gives you the freedom to try dangerous and experimental things with your code. To go down an alley just to see if it pans out. And if it doesn't, you always have the previous version of the code to roll back to. And this is really important.

So as we were about to add the multiplayer layer to our game, and this is going to significantly increase the size of the project, I decided now was the time to get some version control for our project set up. And the first, and probably most difficult decision to make, is which software to use. For me, initially it wasn't even a question. I'm a Perforce guy, going back for years. Just about every project we've built at Robot (and Ensemble before) used Perforce. And when I spent two years working on my own project at home, I had a Perforce repository set up. It works, I'm familiar with it, it's free - just get it in and working.

But Perforce through me a curve ball this time, and in so doing, it opened up an opportunity for me to branch out a bit. (See what I did there?  Jeesh.. programmer humor.. it's the best) See, the latest version of Perforce's software - Helix, puts its evaluation copy inside of a VM machine appliance. And, quite frankly, its a huge pain in the ass, and is a terrible barrier to put between their software and someone who just wants to try it out. The first thing you have to do is download and install some other piece of software - Oracle VirtualBox, or an equivalent, to host the virtual machine. Then you download their 1.2 GB appliance, and import the appliance into their virtual machine. Which means now you're running a virtual machine, a server inside the virtual machine, and that has to run continuously on your server computer - which is probably also your development computer. But to make it worse - for me, it just flat out wouldn't work. I got everything installed and set up correctly, but try as I might, the browser and client software simply couldn't see the server. And after three full mornings of jacking with it, including rummaging through firewall settings, installing on two different machines, etc., I had lost all patience to mess with it a moment more.

So my next thought was, well screw the evaluation VM appliance, let's just install their production server, and set it up.  But then I thought.. wait a minute.

So as I've said, I've been a Perforce guy since day 1. But there are of course a ton of other solutions out there. And I've dabbled with Git, and SVN on a few other, previous occasions, but never really given them much of a try. And I kept hearing on the wonders of distributed revision control, and more importantly, seems like everyone is hosting a project on GitHub these days, so maybe now was the opportunity to learn something more about these, and set this up in the cloud. So that is what I - somewhat begrudgingly, I have to admit - did.

Git & GitHub
So you can just set up plain 'ol Git on your host machine, and host your own local repository, and check software and code directly in and out locally, if you wish. And if you do so, I can assure you it will be no less arcane. Typing cryptic command line commands into Git Bash will have you feeling like your Neo and it's gawddamn 1995. I kept expecting the command line cursor to suddenly start typing on its own to tell me to follow the White Rabbit.

But the GitHub site has a desktop client you can download that does a nice jot of hiding Git's squirrelly commands away from sight, and lets you set up a local repository, and keep it in sync with the remote repository at GitHub. One detail to know about GitHub, and this is an important one - the free GitHub membership only allows public projects. So unless you want to pay, your entire project will be downloadable and viewable to the public at large. I understand that if you don't want your project to be public, BitBucket provides a suitable, online repository that is private, and supports up to 5 collaborators.

So with a relatively short amount of time (a few hours, in total), I had my repository set up, and my Unity project hosted within it. I made a few small changes and tested some commits, and everything seems to be working swimmingly.

And that's that! Not only do I now have version control set up for my project, but I've made it publically available for you to download and peruse, which is in keeping with my desire to make this project more open. I'll provide a link below directly to the repository.

Next time I'll get back to work on the game itself, and hopefully the next blog you read will be about how successful or not I am with integrating multiplayer directly into the game.

Some useful links:

The Unity3D At-Home Project on GitHub
The increasingly inaccurately named Unity-Terrain project on GitHub

Introduction to Version Control
A really nice overview of version control.

Basic Git
If that's your thing.

GitHub Windows Desktop Client
Providing a nice interface between GitHub and your project

Beginner Unity Basics #20 - GitHub and Version Control
And excellent, concise tutorial for setting up your Unity Project on GitHub from Frosty Gaming. Good stuff.

Unity At Home Project
The Master Blog Page for the At Home Project