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.

自从Unity 1.0以来，我们就一直在使用它，但是它的时机终于到了：我们已经开始弃用UnityScript，这是一种类似于JavaScript的脚本语言，如今已成为Unity中C＃的替代语言。 

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.

在此博客文章中，我们将详细讨论该决策背后的细节，但简要地总结一下：对UnityScript的持续支持阻碍了我们交付与脚本相关的新功能的能力，只有大约3.6％的项目正在大量使用它。 

为什么不赞成？ (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.

每次我们从Unity中删除某些内容时，我们都会假设总会 有一些 用户感到不便。 因此，重要的是我们必须确保我们的理由值得。 

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

现在，Unity上的脚本编写正在发生很多事情。 一些最大的作品： 

• The Scripting Runtime upgrade, which brings the ability to use .NET 4.6 and C# 6.脚本运行时升级，带来了使用.NET 4.6和C＃6的能力。 
• The JobSystem, making it possible to easily write multithreaded code in a way that protects you against race conditions and deadlocks.JobSystem，使您可以轻松编写多线程代码，从而保护您免受竞争状况和死锁的侵害。 
• 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.NativeArray类型，使您可以创建和使用其存储受本机代码控制的大型阵列，从而使您可以更好地控制分配行为，并使您不必担心垃圾回收问题。 
• 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.

这只是我们目前正在做的事情的一小部分-还有更多的事情正在发生，甚至还不包括我们为未来计划的一些项目。 除了特定的脚本项目之外，我们还越来越多地开放引擎并扩展我们的API表面-我们希望使用可用的最合适的语言构造来做到这一点。 

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?

今天，在功能和性能方面，UnityScript和C＃的匹配程度相当均匀：对于C＃，您无能为力，而对UnityScript则无能为力。 在开发人员生态系统方面，C＃无疑是赢家–不仅有数百万的C＃教程和示例，还提供了工具支持，例如Visual Studio中的重构和智能感知–但今天您可以说UnityScript 可以工作 ，以及谁还是需要那些精美的工具？ 

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.

今天是对的，但不会永远如此。 当我们升级脚本运行时和我们支持的C＃版本时，将开始出现UnityScript不如C＃甚至根本无法完成的事情。 它已经不支持方法参数的默认值，并且C＃引入了更多的语言功能，例如 ref return ，将具有相同的问题。 我们今天不在API中使用这些语言功能，但我们希望这样做既可以提高性能，又可以实现简洁的API设计。 

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.

这些全都是软件，我们 可以 花一些时间将这些遗漏的部分实现到UnityScript中。 时间不是免费的。 要求工程师努力使UnityScript保持最新状态，就意味着他们将无法从事其他工作(例如上面提到的新功能之一，或者仅仅是修复bug)。 甚至没有提到我们 已经花 了很多时间 来维护UnityScript-在Script Updater中支持它，在文档中支持它，等等。 

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:

因此，让我们看一下另一方面：会影响多少用户？ 编辑器会定期向我们发送有关您的项目的数据，包括您正在使用的不同文件类型以及使用了多少文件，因此我们可以计算出实际上有多少个项目正在使用UnityScript。 我们发现的是： 

• 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).迄今为止，在所有使用Unity 5.6的项目中，大约有14.6％的项目至少包含一个带有.js扩展名的文件。 14.6％的声音听起来很高，但是我们进一步细分了数字，然后查看了.js文件中占文件总数(.js + .cs)的一小部分的文件数。 
• So, that leaves 85.4% of all projects which are entirely in C#, with no UnityScript files at all.因此，剩下的所有项目中有85.4％ 完全是C＃，根本没有UnityScript文件。 
• 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.所有项目的9.5％ 主要 是C＃–它们具有一些UnityScript文件，但少于脚本文件总数的10％。 在所有项目中，另有1.5％的代码在UnityScript文件中占10％至20％。 
• That leaves 3.6% of all projects that have more than 20% of their code in UnityScript.剩下的3.6％的项目在UnityScript中拥有超过20％的代码。 
• Only 0.8% of all projects are exclusively (i.e. 100%) in UnityScript.所有项目中只有0.8％是UnityScript中专有的(即100％)。 

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.

这向我们表明，仍然有UnityScript代码的大多数人并未大量使用它。 您甚至可能根本没有积极使用它：项目中的.js文件可能是Asset Store软件包的示例脚本，而不是您实际依赖的代码。 因此，我们弃用计划的早期步骤是开始与Asset Store发布者合作，以摆脱提供这些文件的软件包-有关更多信息，请参见下文。 

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.

对于3.6％的用户(尤其是仅使用0.8％的用户)使用率更高，我们深表歉意。 我们知道这个决定对您很不利。 我们正在采取一些步骤来尝试平滑过渡，下面将对此进行介绍； 我们希望您最终会同意我们的看法，这最终是值得的。 

怎么会这样 (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.

首先，从6月初开始，我们已经修改了资产商店提交政策，以拒绝包含UnityScript代码的软件包。 您为Asset Store软件包编写的所有新代码都应使用C＃。 (在进行此操作之前，我们先经过了Asset Store Publishers讨论组，以使他们有所了解)。 很快，我们将开始扫描资产商店中的所有现有软件包，以查找包含UnityScript文件的软件包，并将与发布者联系，要求他们将代码移植到C＃。 一段时间后，所有尚未移植的软件包都将从商店中删除。 

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.

其次，您可能已经注意到：Unity 2017.2 beta 在“创建资产”菜单中 不再具有“ Javascript ”(又名UnityScript)选项。 至此，我们要做的就是删除菜单项。 所有的支持仍然存在，您仍然可以在Unity之外创建新的UnityScript文件(例如，通过MonoDevelop)。 我们这样做是为了确保新用户不会继续采用UnityScript。 当这个世界不长时，让他们花时间去学习它是不负责任的。 

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.

第三，我们已经开始使用UnityScript-> C＃自动转换工具。 已经有一些这样的方法了，但是我们对它们使用的方法并不满意。 在编写脚本更新程序时，我们已经学到了很多有关在UnityScript代码上进行操作的知识，因此我们决定仅应用这些知识并构建自己的解决方案。 我们尚未决定是将其直接集成到Unity还是作为单独的开源工具使用，但是无论哪种方式，我们都希望在2017.2年底之前可以使用。 准备就绪后，我们将发布有关此工具的后续博客文章。 

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.

之后，我们将观看我们的Google Analytics(分析)编号。 我们的希望是，我们会看到UnityScript的使用出现相当快速的下降-特别是在“少于10％的脚本”组中，这些组的代码迁移较少-但是，如果不这样做，我们将暂停使用计划并调查阻止人们迁移的因素。 有时，这只是时间问题，而其他时候则是真正的问题，我们希望确保在完全关闭之前不会错过任何内容。 

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.

一旦满足使用率足够低的要求，Unity将不再随UnityScript编译器一起提供，也不再将.js文件识别为用户脚本代码。 我们还将从文档中删除UnityScript示例，并从脚本更新器中删除UnityScript支持。 

The UnityScript compiler will remain available on Github at https://github.com/Unity-Technologies/unityscript 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.

如果您需要它， UnityScript编译器将在Github上仍然可用，网址为 https://github.com/Unity-Technologies/unityscript- 我们将不会接受任何对它的拉取请求，但是您可以对其进行派生并将其用于无论你需要什么。 

关于Boo的说明 (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.

我们在2014年宣布， 我们将从文档和Editor UI中删除Boo支持 。 但是，Boo编译器本身一直存在，因为UnityScript实际上是Boo之上的一层–它使用Boo运行时库，而UnityScript编译器是用Boo编写的。 这使您可以继续在项目中使用.boo文件，即使Unity中再也没有提到它了。 

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.

删除UnityScript支持也将意味着最后删除Boo编译器。 此时，在5.6上只有0.2％的项目包含任何.boo文件，并且只有0.006％的项目包含3个以上的boo文件。再次：很抱歉，它的时机已经到了。 

结论 (Conclusion)

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.

展望未来，对于要删除功能的每种情况，这都是我们要遵循的一种过程：宣布我们的意图，通过Asset Store和Editor UI的调整来推动更改，但最终要根据有关你们都在做什么。 

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.

有时过时和过时的功能感觉就像是相反的进步，但这是简化Unity的重要组成部分。 就像森林大火为新的增长扫清了道路，它有助于我们为尽快提供所需的修补程序和功能扫清道路。

Unity原文:https://blogs.unity3d.com/2017/08/11/unityscripts-long-ride-off-into-the-sunset/

本文转自:https://blog.csdn.net/culiao6493/article/details/108642027