Search Unity

Unity 1.0 の頃から、Unity で C# の代替として利用可能な JavaScript ライクなスクリプト言語としてご利用いただいていた UnityScriptですが、ついにこの言語を終息させる作業に着手すべき時がやってきました。

このブログ記事ではこの決定の背景にある詳細を説明しますが、簡単に要約すると、UnityScript のサポートが継続されていることで、新しいスクリプト関連の機能を提供するために割くべき労力を取られていること、そして UnityScript を本格的に利用しているプロジェクトは全体の約 3.6% に過ぎないこと。これらの事情を鑑みて、UnityScript の終息を決定したということです。

UnityScript を非推奨化する理由

私たちは、Unity から何かを削除することで、不利益を被るユーザーが常に存在することを知っています。ですから、削除するという判断が価値があると確認することが重要だと考えています。

今、Unity のスクリプティング周りについては多くの物事が進行しています。その中で最も大きなものとしては、以下のような事が進められています。

  • スクリプティングランタイムのアップグレードにより、.NET 4.6 と C# 6 を使用できるようになりました。
  • 競合状態やデッドロックを回避する形のマルチスレッドコードの記述を容易にする JobSystem が搭載されました。
  • NativeArray 型の導入により、ネイティブコードでストレージを制御する大規模配列の作成と操作が可能になり、メモリ割り当ての振る舞いをより精密に制御できるようになりました。これによって、ガベージコレクションについて配慮する必要がなくなりました。
  • スクリプトのコンパイルパイプラインを制御することで、スクリプトをアセンブリに結合する方法をカスタマイズすることが可能になりました。

これは現在取り組んでいることのほんの一部にすぎません。このリストの他にも取り組んでいるものは多数あり、近い将来に向けて計画しているプロジェクトのいくつかも掲載されていません。特定のスクリプティングプロジェクトに加えて、Unityはエンジンをさらにオープンにし、API サーフェスを拡大する作業に取り組んでいます。これが、現在利用できる中で最も適切な言語の構造を使ってやりたいことです。

今日では、UnityScript と C#は機能とパフォーマンスの面でほぼ同等であり、C#でできて UnityScript でできないことはありません。開発者のエコシステムに関しては、何百万もの C# チュートリアルやサンプルだけでなく、Visual Studio のリファクタリングや intellisense のようなツールサポートも含めて、C# の方が明らかに優れています。しかし、皆さんは今でも UnityScript は使えるし、誰がそんな上等なツールを欲しがるのかと問われるかもしれません。

確かに現状ではそうですが、いつまでもそうとは限りません。サポートしているスクリプティングランタイムと C#のバージョンをアップグレードしていくにつれ、UnityScript が C#で機能面で及ばない部分や、まったく実現できないということが出てくるでしょう。実際、すでに UnityScript ではメソッドパラメーターのデフォルト値をサポートしていないということも出てきていますし、C#に ref return など数々の新機能がさらに追加される状況で、これらの機能についても同じく UnityScript では対応できないという問題を抱えることになるでしょう。現在の API ではこれらの言語機能は使用していませんが、パフォーマンスとクリーンな API デザインの両方を実現するために、使用したいと考えています。

これはソフトウェアの問題なので、これらの欠けている部分を UnityScript に実装するために時間を割くことはできます。しかし、時間は無料ではありません。エンジニアに UnityScript を最新の状態にする作業を依頼するということは、他の作業(上で述べた新機能の実装やバグの修正など)にあてる時間を奪うことになります。これは、スクリプトアップデーターやドキュメンテーションを整備して Unity をサポートするための作業など、UnityScript を維持するために私たちがすでに投資している時間のことを言っているわけではありません。

他の面からも物事を見てみましょう。すなわち、UnityScript を終息させることで、どのくらいのユーザーが影響を受けるのかということです。Unity エディターからは、皆さんが使っている様々なファイルの種類や、それぞれの種類のファイルがどのくらい使われているかなど、定期的にプロジェクトに関するデータを送ってくれます。これを分析することで、UnityScript を使っているプロジェクトがどのくらいあるか、その統計を取ることができます。その結果、以下のようなことがわかりました。

  • 現在までのところ、Unity 5.6 を使用したすべてのプロジェクトのうち、拡張子が.js のファイルが 1 つ以上含まれているものは約 14.6% でした。14.6% というとかなり高いように聞こえますが、この数字をさらに分解して、プロジェクト内のスクリプトファイル全体(.js + .cs)に占める .js ファイルの割合を調べてみました。
  • 調査の結果、85.4% のプロジェクトに含まれているスクリプトファイルはすべて C# であり、それらのプロジェクトに UnityScript ファイルはまったく含まれていないことがわかりました。
  • 9.5% のプロジェクトではスクリプトファイルのほとんどが C#でした。これらのプロジェクトには UnityScript ファイルがいくらかありますが、全体のスクリプトファイル数の 10% 未満です。また、1.5% のプロジェクトでは、コードの 10% から 20% が UnityScript ファイル中に存在していました。
  • 残りの 3.6% のプロジェクトでは、コードの 20% 以上が UnityScript でした。
  • UnityScript が独占的(コードの 100% が UnityScript)であるプロジェクトは、0.8% だけでした。

この結果が示唆しているのは、まだ UnityScript のコードを保守しているユーザーはいるが、そうした人の大半は UnityScript をそれほど使っていないということです。プロジェクトに UnityScript コードが含まれていたとしても、実際にはそれを使っていない可能性もあります。すなわち、プロジェクトに.js ファイルが含まれていたとしても、それは何かに使われているコードではなく、アセットストアのパッケージについてきたサンプルコードに過ぎない場合があるということです。そのため、UnityScript を終息させる計画の初期段階では、アセットストアのパブリッシャーと協力して、そうしたサンプルの UnityScript ファイルを提供しているパッケージを排除するから着手しました(詳細は後述します)。

UnityScript を主に使用している 3.6%のユーザー、特にプロジェクトの全コードが UnityScript であるという 0.8%のユーザーの方には、ご迷惑をおかけすることになります。この決断は UnityScript のヘビーユーザーの方にとっては辛いものとなります。以下に示すように、Unity ではスムーズな移行を実現するためのステップを準備しています。最終的には、UnityScript から C#への移行が、その労力に見合うだけの価値がある決断だったと思っていただけることを目指し、作業を進めています。

UnityScriptの終息、および移行の計画

もちろん、ある日の夜中に突然 UnityScript を終息させて、それで終わりとするつもりはありません。以下のような計画で UnityScript を終息させる作業を進めていきます。

まず、6 月からアセットストアへの提出ポリシーを修正し、UnityScript コードを含むパッケージを拒否するようにしました。アセットストアのパッケージ向けに新規に書くコードはすべて C# で書かれる必要があります(この変更を行う前に、アセットストアのパブリッシャーが参加するディスカッショングループに注意を促しました)。まもなく、アセットストア上の既存のパッケージをすべてスキャンして、UnityScript ファイルを含むパッケージを見つけ、パブリッシャーに連絡のうえ、コードを C# に移植するように依頼する予定です。この依頼から一定期間を置いてもなおコードの移植が完了していないパッケージはストアから削除されます。

次に行なったことは、すでにお気づきかもしれませんが、Unity 2017.2 ベータ版で、Create Assets メニューから「Javascript」(UnityScript ファイルの作成)オプションが削除されました。現時点ではメニュー項目を削除しただけで、UnityScript のサポート自体はそのまま残っています。また、Unity の外側で新しく UnityScript ファイルを作成する(たとえば、MonoDevelop 上で作成)ことは可能です。これは、新しいユーザーがまた UnityScript を採用することがないようにするための措置です。すでに終息に向かっている言語を新たに覚える労力をユーザーにかけさせることがあってはならないと考えています。

さらに、UnityScript を C# に自動的に変換するツールの開発に着手しました。すでにいくつかのツールが出回っていますが、私たちはそれらのツールのアプローチに満足していません。Script Updater を書いたときに、私たちは UnityScript コードを運用することについてさまざまなことを学び、そこで学んだ知識を活かし得て Unity 独自のソリューションを構築することを決めました。これを Unity に直接統合するのか、それとも独立したオープンソースツールとして利用できるようにするのかはまだ決定していませんが、どちらにしても、今年中に予定されている Unity 2017.2 の公開までには皆さんにご利用いただけるものをお届けできるよう、作業を進めています。このツールについての続報をお伝えするブログ記事を準備でき次第お届けすることにしています。

上記の作業が済んだ後、Analytics の数字を注意深く観察します。Unity としては、UnityScript の使用率がかなり早く減少することを期待しています。特に、全体の 10% 未満のスクリプトでしか UnityScript を使っていないグループでの使用率は早めに低下するのではないかと予想しています。ただし、移行が期待どおりに進まないことが分かった場合は、計画を一時停止して、ユーザーの移行を妨げている要因の調査を行うつもりです。単にタイミングの問題である可能性もありますが、もっと深刻な問題が潜んでいる可能性もあります。UnityScript を完全に終息させる前に、見逃しがないようにきちんと確認を行いながら、計画を進めたいと思います。

UnityScript の使用率が十分に下がったと判断できる状況に至ったら、Unity への UnityScript コンパイラーの同梱を終了します。これにより、.js ファイルをユーザースクリプトコードとして認識しなくなります。また、ドキュメンテーションから UnityScript のサンプルを削除し、Script Updater から UnityScript のサポートを削除します。

上記の終息作業が終了した後も、皆さんが必要なときにお使いいただけるよう、UnityScript コンパイラーは Github(https://github.com/Unity-Technologies/unityscript)で公開し、利用可能な状態のままとします。Unity はこのレポジトリに対するいかなるプルリクエストも受け入れません。ただし、このレポジトリをフォークして、任意の目的にご利用いただく上で制限は設けません。

Boo に関するお知らせ

Unity は 2014 年に、ドキュメンテーションとエディター UI から Boo のサポートを削除することを発表しました。ですが、UnityScript は Boo を基礎として動いているため、Boo コンパイラー自体はまだ残っています。UnityScript は Boo のランタイムライブラリを利用していますし、UnityScript コンパイラーは Boo で書かれているのです。このため、Unity の中ではそれについて言及してはいませんが、プロジェクト内で .boo ファイルを使うことも引き続き可能な状態になっていました。

今回の UnityScript サポートの削除により、ようやく Boo コンパイラーが削除できる状況になりました。現時点で、Unity 5.6 プロジェクトの 0.2% にしか.boo ファイルが含まれておらず、.boo ファイルの数が 3 つを超えるプロジェクトはわずか 0.006% です。これらのプロジェクトを保守されている方には大変申し訳ありませんが、Boo にもついに終息する時がやってきたということです。

まとめ

この記事をお読みになった方に、UnityScript 終息の決断に至るまでの背景が明確に伝わり、Unity がよく考慮せずに UnityScript を終息させようとしているわけではないという安心感を与えられていれば幸いです。

今後も何らかの機能を削除する際には、今回と同様のプロセスを踏んでいきたいと考えています。Unity の意図をお伝えし、アセットストアやエディター UI の調整を通じて移行を促すこともしますが、最終的な判断は、皆さんの活動に関する実際のデータに基づいて行います。

機能を非推奨にしたり削除したりすることは、進歩に逆らうことのように感じられることもあるかとは思いますが、それは Unity を合理化する上で重要な部分です。森林火災は忌むべき出来事ではありますが、火事が収まり、それまで木々に覆われていた土地が更地になったことで、新しい植物が芽生えるということもあります。同様に、ある機能を終息させるということが Unity の実装をクリアにすることにつながり、ユーザーに必要な修正や機能をできるだけ早くお届けできるようになるという結果を導く助けになります。

 

135 replies on “UnityScript 終息までの長い道のり”

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 :
https://docs.unity3d.com/ScriptReference/EditorWindow.Repaint.html

Example of less info in C# than JS section (here’s the excepted results, ex : “// Prints 10”):
https://docs.unity3d.com/ScriptReference/Mathf.CeilToInt.html
https://docs.unity3d.com/ScriptReference/Mathf.FloorToInt.html
https://docs.unity3d.com/ScriptReference/Mathf.RoundToInt.html

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.

https://stackify.com/wp-content/uploads/2017/04/MostUsed4-min.png

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.

Best

Adriano

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

Are you referring to the https://www.assetstore.unity3d.com/en/#!/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

Phil

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: https://forum.unity3d.com/threads/unityscript-2-csharp-conversion-tool.487753/ 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.

Yes please remove those properties as my own catching would like to use those names :)

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…

This.
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…

You should have been doing that years ago. Time to roll with the punches and get with the times.

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

http://ninjagarage.com/

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 (https://github.com/Unity-Technologies/unityscript2csharp) a try and feel free to DM me if you hit any issues / questions.

Best

Adriano

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.

Awesome! Keep deprecating old stuff that holds the engine back! People will adapt no matter what

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.