关于Udon 2、荞麦面（Soba）以及我们为什么改变方向

原文地址：https://ask.vrchat.com/t/on-udon-2-soba-and-why-we-changed-directions/28484

大家好！所以，让我直接切入正题：我们宣布的荞麦面/Udon 2 的方向改变并不顺利。

我们本可以做得更好，这首先要解释我们最初改变方向的原因。

Udon 2 开发烦恼

从社区的观点来看，Udon 2 是对 Udon 的大规模升级，将提供更多功能和显着的性能改进。然而，幕后的开发比最初预期的更为困难。

尽管我们较早便意识到其中许多问题，且这些问题似乎是可以解决的。然而随着时间的推移，随着开发的进行，越来越多的问题开始浮现。其中一些问题与 Udon 2 最初的性能承诺有关。

内部基准测试显示，虽然在某些情景下，Udon 2 的初始性能改进保持不变，但这些情景非常受限，不太可能模拟“实际使用”中的情况。

尽管数学密集型代码会有所改进（这也是我们将程序生成的迷宫作为性能提升基准的原因之一），但更多的标准代码不会获得同样巨大的好处。

深入研究 Udon 2 的性能斗争

更深入一点：在Udon中为优化而构建的代码使用了在 Udon 2 中反而适得其反的技术。就目前而言。如果您想在Udon中编写高性能代码，我们会鼓励您使用EXTERN调用（在本机C#环境中在Udon外部执行的函数）。

然而，在Udon 2中，过于依赖EXTERN调用会导致由于编组（将数据复制到Udon 2中，以及从Udon 2中复制数据的过程）而造成的重大负效应。这些负效应十分严重，以至于在某些情况下它们会抵消 Udon2 的执行速度加成，导致整体性能变差。

我们从一开始就积极传达了这一点：我们认为我们仍然有理由向前推进，因为您会从这一更新得到许多提升。如果改变代码编写方式，创作者将会获得更多好处。然而，事实证明这并不完全正确，实际情况是，（在最糟糕的情况下）您需要完全重写代码才能获得上述的好处。

随着开发的进行，我们越来越感到这是一个坏主意。如果为大多数高级创作者使用的另一种语言编写“续集”，并告诉他们必须以不同的风格重写他们的代码才能获得任何显着的好处，这并不完全“创作者友好”。

为创作者发现主要问题

此外，如果您没有使用 Udon 2 SDK 重新上传您的世界，Udon 2 客户端将在 “兼容模式” 下运行，该模式在 Udon 2 中运行 “原始” Udon 。这几乎总是比 “原始” Udon 自己运行的速度慢——在内部基准测试中，这种兼容模式运行现有代码所需的时间是 2 到 10 倍。

这造成了这样一种情况，我们不得不决定要么在客户端中同时包含 Udon 和 Udon 2（这导致了比 Udon 2 已有的更大的内存占用），要么提供这个兼容模式，这将为任何使用“旧”Udon 代码的人带来麻烦——这将迫使他们修复一堆编译器错误。 否则他们将无法上传他们的世界。

这是一个已经努力了几个月但没有任何重大进展的问题，并且是 Udon 2 向创作者提供的又一个主要障碍。

沉没成本谬误和减少损失

当然，人们都非常希望让Udon 2项目成功，但某种程度上，我们似乎已陷入了巨大的沉没成本。正如评论者所指出的，这个项目已经投入了两年的工作（最初预计只需要3到6个月完成），并且从工程方面来看，仍有一些问题有待解决。

Udon 2 是一个复杂的项目，使用复杂的代码构建。这导致了性能测试和问题诊断的严重困难，团队中的工程师正努力让Udon 2能够稳定地运行在“真实情况”的项目中。

同时，我们也必须考虑到最终用户体验可能会受到多大的负面影响。强迫用户重写他们的代码并不仅仅只是为了提高性能，更重要的是确保他们的代码能够被完全编译。这已经成为一个严重的问题。

Udon 2 继续遇到障碍

在开发后期，随着Udon 2越来越多地进入我们的内部QA团队接受测试，这些问题变得更加明显（以及更多问题——其中一些在上一个帖子中已经举例，例如在所有平台上严重增长的内存占用）。

问题也出现在了Udon 2在VRChat客户端和Unity编辑器之间的性能差异上。虽然这种情况在初代Udon上也有发生，但相对来说表现相当一致和可预测——而在Udon 2中，性能差异变得更加巨大且不一致。这意味着您可能会根据编辑器中的性能来调整代码，并期望在VRChat中运行时更快，然而实际结果却可能出现严重的性能下降。

认真审视 Udon 2

最终，上述所有这些问题都导致了一个非常现实的内部问题：Udon 2是否可以如期发布？我们是否能够实现最初对Udon 2发布所做的承诺？

全力以赴开发Udon 2可能会带来一些额外的风险，这带来了更多的问题：如果我们将Udon 2作为完全替代Udon发布，我们愿意放弃多少内容？需要多长时间才能使旧的VRChat内容“兼容”？

由于Udon 2的开发分支严重落后于VRChat的主开发分支，这些问题变得更加棘手。使Udon 2在最新版本的VRChat中运行需要数周甚至数月的时间。Udon 2的内部分支变得如此复杂，以至于本质上，团队中的大多数人都无法完成功能，从而导致了严重的开发瓶颈。

这引发了对项目的大规模工程审查。结果显示，在Udon 2上继续开发是不负责任的。发布、维护、改进或提供更多“用户友好”工具，所有这些任务都是遥不可及的。

于是问题变成了“好吧，Udon 2无法发布。我们是否仍然可以实现项目最初设定的目标呢？”

我们为什么继续使用 Soba

接着，团队内部提出了一个关于 Soba 的建议。Soba 的立场非常简明：它实现了大部分最初承诺的功能，并以一种更易于团队维护和快速迭代的方式实现。此外，它也解决了之前讨论过的一些工程问题。例如，与 Udon 2 相比，Soba 不需要进行繁琐的封装处理。

总而言之，尽管 Soba 的水平尚未达到与 Udon 2 相等，但它的发展速度要快得多。同时，Soba 是从头开始进行构建的，侧重于实现可维护性和可扩展性，而不是试图将各种技巧拼凑在一起使其运行正常。

我们也注意到一些人担心 Soba 未能解决 Udon（或 Udon 2）对新创作者不友好的问题。尽管我们有这方面的意愿并给予了关注，但我们正在努力避免回到旧有的 VRChat 行为方式，即承诺一切但却无所兑现。我们将完成当前任务，然后收集反馈，认真规划后续步骤，然后进行迭代。

经验教训，向前迈进

在这篇文章中，我们对共享基准测试如此谨慎的原因是因为上述历史记录。在很大程度上，这也是旧VRChat的遗产，但运行方式有所不同。我们现在更加专注，这使我们能够完成长期存在的项目（如Persistence）并解决社区的主要问题（如Age Verification），而无需像过去那样转动轮子。

我不必再多说了，我知道创作者社区真正关心的其他项目还没有越过终点线。我们知道。此外，我们知道您希望它们更加透明。这篇文章可能面临一个明显的大问题：我们怎么知道这些事情也不会发生？

坦率地说，我不能保证它们不会。然而，如果它们被删减、延迟或更改，我们认为社区至少应该立即得到一个答案，就像这篇文章一样详细。

在Udon 2的开发过程中，我们吸取了许多教训，其中许多是惨痛的教训。虽然这篇文章不会让失去Udon 2变得更轻松——我们知道我们炒作得太多了，而且我们知道它有希望实现创作者真正想要的东西——但我们希望它让我们的决定更容易被理解。