I’ve been reading your comments on my last post, and I felt that it was my responsabilitity to further explain my opinion on this.
Unity’s Javascript idiom is called UnityScript, and it’s exactly that, an idiom. Furthermore, it’s implementation its based on Boo (I guess that’s the reason we have boo on Unity). This has some implications:
- UnityScript is not as flexible as normal Javascript
- You cannot attach properties or methods to objects at runtime. I have found a script that does this using a Boo interface, but this not natively supported, and probably the reason is performance.
- The use of static typing (#pragma strict) is strongly recommended for performance reasons
- It’s faster to code in (less typing)
- It’s more intuitive
On the other hand, C# is the “natural” languaje of Mono, the engine behind all Unity3d scripting. It is a free implementation of the M$ .net platform.
- C# is strict by default, and that is good for game performance
- C# gives you more control over when and how casts are performed
- C# lets you create class hiercharies and won’t attach stuff to your script unless you explicitly declare your class as child of MonoBehaviour
- You have to type a looooooot
- Welcome to the casting hell
As I said, UnityScript is faster to code in, it lets you type less, it is a little more intuitive, its perfect for rapid prototyping.
On the other hand, C# is a pain. It makes you write ugly code like:
Fighter fighter = transform.Find(“/fighterMesh”).GetComponent(typeof(Fighter)) as Fighter;
But, with C# you have a lot more control over your code.
My conclusion is the same that it was on my last post. I’d recommend UnityScript for quick, small projects and C# when you need to work with more people (yes, I know a team of great coders can do great stuff in JS) or when you need to work on bigger projects where performance is a big issue (and it normally is).
Seth out.
