Building for Unity - Take 2

My previous post was a bit of a let down, I know, given that it only set the scene (see what I did there... yeah? lame...) for this post. And come to think of it the amount of stuff I want to cram into this one will probably spill into another part (hopefully the last since I really want to talk about my TransformLock component and editing systems and get some feedback on those).

Where were we?

Ah yeah, linking Unity's libraries to our Visual Studio projects so we can reference objects from the Unity engine and not break down.

The easiest way to do this is to manually add the files to the project references like this;

But alas this approach has its own difficulties; is that a trend by now or what?

Notice the example I've given above shows three projects in the solution. At the moment the game I'm working on (Buck... Kickstarter...*cough* *cough*) has 8 projects attached with another two in the making. That's a lot of clicking just to add a couple of files. But even if clicking ain't a problem and you eat games like Diablo for breakfast, there are still some issues at hand.

Phew, that's a long laundry list of stuff, the end result is having a lot of boilerplate maintainance work. In such cases we should always remember that I'm lazy. And so should you be!

So what do we do?

A customized build process. Which in turn requires writing the project files manually (before making templates), writing a couple of custom targets files and writing a batch file to set the dev environment (since I dislike adding global variables to my Windows environment).

Alright, quick disclaimer before we go at it. I'm assuming some knowledge about batch files and how to write them. Not to mention that using/customizing MSBuild is kind of like drinking from a fire hose (through your ear) and so I'm not going to explain much or at all about MSBuild's features/concepts. If any of this seems interesting, read up... And don't forget to wear your earmuffs down the rabbit hole.

With that said, let's go to it. First order of business, before we can link to the Unity libraries, we need to know where they are. And to do this we're going to create a batch file called "__setenv.bat". The double underscores means tapping tab in a console window will bring it up first for quick and easy execution. Probably should have mentioned, I work alot on a console window rather than the explorer.

@echo off
title Dev-Console
set unity4_home=e:/unity4/data/managed
set Path=%Path%;%unity4_home%

Running this batch file will set the "unity4_home" variable to our console environment (meaning we can only access it through that particular environment and not globally) and add it to the current path value. Adding it to the current path isn't that helpful to be honest but what the heck. My own version of the batch file actually does a bit more to set up my dev environment but for the purpose of this series of posts this is all we need.

Well, as usual the post is getting long and I'm going to cut it down. Next time we'll see how to actually set up the first targets file, have a glimpse at the way I structure my project's directory hierarchy and write some XML code.

"I grew up quick and I grew up mean; my fist got hard and my wits got keen, I'd roam from town to town to hide my shame."