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.
Tags: Articles, c#, javascript, scripting
I see your point and though for the most part it is valid, but as someone who does Unity development professionally I would not recommend using “Unityscript” at all. I think the only real benefit it has is that for all of the Flash developers moving over, they have a familiar syntax to deal with.
I used to write in the JS syntax until I hit so many brick walls in development the dev team I work with made the switch and never looked back.
And I have never found the casting to be *that* bad. I mean, sure you have to do the whole “typeof” and such, but for the trade-off it is sooo worth it. Maybe if Unityscript as you call it would mature a little and support better inheritance and a few other features it is lacking, I’d sing differently. Then again, it would lose it’s benefits of being higher level over C#…
Cheers,
-Joseph
Oh, I forgot to mention that C# just is so much more elegant in it’s syntax. No more typing var and function and then specifying return types or casting after-the-fact.
public bool _b = false;
public var _b:bool = false;
public void DoSomething(Class param){};
public function DoSomething(param:Class):void{};
I’d say C# takes the cake in that one as being less of a hassle. I’ll settle for writing a typeof and specifying an extra cast here and there because I’ll do that sort of thing *way* less than the examples I specified above…
UnityScript does support attaching properties to objects dynamically but it has to be enabled with the –expando command line option.