【C3官方新闻】Construct3运行时的未来

StoneFan1987 2017-04-07

Construct3运行时的未来

作者：Ashley|2017年4月4日翻译：Stone Fan

当我们首次公开Construct3时，我们说我们的重点在于编辑器的重新设计，并保持与Construct2相同的运行时。将项目的规模放大是一个明智的选择 – 使用全新的技术从底层改写编辑器足以让我们忙碌好几年。

然而，我们不会一直使用相同的运行时。现在，Construct3已经在进行公共测试，我们想告诉你们接下来的主要项目：现在是时候重写运行时了。 一旦Construct3已经稳定下来，并准备好全面启动，这将是我们的下一个重大项目。

Construct2运行时

技术日新月异。 Construct 2运行时已经为我们提供了非常好的服务，但现在它已经显得苍老。它最初是在2011年进行回写，当时微软最新的浏览器是Internet Explorer 8（根本不能运行HTML5游戏 - IE9才具有这个功能），而且没有WebGL，Web Audio或其他一些可以促进现代web游戏发展的技术。自那以后，很难夸大网页平台的改变。运行时还有很多兼容性代码、工作区和特殊方法，专门应对如今几乎无关紧要的平台，比如IE9-10、已停用的Android股票浏览器，以及被弃用的几代非浏览器引擎比如directCanvas（还记得它吗？）和Ejecta。

除此之外，Construct 2运行时的大部分架构基础进行回写时，Scirra还是一个压力很大的创业公司，我们想尽快将产品推出来。早期的基础代码大部分是参照着写的。这在当时是正确的方法，但是后果是现在它正开始限制我们可以用引擎所能做的事情。

因此，运行时代码越来越难以使用，并且添加重要的新运行时功能非常具有挑战性。它需要现代化。这也是大多数新的Construct3功能仅能在编辑器中实现的部分原因。这将最终让它可以做出全新的事情，同时使代码更容易维护和改进。通过重新设计，我们还可以做很多工作来显着改善性能。

Construct3运行时

开发Construct3让我们对Web平台和支持它的浏览器引擎有了独特的认识。我们学到了很多东西，我们热衷于将这些东西应用到新的Construct 3运行时。在许多情况下，我们已经在Construct3中大量改进了代码，我们可以在新的运行时直接重新使用它们，如新的WebGL渲染器。我们可以在整个引擎上做出类似的改进。以下是我们在新Construct3运行时上的目标概述。

使用精心设计的基础架构进行完整底层改写 ，按照稳定，性能最佳，长期耐用的准则进行设计
在Construct3编辑器的整个开发过程中，使用我们开发并经过微调的现代、可扩展和可维护的编码实践 。这也意味着充分利用最新的JavaScript标准，该标准具有可显着提高代码质量的新功能，以及可提升性能的新数据结构。
重复使用Construct3编辑器代码 ，在编辑器和运行时之间共享尽可能多的代码，加快并简化开发
通过在不再使用的浏览器和平台上删除旧的兼容性代码 ，从而简化代码库，使代码更易于使用。
整合了一套现代Web平台API 。 Construct 2具有诸如canvas2d渲染或HTML5音频的许多依赖项，这增加了维护负担并使添加新功能变得复杂。例如，引擎通过仅支持WebGL被极大简化，并且添加新的高级渲染功能变得更加直接。
优化引擎以消除一些长期的低效率。引擎可以进行大范围的更改，例如减少预览/启动时间、减少大型项目中的内存使用，以及使用单一编码实践来使JIT编译器达到最高性能。
更多地利用异步功能和多线程来更好地利用多核CPU，并使用并行预备纹理的技术来加快加载布局
启用在新的环境中托管运行时，如Web Worker或Node中的headless模式
设计师可以使实现重要的新功能，比如模块化事件、改进的函数功能和子布局
使用SDK 为插件开发者提供更为正式的API，展现更多功能并更好地记录功能

原生技术怎么样？

我们在和原生引擎抗衡的事物阐述了我们坚持使用HTML5引擎的原因。用户有时仍会推荐原生引擎，但我们不太信服。我们经常看到用户推荐原生引擎只是一种遇到问题时下意识的反应，而没有考虑原生引擎是否会真正解决这个问题，或者是否值得相应的更换。例如，我们经常看到用户责怪HTML5，即使问题在于硬件的限制，如GPU带宽。在某些情况下，用户禁用了大部分Construct2的优化，却首先认为问题出在HTML5上。我们对用户日常问题的调查表明很少会有问题能通过使用原生技术真正得到改善。当然，HTML5确实有一些问题，但基本上没有平台是完美的。转换技术并不意味着不会有问题。

就和我们最终意识到任何技术网络技术都不完美一样，我们也看到了人们在技术观念上的反HTML5倾向。所以我们仍然抵制原生引擎似乎看起来令人惊讶，但我们的观点是，从整体来说，HTML5真的很好。而且网络一直在不断发展。例如GPU黑名单曾经是一个大问题，但现在只影响到大约4％的设备，并且还在不断减少。另一方面，WebGL 2代表了Web平台渲染功能的一个重大升级，恰好最近发布了。改进的步伐仍然很强劲，网络技术比以往更加稳健。

WebAssembly怎么样？

WebAssembly是一个有趣的技术，我们觉得它比原生技术的完全转变更有吸引力。然而，虽然性能显然是一个特别重要的考虑因素，但在实践中，还有开发的许多其他方面需要考虑。我们在Construct Classic时期得的一个重要教训是，对引擎过度进行优化可能会导致引擎错综复杂、极其棘手的bug，以及用户在处理重要的可见功能时出现延迟。一味地为了追求性能而牺牲其他所有东西是不明智的。

让开发和维护尽可能简单有助于我们快速的使用引擎，这也是重要的考虑因素。我们在引擎中使用WebAssembly会出现一些问题，包括：

WebAssembly是一种年轻的技术，相对于更成熟的技术而言，它的工具和支持在这一点上是相当不成熟的，特别是在调试等方面。它目前还不能直接访问浏览器API，这将使运行时架构复杂化。
编译到WebAssembly通常涉及使用静态类型的编译语言。这些当然具有优势，但使用更严格的语言和提前编译器涉及较慢的迭代。我们真的喜欢现代JavaScript的发展速度。
Construct3使用高度模块化的架构，每个插件和行为独立写入。对于第三方开发人员来说，使用JavaScript之类易理解的语言是很有价值的，而且我们也很容易添加官方插件和行为。即使使用WebAssembly引擎，我们仍然希望将JavaScript用于许多最大性能不重要的官方插件，例如媒体，网络或表单控件相关的插件。交互使用JavaScript和WebAssembly比在所有地方都只JavaScript更复杂，并且可能涉及性能开销。实际上，Construct2运行时以很高的频率在引擎和插件代码之间进行切换，使得切换时很小性能开销也可能抵消使用WebAssembly的任何好处。

特别是最后一点，我们认为使用WebAssembly几乎是一个不全则无的命题：整个引擎和所有插件和行为都用WebAssembly编写的，或者全部不用，我们坚持使用JavaScript。我们决定坚持所有地方都是JavaScript。其中的一些原因是：

如上所述，我们相信，我们可以做很多工作来显着提高性能，而无需改变JavaScript。

我们希望插件开发人员和我们自己都能够轻松快速地开发插件。

它也使得开发核心引擎变得轻松快捷。

我们还可以直接从编辑器复用代码，如新的WebGL渲染器，而不必重新编写，然后用不同的语言来维护这些组件。

所以基于这些原因，我们决定坚持在新引擎上使用JavaScript。我们仍将尝试使用asm.js / WebAssembly来让可以从中受益的特殊功能实现最大的性能，如已经使用asm.js的物理引擎。

三个运行时

为了澄清我们的开发方法，一旦启动了Construct 3运行时，我们实际上将维护三个不同的运行时：

Construct 2编译器中的Construct 2运行时（C2）：这将持续维护，就像我们多年以来在Construct 2上所做的一样。
Construct 3编译器中的Construct 2运行时（C2.3）：这是Construct 2运行时，具有一些可在新编辑器中兼容的修改，以及Construct3改进相对应的各种升级，例如用于新编辑器的改进过的精灵表单化支持。
Construct3编译器中的Construct3运行时（C3）：这是我们在这篇文章中正在讨论开发的新运行时。

这篇文章的其余部分专注于叙述在Construct 3编辑器中过渡到新的运行时。我们将使用术语C2，C2.3和C3来指代上述运行时，以清楚表达我们的意思。

过渡到新引擎

我们将努力确保新的C3运行时与以前的运行时兼容。尽管这证明是困难的，而且在某些情况下，我们可能想要刻意改变行为，以实现更好的性能，或使引擎在长期内更加稳健。我们将尽可能多地仔细记录这些情况，以便更容易地移植内容。

将插件移植到Construct3到目前为止只涉及重写插件的编辑端。将第三方插件移植到新的C3运行时还会涉及到重写运行时端，这往往是一个更大的工作。我们在发布之后尽快做这件事的原因之一是为了能够着手移植，这可能是一个持续的项目。从长远来看，希望这样一来就不会成为一个问题。与编辑端一样，我们将提供新SDK的详尽文档，协助开发人员进行移植指导。

最后，新的C3运行时可能需要很长时间才能发展到成熟的水平。在此期间，我们将继续维护C2.3运行时。（另外，C2运行时也将作为Construct2持续维护的一部分进行维护。）此外，一旦C3运行时可用，C2.3运行时仍然可以在可预见的未来得到支持。理论上讲，我们终有一天会停止支持C2.3运行时，但我们认识到许多开发人员的项目经历多年的发展，可能依赖于仅在某一个运行时可用的第三方插件，或者可能太复杂，无法移植到新的运行时。因此，您可以选择项目使用的运行时。如果您的项目兼容，您还可以切换运行时，因此您可以在新运行时中尝试现有项目，如果没有问题，请继续使用它。希望这可以带来二者的最好结果：依赖C2.3运行时的长期开发项目具有可预测性，以及新项目或可移植的任何现有项目拥有C3运行时的新功能和改进的性能。

我们经过几个阶段来使新的运行时可用。目前还需要大量的工作。不管怎样，下面谈谈我们将如何推出它：

一旦它准备好进行简单的测试，它将作为一个隐藏的选项提供给有经验的用户尝试，并可让插件开发人员开始移植工作。

随着进一步开发，它将成为一个可见但默认关闭的选项，因此很容易进行尝试。

一旦我们有信心，新项目将默认使用新的运行时，只有现有的项目将保留在旧的运行时。尽管如此，他们也可以通过手动切换到新的运行时进行升级。

嗨，新功能！

一旦架构工作完成并且项目能够被移植，我们将会有一个更快更好的基础来创建主要的新功能。我们渴望通过新的运行时来处理许多长期的请求。我们想要创建的一些新功能包括：