Is BOO mature enough to be used as an alternative to other scripting languages? Is there a definitive resource to learning BOO? Book?
So, i am assuming that I can choose from java-script, BOO or C# as my scripting language of choice, correct? So, all three options are EQUALLY suitable and powerful?
Thanks. Need to know before making a commitment to the program/app.
I’m going with Javascript because I have been using it for the last two years, and know it inside and out.
I was thinking of going with C#, but I didn’t want to learn a new programming language along with a new Engine, so I figured I would stick with Javascript and then move to C# later (just for fun).
I have never even looked at Boo code, so it would be my last choice.
Go with whatever you know most or are familiar with. Unity compiles it all anyway, so they are all equally as fast, as far as I know.
Another point to make, don’t discard script just because it isn’t in the language you like. With Unity, scripts are objects, just like a mesh, or a sound. Build up a library of them to use when you need to. They are very reusable (if made right). Most of my scripts are Javascript, but I have a few C# scripts thrown in there which were made from other people, but I know what it does, so I can use them without needing to know how to write C#.
The last engine I used, used Javascript as their main scripting language, I have never used it for web based stuff.
I also know Java and have been taking c++ tutorials, so I know OOP pretty well. The whole pointer thing in c++ threw me for a loop, but I understand it now.
I actually REALLY like Unitys Javascript. It is very cool to have a sort of OOP Javascript. There are of course some changes which I have had to adjust to. Unitys script is not so forgiving and loosey goosey as regular Javascript.
JS only has simplification to hide the real ongoing things from users (autocasting, dynamic typing and worst: hiding away properties)
Its already interesting how many problems users have with multi-dim arrays in JS …
I mean especially when put in relation to C# only things like properties or the possibility to extend a class and additionally implement interfaces and other things.
Dynamic typing isn’t just a simplification, it’s quite useful in some cases. Duck typing (see this), type inference (can’t use in C# in Unity until its Mono version is upgraded), use of eval().
I think it’s been covered but Unity uses mono (.net) for its scripting. Mono allowed different languages to run on top and Unity supports three of them (JS, C# and Boo). Once byte-compiled, they run the same.
Thee main differences will be at the programmer layer which comes down to programmer choice.
After having grown up with C and C++ for the past 15 years, my new goal is to save my fingers and not use a language that requires semi colons or any extra syntax. So until Ruby is supported by Unity, I’ll be using Boo
(BTW, for people familiar with Python, Boo is a pretty nice language and a nice mashup of Python’s syntax on top of Mono. I always smile at Boo when I see the sample C# code take tons of extra typing to do the same thing.)
ive been always a C# person , but i found unity javascript to be much simpler to do the same thing, less declarations less typing and casting, it feels more simple and casual
i tried to do some things in C# which ends in problems,errors or simply take too much extra code for such a simple thing in javascript
only getting used to the syntax differences take some time but its quick task
i havent tried BOO i dont even know how it looks like and as also most of the examples are either in javascript or C# , but mainly in javascript… i think i will stay with javascript 8)
Not to be pedantic, but Javascript has nothing to do with the Java language. It was once called ECMA script and then renamed “Javascript” by Netscape as a marketing ploy. Knowing either Java or C++ is not going to be specifically beneficial to working in Unity Javascript. Should you chose Mono C# instead, you will find that Microsoft “borrowed” extensively from Java when creating the language, but read on before deciding. You should also not that Unity Javascript (aka Unityscript) is based on Microsoft’s JScript and differs from the ECMA specification in some cases. Also, the Unity compiler disallows programming constructs in Unity Javascript that are allowed in both Javascript and C# (don’t ask me why).
Anyway, things I think you should consider in making your choice:
First, you should understand that your choice is largely irrelevant since the scripts you write are compiled by Unity to byte code before execution. Given that you say you have worked in Java, then you understand of the concept of languages being compiled to bytecode and then executed by a virtual machine on a target platform. In the case of Unity, your code is compiled to MISL (actually CIL) bytecode. It is unclear to me whether Unity then does JIT compiling of the bytecode to native executable object code for each deployment platform or uses a CLR virtual machine to executve the bytecode code at runtime, but given the first level compilation to bytecode of each supported programming language, your choice should not matter. (Although I have not investigated this on the Mono platform with respect to Unity Javascript, on Microsoft’s own CLR, compilation of, for example, VB vs. C# does NOT result in identical MISL. The resulting MISL is equivalent, but that which was produced by compiling VB results, in some cases, in much more verbose MISL instruction sets which makes the code perform slightly slower than that the MISL resulting from compiling C#. Even if this is the case with C# versus Javascript on Mono, I think the resulting difference in execution speed would just similarly trivial and given the number of performance killing sins you will commit in either language, I wouldn’t factor this into your decision.
There are a few things that can only be done in the supported version of Mono C#, but their utility from your perspective will likely be limited so I wouldn’t worry about them. The list may grow as Unity adopts later versions of Mono and as Mono converges on the C# “spec” being pushed by Microsoft, but you can cross that bridge when you come to it.
Unity Javascript supports sufficient OOP constructs for game scripting purposes, but it is not a fully OOP language, nor does it need to be. The encapsulation it supports should be sufficient for what you need to do. You can also effect basic polymorphism by taking advantage of duck-typing as well, but that it not recommended. Late binding is definite performance killer. You should use explicit typing everywhere you can.
I think as you are learning, you should stick with Javascript. The Unity engine has been architected to require minimal scripting to do very powerful things, all of which are possible to script via Javascript. Early on, if you find yourself needing to code things that are difficult or seemingly impossible to do in Javascript, then it is likely that you are not correctly using the Unity framework, and you should consult this forum and the documentation. Sticking with Javascript will also help “keep you on the reservation” in terms of using the Unity engine. This will help ensure that things you develop will remain compatible with the engine as it evolves. For example, you can, through C# extend classes defined in the Unity framework (at least the few cases I tried). However, it is not clear from the documentation whether specific classes as implemented in the Unity framework are meant to be final. If they are, but were not implemented as “sealed”, and you extend them, then you run the risk of your extensions being broken as those classes are further developed by the Unity development team. Unfortunately the documentation is not explicit about this.
Pay particular attention to the use of static and “instance” script variables (and as mentioned avoid late binding), especially if you programming for a CPU and/or memory constrained platform, such as the iPhone. For example, a common mistake is to continually lookup game object references in the Update or Fixed Update functions when those objects exist at game initialization. Looking them up once in the Start or Awake functions and storing them in static or instance members can be a real performance enhancer. Also, game development on garbage collected frameworks such as Unity or XNA can be challenging since you don’t have the benefit of fully deterministic memory management you have on native C or C++ based frameworks. Of course, writing less code and not having to deal with memory management directly can also be blessing, depending on your perspective.
The other thing you may miss if you chose Javascript is explicit control over argument passing. In Javascript, parameters are passed by value. When objects are passed, the copy of the object’s reference is passed and this allows you to modify its public properties (if allowed) and invoke its public members. It is not possible to pass primitive types by reference, though, so if you want to return multiple modified primitive parameters, you’ll need to wrap them in a “class” (since you have worked in Java, for example, you will have already dealt with this issue in comparison to C and C++). In C#, you do have explicit control over whether parameters, primitive and complex, are passed by value or reference, but I have not seen a scripting use case as of yet that make this a compelling need. There are some other features in C#, such as jagged arrays, that I am currently on the fence about, but, again, I haven’t run into hard use cases for the features as of yet.
Finally, with Unity I would mention that, early on, I spent 90% of my time looking at at all the great examples both here and in the documentation before starting to develop anything substantive. In learning different game dev frameworks (actually any new technology) over the years, I learned (sometimes the hard way) that there is no substitute for learning first from those that came before you. Nothing worse that struggling for hours to script something that is readily explained in one of the tutorials, or worse, that is not even necessary because it is directly supported by the engine or the physics framework.
A while back I’ve started a thread asking people to report on their background and experiences with their language of choice. This also includes a little poll to find out how popular the different languages are across the Unity forums population