12月19日，油管频道主Kaupenjoe发布了他和Hytale技术总监Slikey的访谈
视频已经把访谈全文压缩了，但仍然很长。
为了照顾大家的注意力，我读了一遍原文，把内容缩减到了一千多字，保留了所有关键信息，发了个视频。
【12月19日Hytale访谈省流版，Mod一切！】
然后，以下是访谈全文翻译，哈基米翻的。
Q1: 能否详细阐述Hytale背后的核心技术设计理念？这些理念如何影响模组支持？
A1: 让我先回顾一下我们的背景。我们运营着世界上最大的Minecraft服务器已近十年。我们将Minecraft推向了远超其原有极限的境地。我们创造了完全基于服务器端的原创概念，如Pixelpainters、Warlords、Turbo Kart Racers、Galaxy Wars等... 我们在一款原本极其受限的游戏中探索了服务器端模组开发。
Hytale的核心理念是，Hytale的引擎不仅支持一款沙盒游戏，更支持一个沙盒创作过程。从第一天起，我们就知道我们希望在Hytale内部构建Hytale。我们在服务器端模组开发的背景中，一直饱受“如果我们只拥有那一个缺失的拼图碎片，我们就能做这么多事情！”这种想法的困扰。Hytale的愿景就是将那一整袋拼图碎片倒在桌上，然后拼凑起来。
我们的目标从来不是成为某个XYZ杀手级游戏，甚至不是走向主流。我们只是试图制作我们所需要的游戏——我们过去是，现在也是我们的第一个客户。这一理念贯穿了整个开发过程。目标是没有任何内容是硬编码的，一切都通过我们的资产系统，以利用其广泛的功能集和工具。
在底层，服务器中有3个重要的技术系统：
- 实体-组件系统：游戏的内存和运行时模型，旨在防止面向对象的编程模式破坏模组开发。
- 资产系统：游戏的JSON数据配置层，负责加载、保存、验证和热重载资产。
- 插件系统：加载服务器的扩展，例如事件处理器、资产类型、组件类型、系统例程等。
这3个系统是我们服务器的内核，构成了Hytale的骨干。其设计本身就是高度模块化和可选的。
我们遵循的理念是：“我们希望模组开发者能够从Hytale中移除Hytale，转而创造属于你自己的Yourtale。”
Q2: 在团队的第一篇博客文章中，他们提到“非开发者只需最少的专业知识就能创造出令人印象深刻的体验”——对于程序员和非程序员来说，模组制作将有多容易上手？首先在抢先体验阶段，然后未来的愿景是什么？
A2: 考虑到我们急于推出抢先体验版，我认为你会发现我们系统中的成熟度各不相同：
- 成熟: 这些功能在我们的资源编辑器中已经得到了很好的支持。它们可以在我们的游戏内/原型节点图编辑器中轻松编辑，并且不需要编程经验。这类功能包括方块、世界生成v2、物品、视觉特效、建模、动画、掉落表、制作、天气等。
- 可模组化: 这些功能已经非常丰富且可扩展，但通常缺乏良好的编辑器集成和工作流程。有时你需要深入底层的JSON文件进行修改，或者编写自定义插件来扩展它们。这类功能包括NPC、交互、库存、摄像机等。
- 原型: 这些功能通常是硬编码的，或者目前还不能从服务器端进行扩展。我们通常会先让某个功能运行起来，然后再去完善它，以避免过早复杂化的谬误。我们需要确保我们以1、2、3种或更多不同的方式来理解一个功能，以便明白应该构建什么样的抽象。你会遇到不少这样的系统。我们的目标是尽快将它们带入可模组化阶段。这类系统包括物理、输入、着色器、视觉效果等。
- 已弃用（待移除）: 游戏中的一些系统将被移除，取而代之的是更新的系统。这些系统之所以还存在，是因为我们未能完成过渡。这类功能包括自定义UI（我们正在将所有UI迁移到使用XML布局的NoesisGUI，并逐步淘汰我们的.ui文件）、事件总线（旧的已被EcsEvents取代的事件系统）等。
我们不仅仅是在添加我们自己需要的功能。我们添加任何有意义并且我们能够维护的功能。我们一直在寻找用例和局限性，以调整我们的系统设计。如果你希望加入某个功能：请告诉我们你想做什么，以及为什么Hytale阻止了你实现它。我们越了解这个局限性，就能越快修复它。
Q3：当我设想Hytale模组制作时，我应该想到MC锦标赛、Hypixel或其他MC Java服务器所创造的那些东西吗？这些功能是否可以通过类似于Minecraft插件的服务器端插件模型来实现？
A3：我认为你应该想得更远。我们创造Hytale是因为我们在
@HypixelNetwork
上遇到的限制。看看我们的一些游戏模式，比如《Warlords》。那是《魔兽世界》经典战场战歌峡谷和阿拉希盆地的重现：https://youtu.be/bYdLW6CdBo0?si=S1LcK3SKxvCBCOVu&t=202（示例视频）
最令人瞩目的缺失之一是视觉特效。同时，我们无法添加“新”物品——我们不得不使用资源包重新设计盔甲外观，这限制了我们实际能制作的内容量。我们不得不滥用屏幕侧边的记分板来显示统计数据，而不是拥有一个合适的自定义用户界面。即使是一些简单的功能，也本可以让整个体验好得多！
在这个视频中：https://youtube.com/watch?v=PEbF0h_...le成为服务器权威的。你可以看到服务器无法控制的客户端修改是如何破坏我们预期的游戏体验的。
我们在Minecraft中最大的问题之一是缺乏“传输”数据包，以及需要运行一个名为“BungeeCord”的代理。这个代理的存在仅仅是为了让多个Minecraft服务器表现得像一个单一的Minecraft服务器。我们使用这些代理进行负载均衡和在实例之间移动玩家。它们的运营成本极其高昂，并且也构成了单点故障。
所以，当我说你应该超越我们在Hypixel网络上所创造的东西时，我指的是超越我们所做的，以及如果仅仅拥有一些更好的功能本可以做到的事情。我们梦想中的Hytale，是允许玩家在Hytale中制作一个类似《EVE:Online》的太空大型多人在线角色扮演游戏。我们希望以这样一种方式支持模组制作者，让他们能够震撼所有人，并远远超越我们在拥有216k CCU和3000万以上UU的服务器网络上所取得的任何成就。
Q4: Hytale的更新将如何运作？团队对于API稳定性和版本控制的方法是什么？模组是否需要为每个新版本进行重大重写，还是会保持一定的向后兼容性？
A4: 这是个棘手的问题。我们将发布一个启动器，提供两个补丁线：“正式版”和“预发布版”。
- 正式版：当前推荐的游戏版本
- 预发布版：即将到来的游戏更新（提前约1周）
我们打算让玩家始终更新到正式版补丁线上的最新版本。这个决定同样是基于过去的痛苦经验做出的。直到最近，Hypixel网络上超过50%的玩家仍在使用1.8版本。我们支持从1.8到1.21的每个版本，但维护这种协议兼容性带来了很多痛苦。这种版本丛林问题已经困扰我们十年了，我们不希望Hytale玩家也经历这些。
我们旨在为我们的API、配置等制定适当的弃用政策。遗憾的是，现在我不得不告诉你更多坏消息：抢先体验的头几个月可能会很混乱！在我们解决最严重的问题时，我们必须快速行动，这也意味着我们不得不牺牲兼容性来走捷径。我预计这不会像影响几乎无法修改或已弃用的系统那样，对成熟的系统造成太大影响。
在抢先体验发布后不久，我们将在只读的Github仓库中发布服务器源代码，同时我们也在努力开放贡献。此外，您将获得我们的Gitbook文档访问权限，该文档将逐步包含我们系统的所有细节，以解释其目的和我们为其制定的路线图。这些都是重要的透明度努力，旨在让模组制作者了解未来的发展，但随着时间的推移，我预计系统会稳定下来，并被认为是“足够好”的，只进行迭代更改，从而使弃用政策变得容易。
Q5: 是否有计划创建一个官方的模组发布和管理平台，类似于Modrinth和Curseforge，但是官方的？如果有，这个系统会类似于Roblox或Minecraft基岩版中的市场吗？
A5: 我们已经与
@CurseForge
合作，以启动Hytale模组制作。这次合作并非排他性的，我们也在与其他UGC市场合作，为它们带来Hytale支持，但只有Curseforge支持多款游戏，并且能够在其团队内部调动足够的资源来与我们一同打破这个“诅咒”。
他们提供了极大的帮助，通过将我们与模组制作者联系起来、创建教程和示例模组，为我们分担了大量工作。这次合作，令人难以置信的是，没有任何附加条件，Curseforge在这里确实值得高度赞扬，因为他们如此以创作者为导向，并且总体上非常支持Hytale。
我们计划将模组制作直接整合到游戏中。这与我们长期的创作者战略紧密相连。我们正在制定一项战略，使我们能够保持模组的免费和可访问性，同时又能让模组制作者获得丰厚的回报和财务上的成功。我们正尝试在整个UGC奖励机制上进行创新，我们相信Hytale能够提供一个优秀的生态系统，真正为玩家和模组制作者带来模组和模组制作的新黄金时代。我们将共同克服“购物中心”式的模组体验，创造出能够持久存在、并且让我们在道德上感到自豪的东西。
Q6: 从技术角度来看，模组化装饰品大体上是如何运作的？引擎如何处理模组化装饰品的资源交付和同步？例如，我能否制作自定义装饰品，并且当我加入服务器时，其他人能看到这些装饰品，还是这一切都基于服务器？
A6: 这已经成为一个有争议的话题，我认为我们在解释全貌方面做得相当糟糕。
Hytale有两种类型的装饰品：
- 全局装饰品：这些是你在角色创建界面可以选择的外观。它们将是你加入单人游戏或任何多人游戏时的默认外观。
- 服务器装饰品：这些由单人游戏/多人游戏中的模组提供。假设你安装了“Yuki的动漫衣柜模组”。你会获得一个可制作的动漫服装衣柜，该模组允许你在单人游戏中自由使用它。这些装饰品不会改变你在主菜单中看到的角色外观，也不会被带到另一个服务器。
政策：玩家喜欢他们在Minecraft中的个性化皮肤纹理，但我们也看到了硬币的另一面。我们不得不在Hypixel网络上封禁了5万个皮肤纹理。但这并不是我们这样做的唯一原因。我不想将这一决定完全归咎于安全考虑。我们以20美元的价格出售游戏（即将推出区域定价），我们预计，如果没有某种形式的货币化，我们将无法永远维持工作室的运营成本。我们审视了整个游戏，发现真正侵入性最小的选择就是角色自定义。
我们不会为这些装饰品添加任何开箱机制。我们承诺提供透明的购买方式！
@Kaupenjoe
对A6的看法：
作为来自Minecraft Java版和完全自定义皮肤的玩家，这肯定是不同的！然而，我认为关键在于，这将更接近于Roblox角色编辑器或Minecraft基岩版市场处理其自定义系统的方式！
仍然是高度可定制的角色，拥有很大的自由度，但不是像素级的完美自由！最后一张确认的角色创建器截图来自2019年，但由于这仍然是主要遗留引擎的领域，这很可能仍然是角色自定义的样子：https://hytale.com/news/2019/2/customizing-your-character-in-hytale
只要保持透明，他们也提供高质量的自由选项，并且定价不具有掠夺性，我认为这会运作得很好！
Q7：再举一个技术性的例子，游戏通常有某种游戏循环或滴答系统。我们会有滴答、增量时间或类似的概念可用吗？Hytale 运行在什么样的 TPS 上？
A7：Hytale 服务器采用动态滴答系统。每个滴答系统都基于增量时间运行，但间隔具有可配置的滴答率（默认 30 tps）。当 CPU 负载过高时，TPS 会下降，但通过增加增量时间来维持模拟速度。
Q8: 所以，客户端模组是一个热门话题！在模组博客文章中，你说：“我们不打算支持任何客户端模组”。不少模组制作者对此持相当批判的态度，他们不太习惯这种做法。首先，也许可以解释一下为什么这是核心理念？
A8: 我想我在第一个问题中已经部分涵盖了这一点，但我实际上对这里的策略有一些调整。
服务器端模组的核心理念是：
- 设计师的创作自由：我们已经看到客户端模组如何破坏我们预期的游戏体验，即使不被视为作弊。
- 安全与保障：Minecraft中的客户端模组是.jar文件。你正在你的计算机上运行不受信任的代码。这就像从互联网下载一个随机的可执行文件并运行它。我们已经封禁了数百万因恶意模组而被盗的账户。
- 性能：客户端模组真的会破坏性能，而我们无法优化这些路径。此外，它会进一步加剧版本丛林问题。
- 跨平台：我们正在使用.NET 10和NativeAOT编译客户端，为Hytale登陆游戏机和手机做准备。修改原生应用程序是不可行的。这既困难又耗时。一旦我们为了打击作弊而加上变异的混淆处理，你将会有糟糕的体验。
- Roblox（作为一个例子）：Roblox做了同样的事情。在Roblox中你并不“修改”客户端，但你却看到了截然不同的游戏体验，并且不断有新的功能被添加。
然而：我们已经重新考虑了这项政策，我们可以在这里做出进一步的妥协。我们阅读了所有的反馈，有一个例子最为突出：
“我和朋友在服务器上玩，我们不在乎谁用什么材质包或UI修改。为什么我们必须把它们添加到服务器上？”
这个例子很完美，真的让我明白我们可以做得更多……如果服务器不在乎呢？我们拥有技术能力，可以让客户端自行加载某些类型的资源。比如说一个修改过的纹理。服务器可以告诉客户端它是否在乎纹理更改。如果它在乎，客户端就不会加载那个“客户端资源包”，从而恢复服务器的创作完整性。
这样，当我们添加对高级资源（如着色器图）的支持时，我们可以让它们成为客户端本地的，而服务器不会失去控制。
Q9: 既然客户端模组不受支持，那么团队会提供什么样的API钩子或扩展来让自定义UI、着色器，也许还有一个“Hytale Optifine”成为可能？
A9: 我们的一位团队成员（
@Ktar5
）在推特上发布了一个服务器端UI发送到客户端的示例：https://x.com/Ktar5/status/1991664868131500049
对于着色器，我们目前没有解决方案，但我们正在考虑一种基于节点的着色器图资源，其功能类似于Unity的着色器图。我们在这方面总是会受到更多限制，这将考验我们倾听和交付的承诺。
Hytale Optifine根本不会出现。我们高度致力于性能，特别是在渲染器方面，因为它将不可修改。我们聘请了以制作Minecraft模组“Sodium”而闻名的JellySquid来领导我们渲染器的架构设计。我认为地球上很少有人能像Jelly那样理解方块游戏的渲染和优化。
(编者按：最后几个回答来自我与
@slikey
的对话，当时是德语，所以这是我的措辞和翻译，旨在传达真实信息)
Q10：您说过“没有版本丛林”！是否会有办法回溯到游戏的旧版本？还是人们应该始终使用最新版本？
A10：我们可能会每周向Hytale发布一次更新！提前一周提供预发布版本，以帮助创作者进行模组/插件兼容性测试！总的来说，如果您在发布分支中，它将自动更新，但您始终可以回退一个版本，包括存档文件！
然而，长期愿景是，旧版本将不再由Hytale提供支持。
Q11：我还与Slikey进一步讨论了关于审核或货币化的方法！
A11：我们的目标是透明度和内容过滤系统，而不是严厉的审核。我们希望让玩家能够根据服务器在内容成熟度或货币化策略方面的评级，来禁用服务器的可见性。这意味着从无政府状态到装饰品或付费获胜，添加这些功能是服务器运营商可以自由决定的事情。然而，如果玩家不想看到某些类别，他们可以将其过滤掉。
Q12：最后，你自己过得怎么样？我能想象工作很多，但也很有意义。到目前为止，社区对游戏的回应非常棒，团队对社区的开放态度也是如此！
A12：终于能把游戏发布出来真是太好了。我有点太忽视我的健身房了，但除此之外，我正经历着人生中最美好的时光。我整个20多岁都在为Hytale工作，并在30岁生日前一天离开了Hypixel Studios。这对我来说是一个非常痛苦的时刻，感觉我浪费了我的20多岁。
现在站在这里，不到两年后发布Hytale，不仅为我未来10年赋予了目标，也让我的过去发生了180°的转变，使我的20多岁完全值得。
这种感觉超乎现实，我希望当社交媒体上的人们认为Hytale是某种捞钱工具时，能记住这一点：我们做这件事是出于热情和目标。我们很高兴能够持续为Hytale工作直到退休，并创造出有意义、我们真正引以为豪的东西。
视频已经把访谈全文压缩了，但仍然很长。
为了照顾大家的注意力，我读了一遍原文，把内容缩减到了一千多字，保留了所有关键信息，发了个视频。
【12月19日Hytale访谈省流版，Mod一切！】
然后，以下是访谈全文翻译，哈基米翻的。
Q1: 能否详细阐述Hytale背后的核心技术设计理念？这些理念如何影响模组支持？
A1: 让我先回顾一下我们的背景。我们运营着世界上最大的Minecraft服务器已近十年。我们将Minecraft推向了远超其原有极限的境地。我们创造了完全基于服务器端的原创概念，如Pixelpainters、Warlords、Turbo Kart Racers、Galaxy Wars等... 我们在一款原本极其受限的游戏中探索了服务器端模组开发。
Hytale的核心理念是，Hytale的引擎不仅支持一款沙盒游戏，更支持一个沙盒创作过程。从第一天起，我们就知道我们希望在Hytale内部构建Hytale。我们在服务器端模组开发的背景中，一直饱受“如果我们只拥有那一个缺失的拼图碎片，我们就能做这么多事情！”这种想法的困扰。Hytale的愿景就是将那一整袋拼图碎片倒在桌上，然后拼凑起来。
我们的目标从来不是成为某个XYZ杀手级游戏，甚至不是走向主流。我们只是试图制作我们所需要的游戏——我们过去是，现在也是我们的第一个客户。这一理念贯穿了整个开发过程。目标是没有任何内容是硬编码的，一切都通过我们的资产系统，以利用其广泛的功能集和工具。
在底层，服务器中有3个重要的技术系统：
- 实体-组件系统：游戏的内存和运行时模型，旨在防止面向对象的编程模式破坏模组开发。
- 资产系统：游戏的JSON数据配置层，负责加载、保存、验证和热重载资产。
- 插件系统：加载服务器的扩展，例如事件处理器、资产类型、组件类型、系统例程等。
这3个系统是我们服务器的内核，构成了Hytale的骨干。其设计本身就是高度模块化和可选的。
我们遵循的理念是：“我们希望模组开发者能够从Hytale中移除Hytale，转而创造属于你自己的Yourtale。”
Q2: 在团队的第一篇博客文章中，他们提到“非开发者只需最少的专业知识就能创造出令人印象深刻的体验”——对于程序员和非程序员来说，模组制作将有多容易上手？首先在抢先体验阶段，然后未来的愿景是什么？
A2: 考虑到我们急于推出抢先体验版，我认为你会发现我们系统中的成熟度各不相同：
- 成熟: 这些功能在我们的资源编辑器中已经得到了很好的支持。它们可以在我们的游戏内/原型节点图编辑器中轻松编辑，并且不需要编程经验。这类功能包括方块、世界生成v2、物品、视觉特效、建模、动画、掉落表、制作、天气等。
- 可模组化: 这些功能已经非常丰富且可扩展，但通常缺乏良好的编辑器集成和工作流程。有时你需要深入底层的JSON文件进行修改，或者编写自定义插件来扩展它们。这类功能包括NPC、交互、库存、摄像机等。
- 原型: 这些功能通常是硬编码的，或者目前还不能从服务器端进行扩展。我们通常会先让某个功能运行起来，然后再去完善它，以避免过早复杂化的谬误。我们需要确保我们以1、2、3种或更多不同的方式来理解一个功能，以便明白应该构建什么样的抽象。你会遇到不少这样的系统。我们的目标是尽快将它们带入可模组化阶段。这类系统包括物理、输入、着色器、视觉效果等。
- 已弃用（待移除）: 游戏中的一些系统将被移除，取而代之的是更新的系统。这些系统之所以还存在，是因为我们未能完成过渡。这类功能包括自定义UI（我们正在将所有UI迁移到使用XML布局的NoesisGUI，并逐步淘汰我们的.ui文件）、事件总线（旧的已被EcsEvents取代的事件系统）等。
我们不仅仅是在添加我们自己需要的功能。我们添加任何有意义并且我们能够维护的功能。我们一直在寻找用例和局限性，以调整我们的系统设计。如果你希望加入某个功能：请告诉我们你想做什么，以及为什么Hytale阻止了你实现它。我们越了解这个局限性，就能越快修复它。
Q3：当我设想Hytale模组制作时，我应该想到MC锦标赛、Hypixel或其他MC Java服务器所创造的那些东西吗？这些功能是否可以通过类似于Minecraft插件的服务器端插件模型来实现？
A3：我认为你应该想得更远。我们创造Hytale是因为我们在
@HypixelNetwork
上遇到的限制。看看我们的一些游戏模式，比如《Warlords》。那是《魔兽世界》经典战场战歌峡谷和阿拉希盆地的重现：https://youtu.be/bYdLW6CdBo0?si=S1LcK3SKxvCBCOVu&t=202（示例视频）
最令人瞩目的缺失之一是视觉特效。同时，我们无法添加“新”物品——我们不得不使用资源包重新设计盔甲外观，这限制了我们实际能制作的内容量。我们不得不滥用屏幕侧边的记分板来显示统计数据，而不是拥有一个合适的自定义用户界面。即使是一些简单的功能，也本可以让整个体验好得多！
在这个视频中：https://youtube.com/watch?v=PEbF0h_...le成为服务器权威的。你可以看到服务器无法控制的客户端修改是如何破坏我们预期的游戏体验的。
我们在Minecraft中最大的问题之一是缺乏“传输”数据包，以及需要运行一个名为“BungeeCord”的代理。这个代理的存在仅仅是为了让多个Minecraft服务器表现得像一个单一的Minecraft服务器。我们使用这些代理进行负载均衡和在实例之间移动玩家。它们的运营成本极其高昂，并且也构成了单点故障。
所以，当我说你应该超越我们在Hypixel网络上所创造的东西时，我指的是超越我们所做的，以及如果仅仅拥有一些更好的功能本可以做到的事情。我们梦想中的Hytale，是允许玩家在Hytale中制作一个类似《EVE:Online》的太空大型多人在线角色扮演游戏。我们希望以这样一种方式支持模组制作者，让他们能够震撼所有人，并远远超越我们在拥有216k CCU和3000万以上UU的服务器网络上所取得的任何成就。
Q4: Hytale的更新将如何运作？团队对于API稳定性和版本控制的方法是什么？模组是否需要为每个新版本进行重大重写，还是会保持一定的向后兼容性？
A4: 这是个棘手的问题。我们将发布一个启动器，提供两个补丁线：“正式版”和“预发布版”。
- 正式版：当前推荐的游戏版本
- 预发布版：即将到来的游戏更新（提前约1周）
我们打算让玩家始终更新到正式版补丁线上的最新版本。这个决定同样是基于过去的痛苦经验做出的。直到最近，Hypixel网络上超过50%的玩家仍在使用1.8版本。我们支持从1.8到1.21的每个版本，但维护这种协议兼容性带来了很多痛苦。这种版本丛林问题已经困扰我们十年了，我们不希望Hytale玩家也经历这些。
我们旨在为我们的API、配置等制定适当的弃用政策。遗憾的是，现在我不得不告诉你更多坏消息：抢先体验的头几个月可能会很混乱！在我们解决最严重的问题时，我们必须快速行动，这也意味着我们不得不牺牲兼容性来走捷径。我预计这不会像影响几乎无法修改或已弃用的系统那样，对成熟的系统造成太大影响。
在抢先体验发布后不久，我们将在只读的Github仓库中发布服务器源代码，同时我们也在努力开放贡献。此外，您将获得我们的Gitbook文档访问权限，该文档将逐步包含我们系统的所有细节，以解释其目的和我们为其制定的路线图。这些都是重要的透明度努力，旨在让模组制作者了解未来的发展，但随着时间的推移，我预计系统会稳定下来，并被认为是“足够好”的，只进行迭代更改，从而使弃用政策变得容易。
Q5: 是否有计划创建一个官方的模组发布和管理平台，类似于Modrinth和Curseforge，但是官方的？如果有，这个系统会类似于Roblox或Minecraft基岩版中的市场吗？
A5: 我们已经与
@CurseForge
合作，以启动Hytale模组制作。这次合作并非排他性的，我们也在与其他UGC市场合作，为它们带来Hytale支持，但只有Curseforge支持多款游戏，并且能够在其团队内部调动足够的资源来与我们一同打破这个“诅咒”。
他们提供了极大的帮助，通过将我们与模组制作者联系起来、创建教程和示例模组，为我们分担了大量工作。这次合作，令人难以置信的是，没有任何附加条件，Curseforge在这里确实值得高度赞扬，因为他们如此以创作者为导向，并且总体上非常支持Hytale。
我们计划将模组制作直接整合到游戏中。这与我们长期的创作者战略紧密相连。我们正在制定一项战略，使我们能够保持模组的免费和可访问性，同时又能让模组制作者获得丰厚的回报和财务上的成功。我们正尝试在整个UGC奖励机制上进行创新，我们相信Hytale能够提供一个优秀的生态系统，真正为玩家和模组制作者带来模组和模组制作的新黄金时代。我们将共同克服“购物中心”式的模组体验，创造出能够持久存在、并且让我们在道德上感到自豪的东西。
Q6: 从技术角度来看，模组化装饰品大体上是如何运作的？引擎如何处理模组化装饰品的资源交付和同步？例如，我能否制作自定义装饰品，并且当我加入服务器时，其他人能看到这些装饰品，还是这一切都基于服务器？
A6: 这已经成为一个有争议的话题，我认为我们在解释全貌方面做得相当糟糕。
Hytale有两种类型的装饰品：
- 全局装饰品：这些是你在角色创建界面可以选择的外观。它们将是你加入单人游戏或任何多人游戏时的默认外观。
- 服务器装饰品：这些由单人游戏/多人游戏中的模组提供。假设你安装了“Yuki的动漫衣柜模组”。你会获得一个可制作的动漫服装衣柜，该模组允许你在单人游戏中自由使用它。这些装饰品不会改变你在主菜单中看到的角色外观，也不会被带到另一个服务器。
政策：玩家喜欢他们在Minecraft中的个性化皮肤纹理，但我们也看到了硬币的另一面。我们不得不在Hypixel网络上封禁了5万个皮肤纹理。但这并不是我们这样做的唯一原因。我不想将这一决定完全归咎于安全考虑。我们以20美元的价格出售游戏（即将推出区域定价），我们预计，如果没有某种形式的货币化，我们将无法永远维持工作室的运营成本。我们审视了整个游戏，发现真正侵入性最小的选择就是角色自定义。
我们不会为这些装饰品添加任何开箱机制。我们承诺提供透明的购买方式！
@Kaupenjoe
对A6的看法：
作为来自Minecraft Java版和完全自定义皮肤的玩家，这肯定是不同的！然而，我认为关键在于，这将更接近于Roblox角色编辑器或Minecraft基岩版市场处理其自定义系统的方式！
仍然是高度可定制的角色，拥有很大的自由度，但不是像素级的完美自由！最后一张确认的角色创建器截图来自2019年，但由于这仍然是主要遗留引擎的领域，这很可能仍然是角色自定义的样子：https://hytale.com/news/2019/2/customizing-your-character-in-hytale
只要保持透明，他们也提供高质量的自由选项，并且定价不具有掠夺性，我认为这会运作得很好！
Q7：再举一个技术性的例子，游戏通常有某种游戏循环或滴答系统。我们会有滴答、增量时间或类似的概念可用吗？Hytale 运行在什么样的 TPS 上？
A7：Hytale 服务器采用动态滴答系统。每个滴答系统都基于增量时间运行，但间隔具有可配置的滴答率（默认 30 tps）。当 CPU 负载过高时，TPS 会下降，但通过增加增量时间来维持模拟速度。
Q8: 所以，客户端模组是一个热门话题！在模组博客文章中，你说：“我们不打算支持任何客户端模组”。不少模组制作者对此持相当批判的态度，他们不太习惯这种做法。首先，也许可以解释一下为什么这是核心理念？
A8: 我想我在第一个问题中已经部分涵盖了这一点，但我实际上对这里的策略有一些调整。
服务器端模组的核心理念是：
- 设计师的创作自由：我们已经看到客户端模组如何破坏我们预期的游戏体验，即使不被视为作弊。
- 安全与保障：Minecraft中的客户端模组是.jar文件。你正在你的计算机上运行不受信任的代码。这就像从互联网下载一个随机的可执行文件并运行它。我们已经封禁了数百万因恶意模组而被盗的账户。
- 性能：客户端模组真的会破坏性能，而我们无法优化这些路径。此外，它会进一步加剧版本丛林问题。
- 跨平台：我们正在使用.NET 10和NativeAOT编译客户端，为Hytale登陆游戏机和手机做准备。修改原生应用程序是不可行的。这既困难又耗时。一旦我们为了打击作弊而加上变异的混淆处理，你将会有糟糕的体验。
- Roblox（作为一个例子）：Roblox做了同样的事情。在Roblox中你并不“修改”客户端，但你却看到了截然不同的游戏体验，并且不断有新的功能被添加。
然而：我们已经重新考虑了这项政策，我们可以在这里做出进一步的妥协。我们阅读了所有的反馈，有一个例子最为突出：
“我和朋友在服务器上玩，我们不在乎谁用什么材质包或UI修改。为什么我们必须把它们添加到服务器上？”
这个例子很完美，真的让我明白我们可以做得更多……如果服务器不在乎呢？我们拥有技术能力，可以让客户端自行加载某些类型的资源。比如说一个修改过的纹理。服务器可以告诉客户端它是否在乎纹理更改。如果它在乎，客户端就不会加载那个“客户端资源包”，从而恢复服务器的创作完整性。
这样，当我们添加对高级资源（如着色器图）的支持时，我们可以让它们成为客户端本地的，而服务器不会失去控制。
Q9: 既然客户端模组不受支持，那么团队会提供什么样的API钩子或扩展来让自定义UI、着色器，也许还有一个“Hytale Optifine”成为可能？
A9: 我们的一位团队成员（
@Ktar5
）在推特上发布了一个服务器端UI发送到客户端的示例：https://x.com/Ktar5/status/1991664868131500049
对于着色器，我们目前没有解决方案，但我们正在考虑一种基于节点的着色器图资源，其功能类似于Unity的着色器图。我们在这方面总是会受到更多限制，这将考验我们倾听和交付的承诺。
Hytale Optifine根本不会出现。我们高度致力于性能，特别是在渲染器方面，因为它将不可修改。我们聘请了以制作Minecraft模组“Sodium”而闻名的JellySquid来领导我们渲染器的架构设计。我认为地球上很少有人能像Jelly那样理解方块游戏的渲染和优化。
(编者按：最后几个回答来自我与
@slikey
的对话，当时是德语，所以这是我的措辞和翻译，旨在传达真实信息)
Q10：您说过“没有版本丛林”！是否会有办法回溯到游戏的旧版本？还是人们应该始终使用最新版本？
A10：我们可能会每周向Hytale发布一次更新！提前一周提供预发布版本，以帮助创作者进行模组/插件兼容性测试！总的来说，如果您在发布分支中，它将自动更新，但您始终可以回退一个版本，包括存档文件！
然而，长期愿景是，旧版本将不再由Hytale提供支持。
Q11：我还与Slikey进一步讨论了关于审核或货币化的方法！
A11：我们的目标是透明度和内容过滤系统，而不是严厉的审核。我们希望让玩家能够根据服务器在内容成熟度或货币化策略方面的评级，来禁用服务器的可见性。这意味着从无政府状态到装饰品或付费获胜，添加这些功能是服务器运营商可以自由决定的事情。然而，如果玩家不想看到某些类别，他们可以将其过滤掉。
Q12：最后，你自己过得怎么样？我能想象工作很多，但也很有意义。到目前为止，社区对游戏的回应非常棒，团队对社区的开放态度也是如此！
A12：终于能把游戏发布出来真是太好了。我有点太忽视我的健身房了，但除此之外，我正经历着人生中最美好的时光。我整个20多岁都在为Hytale工作，并在30岁生日前一天离开了Hypixel Studios。这对我来说是一个非常痛苦的时刻，感觉我浪费了我的20多岁。
现在站在这里，不到两年后发布Hytale，不仅为我未来10年赋予了目标，也让我的过去发生了180°的转变，使我的20多岁完全值得。
这种感觉超乎现实，我希望当社交媒体上的人们认为Hytale是某种捞钱工具时，能记住这一点：我们做这件事是出于热情和目标。我们很高兴能够持续为Hytale工作直到退休，并创造出有意义、我们真正引以为豪的东西。
