Unity3d not using true Javascript?

I have have read a lot about which programmming launguage to use when starting out with Unity - I am planning to choose javascript as I am new to programming.

That said, a programmer friend of mine, who had a tinker with Unity, said that its unity doesn’t use true javascript - I am not a progammer so I don’t know what he means.

I need to know if Unity uses specific version of javascript because I want to get a book on learning it.

Or should i just go with unity script as I am a total Noob to progamming? I just need to start small...

 

Unity uses "UnityScript" which is like Javascript, but it's not javascript.

For you? Learn C#. It's a little harder, but in return you get more power. Plus it's harder to make mistakes.

 

Thanks for that info.

What would I be missing out by going with Unity Script and not C#?

 

Lots of docs and resources. The start is easier but if you decide to be a programmer it's more limiting.

I suggest getting some unity books [or free video tuts] and just spend some time making basic stuff.

Then once your happy with the engine make the decision on what language to focus on.

I started in US [because I came straight from ActionScript] but code almost exclusively in C#.

 

I would simply say go with c#. I use js myself but thats because I'm experienced in coding and just prefer to use it. C# is almost identical (needs a bit more fluff but you wouldn't notice it much). Cos there's more resources to learn c#

 

If I go the c# route - there a special section of begginner unity scripting tuts that relate to C# programmers?

 

I dont get why everyone belives that? i remember back when i first learned unity (2009 aparently) and the best resorce was the TornadoTwins tutorials and they only scripted in unity script, and all the general assets are unity script arnt they?

 

But in C# there is the MSDN, and an insurmountable amount of learn C# resources across the web.
While they will not always unity specific they can cover a more varied range of subjects.

 

Exactly.

I won't go into detail, but I needed a very specific data-structure. I found a beautiful example done in C#, that comprised of thousands of LOC.

Imagine trying to build the same structure from scrap in US!

With US you are limited to unity, with C# you have an entire world of resources to use - It's the difference between scripting and programming.

Not to say you can't do most or all of the same in US - it's just harder.

 

They are both equally programming. You can generally use C# functions in Unityscript, so rewriting existing code wouldn't be an issue. @steam_bucky: Unityscript is written specifically for Unity, so many things that you encounter frequently are simpler and more direct. I use Unityscript in preference to C# when I can, though there are some more advanced cases where Unityscript isn't feasible. Generally, go with what seems more comfortable to you. If you get into it, learn both; they're more similar than different. While Unityscript is called Javascript for marketing reasons apparently, it's a different language and web Javascript books won't help much.

--Eric

 

I would argue that in practice you'll find that one is used as one would a scripting language, while the other as a programming language scripting. At least based on what I've seen in the forums. I could be biased.

 

Guys, maybe I should have added I am a Mac user. From what I have read C# is windows thing? I guess I go the Unity Script route?

 

No, C# is just a language and has nothing to do with Windows or Macs.

--Eric

 

Um, don't forget there is the *entire internet* which is full of C# resources, as opposed to only unity having unity js resources. I just shipped a game which only uses unity js, so my statement leans towards factual, rather than personal preference.

 

UntiyScript is closer to ActionScript than Web Javascript, and ActionScript is basically a lite version of C#/Java.

Honestly, it doesn't make that much different, it's like the Mac/PC preference, we could argue fine details all day but both get the job done.

When I started using Unity I used UnityScript as I was an Actionscript/Flash programmer before that, and a Lingo programmer before that */hi-fives the fellow director castoffs in the room*/ but have since switched to using C# which is closer to what I started programming with, pure Java. At the end of the day they're called "different languages" but really it's more like "different accents". I reckon UnityScript has a kind of Northern Irish brashness to it, C# is more or a reserved Anglo-German feel, textured but a wee bit stuffy - Lingo would have to be balls-to-the-wall Aussie cockney all the way.

Or you could always use Boo. He's like the crazy Indian dude in the corner no one can understand but you just know he's a freakin genius.

 

I tried learning both, and found learning C# to be a much better experience.

Plus you can take that knowledge to other engines in the future more easily...

 

Does US run WCF/ASP.NET, Console apps or Win Forms? What about Photon and Player.IO?

I do agree it gets a job done. But if one wants to take programming seriously to deny oneself entire other ecosystems for a few trivialities such as not having to declare your class....

Nothing wrong with 'scripting' - that is to say knowing just enough to manipulate Unity - but I personally like the ability to relegate it to nothing more than a fancy GUI and some helpful libraries. [No jokes, I integrated an entirely separate C# physics engine in just for laughs].

 

If I go the c# route on the Mac, is there any specific sites or books for the noob you advocate?

 

You don't use things like Win Forms in Unity.

That's fairly absurd. It's not like learning Unityscript means it's burned into your brain as the only language you can ever learn. Nothing will ever stop you using C# elsewhere if you need to (or in the same Unity project, for that matter). But when you're programming thousands of lines of game code, those "few trivialities" add up to a lot. Enough with the snooty language nazism please.

--Eric

 

Out of curiosity, is this (http://en.wikipedia.org/wiki/JScript_.NET) what US is built off of?

 

True, but you can certainly use it and the others I mentioned to help make Unity Games.

True, I learnt it first

Hehehe, Okay I'll stop poking sticks. Though I would point out I do love languages, I've experimented with VB, C#, JS, AS, US, XML, HTML, CSS, Erlang, Lingo, SQL etc.

If you don't use windows you can't use Visual studio or WinForms IIRC.

So I'd pick tutorials that focus on console applications and .NET 3.5 or earlier. Though do double check - as that's off the top of my head and I'm not putting $ on the accuracy of it. Google might be able to help.

 

Many of those such as XML, HTML, etc. are not languages, they are just markup. [/definition nazi]

--Eric

 

Shh... I stuck them in the middle to make the list look longer!

 

so basically you cant use .NET classes in US, e.g you don't like Unity's Player Prefs and you want to save by writing a file, you can use C#'s SystemIO.file and write your own save file, in US this isn't an option. but everything you need is usually built in to Unity(Player Pref, GUI, etc). C# just give's another option. i personally learnt C# by Burzerg's hack Slash tutorial, not the best option, YouTube has 100's of C# tutorials/lessons. MSDN and sometimes the Unity docs is a good place to refer to C#.

 

No, that's perfectly doable in US. They both have access to the same .NET [or more accurately mono] libraries within Unity.

 

System.IO.File is not C#, it's a .NET class. All of the .NET classes (implemented by Mono in Unity anyway) can be used by all 3 languages equally.

--Eric

 

My suggestion: First learn basics of C# and programming in general before ever doing a single line in Unity3D. Once you got a basic understanding and could write some smaller apps, you should come back and try to make a game.

Trying to learn make anything in Unity3D without ANY programming experience at all is just plain wrong and you're doomed to fail or have horribly ugly looking (and maintainable) code. There are just too many people around here and on Unity Answers who just ask the most basic things about programming and honestly, most of the people here are not to teach you how to do the most basic programming (there are enough resources on the internet for this) but to help you with Unity3D specific problems.

For someone who doesn't know a single thing about programming, there is much more C# stuff to find around to start with it than UnityScript. You can't really apply many of the JavaScript tutorials to UnityScript, simply because JavaScript UnityScript have little in common other than the syntax and even this one is quite different.

Many people also say Visual Basic is easy, but actually it's much harder when it comes to syntax, the code is harder to read and most of the stuff that's done easy in C# is comparably hard in VB (That's coming from someone who did Basic, C++, Pascal and VB before C# was released). It's by far the easiest language for programming.

 

I'd call you out on that.

VB has much easier to read code for beginners than C#.

Parentheses are ugly messy things that a lot of counting to what would otherwise be simple code.

Once you get used to programming, and the parenthesis they make life beautiful and clean [well sometimes anyway], but as a beginner they are the devils own spawn.

 

My suggestion is the pure opposite. When you`ve never programmed before then grab UnityScript, grab Unity, and start to develop. To actually try to develop something is the fastes and most efficient way to learn. You have chosen Unity to have an easier and faster workflow, and to make games. So why leave it and work with a C# ide for months first, producing non game content that you don`t really want and need?

Inside Unity you can do the same things with US and C#. The result runs at the same speed too. So the choice is more a thing of flavour, you miss nothing, no language is really "better" than the other. The point is, it makes no sense to learn US when you already know C#. That`s why C# in Unity exists. Not because it is any better. In Unity Unity Script is a bit better documented than C# though, it is much easier to understand for non programmers, and most thing can be easier and shorter written than in C#.

 

@Tiles:
Because that what many newbies try to do and horribly fail. Instead of learning how to program, they make broken code, post it on Unity Answers or here and as others to fix them and some of them are beyond of the realm of being "fixed" without a complete rewrite.

It's just impossible to write good and stable code if you have NO experience at all. You may get simple things like moving a character or rotating but once things get more complex, then code done by a complete newbie to programming will become unmaintainable. That's a fact. Whoever writes his first 2-3 Apps will find dozen of design flaws, errors and mistakes in them which at one point makes it impossible to extend this piece of code without scrapping everything and starting from scratch.

This will become very frustrating to everyone who newly starts with Unity3D and has NO PROGRAMMING experience at all and then they'd just give up. In order to write good, stable and maintainable code you just need months or years of programming experience (depending how good of a learner you are). Only then people should start writing stuff which they plan on to publish.

Just throw out a look at answers and you'll see that there are people who don't even know the most basic stuff about programming, like handling of member and local variables (in fact, a huge part of them can't even use/read the documentation...). I'm sorry to say, but this people just shouldn't touch Unity3d programming until they got the basics of programming and OOP. To many people just assume that everyone can do games in Unity, which is plain wrong. Even though Unity3D makes it like 100 times easier to develop a game, you still need a GOOD understanding of programming and software development to get anything half looking good with Unity3D.

Don't wont to destroy the bubble of all that new people who think they can make a good game with Unity without any programming knowledge, but that's how the reality looks like. Telling them to start straight of learn programming AND learn unity it's 3D stuff, is like telling someone to migrate to the USA and start as dishwasher and they eventually may become millionaire. While technically possible, it's highly unlikely, especially in times like we have it now.

 

Just learn C#. It's a first-class, real language used by millions of people. It has a standard, and there are literally millions of pages on the internet where you can learn, and many multi-millions of developers that are solving problems and posting their experience every day. Yes, you may need to occasionally type an extra line of code here or there, but in the end you have more control over what is happening and that can be helpful on larger projects.

 

And you think they don`t fail a the harder solution when they already fail at the easier solution? Please. The only difference would be that they post their broken code at a C# forum then instead

To learn a language you have to use a language. This is true for real life, and this is also true for programming languages. You will of course talk nonsense in the beginning. But that is where every learning begins.

 

No, if they start by learning the basics and OOP the chances to fail are much lower. When you make smaller Apps or just test/improve your understanding you don't write stuff you gonna release on other people.

But if you have a half done game with crappy code, the only viable solution is to scrap it and start over, which has a high frustration factor. However, if you start programming and notice that you already suck with the "basics" you can quit early enough without wasting months of trying to get a working game with copy paste code from 1000 different sources. Not everyone has ability to be a programmer, if they would the programmer profession would be obsolete.

And just giving newbies a false hope that they could accomplish something noteworthy is just plain wrong. There is a chance that a complete beginner to programming could get something good and halfway clean and working code, but the chances are very low and they will just waste their time. And that's true for all professions. You can't become good at Marketing just by trying, you need to learn the basics first. You can't become become a bank director without trial and error, without having a degree in economics.

It's like people who use jQuery and think they can do JavaScript. Hilarious.

 

And you think a MMO kid is going to build SMALL apps in C#?

Also in Unity you have to start with the basics first when you are a rookie. You can do smaller apps in Unity too. And you have in fact to start with small stuff and the basics, no matter if you use Unity and its Javascript, or C# inside or outside Unity.

The learning process itself has absolutely nothing to do with the environment. You will do the nearly same amount of errors. You need to restart a crappy C# app from scratch too. You will find yourself trapped in rewrites. And you will of course also first try to grab your mentioned 1000 different sources to try to achieve what you want. That`s simply part of the learning process. The difference is that with C# and outside Unity the frustration factor is ten times higher. Because you learn boring and dry stuff that doesn`t even point in your needed direction, and which you will most probably never ever need in your game. And that`s wasted time and energy.

To stay with your analogy, you don`t need to learn to be a factory president to become a bank director.

As told, in Unity you can do the exact same things with Javascript and with C#, with the exact same results. You can learn the language in Unity too, no matter if C# or Javascript. And when you want to make a game in Unity only then there is no need to learn outside of Unity really.

 

As said, people who fail at basic programming will also fail at Unity3D, which is basically new people who "dream" on easy making games.

People who are serious, first start with the basic (or actually already know the basic) before they even think on getting a serious game done.

 

Except for create anonymous delegates, or use LINQ, or use Events, or +=/-= delegate syntax, or (at least didn't work in 3.0) assign a char via single quotes. Or use a proper IDE (Visual Studio/MonoDevelop) with Intellisense/DocFood/Code Completion and integrate Doxygen documentation seamlessly(as a Unity editor menu button), or receive help from anyone not using Unity.

And on this point I couldn't agree less. That sort of introspective focus is only going to get you stuck. If Unity doesn't provide an AI solution, you need to look externally. If you want a shader that's not built-in, you need to start learning how to make proper shaders, most commonly externally (the number/quality of CG tutorials compared to Unity shader syntax tutorials is pretty drastic). Any time you want to grow, or create something that is not just a rehash of an existing Unity game, you need to look elsewhere, and being able to broaden your available sources (many people on here seem to think JS can't use the standard .NET libraries, and completely ignore the MSDN) you are shooting yourself in the foot, and closing doors.

You can learn using only a proprietary language in a singular engine, but being able to utilize more resources, more tools, and have more capabilties, is nothing to scoff at, and being able to go anywhere online for your programming assistance/learning compared to being jammed onto the Unify wiki and Unity Community can make a huge difference in actually learning programming and not just trying and failing with little help.

EDIT
To shorten, the more resources, the more available assistance, the more tools, the more tutorials, the more likely you are to succeed. And while you can make do with less, you end up having to do more to break even.

 

I love how everyone is saying the opposite of everyone else. The takeaway here is: don't listen to anyone, they are all wrong (including me).

There's actually a reason for that.

Code (csharp):

1. var someString = '"Well," he said, "here we go again."';

vs.

Code (csharp):

1. var someString = "\"Well,\" he said, \"here we go again.\"";

Which one is easier to read? Of course, the tradeoff is:

Code (csharp):

1. var someChar = "X"[0];

vs.

Code (csharp):

1. var someChar = 'X';

Overall I'd rather have the single quotes for chars and deal with escaping double quotes in strings, but I can't deny there have been occasions when not having to escape quotes is quite nice. So as usual it's not a black and white issue.

--Eric

 

Wait, are you saying that JS uses single quotes for strings?
Granted, I never use it, only read others, but I coulda sworn it was:

Code (csharp):

1.  
2. var someString = "This is a String";
3.  

I figured out the char literal trying to provide an example for someone, but I'm now curious the JS difference between ' and ".

Also for the char example if you need chars in any sort of tight loop that could hurt. You'd need to A) create a string (~20 bytes + 2 bytes per char) which will require garbage collection, and then copy out a single char for use.

Although this one I could just get upset about it because I'm used to C-C++-C# where I feel some syntax should just be consistent.

 

I'd go for

Code (csharp):

1.  
2. var someString = @"""Well, "" he said, ""here we go again.""";
3.  

It's slightly less readable than single quoted, but more readable than \". Notice the @ in front of it for literal strings.

Also, if you do

Code (csharp):

1.  
2. var someString = @"This is the first line
3. And this the second";
4.  
5. Console.WriteLine(someString);
6.  

then it would output

Code (csharp):

1.  
2. This is the first line
3. And this the second
4.  

Or if you use path, usually you have to add "\n" for line breaks or

Code (csharp):

1.  
2. var someString  = "This is line one\n"+
3.     "And this the second.";
4.  

while with C# literal strings (@ in front of the " "), you don't have to.

http://msdn.microsoft.com/en-us/library/Aa691090

Also makes pathes much more readable.

Thanks for reading

 

@Tseng: Fair enough.

You can use either single or double, but if you use single quotes, then you don't have to escape double quotes.

--Eric

 

But then you'd still need to escape single quotes, not really solving the problem, just shifting it around a bit; I'm agreeing with Tseng, and even if there's a reason, the current C# method is much easier to understand/keep consistent. At least I'll now recognize it when I see it, and that there is a method behind the madness(even if I don't agree with it).

I feel that if you own the language and can choose the syntax/standard you should at least match current standards as far as readability/usability, otherwise your both harder to use and less well documented.

 

Wow - I went to bed and woke up to all these posts. Thanks guys for your opinions, they are apprciated. After reading them, I am going a slightly different route.

I am just going to get this book:

http://www.packtpub.com/unity-3-x-game-development-essentials-with-c-and-javascript-will-goldstone/book

Go through the tuts, and then decide what route of scripting or coding to take. Or do the book and come back with more intelligent questions. I only want to do very simple stuff to begin with. I don't expect to use this book and think I be able to to do multiplayer skyrim. Just need to some exposure to Unity3D.

Thanks for your time.

 

Ah, another language thread where the C# users tell us how theirs is the one true language, and every other language is for rank amateurs.

Fact is, a lot of experienced coders want a clear, easy to read, wrist friendly syntax with automatic type interference.

Guido van Rossum, the creator of Python, is one such individual. Another is Rodrigo B. De Oliveira, the creator of Boo. Oh, and of Unity Script.

One of the great things about Unity is we have a choice of languages. I recommend you use the language you most enjoy. If you happen to enjoy using a language that requires you to type 30% more code and is missing much of the "syntactic sugar" of the alternatives, be my guest.

But the rest of us will enjoy using Unity Script and Boo.

 

This might be a slightly different take on the question, but here's one thing to ask yourself when you're deciding which language to learn : "Will this language be around in 5 years?" and "Where else will this language ever be used?"

UnityScript is really a unity-only skill. It may transfer somewhat to Flash and AS3 because they are both derived in ways from ECMA4, but no other language uses ECMA4 as a base, and none ever will at this point. We can see that the future for Flash is grim now, so there's no reason to believe you'll gain any "outside use" from choosing UnityScript, which means that the future of the language rests entirely on the success of Unity as a platform.

Conversely C# is used widely, in many more places, and for many other purposes than just Unity. If you know C# and Unity dies in a fire much like is happening with Flash right now, you at least have some other options with where you can deploy the skill.

 

Interesting question, since JScript and ECMAScript (the two languages most similar to UnityScript) have both been around longer than C#.

If your end goal is to work for someone else, I might recommend C#, as most of the big game companies are using it or C++.

Then again, UnityScript is still a C style language, and it wouldn't be too difficult to make the leap from it to something else.

 

I just can't see how that argument is relevant. If people were only capable of learning one language, it would be an issue, but they're not, so it's not. I really don't care even a little bit if Unityscript is only limited to Unity. I makes me more productive there, so worrying about transferring it elsewhere is a total non-issue. I'll just use other languages for other things (and I do--I certainly don't use Unityscript for website programming). Also Unityscript and C# aren't so different that learning both takes that much time.

But hey, as long as there are C# tips in this topic , here's a question. In US I do this:

Code (csharp):

1. import UnityEngine.GUILayout;
2.  
3. function OnGUI () {
4.     Label("Yay");
5.     if (Button("Click!", Width(100))) {}
6. }

In C#, having to write

Code (csharp):

1. void OnGUI () {
2.     GUILayout.Label("Yay");
3.     if (GUILayout.Button("Click!", GUILayout.Width(100))) {}
4. }

is really starting to annoy me. This:

Code (csharp):

1. using UnityEngine.GUILayout;

Fail. So: how? (If only I could declare ref variables in US functions, I'd ditch C# for this particular script....)

--Eric

 

I strongly push C#, but I do so towards new users.

If you are an experienced coder, then using whatever feels natural makes sense.

However if you are new to programming I push C# for the reasons iterated before(orders of magnitude more resources for learning/getting help). as well as I feel that the implicitness can get in the way of actually learning and understanding programming.

For example:
Having the class created around the file with implicit MonoBehaviour inheritance. Oh nice, I don't have to type: public class Yadayada : public MonoBehaviour. But at the same time, I see many, many users equating 1 file to 1 class, and not understanding that Destroy() and Instantiate are class functions, and not just some general global functionality. That not all objects have .transform, or .enabled, and that in fact most classes wouldn't have any concept of that. When you go from entry level JS programmer to experienced programmer you require a large leap of logic, because there is no explicit syntax explaining what you had in the first place. There is nothing there to question whether or not each file has to contain 1 and only 1 type of object.

The same goes with var.

Code (csharp):

1.  
2. var A = 1;
3. var B = 2;
4. var C = Vector2(1, 2);
5. //A / B != C.x / C.y
6.  

Without typing out float or int, You're not going to think to ask what is a float and what is an int, and how do they work.

Sure, once you know the basics it's who cares, use what gets the job done, you may still be shooting yourself in the foot with regards to missing behaviours in JS (I listed a bunch earlier in this thread), but you'll probably get by. But it's the new users that are going to want a more explicit language so that as they learn they can see the results of what they type, because they actually typed it and it's not done behind the scenes.

As to Eric5H5, you are correct in that using in C# only works for namespaces, which particularly in the case of GUI, can get quite obnoxious. One thing you can do is use a using alias

Code (csharp):

1.  
2. using UnityEngine.GUILayout = G;
3.  
4. void OnGUI () {
5.     G.Label("Yay");
6.     if (G.Button("Click!", G.Width(100))) {}
7. }
8.  

You still need a name, but you can at least modify them. These also work with Generics which can make things a bit more readable as well.

One area as well that I see people say that JS has a strong advantage is the amount of code to write, but I've not seen a strong Intellisense/DocFood/Code Completion set of tools that work with JS, and I would argue any time saved on syntax would be quickly lost with a lack of Intellisense/Code Completion.

 

My orginal question was does Unity use true Javascript ( the answer was no ) - but why do the creators promote java script working with Unity when its actually Unity Script?

 

And again, UnityScript isn't really that close to JavaScript or JScript. It's most similar to AS3, which is based on ECMA4... the version that died in committee. US isn't particularly transferrable to a world without the UnityAPI. It surely won't teach you JQuery, which arguably is more useful than bare JS itself for most purposes.

Or if your goal is to leverage other people's code, who may not have written their code in UnityScript for Unity. The world is not so black and white as "C# is for employees, US is for Entrepreneurs" as you seem to be saying.

It shouldn't in theory, but again, it's about investing one's time... which ultimately is the most valuable commodity one has. Why make things harder on yourself by learning and getting accustomed to an oddball language that is used in one small niche? If you love that language and you know the risks, and you're comfortable with the risk/reward tradeoff, then feel free to persue it. I'm just advocating going in with your eyes open to the wider world.

 

Hmm...if I have to use a name, I'd rather use GUILayout for consistency. Oh well, thanks anyway. It's official, C# and US both suck, I'm switching to Boo. As far as code completion goes, at least for me, it's far more about reading it than writing it. It's easier for me to find bugs with simple clear code, rather than wading through extraneous syntax. Once I get a ways into a project, I spend more time re-reading existing code than writing new code.

Because if you spend a lot of your time in that niche, it far more than pays back the small amount of extra learning time. If you only use Unity occasionally on the weekends or something, it makes sense to stick with what you use at work. Anyway, flexibility is good. I did actually learn Boo a while ago, but some things about it that seemed good at first ended up kind of bugging me in practice, so I didn't really pursue it.

--Eric