In which I continue to write about my coding practices for Unity3D and where squishy objects are thrown at me to the wild jeers of the confused mob.
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.
We need to manually add the files to each new project.
We're going to need to remember which project is designed for the editor side of things and which one for the runtime side of things so we don't end up linking the wrong files (Unity doesn't like mixing the two, though I wish it did the separation in a smarter way, but, altogether now: "that's a topic for another post!").
We'll also need to go through the same process if we ever change the Unity library location.
And finally it seems like sometimes Visual Studio will set the paths to absolute and sometimes to relative which doesn't play very nice between different computers.
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.
Read more about:
BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
