Search Unity

It’s been with us since Unity 1.0, but its time is finally coming: we have begun the deprecation process for UnityScript, the JavaScript-like scripting language available as an alternative to C# in Unity today.

In this blog post, we’ll go into the details behind the decision, but to briefly summarise: continued support for UnityScript is obstructing our ability to deliver new scripting-related features, and only about 3.6% of projects are using it heavily.

Why deprecate it?

Every time we remove something from Unity, we assume there are always some users that it’s going to inconvenience. So, it’s important that we have made sure our reasons are worthwhile.

There’s a lot happening around scripting at Unity right now. Some of the biggest pieces:

  • The Scripting Runtime upgrade, which brings the ability to use .NET 4.6 and C# 6.
  • The JobSystem, making it possible to easily write multithreaded code in a way that protects you against race conditions and deadlocks.
  • The NativeArray type, allowing you to create and work with large arrays that have their storage controlled by native code, giving you more control over allocation behaviour and exempting you from garbage collection concerns.
  • Control over the script compilation pipeline, so you can customize how your scripts are combined into assemblies.

That’s just a fraction of what we’re working on right now – there are many more things happening, and that doesn’t even include some of the projects we have planned for the future. In addition to the specific scripting projects, we’re also increasingly opening up the engine and growing our API surface – which we want to do using the most appropriate language constructs available.

Today, UnityScript and C# are fairly evenly matched in terms of functionality and performance: there’s nothing you can do with C# that you cannot do with UnityScript. C# is the clear winner when it comes to developer ecosystem – not just the millions of C# tutorials and samples out there, but also tooling support, like refactoring and intellisense in Visual Studio – but you could say, today, that UnityScript works, and who needs those fancy tools anyway?

It’s true today, but it won’t be true forever. As we upgrade the Scripting Runtime and version of C# we support, there will begin to be things that UnityScript doesn’t do as well as C#, or even can’t do at all. It already does not support default values for method parameters, and there are more language features coming to C#, such as ref return, that will have the same problem. We don’t use these language features in the API today, but we want to, both for performance and to achieve a clean API design.

It’s all just software, and we could take the time to implement these missing pieces into UnityScript. Time is not free, though; asking an engineer to work on bringing UnityScript up-to-date means taking them away from working on something else (like one of the new features I mentioned above – or just from fixing bugs). This isn’t even mentioning the time we already invest in maintaining UnityScript – supporting it in the Script Updater, supporting it in the documentation, and so on.

So let’s look at the other side of this: how many users will be affected? The Editor periodically sends us data about your project, including the different file types you’re using and how much you’re using them, so from that we can calculate statistics about how many projects are actually using UnityScript. What we found was:

  • To date, of all the projects that have used Unity 5.6, about 14.6% of them have at least one file with a .js extension in it. 14.6% sounds quite high, but then we broke the numbers down further, and looked at how many files were .js files as a fraction of total script files in the project (.js + .cs).
  • So, that leaves 85.4% of all projects which are entirely in C#, with no UnityScript files at all.
  • 9.5% of all projects are mostly in C# – they have some UnityScript files, but fewer than 10% of their total script file count. Another 1.5% of all projects have between 10% and 20% of their code in UnityScript files.
  • That leaves 3.6% of all projects that have more than 20% of their code in UnityScript.
  • Only 0.8% of all projects are exclusively (i.e. 100%) in UnityScript.

What this suggests to us is that the majority of you who still have UnityScript code aren’t using it heavily. You may even not be actively using it at all: a .js file in the project might be an example script for an Asset Store package, rather than code that you are actually relying on. Therefore, an early step in our deprecation plan is to start working with Asset Store publishers to get rid of packages that are providing these files – more on this below.

To the 3.6% of you who are using it more heavily – and especially the 0.8% who are using it exclusively – we are sorry. We know that this decision sucks for you. We’re taking some steps to try and smooth the transition, that I’ll describe below; and we hope that you will eventually agree with us that it was worth it in the end.

How will it happen?

We’re not just going to pull the plug overnight. Here’s what you’re going to see us do:

Firstly, as of the beginning of June, we have amended the Asset Store submission policy to reject packages that contain UnityScript code. All new code that you’re writing for Asset Store packages should be in C#. (We ran this past the Asset Store Publishers discussion group before we did this, to give them a heads-up). Soon, we will begin a scan of all existing packages on the Asset Store to find ones that contain UnityScript files, and will contact publishers to ask them to port their code to C#. After a while, any package that hasn’t been ported will be removed from the store.

Secondly, you might have already noticed: the Unity 2017.2 beta no longer has a ‘Javascript’ (a.k.a UnityScript) option in the Create Assets menu. All we have done at this point is remove the menu item; all the support is still there, and you will still be able to create new UnityScript files outside of Unity (for example, via MonoDevelop). We’re doing this to help ensure that new users do not continue to adopt UnityScript; it would be irresponsible of us to let them invest time in learning it when it is not long for this world.

Thirdly, we have begun work on a UnityScript -> C# automatic conversion tool. There are a few of these out there already, but we weren’t happy with the approaches they use; we already learnt a lot about operating on UnityScript code when we wrote the Script Updater, so we decided just to apply that knowledge and build our own solution. We’ve not yet decided whether this will be integrated directly into Unity or just available as a separate open-source tool, but either way we are expecting to have something available by the time 2017.2 ships later this year. We’ll have a follow-up blog post about this tool when it’s ready.

After that, we will be watching our Analytics numbers. Our hope is that we’ll see a fairly quick decline in the use of UnityScript – particularly in the “fewer than 10% of scripts” group, who have less code to migrate – but if we don’t, we’ll pause our plans and investigate what’s blocking people from migrating. Sometimes it’s just a matter of timing, but other times there are real issues, and we want to make sure we didn’t miss something before we switch it off entirely.

Once we’re content that the usage level is low enough, Unity will no longer ship with the UnityScript compiler, and will no longer recognise .js files as user script code. We’ll also remove the UnityScript examples from the documentation, and remove UnityScript support from the Script Updater.

The UnityScript compiler will remain available on Github at in case you need it for anything – we will not be accepting any pull requests to it, but you can fork it and use it for whatever you need.

A note about Boo

We announced back in 2014 that we were dropping Boo support from the documentation and Editor UI. The Boo compiler itself has stuck around, though, because UnityScript is actually a layer on top of Boo – it uses the Boo runtime libraries, and the UnityScript compiler is written in Boo. This has allowed you to continue using .boo files in your projects, even if there’s nothing in Unity that mentions it any more.

The removal of UnityScript support will also mean the final removal of the Boo compiler. At this point, only 0.2% of projects on 5.6 contain any .boo files, and only 0.006% of projects have more than 3 boo files in. Again: we’re sorry, but its time has come.


We hope this post has explained our reasoning clearly, and given you some reassurance that we are not just doing this without having thought carefully about it.

Going forward, this is the kind of process we want to follow for every situation in which we are removing a feature: announce our intentions, push for change through the Asset Store and Editor UI tweaks, but ultimately make the decision based on actual data about what you’re all doing.

Deprecating and removing features can feel like the opposite of progress sometimes, but it’s an important part of streamlining Unity; like a forest fire clearing the way for new growth, it helps clear the way for us to deliver the fixes and features you want as quickly as possible.


135 replies on “UnityScript’s long ride off into the sunset”

very smart decision. Engineering hours are very expensive nowadays and allocating them to support and maintain a dying horse is a pure waste of time.
as a C# developer , I am very excited to see .NET 4.6, C# 6 and hopefully Roslyn being adopted as the ONLY scripting option for Unity3D

Leave JavaScript and all its derivatives where they belong –> web development (gross!)

>This has allowed you to continue using .boo files in your projects, even if there’s nothing in Unity that mentions it any more.
UnityEngine.Boo namespace?

Shouldn’t be a big deal as long as you give some mechanism for those projects which adopted Unity Script to work their way through the pipeline.

You might want to also start talking about how you’re going to kill off all the legacy content which has UnityScript in it. Nothing sucks more than having a bunch of dated documentation around telling you how to do something that is no longer supported.

That said, would have been nice to have support for Python at some point but it looks like that’s never going to happen now ;)

Undoubtedly a good decision. Somehow i doubt you guys have time to spare, and maintaining support for two languages must inevitably come at the cost of new features, bugfixing etc.

Hopefully now, in time we will see support for the newer language features, such as task-based async.

I myself am fairly new to Unity, and have nothing invested in unityscript. I see some commenters chose Unity for the JavaScript(ish) support. Me, I would never have chosen Unity if that was the language I had to use. So that goes both ways.

Keep up the good work. And kudos for the open, professional way you go about it.

Here is my experience in Unity: I was the project manager for a cross platform/cross play game for my senior project at Drexel. It’s a great tool! I’m also close to getting my bachelor’s in interactive digital media (web development and design basically). Here’s what I have to say about the removal of UnityScript:

UnityScript should have never been a thing. It should have ALWAYS been vanilla javascript. This always leaves Unity open to either hardcore C# programmers, web developers, and front end developers. I feel if Unity went all the way with vanilla javascript support it would have been quite a different world.

Unity uses vanilla C#. I just wish the same was always true for javascript.

lol Did the entire 3% show up to comment? :D

It’s been long overdue. If you read the article, the reasoning is more than worth dropping it. You exist in the world of technology, so having to learn new stuff and change over time is a never ending process. As for those mentioning the documentation, it’s insanely easy to translate logic from UnityScript to C#, and vice versa. Also, C# is very easy to learn, you may even enjoy it. ;)

Why Unity will remove UnityScript completely? Why Unity not only freeze the development of UnityScript and keep it as a possibility to transfer simple javascipt logic from web projects to native Unity projects? E.g. I have developed a simple Javascript to UnityScript framework to transfer the basic game logic from my web project. I need only basic UnityScript functionalities, no parallel processing, no new .NET libraries.

Unfortunately there are stille some doc pages where there is nothing in C# (or less info than JS section) :

Example of JS used instead of C# in the doc :

Example of less info in C# than JS section (here’s the excepted results, ex : “// Prints 10”):

While I certainly feel your pain Unity-folk (maintaining two disparate languages is effectively impossible), you will be losing a growing stream of new developers. As a web developer, the reason I chose Unity is because of the easy mental transition to UnityScript (yes, it’s not quite JS, but close enough). Within a week I had a pretty cool game going. I think Unity is a great tool.

Is C# a deal breaker? Well, I would not have chosen Unity in the first place if it was C# only. I might stick with it now that I am far enough up the learning curve, but it certainly puts a sour taste in my mouth now, and you’ve definitely lost a differentiating factor among game engines.

Your current base seems happy enough, but I think you may be underestimating the growing popularity of JS (or TypeScript). Here’s just one data point (GitHub commits), but JS is far and away the most popular language there.

Just because people use JS in the Web Dev world doesnt mean it should be used here. Not to mention its not real JS anyway as you mention. You also mention the growing use of TypeScript which in my limited knowledge, allows developers to create type safe code. Which surely would be a point in favour of C#?

Perfect reply. I started using Unity because I knew javascript from being a webdev, it gave me the initial confidence and familiarity. If I had to begin now, I probably would have gone with UE4 since it uses a framework system (with superior default graphics) instead of raw C/C#/C++. Somehow people have been fooled into cheering when fewer options are available. Remember building out to web browser? The unity player used to work perfectly, now we’re forced to use WebGL which performs at like 2-3fps garbage most of the time, because Flash is the new face of evil! Hey, we could’ve just not run it on mobile, lord knows WebGL won’t either, but nope some smooth talk and everyone has to suffer, it’s thrown in the garbage along with unityscript.

Speaking of programming languages, what do you guys think about the D programming language? Not for scripting, but for the core engine?

The people complaining about the loss of unityscript clearly don’t understand what is to gain by going to .NET 4.5. Parallel processing and task based threading are going to be massive performance gains.

Not every game designer is focused on performance though. UnityScript made it easy for web developers to jump into Unity, especially coming from Flash. We are gaining performance but we should acknowledge that it’s at the expense of user friendliness and ease of use for some of us. I feel like Unity is becoming all about programming and engineering vs fast. messy artistic iteration, and some kind of arms race for great graphics with Unreal, when it’s openness and flexibility was what attracted me to it in the first place.

I’m not surprised by the decision but this is a MASSIVE problem for me. I want to convert overy my program now to C# but I have Unityscripts that access C# scripts in the Stand Assets folder. If I convert any of my Unityscripts to C# in the scripts folder then they can no longer access the other unityscripts in the scripts folder as they C# scripts and get compiled first. It kind of means I have to convert my entire project over to C# in one go which is of over 50 scripts and tens of thousands of lines of code. It’s going to cost me a lot of money and time to do this.

One thing that would help me is if there was a special folder that was compiled last so I could move over some of the scripts over one at a time.

For anyone who has scripts that communicate with each other this is going to be a difficult task if Unity don’t suply ways in which to help with this.

Hi Philip

> It kind of means I have to convert my entire project over to C# in one go which is of over 50 scripts and tens of thousands of lines of code. It’s going to cost me a lot of money and time to do this.

Why don’t you give it a try to the conversion tool? Theoretically it should be able to convert your code requiring minimal changes.



Thanks for the reply :) Sorry I didn’t responded sooner.

Are you referring to the!/content/20232 tool? I’m very much going to give that a go. Fingers crossed that it will help immensely. It’s just a bit of a frightening prospect as I already know my Unityscript isn’t that well written or optimized and shifting it over to C sharp when I can’t remember half of the code and why I’ve done things in certain ways. For example in my early scripts and as a result my largest scripts I’ve removed #pragma strict to make things easier. I’m now aware that this was not a good idea and I need to re introduce it (which throws up over 100 errors) before trying to convert. Another thing I’m aware of is that I’ve useded a declare/find proccess for a lot of object.

private var MouseWarning : GameObject;
MouseWarning = GameObject.Find(“MouseWarning”);

For example which in C Sharp will need reorganizing as the ‘find’ has to accur within a void.

So there are quite a few things I can do to improve things before the conversion but I shudder to think of the ones I don’t know about yet.

In the long run it’s a good thing but in the short term it does worry me quite a bit. I’m hoping the conversion tools will be a great asset to me for this. Time will tell once I make that dive :)

I’ve just realized you’re referring to the conversion tool being developed by Unity. I’m going to a go with that and see where I get :)

All the best


As a developer, I usually don’t mind any ground breaking change in *new version* Unity.
It does not affect the version of Unity I am using, I always have a choice to keep on existing version.

I want projects build using older version of Unity can be published to the Apple / Android market.
Usually submission requirement change are quite small, such as icon size, splash screen size, xcode project version or setting, etc.
If there are update for these changes, I have no need to take the risk of upgrading my projects.

This is kind of my approach too. I’m on Unity 5.2 and the only extra steps i had to do were add a script to automatically populate Apple’s camera permissions and i manually drag in the iPad Pro 167px icon each time I build in Xcode. But somethings don’t work with earlier versions. For example I have held off on my AppleTv version because only 5.3 and up support TvOS. But i think for the time being if converting large, legacy projects to C# is too resource intensive we can thankfully at least stick with earlier versions for as long as is possible. it’s funny because a lot of these problems apply only to IOS and Android developers. If i was making PC and Mac games I think it would be a lot easier to upgrade to newer versions of Unity.

@Richard Fine – you wrote “After a while, any package that hasn’t been ported will be removed from the store.” Don’t you mean will be transitioned to “deprecated status” so no new sales are possible but customers who “paid” for those assets will continue to have access to them?

Well, I’m one of that little .8% totally Unityscript projects. I am happy to switch as I’ve been meaning to for a while and this will finally push me to do that. I think C# is fine the only thing that really bothers me is having to use temp variables. They add several lines of code and are much harder to read. Is there any chance that C# will handle assigning variables like UnityScript?

I assume you mean being able to do something like

vector3.x = 1;

In C# Vectors are structs without public accessors to each number, only a constructor that takes all 3 variables making this impossible.
The only way around this would to make it Vector structs a class instead but I remember a Unity3D guy talking about this saying if it was a class projects would crash without the memory overhead!

Yes, not being able to write transform.position.x = 1; is really annoying in C#. The lovely thing about Unityscript is that it allowed you to do that and handled it behind the scenes. I’m a designer turned programmer so this is a really nice thing to have when writing clear code.

I’m shocked C# can’t do that – I had no idea.

I’ve mentioned this before but this really reminds me of Flash moving from ActionScript 2 to ActionScript 3. All of a sudden we had to write three lines of code to open a URL and the devs kept telling us how much better it was:) It was about that time I left Flash for Unity ironically.

When they came for the boo and removed it, I was silent – I did not write on boo.
When they came for javascript and removed it, I was silent – I did not write on java.
When they came for C # I left with unity.

Lol:) Funny – but you know you may be showing great foresight in the long run.

Ive used JavaScript for years. UnityScript was there from unity 1, and syntactically similar enough to JavaScript that its made the transition a breeze for me, and I never thought it would disappear. that’s why i relied on it.

I’m 45 so C# isn’t old enough to be seen as an old-time language for my generation. But as I’ve been told many times now on the forums, I should know that technologies move on and accept it gracefully.

Your statement is just a reminder that in 2030 maybe the kids will all be using some kind of eye-activated visual language, and C# will go the way of the dodo.

It’s never a big deal until it happens to you;)

Great post and thanks for the transparency about your decisions. I started with UnityScript as it was easier for me as a non programmer years ago. Now I’m a computer science student who relies on C# and I love it.
It would be great to include some official Migration tutorials. I remember myself being totally confused about why can’t I easily use GetComponent(SomeComponent) in C#.

This is so exciting! (You can tell I’m a C# developer, haha) I’m sure this will free up a lot of resources for the Unity developers in the long run to focus on important stuff! It must stink for people who rely heavily on JavaScript/UnityScript, but at least Unity is working on those conversion tools to convert JavaScript to C#

This is a very exciting news! It shoud have been done years ago but, better now than never!
Not only the Dev team will have more time to work on new tools and bug fixing, but the whole community will have access to more powerful features in the future.
I know it’s hard to accept something new, something that’s changing your daily basis, but thisis IT and this update it’s a step foward and I hope the majority of the community will understand this with time.

Like many I feel like this should have been done years ago. It seems that Unity have held back updating C# and .Net support in unity so that C# does not gain an advantage over Unity Script.

What really surprises me is the people saying they “hate” C# and that they might leave Unity due to this. Not only is C# more powerful once we get C# 6 and a higher .Net support, the syntax for Unity Script and C# are probably the closest you can get. I could understand C language programmers not liking a language such as Python due to a fair difference in syntax and functionality, but to like Unity Script and use the word “hate” against C#, this just confuses me.

I have personally never any time even looking at Unity Script, but a colleague of mine needed help with something once in Unity Script and I was able to understand the code and fix bugs in it having pretty much never looked at it before, that is how similar Unity’s C# and Unity Script is.

When I started using unity 8 years ago, it was for .js support which was close to .java, a language I learned and thought I loved.
Fact is after a year of trying to make a game, .js had to go. The lack of strong typing at the time, and the implicit variable creation were killing me.
I am glad it is finally FINALLY being phased out, this language should have been removed years ago and its team moved to some more exciting projects inside Unity.

UnityScript user here (making projects in UnityScript since Unity 3), I have to say I totally understand and support the decision, however as others have noted, the transition needs to be as smooth as possible. This is going to be difficult for all of us who are used to JS. All of my old projects and my current project use like 90% JS. That said, I’m lucky to be fluent in C# as well, but there are others who are not as lucky.

The arguments of efficiency vs accessibility have already been established, but there’s another element which I wanted to bring up: time. I find that I can write code faster in UnityScript than in C#, there is less to write and it’s more straightforward, allowing for less time pondering at the keyboard and more time writing code. This is a very small inconvenience (so don’t let it hinder your decision) but it’s something that we have to consider.

My biggest problem with this switch is that I have A LOT of old code from other projects that are extremely useful in every new project I start. So where I used to be able to just drag and drop/copy old scripts, now I would have to convert them to C#. Once again, not a huge issue seeing as there are Converter tools out there, but it’s another inconvenience that adds up.

As stated already, if this is what Unity needs to do to keep up to date, then I’m all for it. However, I do think that the 3.6% figure is too high, considering how many people use Unity. This is similar to the x64 bit Editor issues. Forcing the number down in a set time might not be a wise decision, rather we should encourage conversion and increase awareness until the number declines on its own. Not worried, because the Unity Team seems to understand this. Sadly, it would eat up too much development time to convert my current project, but from now on with new projects I will use C# to help drop the percentage.

Lastly, by dropping UnityScript Documentation examples, you mean from the current/new Docs? I would hope the old Docs for 5.6/beyond would still include the JS examples.

Having gone through my own .js to .cs transition a few years back I read this article with great interest. For me, it was really important to keep my project both ‘alive’ and in a format I could continue to build upon. As such I’m afraid a couple of the Unity converter’s stated limitations would have made it a non starter for me:

– Comments are not preserved
– Formatting is not preserved

…Without these the output would barely have felt like _my_ script any more and certainly wouldn’t have been code I could have continued working with without spending a ton of time manually re-formatting.

So in my case I took the opportunity to write the asset CSharpatron. It was a lot of work, but I successfully used it to convert about 150k lines of Unityscipt with minimal hand-editing. Since then it has been used by quite a few people with (mostly) a very high degree of success. Various improvements were rolled in over subsequent releases.

I first read Richard’s comment: ‘we weren’t happy with the approaches they use’ (re: existing converters) and thought ‘fair enough, given their deep insights, experience creating IL2CPP and other conversion tools, they’re probably right’. BUT now that I look at the stated list of limitations for the Unity converter, especially the comments and formatting aspect, I feel justified in at least putting CSharpatron forward as an alternative…

CSharpatron _does_ preserve comments and formatting, and it has a damn good go at converting almost everything you might be doing in Unityscript into clean C# code. If you have .js to convert, perhaps you may find it useful :)

Thank you for sharing this. I spent last night looking for JS to C# converters on the asset store and I didn’t see this one. It actually answers a lot of the questions i had for the Unity converter that i asked here: and which to their credit Unity promptly and honestly answered. I will definitely back things up and give CSharpatron a go. I have been considering switching bit by bit to C# and i think its just the relative suddenness of this announcement and the fact that its an obseletion of UnityScript and not a deprecation that has given all of this such a sense of urgency.

I’m a c# developer, but i think unityscript make web developers ( which is a HUUUGE community ) choose unity when they are choosing an engine ( even though they will probably use c# after learning the engine )

I agree. From what I understand, JavaScript is the most popular language due to it’s prevalence on the web, and that’s why I chose Unity over Unreal. it just felt more accessible. It opened Unity to a huge body of developers and designers.

So it’s about time to switch to GODOT Game Engine , they have an easy Script Language and in V3.0 also a Visual Script Editor and ohh without that fu%&ing SplashScreen compulsion

Sure go ahead and learn a new engine, and scripting language, just to avoid a quickly growing industry standard language like C#, which now gives you access to the now free Xamarin, .net core 2.0, and all the other cool new stuff Microsoft and other big companies are doing, after .net gone open source.

UnityScript may not be JavaScript, but the syntax is close enough that it allowed web designers like me to migrate to Unity en masse. This reminds me of when Flash switched from the messier but more accessible ActionScript 2 to the more performant but verbose ActionScript 3.0. That was a big reason many artists like me dropped it.

I completely understand why Unity is doing this, and I know that C# is probably a superior language in many ways. But sometimes you lose accessibility in the race for efficiency. Nimian Legends : BrightRidge is almost 100% coded in UnityScript, and while a lot of my project would seem to be in C#, that’s because I use so many Asset Store C# assets, not because I’m coding homemade scripts with it.

I’m going to give the converter a shot, but I want to say this is a serious issue for some people who have legacy projects we have been developing for years. Please don’t dismiss the concerns of UnityScript coders. It is NOT a trivial thing for the average non-coder to learn a new language like C#. For me this is a real blow to my production, and frighteningly makes we wonder how I will be able to continue with Unity in the future.

I’m all for it and honestly surprised UnityScript was deprecated years ago. Now Unity can focus solely on C#.

Personally I hate C#; one reason I embraced Unity was Unityscript, all my projects rely on that. This will probably make me depart from Unity. Sad thing but inevitable….

Transition to subscription model (like Adobe), then killing JS to only support C#…. Time to find another tool, like I’ve already found replacing Adobe’s Phoshop and Illustrator with Affinity Photo and Affinity Designer.

The time has come, it’s a well-reasoned decision, and there are plenty of resources to teach people how to code in C#. In fact, it’s a far superior skillset since it will translate to other programming tasks (which was not the case for UnityScript). I know it’s going to anger some folks, but it’s time.

While we’re moving with the times, is there any chance you could stop referring to C# code as ‘scripts’. If I want to write a script, I’ll write in LUA or something. I certainly wouldn’t categorize the structures, frameworks and controls systems I do build for Unity that way.

As a C# developer for many years (.NET beta 1 actually) it’s like hearing nails on a chalk board whenever you talk about my code as ‘scripts’.

Yes, I know it’s petty….I’ll go back in my box now…..

I’m also very dissatisfied with the term script, because the art of programming has been devalued to scripting. The perception of programming among many disciplines in the games industry shifted to “writing scripts in Unity is no real programming, why do we need programmers at all”.

That’s not why I chose a career as a software developer. I wish the perceived value of programming is being recovered and I believe Unity can make a start by not using the terms script and scripting anymore.

Alas, script is the proper term for how this code is used in Unity… That is, the intermediate output is interpreted by the game engine, as opposed to being executed natively on the CPU. C# is a high-level multipurpose language, and in this case, it is being used as a scripting language. C# is, in fact, designed to do many of the things that scripting languages are famous for leveraging (for example, not having to directly manage memory usage, safer sandboxing, etc). It doesn’t matter if it’s called scripting or programming… what matters is if you’re sitting down to do coding, or software engineering.

No, C# is not a scripting language, and writing subclasses of MonoBehavior is not scripting. Scripts are generally interpreted, whereas C# is JIT compiled and actually executes natively.

So I agree that the term ‘script’ is somewhat of a misnomer, and probably just stuck in the Unity vocabulary from earlier days. Perhaps with time it will go away, but I honestly can’t work up any great passion about it. I love working with Unity, and what they call my .cs files doesn’t bother me.

Just think of “script” as synonym for MonoBehaviour or, in general sense, something “updatable” — the entity whose life cycle is controlled by engine.

Of course, the majority of code should be outside such “scripts” — if you’re real software developer rather than regular “game maker”.

Time to keep working on that amazing visual scripting hack week prototype from a few years ago that actually wrote c#. It seemed like the perfect blend of artist friendliness, nodey free form code and snapping vertical flow of text. Could be much better than blueprints as that throws out all the benifits of text editors.

It’s real great news!
I hope that after it we can make Unity is more awesome and improve supporting of all latests features of C#.

Sometimes required the small things that provide that many reducent code with OOP structure, and small js scripts allow to users write quck sequences of actions. But I think that it’s the wrong way to use the js scripts for it, the more correct way – use visual programming, and as I understand Unity moves to it.

You make decision based on interested statistics – it’s cool!

I translate this post on Russian.
Я перевел этот пост на русский язык, если кому будет интересно.

Idea: Can you make a simple draft converter? Just for having a fast first draft c# that we can improve.

The fact that the numbers were crunched and it really does make sense to move to a more unified (no pun intended) scripting environment, shows that things are progressing for the better. I apologize for a bit of bias as a C# developer, but I am really looking forward to having new language features and syntactic sugar for the more current versions of C#.

I imagine that eventually things like co-routines will be eventually going away in favor of the “async… await” pattern, which really does make the code a lot cleaner and readable when dealing with asynchronous tasks.

I think this is a wise move –I do feel for those who have to take the plunge and hopefully the proffered conversion tools will lessen the pains of having to transition from scripts of one language to another. In the end, the tools will be leaner and we’ll all be on the same page when it comes to scripting in Unity.

Would it make sense to make the “drop Unityscript” version a full point release, where devs who _must_ stick with it can install the C#-only version concurrently so both project types can be supported? All future updates will only occur on the C# version, but devs can still keep developing on the Unityscript version as long as their product requires.

While you are at it, could you please remove the deprecated Properties like

? There are so many deprecated functions and properties that have been in for YEARS.

Just use the keyword “new”, which will override the same name of the deprecated variable/property name.

private new Rigidbody rigidbody;

Yes, using ‘new’ can mitigate this. This is something I am already doing but it has fringe drawbacks. My point being, Unity has a lot of deprecated parts of their API that never get removed. Provided they’ve just ended the 5.x life cycle, that would have been a prime time to remove deprecated Fields/Properties/Methods. It was the 4.x->5.x transition that deprecated these specific Properties anyway, so ample time has certainly passed.

I think it’s a reasonable and probably good decision to drop UnityScript, but I don’t believe you can just conclude by the percentages that in a mixed .js/.cs project that the .js is less important or not even used. If you said here’s a mixed project, without looking at it I would guess that the developer is coding in Unityscript and the CS is all third-party code from the Asset Store or wherever. This was certainly the case in my projects for a long time until switched to C# and it is actually still the case in many of my projects, where typically I haved a bunch of C# plugins and the game scripts are still UnityScript.

They are able to tell what is your scripts by eliminating the C# scripts commonly used by asset store packages, and apologised to your 0.8% demographic…

Remove even “.transform”, “.material”, etc, etc….. It has to be ultra-clear and explicit when something does a GetComponent, when something returns a copy of an array, etc…

It will be well worth it

What I find to be super aggravating about it is that the Auto Script Updater already catches these things when moving between the versions. This should have been a “will be straight-up removed next version” thing.

I feel like 2017.1 was a really good opportunity to do so, considering these have been deprecated for the *entirety* of the 5.x life cycle.

Great… Now I have to learn proper C# and start converting almost 100 scripts. As if I don’t have enough on my plate. Thanks a lot…

Great move. Unify the Unity community on a single language.

It would be a harder decision I think if UnityScript were actually JavaScript and not just a look-alike custom language. But it really is a stretch to call it JavaScript. Kill it and put those resources into giving us all more C# goodness.

In the process of chosing the right game engine to use we found Unity3d adverting the engine like an option friendy to non coders. Unityscript was pointed as a powerful, easy, painless and like a futuristic solution.

We are a couple of developers doing a humongous game, almost too big for 2 people. We are working hard in this project,
I am art director by formation and had lots of problems with coders the last
15 years, so I found unity3d the chance to make our games. We spent lots of money (money we don’t have) in the engine itself, upgrades etc etc
we abandoned our careers to make this game happen and now we face the fear of this deprecation.

Unity3d was adverted as a simple-codying, artists friendly engine. We had 7 years of work here being simple “deprecated”
and we have no good words for this at this point. All we have now is to rush our project and that’s it. Remake the code is
virtually impossible.

Dinart Filho

Hi Dinart

> . All we have now is to rush our project and that’s it

We are not dropping support on 2017.2 for sure (there’s always the possibility that the final deprecation will happen in an upcoming version, not 2017.3). So, one option is to stick to version 2017.2 for this project and be free to move to newer versions for any new project.

You can continue to use UnityScript (or any other language that targets .Net); the point is that it will not be officially supported and you’ll need to compile your scripts manually (I understand this is not optimal and requires effort, but at least it is an option if you need to upgrade Unity and is not able to convert your code to C#)

> Remake the code is virtually impossible.

The idea is to have your code converted automatically, requiring as little work from devs as possible (of course you’ll still need to know C#, but given the time you said you have been working on the game, I don’t think you’ll have big troubles using C#).

If you are willing to, give the conversion tool ( a try and feel free to DM me if you hit any issues / questions.



As a Web developer who uses JS all the time of necessity, building my Unity games in 100% UnityScript has always made sense. I have shipping products and VERY complex long-term in-progress jobs that will all be affected, all 100% JS! If finishing or maintaining them in the future becomes impractical, that will be a massive blow to a Unity-based developer going back to the Unity 1 days..

This isn’t to say Unity shouldn’t make the transition—I trust the reasons. But please make it as gradual and painless as possible! Lots of people will vote to barge ahead quickly, so you need the votes on the other side! Here’s mine :) Keep JS support for as long as humanly possible. And take the time to make that convertor elegant.

C# aside… any hope of Swift in future? I was really hoping my next language would be Swift!

Good decision, I have just been waiting for a good conversion tool to be able to abandon js altogether, as right now it’s not easy to convert a large old project with mixed code. The UI/inspector integration of many js files makes it particularly difficult

As a developer who still primarily uses UnityScript, I’ll of course be a little sad to see it go. However, It’s definitely the right decision and I don’t feel it’ll take too long for me to switch over to C# (I’ve worked with it for long enough to get a handle on its syntax, and the conversion tool should save me some time porting my projects.)

It was a good decision to include UnityScript back at Unity 1.0, it’s an equally good decision to deprecate it now.

There is no need for NativeArray. The latest .NET and Mono 5.x have Span which does just that and has special support in the runtime.

Well I am glad to see that Unity have finally decided to get rid of UnityScript. This is the right decision.

As a front-end web dev trying to step into the game dev world, I chose Unity because I was comfortable with the JS-like syntax of UnityScript. I’m sorry to see it go because it will raise the bar for those making the same step, but I understand the maintenance costs for a second language must be high.

Even though I have a few active projects in Unityscript it still feels like it’s a good move.
I’d love to see how good a job the compiler does… Bet I can break it :P

well reasoned, if you are going to spend the time on more useful features and bug fixes, then this is definitely justifiable.

Just don’t forget a lot of code has to load JSON from the internet, and that data won’t show up in the projects file system!

It´s a great thing to have JScript removed from Unity, it´s unsafe and filled with bugs. Maybe you should replace it with Lua language or Python… It would help a lot.

Thanks for looking out guys. I know its not the simplest thing to do this kind of transition but it will be worth it for everyone. As far as I know Unity was one of the few engines supporting multiple languages to begin with.

J. McKenzie: “Considering how there are more developers using JavaScript than C#, you might want to reconsider this decision.”

Not many, because Unity Script != web Javascript.

I for one welcome these changes. I know there’s very little difference in developing in either Unity’s Javascript variant or in C# – most of the time we are doing logic and talking to the Unity API :)

UnityScript was never JavaScript (as in Node.js / Browser) which led to a lot of confusion among beginning developers and people claiming UnityScript should be saved “because JavaScript is so big elsewhere” which is totally bogus. Yes, please led it die, it will streamline documentation among other things.

Sounds like the exact opposite to me. Let’s not add yet another superficial scripting option that costs precious dev time. Let’s just focus on one single way of doing things

You can already do that in practice, I believe. There’s no official Unity support for it, but as long as you compile it to compatible version, it should be fine. C# and F# are both .NET languages, so it shouldn’t be a problem. I suppose that would also make F# one of the easiest languages to add support for, but whatever. You ought to be able to do it already anyway if you really want to.

Almost true. I think it can fail under some circumstances, and there’re some compiler optimizations which might not be there, but I can’t talk about the details. It somehow works. The thing is that there’s a lot of different features, so I think it could fit the bill in the long run.

This is a great decision. I work as the community manager of a small software company and I know how valuable developer time is on the RIGHT products. Well done.

I’m happy with the decission. In fact, I wrote almost every UnityScript into C# on my own in the past, just to not have mixed scripts in our projects. Focus on the new features and drop old stuff, which is hardly used.

I have mixed feelings about this.
On one side, i totally understand the technical reasonings and support those.
As one of the main ones, of course it is way more streamlined, easier and faster to maintain one language instead of 2-3+.
Me personally, i also don’t use unityscript for many many years anymore unless a client explicitly asks for it (and then that makes me feel a bit dirty to use it =) ).
There are many very obvious and valid reasons why going with C# as main “pro coder” language makes more sense in Unity right now.
But on the other side, we all started coding/creating somewhere, and i know for many that has been a scripting language like javascript, actionscript, some other ecmascript derivate or similar in general.
And so while it is not the case for me anymore for many years, especially since i had an oop programming education, i still remember
when i started out all those years ago, it was enough work and daunting to learn to do the basic coding things already and back then learning to get going in a basic scripting language without strict data typing etc made it way easier to get into and get basic things going and have that success feeling.
It’s also many things one does not even consider as complicated anymore when one is used to it like for example in C# and such languages one can’t populate arrays and other list types etc as freely nilly willy with any type etc, there’s not one list, one object type one can just populate with anything with no restrictions as easily, one should learn the pros and cons of different list types, their methods etc.
Now while regarding resource allocation, debugging and other reasons that is a good thing, it makes things way harder to get into for beginners.
One could bring up many such examples, like when i first used Unityscript in Unity and then transitioned to C# it at first already threw me off one couldn’t do some things “as inline” in C# as in Unityscript, like for example yield instructions.

While OOP, strict data typing, nice encapsulated clean classes, apis etc all make a lot of sense and so of course have their place and it makes sense most more seasoned devs transition to such things at least partially over time, there is also something to be said about what is easier and quicker to get into for beginners or maybe more design/art oriented people than (clean nice) code oriented people.

To me Unityscript in Unity was never a great replacement or in tandem usable solution next to/with C# since always too many things did not feel fully supported well in Unityscript and just having to put scripts in different languages in different folders as one has to consider compilation order etc when using several languages together always felt a bit hacky and wonky to me.

But i’m not sure dropping it is the better solution compared to making it full futured for those maybe less “seasoned programmer” types so that Unity has a first class easy for beginners/non coders to get into option, too.

It also sets a bit the focus on what type of engine one wants it to become more. Does one then just say things like Playmaker etc are what non coders/more design/artside oriented people should use and not code much else themselves or make it all visual workflow driven even more for them or still also offer them an easier in into the “full on ” programming side of things.

There are also other aspects to consider like i feel the web does not accelerate as much anymore as back when there were plugins which indirectly pushed unofficial standards evolving faster than when it’s all on the browser makers to adopt and push further official standards faster and nicely, but hey, at the end of the day, maybe they’ll get there and maybe then what some envision as happy thing could still happen at some point, that javascript like web scripting languages also become used more and more for desktop/high end level games/apps and then maybe not the worst thing when one’s engine has a similar language to what such people are already used to using.

Very good decision. Designing good software is skipping features as much as it is adding features.

Considering how there are more developers using JavaScript than C#, you might want to reconsider this decision.

No. While JavaScript is great (I personally use it daily), it doesn’t belong in every facet of development. C# is much more well suited towards game development and as such should recieve all the support and development it can in Unity.

What are you talking about? The FIRST sentence says that only 3.6% of the projects currently are mainly relying on UnityScript.
And in terms of JavaScript: Unity Script never was JavaScript in the first place. It simply used the syntax.

What numbers are you basing your statement on?

Did you read the article? Only 3.6% of users have more than 20% of their script files in UnityScript, and less than 0.8% exclusively UnityScript. C# is absolutely the de facto standard in Unity now.

That is absolutely not true. Sometimes you get the impression that a lot of people use UnityScript because there’s some kind of urban legend going on in the Unity community saying that “javascript is easier”, which is completely ridiculous. So you often see first-time programmers giving code examples in unityscript in the forums. But in reality, the extremely large majority of actual game developpers are using c# exclusively

Comments are closed.