Unity和iOS 4.0更新III

Dear community, once again I’d like to start by offering my thanks to everyone for their patience through an unclear situation. We’re grateful for the dedication and commitment many of you have shown through all this and it once again serves as another reminder of just how awesome our community is.

亲爱的社区，我想再次感谢大家在不明情况下的耐心等待。 我们感谢你们中许多人的奉献精神和奉献精神，这再次提醒我们我们的社区多么出色。

Like everyone else who’s excited about mobile development, and in particular using Unity to create awesome games for the iPhone, we’ve been following the development of the iOS 4.0 Terms of Service closely. While we’ve had some reason to believe Unity using C# and JavaScript would be okay, Apple has not confirmed anything and in general very little information has been forthcoming. However, as of today Apple is still approving every game we know of and Apple has recently featured several excellent Unity games in the App Store. And all along we’ve continued to invest heavily in our Unity iPhone line, including a number of new features that will be coming soon in the Unity 3.0 release. But as soon as the new terms of service were revealed we also started working on a contingency plan, just in case Apple decides to stop approving Unity-based games. Allow me to explain that contingency plan so everyone out there knows what “plan B” looks like.

像其他每个人一样对移动开发感到兴奋，尤其是使用Unity为iPhone编写出色的游戏时，我们一直在密切关注iOS 4.0服务条款的开发。 尽管我们有一定的理由相信使用C＃和JavaScript的Unity是可以的，但是Apple尚未确认任何事情，并且总体而言，几乎没有信息。 但是，到目前为止，Apple仍在批准我们所知道的每款游戏，并且Apple最近在App Store中推出了几款出色的Unity游戏。 一直以来，我们一直在Unity iPhone系列产品上投入大量资金，其中包括许多即将在Unity 3.0版本中推出的新功能。 但是，一旦新的服务条款公布，我们也将开始制定应急计划， 以防万一苹果决定停止批准基于Unity的游戏。 请允许我解释该应急计划，以便所有人都知道“计划B”的模样。

As you probably know, Unity is mostly written in optimized C++ with assembly optimizations and Objective-C wrappers thrown in for good measure. Game logic is written by the developer, using C# and JavaScript, both of which are running on top of .NET. The beauty of this scheme is that we’ve been able to sidestep the old scripting-versus-native question as .NET provides for very rapid development (and almost near-instant compilation), while at the same time generating highly optimized code. And on the iPhone we actually ahead-of-time compile .NET to completely static machine code for speed and conformance with the old iOS Terms of Service. Also, on the iPhone it’s easy to drop into Objective-C code to access fresh APIs like the Game Center, Core Motion, etc. This is truly a case of best of both worlds.

您可能知道，Unity大多数情况下都是使用经过优化的C ++编写的，并具有汇编优化和良好的Objective-C包装器。 游戏逻辑是由开发人员使用C＃和JavaScript编写的，它们都在.NET之上运行。 该方案的优点在于，由于.NET提供了非常快速的开发(和几乎即时的编译)，而我们同时又生成了高度优化的代码，因此我们能够回避旧的脚本与本机的问题。 在iPhone上，我们实际上是提前将.NET编译为完全静态的机器代码，以提高速度并符合旧的iOS服务条款。 另外，在iPhone上，很容易放入Objective-C代码来访问诸如Game Center，Core Motion等的新鲜API。这确实是两全其美的情况。

Since Unity’s .NET support may conflict with the new terms of service, we are working on a solution where entire games can be created without any .NET code. In this proposed scenario all the scripting APIs will be exposed to and can be manipulated from C++. This is of course not ideal as there are thousands of code examples, snippets, and extensions created by the community can no longer be copied into your project, .NET assemblies can’t simply be dropped in, and C++ is more complex than JavaScript or even C#.

由于Unity的.NET支持可能会与新的服务条款冲突，因此我们正在研究一种无需使用任何.NET代码即可创建整个游戏的解决方案。 在这种建议的方案中，所有脚本API都将公开给C ++并可以从中进行操作。 当然，这不是理想的，因为社区创建的成千上万的代码示例，代码片段和扩展无法再复制到您的项目中，.NET程序集不能简单地放入其中，并且C ++比JavaScript或甚至C＃。

But honestly, it’s not as bad as one might imagine. One still has the full benefit of the asset pipeline, the shader language, an array of tools and of course the engine and its optimizations. We are also working on maintaining the elegant workflows of the JavaScript and C# in Unity: “scripts” will still be able to be edited live, variables will still be shown in the inspector, and a number of other sweet features that one doesn’t usually associate with C++ development. Essentially we are creating a .NET based C++ compiler that will allow us to write purely managed C++ code in the Web Player and other Platforms. On iOS C++ code will be compiled by Apple’s Xcode tools. This indeed is a very powerful combination. In the Unity Editor, you have fast compilation times and a completely sandboxed environment. On the device you have native C++ performance and low memory overhead. This combines the key strength of scripting languages and C++ code.

但老实说，这并不像人们想象的那么糟糕。 仍然可以充分利用资产管道，着色器语言，一系列工具，当然还有引擎及其优化。 我们还在努力在Unity中维护JavaScript和C＃的优雅工作流程：“脚本”仍将可以实时编辑，变量仍将在检查器中显示，许多其他甜美的功能却没有通常与C ++开发相关。 本质上，我们正在创建一个基于.NET的C ++编译器，该编译器将允许我们在Web Player和其他平台中编写纯托管的C ++代码。 在iOS上，C ++代码将由Apple的Xcode工具编译。 这确实是一个非常强大的组合。 在Unity编辑器中，您具有快速的编译时间和完全沙盒化的环境。 在设备上，您具有本机C ++性能和低内存开销。 这结合了脚本语言和C ++代码的关键优势。

When you combine those with the fact that when it comes to straightforward game logic, C++ really isn’t as complex as it’s often made out to be (and as it can be) hopefully you can see that life won’t be so bad after all. To help demonstrate my point, let’s look at a few different examples.

当您将这些知识与简单的游戏逻辑结合在一起时，C ++实际上并不像通常所说的那样(并且可以如此)那么复杂，希望您会发现生活在以后不会那么糟糕所有。 为了说明我的观点，让我们看几个不同的例子。

Here is a simple JavaScript function to rotate an object around the world origin:

这是一个简单JavaScript函数，用于围绕世界原点旋转对象：

And now here is that same bit of code written in C++:

现在这是用C ++编写的相同代码：

As you can see the code required isn’t all that different in simple case scenarios, but what about a more complex example?

如您所见，所需的代码在简单的情况下并没有什么不同，但是一个更复杂的示例呢？

Here is a bit of JavaScript that peeks accelerometer and looks for user touch input on an iOS device, then uses that to fly a craft and fire a missile in the game:

以下是一些JavaScript，它可以窥视加速度计并在iOS设备上寻找用户触摸输入，然后使用它来飞艇并在游戏中发射导弹：

And again, here is that same set of code in C++:

同样，这是C ++中的同一组代码：

Again, the code doesn’t get that much more complicated just by writing it in C++ versus JavaScript, and the difference is even smaller compared to C#.

同样，仅使用C ++和JavaScript编写代码并不会变得更加复杂，与C＃相比，差异甚至更小。

We continue to be excited about the iPhone, iPod touch and iPad as platform targets for Unity developers. While we don’t think C++ is the best language to write game code, using C++ as a scripting language has memory and performance advantages on low-end devices. This is a great feature to have for developers who want to squeeze the last ounce of memory & performance out of their games.

iPhone，iPod touch和iPad作为Unity开发人员的平台目标，我们继续感到兴奋。 尽管我们认为C ++不是编写游戏代码的最佳语言，但将C ++用作脚本语言在低端设备上具有内存和性能优势。 对于想要从游戏中挤出最后一点内存和性能的开发人员来说，这是一个很棒的功能。

We still can’t believe Apple will force developers into choosing a specific language for development. And as mentioned, Apple is still approving every Unity-based game we know of. In case the situation changes, rest assured that we are working this Plan B.

我们仍然无法相信Apple会迫使开发人员选择特定的开发语言。 如前所述，Apple仍在批准我们所知道的所有基于Unity的游戏。 如果情况发生变化，请放心，我们正在执行此计划B。

We’ll be ready to talk more about this as well as share some time-line information with you soon, while of course waiting to find out if any of this will actually be necessary.

我们将准备就此进行更多讨论，并尽快与您分享一些时间表信息，同时当然还要等待找出其中是否确实有必要。

翻译自: https://blogs.unity3d.com/2010/07/02/unity-and-ios-4-0-update-iii/