Lucas Meijer

Mono is the software that powers the scripting functionality in Unity3D.

Why this is so exciting? Mono is a free, open source implementation of:

• A C# compiler
• A .NET CIL Virtual Machine
• The .NET class libraries.

Why is that so exciting?

C# is a great language. I think it has a great mix of flexibility, static typing and managing my memory.

C# compiles into CIL (often referred to as MSIL).  This is a relatively low level bytecode.  This bytecode does not run directly on your processor. You need a .NET VirtualMachine that will JustInTimeCompile your bytecode to native code for your processor. Microsoft naturally comes with its own VM, and Mono also provides one.  Unity3D embeds Mono’s VM (with a surprisingly low footprint).  Mono’s bytecode is the same as Microsoft’s.  So you can run code compiled by Microsoft’s c# compiler with the Mono VM, and you can run c# code compiled with Mono’s c# compiler on Microsoft’s VM.

When you create a c# script in Unity, Unity calls Mono’s c# compiler behind the scenes, and will receive a .dll file containing the CIL code of your script. This is what actually goes into your webplayer / standalone build.

There is actually nothing in the VM that says the CIL bytecode has to be created by compiling a C# ascii file.  you could handwrite it, or do whatever you want.  Or you could use one of the other many languages that compile to CIL bytecode. (IronPython, IronRuby, Boo, Visual Basic, F#, and many more).

The folks at Unity wanted to make sure there was also a language that was really easy to get started with, and looks very familiar to what people know. They had the creator of Boo (a python for .net implementation), create a “mangled version of boo” that looks and feels just like JavaScript.  Pretty good call if you ask me, c# can be quite verbose if all you want to do is move a box around. Unfortunately they named the language JavaScript, which is in my opinion very silly, since it only looks like JavaScript, but as soon as you do anything serious you notice that it’s not “really” like javascript, but just looks like it.  That wouldn’t be a problem at all, weren’t it for the fact that it has this big sticker “JavaScript” on it. IMHO, it should just be called UnityScript, and everything would be clear for everybody.

Anyway, back on topic.

“Virtual Machine” might sound like “oh that’s going to be slow” to some people. The dot net VM (both microsofts and Mono’s) is really fast.  (todo add some benchmarks. until that time, you can look at this)

Okay, so the .net VM is cool and all that, but why choose C# as the language to create this CIL bytecode with?

50% of the reason for that is that I like the language itself. (more on that later)

the other 50% is that C# has a great ecosystem of supporting tools around it:

• Visual Studio C# is the best IDE I have ever worked with. It’s intellisense is stellar. It’s double great if you’re learning a certain api, and you don’t want to look in the help to check if this method was called GetComponentsInChilderen,   or GetComponentsFromChildren.  You just write GetC, and you get a dropdown with all available methods starting with GetC. When you select one (or just continue typing), it will show you what arguments that method expects and in what order. And the documentation of each argument as you’re typing that one.

• Visual Studio C#’s refactoring tools are awesome. Rightclick a class, or some field, and say Refactor->Rename.  You can enter a new name, and the IDE will do a “language aware” replacement of the name.  That is so much better than a search & replace, it’s no longer funny.  It also very nicely displays a preview of what it’s about to rename. I never look at the preview anymore, it has always been 100% right for me.  (VIsual Studio C# Express is free, and is more than adequate for unity3d development)

• NUnit A Unit testing framework.
• MBUnit Another unit testing framework, adding data driven test support.
• NCover A tool that gives you an idea of how much of your code is covered by tests. Dangerous when used incorrectly,  useful if you’re wondering if you’re missing some codepaths in your tests.
• Moq A mocking framework that makes it easier to test units of your code in isolation.
• Gendarme.  A tool by the Mono folks that analyzes your compiled c# code, and tells you in 200 different ways how much you suck, and that you shouldn’t have done this like that, but like this instead.
• StackOverflow.com A website filled with people asking and answering questions about c#.  Some might say it’s silly to list this as a tool, but it’s very valuable.  How can a window on your screen where you write a question, and out comes an answer not be a very valuable tool for a language? (I know stackoverflow is language agnostic, so this argument goes for any widely used language.)

Some additional tools that I don’t use yet, but think are extremely interesting:

• Code Contracts A way to explicitize things your code expects, and things it promises.
• PEX A tool that analyzes your code, and (among other things) finds possible inputs for your unit tests that you have not covered yet.  It also does things like “right click on a line to have it analyze under what circumstances execution would ever arrive at this line”
• NInject “Lighting fast dependency injection for .net” There are still some Mono compatibilities here preventing my usage of it, but I can’t wait to achieve better decoupling and easier testing in my codebase.

As more tools evolve, and I discover more already existing tools this list will undoubtedly grow.  Compare this list with a similar list for your proprietary scripting language of choice. say lingo. or torquescript.  The amount of “scaffolding” for the language, created by other people, is just an enormous upside for languages that are used by many.

Both Microsoft and Mono provide an implementation of the “.net class libraries”. These are a very complete set of libraries that let you do a lot of stuff. (Cryptography, check. Sockets, check. XML parsing/writing, check. Serialization, check. HTTP, check, the list just goes on and on and on).

Then there is the C# language itself. You’d almost forget about it in between all tool and library goodies.

I’m a big fan of statically typed code. It might be a bit more typing, but I think the compiler just telling me that I have a bug at this and that line number, is a pretty cool feature, instead of me having to take a specific action at runtime in order to find out I have a bug.  That’s quite a bit of an exaggeration, since it’s perfectly possible to write statically typed code that explodes at runtime, but certainly being statically typed does rule out a certain class of bugs at a much earlier time. It also enables the refactoring->rename feature mentioned above. I like c# a lot over c++, c++ has just too much typing, and too much worrying about too much stuff for the types of code I write. (not extremely low level code), and let’s not get started about humanly readable compiler error messages.  I’d love to see python style slicing support added to c# ( myList[4:6], or myList[-7:-2] etc ),  but overall I’m very happy with the rich featureset I can use.

Unfortunately not every C# feature you will find in Unity.  Normally the process goes like this: Microsoft adds something to the C# language. Then Mono has to follow suit, and also support that in their compiler (and sometimes VM).  Then Unity needs to upgrade the version of Mono they embed.  All those three steps take nonzero time.

The good news is that a lot of very cool C# features are actually now stuck at the last step. They’re already in Mono, and we only need to wait for the Unity folks to make a release with that new version of Mono.  Understandably they don’t like to update Mono all the time, because it could break things, and it requires a lot of QA to make sure everything still works..   If you can skip a version of Mono from time to time, you can skip quite some QA time.

At this time, Microsoft’s most recent release is .net 3.5.  Mono’s is at 2.0 (it branched for its 2.2 release a few days ago), and Unity2.1 carries Mono 1.9.1 in it.  There is no direct mapping between Microsoft’s c# version numbers, and the version number of Mono supporting that version of c#.  It usually takes a little bit of googling to find out in what Mono release what c# feature got added.

Features that are in Mono but not yet in Unity are:

• Type Inference.
  Your wrists will thank you. instead of writing:

  List<BadAssDudeWithChainsaw> mylist = new List<BadAssDudeWithChainsaw>();

  you can write:

  var mylist = new List<BadAssDudeWithChainsaw>();

  Note that the variable mylist is still statically typed, and has the same type as before.  You’re basically just telling the compiler: Okay, I’m going to make a variable here, and I want you to use the type of the thing I’m about to stuff into it, instead of me having to type out the name yet again.

• Extension Methods.
  These let you add methods to classes outside of that class. Handy for when you don’t have the sourcecode for the class you’d like to attach a few methods to.
• LINQ.
  Linq is basically a bit higher level way to deal with collections that looks a lot like sql. I like it a lot, but covering its pros and cons here would be outside of the scope of what I want to talk about . Follow the link if you’d like to find out more.

If you feel like being a cowboy, you can already get type inference working in Unity now, by “hacking in” your own Mono. Rename Unity’s Mono directory, and symlink it to your own downloaded more recent Mono. This only works because type inference is only a c# language feature. It’s just a more sexy way to generate the same bytecode.  The other two features actually require a newer Mono VM to be available for playback. Since we cannot control the version of Mono in people’s unity webplayers, you’ll have to wait with extension methods and linq until the unity folks upgrade the version of Mono they’re embedding.

A few weeks ago Microsoft announced some new features they’re going to put in C# 4.0. I won’t go to deep into these, since it will be quite some time until they’re usable in Unity, but the shortlist is co and contravariance, a new (static) type called dynamic, which should make interoperability with dynamic languages easier on the wrists and optional and named parameters.  All very welcome additions.

I think it has been a very smart move from the unity team to embed Mono. It basically means they have a team of 30ish programmers at Novell (Novell is the ‘parent’ company of Mono, being the company that puts a lot of money in its continued development) working on improving their scripting support.  The only thing they have to do is update their Mono version from time to time, which although maybe a bit painful from time to time, beats the hell out of maintaining and improving your own proprietary scripting language.

The current big gaping hole in Unity’s scripting department is the lack of a debugger. This is really big, and fortunately the unity team knows it. Mono has recently gotten a command line debugger. The Mono team is hard at work integrating that debugger with the MonoDevelop IDE.  There is also an effort underway to hook up the Visual Studio Debugger frontend to the Mono debugger.  Now that sounds like music to my ears.  There’s probably still some work to do here though.  The Mono team is accepting signups for the alpha of the visualstudio debugger support, but it hasn’t started yet. When that works, it also needs to work for embedded Mono, (Mono usually runs as a standalone VM. Unity actually “embeds” it, which is a less common usecase).  When that works the Unity folks will have to put it in.  (I’m not that worried about the last part, from my talks with them a debugger is very high on their list of stuff they realize they need to add).

All in all, the scripting situation for Unity looks very good, especially when looking into the future where a debugger would be available. I can’t wait untill that day is upon us

Bye, Lucas