UnityScript 終息までの長い道のり

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

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

まず、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 はこのレポジトリに対するいかなるプルリクエストも受け入れません。ただし、このレポジトリをフォークして、任意の目的にご利用いただく上で制限は設けません。

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 の実装をクリアにすることにつながり、ユーザーに必要な修正や機能をできるだけ早くお届けできるようになるという結果を導く助けになります。