Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
November 29, 2015
arrowPress Releases
November 29, 2015
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Building for Unity
by Amir Barak on 05/04/14 08:54:00 am   Featured Blogs

1 comments Share on Twitter Share on Facebook    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


Well there you go, my second blog post on this wonderful site. I really need to figure out an easy way to cross-post between here, my own blog and Wave's. But that's a problem for a different day. Today we tackle the different ways to write code for Unity (with a quick, oh so very quick diversion concerning MSBuild). Snorkels on and let's dive!

The really easiest way to write code for Unity (and the one most people choose I suspect, please comment if I'm wrong) is to simply create a [.cs] file somewhere in the /Assets/ folder and go to town. For extra points use Sublime Text, possibly the best text editor currently available. This is the sane version. Alas it is not without its drawbacks.

For starters and up until recently Unity did not support namespaces. I like namespaces. I really like namespaces and so should you!

The second drawback is somewhat more serious, without compiling the code ourselves we're losing a lot of compile-time error checking and are relaying on switching between the code-editing window and the Unity window (then waiting for Unity to complie, spit out the error before going back to the code-editing window, etc, etc).

The answer my friend is blowing on the wind and in this case the wind is made out of MSBuild and the Visual Studio IDE. Now, don't get me wrong, the MonoDevelop thingy that they ship with Unity is nice and all but I'm working on a Windows machine and there's no better tool for writing code on Windows then Visual Studio. So let's look at our coding process now, surely it'll be easier. Write code, complie, find dll, delete previous dll from assets folder, copy current dll to assets folder, switch to Unity, see it break, switch to IDE... go crazy, yell at top of lungs and go hug some kittens. Yeah, so not easier, huh? Why would anyone do this to themselves?

Well, beyond the fact that the next part is going to show a more streamlined process, the benefit (other than namespaces, did I mention those already?) is that I can give the designers I work with a couple of files to simply copy into their asset folders and I don't have to worry about anyone seeing/messing around with code.

So how do we streamline the process?

Also, how many of you reading this have spotted the single biggest caveat in the mentioned process? Yes? No? Anyone? Well, writing code then compiling is completely and utterly impossible unless we link our projects against Unity's own [.dll] files. 

Alright, I'm going to stop here actually. This post has grown a bit longer than I expected and given that I don't like long posts and I also actually have to write code, I'm breaking it into two. All that's left here is a short summary of todo items for the next part.

  • Easily link against the correct Unity libraries.
  • Separate between Editor and Runtime projects.
  • Automatically generate libraries into correct folder/s.
  • Make it easy to add new projects to the build.

Ok, that's it for now and as usual come check out our cool Kickstarter!

But she never escaped my mind and I just grew; Tangled up in blue.

Related Jobs

Vicarious Visions / Activision
Vicarious Visions / Activision — Albany, New York, United States

Online Multiplayer Gameplay Engineer
3BLACKDOT — Los Angeles, California, United States

Contract Game Engineer
Red 5 Studios
Red 5 Studios — Irvine, California, United States

Senior Gameplay Programmer
Cignition — Palo Alto, California, United States

Gameplay Programmer

Loading Comments

loader image