Programming Languages and Compatibility

So, I'm looking to start developing with Unity. I've already got some experience with C# and Javascript (and a few other languages), and am wondering about their compatibility to operating systems.

I know that most people recommend C# over Javascript because of its capabilities, but if I develop my game in C# then I assume that it will only be playable in Windows. How about with Javascript, would the game be easier to make compatible on Mac OS and Linux?

Thanks.

 

Never do that. Remember that a huge number (most) Unity games are published for iOS and Android; you wouldn't think anyone would recommend C# if it only ran on Windows for some reason. That would certainly ruin Unity's "write once, publish anywhere" philosophy, and such a huge drawback would have been mentioned somewhere. Any language is compatible with any platform since they compile to the same code. Which is true of pretty much everything, not just Unity...computers don't run languages, they run machine code, which languages are compiled to. Any language ever invented will run on any platform ever invented as long as there's a compiler for it.

--Eric

 

Yep.

To add to what Eric said about iOS and Android, Unity even started out as a Mac application. If languages were tied to platforms like you assumed then it probably wouldn't have ever had C# in the first place.

Slightly different topic, but worth mentioning - the thing Unity calls "JavaScript" is not the same thing everyone else calls JavaScript. In fact, Unity veterans often call it UnityScript to help minimise confusion.

 

It is in fact much more similar to ActionScript 3 and JScript.NET.

--Eric

 

Cool, thanks for the info. But, along with what you said, are there compilers for C# for Mac/Linux users?

 

Check out a thing called "Mono". It's what Unity's scripting system uses. It's a cross-platform implementation of .NET. All of Unity's languages compile for Mono, which runs on all of Unity's target platforms. Some platforms have different underlying details, but that's something you don't have to worry about at this stage.

The info you're probably looking for is this: C# works on all of Unity's target platforms.

I think that's true of all of the built in languages, but I'm not 100% sure about Windows Store / Windows Phone and US/Boo. Can anyone confirm?

 

Why would anybody want to use Boo, anyway? It will get scrapped in Unity 5, and it deserves to.

 

Some people prefer a Python-like syntax. It's not going to be scrapped in Unity 5. If you don't want to use it, fine, but it's silly to complain about people having different preferences.

I'm pretty sure that works with US/Boo now; I know it didn't at first.

--Eric

 

Just how close is it to python's syntax? I've only ever mucked around inside of some scripts so I don't know much about it. I've assumed it's structurally similar and spiritually analogous, but that it's still pretty far from being typical python.

 

Yeah, it's not Python, but typically the syntax is pretty close...this Python:

Code (csharp):

1. a = 0
2. while a < 10:
3.     a = a + 1
4.     print a

Would work in Unity as:

Code (csharp):

1. a = 0
2. while a < 10:
3.    a = a + 1
4.    Debug.Log (a)

I've thought that maybe beginners should be required to use Boo for the first month so they're forced to learn to indent code properly.

--Eric

 

Technically speaking you don't need to worry about the scripting language you program in because they will all accomplish the same thing and they all go through Mono which is the .NET cross-platform framework implementation. When people say C# is the best to use out of the three it's mostly because it has the best support behind it.

Boo and Python are very similar in syntax, the biggest difference between the two is that Boo is statically typed while Python is dynamically typed (This is also the same difference between UnityScript and Javascript btw). Boo being statically typed makes it faster. The other major difference is Boo requires the .NET framework to run (Much like C#).

 

Boo is awesome! I never used it but I admire it from afar

 

Well, it is the language that sees the least use and therefor, most tutorials and docs completely ignore it. So I wouldn't recommend using it unless you are a hardcore Python fanboy...

 

Boo is like Vim: it's for people that have it in their DNA and the only tutorial they need is a decompiler!

(woooah admiring things from afar makes them so much more romantic)

 

I vaguely remember hearing or reading something to that effect. But when I checked the docs for the various Windows Store platforms the overview didn't list is as a difference or a requirement, which is what I'd expect.

 

Is US statically typed when not defined as strict? It's been a while but I'm sure I remember it behaving as a dynamically typed language. Or is it just the case that it uses inference?

 

I have not worked with US much but from what I know, it supports both dynamic and static typing while JS only supports dynamic.

 

That makes sense, cheers!

 

It's primarily a statically typed language. On some platforms (desktop, web) it can be dynamically typed, but using #pragma strict prevents this. (It doesn't "turn on" static typing like some people seem to think; it merely prevents the usage of dynamic typing. That is, code which is compatible with #pragma strict will always compile the same way regardless of whether #pragma strict is actually present or not.)

--Eric

 

It's not getting scrapped; it's just getting deprecated in some ways. They're just getting rid of documentation examples.

(though I agree there's no point in learning it at this point)

 

Yeah I was aware of pragma strict enforcing type definition, I had to convert a mammoth project to use #pragma strict when testing if we could do Android development with our code (turns out, no, for that project ).
I was just unsure if the 'dynamic' side was actually just static typing using type inference, but it seems not! Good to know, though I won't be using US again any time soon that's for sure, at least not of my own will!

 

Very good to know! I came across MonoGame when checking out alternatives to XNA before deciding to try Unity. At that time the site said cross-platform but the platforms were only desktop and mobile. Nothing about console support. Since I was most interested in making some very low cost PS3 game (in the home brew program thingy) I chose Unity.

If MonoGame can actually handle all of the platforms and is in fact what Unity is built on it sounds like that is just what I was looking for! Straight coding without the overhead of a GUI scene manager and so forth. Of course, now I am kind of used to it and know how to work around it so I spend minimal time in the GUI.

Ah just did a quick search. I see now Mono and MonoGame seem to be two different things. Anyway thanks for mentioning this. I need to check out this Mono.

 

Yes, compiling for different platforms is primarily up to the engine. Unity has had to make custom implementations of Mono for platforms that weren't already supported. (One reason they're interested in IL2CPP.)

--Eric

 

No, not "MonoGame". Just "Mono". XNA is a game development framework built on .NET. MonoGame is a Mono implementation of the same. Unity has nothing to do with MonoGame.

As Eric said earlier, Unity's Mono can target additional platforms to normal Mono because Unity put in the effort of providing support for them. (That's also why it's an older version than base Mono is up to. Adding and maintaining that support is a huge task.)

 

Thanks. Yeah I found that. At the bottom of my post I wrote "Ah just did a quick search. I see now Mono and MonoGame seem to be two different things. Anyway thanks for mentioning this. I need to check out this Mono."

So, it sounds like Unity is still the only thing out there that actually let's a person deploy to all of the targets including consoles. I'm slowly making the transition. When you're used to decades of just programming everything it just seems kind of inefficient to have to go through the GUI Scene Editor for everything. But it also has its benefits with being able to modify values and test quickly. I like that part. Normally I'd just code it up myself but it is nice to have it already available.

I am sure given more time I will come to appreciate it more. I had the same issue with VB6, VB.Net and C#.Net. When I saw forms being built with GUI designers I hated it. So, spent my time figuring out how to do it all in code so I could get straight to it. These days, I definitely appreciate just being able to drag n drop controls onto a form and code up the events and such.