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

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

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

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

我们相对较早就知道其中的许多问题，但它们似乎是可以解决的。随着时间的推移，越来越多的问题开始随着开发而出现。其中一些问题首先与 Udon 2 的初始性能承诺有关。

内部基准测试表明，虽然在某些情况下，Udon 2 的初始性能改进保持不变，但这些情况非常具体，不太可能模仿“现实生活”的使用。

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

更深入一点：在 Udon 中为优化而构建的代码使用了在 Udon 2 中直接适得其反的技术。在 Udon 中，就目前而言，如果您想编写高性能代码，则会激励您将工作外包给 extern（在本机 C# 环境中在 Udon 外部执行的函数）。

然而，在 Udon 2 中，过于依赖 extern 会导致由于编组（将数据复制到 Udon 2 中和从 Udon 2 中复制数据的过程）而造成的重大惩罚。这些惩罚足够严重，以至于在某些情况下它们会抵消乌冬面 2 的执行速度加成，导致整体性能变差。

我们很早就以积极的方式传达了这一点：我们认为仍然有理由向前推进，因为您会立即获得大量好处，如果您改变编写代码的方式，您可以获得更多好处。事实证明这并不完全正确，现实情况是，在最坏的情况下，您需要重写代码才能获得任何好处。

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

此外，如果您没有使用 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 进入我们的内部 QA 团队，这些问题（以及更多问题——其中一些在上一个帖子中共享，例如所有平台上的严重内存回归）变得更加明显。

VRChat 客户端和编辑器之间的 Udon 2 性能差异也出现了其他问题。虽然这发生在原始乌冬面上，但它是相当一致和可预测的——在乌冬面 2 中，这些性能差距是巨大且不一致的。这意味着您可能会调整代码，由于它在编辑器中的性能而期望它更快，然后在 VRChat 中运行它并看到严重的回归。

最终，上述所有这些问题都导致了一个非常现实的内部问题：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 尚未达到与 Udon 2 同等水平，但它的发展速度要快得多。同样，它是从头开始构建的，重点是在多个贡献者之间实现可维护性和可扩展性，而不是试图将一系列技巧拼凑在一起以使其正常工作。

我们还看到一些人担心 Soba 未能解决 Udon （或 Udon 2）难以为新创作者使用的问题。虽然我们想这样做，并且我们很注意这一点，但我们正在努力避免回到旧的 VRChat 思维方式，即向世界承诺，但什么都不兑现。我们将完成此任务，然后获取反馈，仔细规划后续步骤，然后进行迭代。

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

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

诚实的回答？我不能保证他们不会。然而，如果它们被删减、延迟或更改，我们认为社区至少应该立即给出一个答案，就像这个一样详细。

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