本文是 HytaleModding 社区询问官方程序设计人员关于模组开发的问答总结。
（本文允许规范地搬运与转载。转载须注明原文链接、译者、所属平台（HytaleCN）。）
原文链接：https://hytalemodding.dev/en/docs/qna/26-05-2026
HytaleModding 就 Hytale 模组开发的未来采访了 Slikey、ZeroErrors 和 DevSlashNull。本页面收录了访谈中的回答。
Slikey：
旧版自定义 UI 将不会获得更多文档。UI 将在未来的更新（更新 6）中迁移至 NoesisGUI，而 NoesisGUI 已有自己的 XAML 文档可供社区参考。针对 Hytale 的特定 UI 文档（服务端 UI 扩展、与玩家通信等）将在 NoesisGUI 更新后的某个时间点提供，但目前我们还没有明确的时间表。
旧版自定义 UI 在短期内不会被移除，但最终会被淘汰。
ZeroErrors：
NoesisGUI 的更新将是一个重大变化，我们希望确保社区有足够的学习资源。我们计划在更新发布后，举办一些像本次一样专注于 NoesisGUI 的交流活动，同时也会提供更多的原始资料（例如带注释的共享源码、Maven 源码 JAR 包），以便更容易推导出文档。
Slikey：
只要客户端可视化脚本存在，我们可能会添加脚本支持，未来可能会为 UI 添加基于客户端节点的脚本。一旦 NoesisGUI 的粒子和着色器效果投入使用（旧系统目前完全无法实现），你就能期待新 UI 会变得更加生动、更有活力。
并非所有硬编码的 UI 都会被迁移，但目标是让标签菜单、角色面板、物品栏和合成工作台都迁移到由资产驱动的自定义 UI，这样每个工作台都会成为一个服务端可修改的资产。
Slikey：
在内部构建文档会耗费大量时间，而且如果没有反馈，就如同“向森林喊话”。目前的方向是依靠社区驱动的文档、针对严重缺乏文档的系统举办此类交流活动，以及提供更多的原始资料（例如带注释的共享源码、Maven 源码 JAR 包），以便更容易推导出文档。
我们团队发布的任何文档都可能不如社区已有的资源；我们更愿意为社区的努力做出贡献并提供原始资料。
Slikey：
是的，整个系统正在由 Arcaniax 和 Ktar 在服务端重写，这将解锁更多的功能并实现真正的协作。当前的系统编写于 2017 年左右，仅作为客户端功能。它在本地保存状态，客户端生成的实体只有它自己能看到，导致客户端与服务端不同步。
我们已经为动画化工具发布了新的 NoesisGUI（这是最早使用 NoesisGUI 的系统之一），但底层技术仍然是旧版的混乱状态。替代方案是由服务端驱动的：样条线和摄像机实体存在于服务端，支持协作编辑——一个人铺设粗略的样条线，另一个人建造一棵树，第三个人可以细化样条线。新系统将支持所有玩家共享回放。我等不及要看到功能推出了。
Slikey：
目前没有计划这个功能，但如果第一章需要，我们会进行开发。目前，针对单个功能的渲染工作优先级较低，会优先进行渲染器的现代化（见下文问题）。
Slikey：
Slikey：
样条线“可能是我们会较早引入的东西”。目前已在两个地方纳入规划：新的服务端引擎动画系统（样条线 + 摄像机实体）和适配样条线的方块模型（“渲染部分相对容易，难点在于我们到底想如何配置它”）。
Slikey：
如果我们不为了玩法做这个，那么你可能可以通过 Mod 来实现。如果这项技术用于可移动结构，我会确保给出一个缩放组件，可通过滑动条来调整。
ZeroErrors：
这目前是渲染器工作原理带来的限制，提高它会导致旧显卡无法工作。我们也认为这个限制很烦人，希望将来能提高这个限制。我们期望随着 Vulkan / Metal 等更现代图形技术的引入，这类改进能够实现。
Slikey：
我们计划保留状态树。这个编辑器会持续更新，直到它被迁移到资产编辑器——我建议去看看 Unreal（虚幻引擎）的状态树。目前最大的痛点是缺乏实时调试：在 Unreal（虚幻引擎）中你可以暂停执行并在运行中检查状态树；这里还做不到。一旦它进入游戏，调试体验会大幅改善。
目前，只有一名内部开发人员专门负责 NPC，我们目前没有足够的精力来编写文档。NPC 从根本上说是最困难的系统，因为它们要模拟一个活生生的世界。
ZeroErrors：
我们计划将 NPC 编辑器直接移入资产编辑器，一旦完成，更友好的 UI 可以引导初学者完成第一步的创建，而不必强迫人们去逆向工程示例配置。
Slikey：
Sach 和 Panda 正在将所有内容迁移到 Noesis。目前编辑器仍然是一个外部工具，有点像是附加在游戏之上的，我们的目标是将所有东西连接起来。目前它有点像 Photoshop 的情况，对初学者来说选项太多，所以一旦高级用户的工作流稳定下来，预计会推出简化的 UI 和向导。
如果我们能获得真正的初学者使用编辑器的最初几个小时的视频，并尝试制作一个 Mod，那将对识别痛点和改进机会非常有帮助。我们内部只有熟悉编辑器各个方面的专家用户，缺乏新手视角。
Slikey：
世界生成 v2 的性能还不够好，且需要更多功能，所以它会不断增加新功能。节点编辑器是一个原型，最初从未打算公开发布，它也会被移入资产编辑器本身。
ZeroErrors：
我们正在原型设计一个新的资产系统，以解决当前资产系统的多个问题。我们希望这也能帮助我们改进运行时安全注册、客户端缓存/预加载、Mod 包同步以及其他资产问题。具体时间尚不明确，但我们正在努力。
ZeroErrors：
是的，这是新资产系统的目标之一。目前我们还没有时间表。
ZeroErrors：
目前没有计划支持这种功能，因为这种权衡会给资产系统带来更多的复杂性和性能问题。
ZeroErrors：
这个功能最近已经添加了，现在支持自定义名称和描述，由堆叠上的元数据支持。
ZeroErrors：
每个堆叠的元数据是受支持的，因此 Mod 实现从物品堆叠读取元数据以进行伤害修改应该相当直接，尽管属性修改可能会稍微复杂一些。Mod 只能在自己的物品上存储数据；目前没有内置的方法来进行属性修改。
ZeroErrors：
没有理由说它不能通过更换模型或改变其变换以缩得更大来改变外观。我很确定我过去见过能够切换外观的 NPC。
如果这不起作用，一个可重现的小型 NPC 配置将让我们确认这是一个错误还是一个不应存在的限制。
Slikey：
目标系统仍在代码库中，我们只是移除了它的所有使用途径。它目前算是被废弃了，但很可能会在未来的地牢中重新出现。开放的设计问题是隐式任务设计（制作什么物品、收集多少素材、然后任务完成）与显式任务（进入传送门、击败敌人、通过 HUD 显示进度）——这取决于设计团队。
我们引入的任何任务系统，Mod 开发者都将能够接入。如果你愿意，现在就可以使用目标插件。
ZeroErrors：
我们通常在进行性能改进，例如 MachineBreaker 在 ECS 和服务端的各种工作。一些系统已经利用了多核和并行，但对于较小规模的系统，效果可能会更差，因为可能在同步上花费更多时间。在发布前，我们不得不禁用一堆多线程运行的系统，因为对于当时我们的主要目标——单人玩家来说，性能更差了。完整多核的交付日期尚未确定，这项工作正在进行中。
我们正在积极改进这一点，如果你发现特定的性能问题，我们很高兴听到并查看。
ZeroErrors：
我们目前不打算提供官方的代理服务器，因为我们目前没有使用它的场景。如果协议中有某些东西导致实现代理变得困难，我很有兴趣了解更多相关问题。
目前，你可以通过附加数据传输到同一服务器，或使用域名进行切换。
我们已经发布了崩溃回退功能，你可以指定一个回退服务器，当客户端因错误断开连接时会连接到该服务器。传输数据包不支持多个地址。你也可以使用 Cloudflare 负载均衡。
ZeroErrors：
这不是我们需要直接支持的事情。跨服务器边界同步游戏玩法元素会非常迅速地变得非常复杂，所以更好的方式是希望进行特定分片方式的服务器主机以对其有意义的方式构建它。如果社区中出现了一些成熟的方案，我们可能会考虑。
ZeroErrors：
确实应该在人体工学方面做一些工作。没有理由让一个如此简单的事情需要这么多步骤。对于在代码库中重复做的事情，提供便利/实用函数是有意义的。目前的复杂之处在于旧系统的大量代码仍然存在，如果团队正在迁移到直接区块访问，我们宁愿不会在即将消失的接口上投入便利 API 的开发。
Slikey：
目前，我认为我们没有任何关于统计或成就的计划。记忆系统存在，章节任务即将到来，但这些更多是进度系统，而非成就系统。
ZeroErrors：
这确实是一个痛点，我们意识到了……但存在技术复杂性，因为目前服务端不理解动画或动画状态。因此无法知道骨骼的位置来正确附着玩家的位置、进行位置验证等。
Slikey：
目前配置中只有一个坐骑偏移量，这是一个糟糕的解决方案，理想情况下应该使用一个附着点，这样玩家会与生物本身一起动画，而不是固定在一个位置。
ZeroErrors：
随着我们增加无限高度的代码基础，垂直方向的生物群系也很有意义，所以这肯定是我们会在过程中考虑改进的事情。
DevSlashNull：
我们正在构建并即将在更新中发布模组浏览器，并有潜力集成某种形式的捆绑体验来获取模组。模组包确实很有用，我们知道我们想做，但目前还没有计划。我预见会有一个类似 Steam 创意工坊的订阅模式，制作人将模组打包，你可以订阅它们。
ZeroErrors：
没有日期。最近的移动系统改动是一次大的清理，以改进玩家移动处理的一般方式，我很确信这将来会扩展到坐骑相关的东西……这确实是我们想要改进的事情。
ZeroErrors：
这可能取决于具体负责的人。如果一组插件/模组符合我们所关注的领域，我们或许会研究它们是如何工作的，但更可能不会。任何负责游戏玩法代码的人都会实现对冒险模式有意义的方案。
Slikey：
所有技术都已准备就绪，只等几个法律障碍解决。将会有一个私有的 GitHub 组织（有点像 Unreal Engine），你可以通过账户管理门户链接并自动收到邀请，这可以防止匿名爬取。
最初将仅限查看；发布时不接受 PR。我们将在本周内向 Neil 和 Kaupenjoe 提供服务端源码，以测试工作流程。
Slikey：
这是标准做法，主要是一项安全功能。例如，更新 5 的发布使用了实时配置，在禁用社交和服务器发现的情况下发布，待稳定后再开启这些功能。
Slikey：
我们计划进行 Hypixel 式的深度社交整合——整个生态系统应该受益，而不是每个服务器重新发明轮子。组队系统即将上线，目标是：在未来的更新中，当小游戏/短时体验发布时，玩家可以组建队伍并开始游戏，组队可扩展到其他服务器，这样你可以作为一个队伍跨服务器排队，这将解锁快速重复可玩性。Mod 浏览器将包含与主档案系统关联的创作者档案。
（本文允许规范地搬运与转载。转载须注明原文链接、译者、所属平台（HytaleCN）。）
原文链接：https://hytalemodding.dev/en/docs/qna/26-05-2026
HytaleModding 访谈：文档、自定义 UI 及更多
HytaleModding 就 Hytale 模组开发的未来采访了 Slikey、ZeroErrors 和 DevSlashNull。本页面收录了访谈中的回答。
文档与自定义 UI
何时能提供关于自定义 UI 的更多文档？
Slikey：
旧版自定义 UI 将不会获得更多文档。UI 将在未来的更新（更新 6）中迁移至 NoesisGUI，而 NoesisGUI 已有自己的 XAML 文档可供社区参考。针对 Hytale 的特定 UI 文档（服务端 UI 扩展、与玩家通信等）将在 NoesisGUI 更新后的某个时间点提供，但目前我们还没有明确的时间表。
旧版自定义 UI 在短期内不会被移除，但最终会被淘汰。
ZeroErrors：
NoesisGUI 的更新将是一个重大变化，我们希望确保社区有足够的学习资源。我们计划在更新发布后，举办一些像本次一样专注于 NoesisGUI 的交流活动，同时也会提供更多的原始资料（例如带注释的共享源码、Maven 源码 JAR 包），以便更容易推导出文档。
Slikey：
只要客户端可视化脚本存在，我们可能会添加脚本支持，未来可能会为 UI 添加基于客户端节点的脚本。一旦 NoesisGUI 的粒子和着色器效果投入使用（旧系统目前完全无法实现），你就能期待新 UI 会变得更加生动、更有活力。
并非所有硬编码的 UI 都会被迁移，但目标是让标签菜单、角色面板、物品栏和合成工作台都迁移到由资产驱动的自定义 UI，这样每个工作台都会成为一个服务端可修改的资产。
你们对官方文档有何计划？
Slikey：
在内部构建文档会耗费大量时间，而且如果没有反馈，就如同“向森林喊话”。目前的方向是依靠社区驱动的文档、针对严重缺乏文档的系统举办此类交流活动，以及提供更多的原始资料（例如带注释的共享源码、Maven 源码 JAR 包），以便更容易推导出文档。
我们团队发布的任何文档都可能不如社区已有的资源；我们更愿意为社区的努力做出贡献并提供原始资料。
引擎动画工具
引擎动画工具会改进吗？比如自定义摄像机角度、关键帧动画、直接在游戏中操作骨骼？
Slikey：
是的，整个系统正在由 Arcaniax 和 Ktar 在服务端重写，这将解锁更多的功能并实现真正的协作。当前的系统编写于 2017 年左右，仅作为客户端功能。它在本地保存状态，客户端生成的实体只有它自己能看到，导致客户端与服务端不同步。
我们已经为动画化工具发布了新的 NoesisGUI（这是最早使用 NoesisGUI 的系统之一），但底层技术仍然是旧版的混乱状态。替代方案是由服务端驱动的：样条线和摄像机实体存在于服务端，支持协作编辑——一个人铺设粗略的样条线，另一个人建造一棵树，第三个人可以细化样条线。新系统将支持所有玩家共享回放。我等不及要看到功能推出了。
渲染
是否有计划扩展 API 以实现屏幕特效/后期处理（滤镜、雨的图层覆盖）？
Slikey：
目前没有计划这个功能，但如果第一章需要，我们会进行开发。目前，针对单个功能的渲染工作优先级较低，会优先进行渲染器的现代化（见下文问题）。
除了调试形状外，是否会提供更多由服务端驱动的渲染选项？（方块状态、方块动画等）
Slikey：
- 模型实例化/优化目前暂不考虑，因为渲染器性能已足够。
- 方块状态驱动的渲染（例如热力膨胀中管道带流体的情形，方块状态改变模型的渲染方式）内部与所有渲染开发人员进行了详细讨论。结论是：“因为没有客户端的可视化脚本，配置起来会非常混乱”。因此这被推迟到未来，但确实是希望实现的功能。
- 愿景： 一个类似 Unreal（虚幻引擎）材质图形编辑器的节点图。方块状态获得数据定义，可视化脚本对其解释，并输出实际的渲染状态。“那是未来的计划。在此之前，我们首先需要可视化脚本成为现实，然后需要将其集成到渲染器中”。
- 时间点： 可能在 1.0 版本，大概两年后。在此之前不会有临时的钩子，因为那会“在我们实际尝试将渲染从 OpenGL 3.3 迁移走的时候，把代码库搞得一团糟”。
是否有计划在游戏中添加样条线？
Slikey：
样条线“可能是我们会较早引入的东西”。目前已在两个地方纳入规划：新的服务端引擎动画系统（样条线 + 摄像机实体）和适配样条线的方块模型（“渲染部分相对容易，难点在于我们到底想如何配置它”）。
系统会支持微雕方块（将方块打破为 1/8 或 1/16 体素）吗？
Slikey：
如果我们不为了玩法做这个，那么你可能可以通过 Mod 来实现。如果这项技术用于可移动结构，我会确保给出一个缩放组件，可通过滑动条来调整。
模型的 255 节点限制——有计划提高吗？
ZeroErrors：
这目前是渲染器工作原理带来的限制，提高它会导致旧显卡无法工作。我们也认为这个限制很烦人，希望将来能提高这个限制。我们期望随着 Vulkan / Metal 等更现代图形技术的引入，这类改进能够实现。
资产编辑器
你们希望 NPC 编辑器向什么方向发展？有没有计划简化这个工作流程？
Slikey：
我们计划保留状态树。这个编辑器会持续更新，直到它被迁移到资产编辑器——我建议去看看 Unreal（虚幻引擎）的状态树。目前最大的痛点是缺乏实时调试：在 Unreal（虚幻引擎）中你可以暂停执行并在运行中检查状态树；这里还做不到。一旦它进入游戏，调试体验会大幅改善。
目前，只有一名内部开发人员专门负责 NPC，我们目前没有足够的精力来编写文档。NPC 从根本上说是最困难的系统，因为它们要模拟一个活生生的世界。
ZeroErrors：
我们计划将 NPC 编辑器直接移入资产编辑器，一旦完成，更友好的 UI 可以引导初学者完成第一步的创建，而不必强迫人们去逆向工程示例配置。
资产编辑器的改进计划何时进行？
Slikey：
Sach 和 Panda 正在将所有内容迁移到 Noesis。目前编辑器仍然是一个外部工具，有点像是附加在游戏之上的，我们的目标是将所有东西连接起来。目前它有点像 Photoshop 的情况，对初学者来说选项太多，所以一旦高级用户的工作流稳定下来，预计会推出简化的 UI 和向导。
如果我们能获得真正的初学者使用编辑器的最初几个小时的视频，并尝试制作一个 Mod，那将对识别痛点和改进机会非常有帮助。我们内部只有熟悉编辑器各个方面的专家用户，缺乏新手视角。
节点编辑器是“已完成”了，还是会有更多工具/节点出现？
Slikey：
世界生成 v2 的性能还不够好，且需要更多功能，所以它会不断增加新功能。节点编辑器是一个原型，最初从未打算公开发布，它也会被移入资产编辑器本身。
资产系统
是否计划实现运行时安全的资产注册？预计何时可以实现？
ZeroErrors：
我们正在原型设计一个新的资产系统，以解决当前资产系统的多个问题。我们希望这也能帮助我们改进运行时安全注册、客户端缓存/预加载、Mod 包同步以及其他资产问题。具体时间尚不明确，但我们正在努力。
资产会缓存在客户端，以避免加入服务器时超时吗？
ZeroErrors：
是的，这是新资产系统的目标之一。目前我们还没有时间表。
你们是否计划为每个世界添加不同的 Mod？
ZeroErrors：
目前没有计划支持这种功能，因为这种权衡会给资产系统带来更多的复杂性和性能问题。
物品
是否有计划改进 ItemStack 的处理——在运行时更改名称/描述？
ZeroErrors：
这个功能最近已经添加了，现在支持自定义名称和描述，由堆叠上的元数据支持。
是否有计划的 API 用于具有每个 ItemStack 独特属性的物品变体（每次掉落的修饰符、等级、稀有度）？
ZeroErrors：
每个堆叠的元数据是受支持的，因此 Mod 实现从物品堆叠读取元数据以进行伤害修改应该相当直接，尽管属性修改可能会稍微复杂一些。Mod 只能在自己的物品上存储数据；目前没有内置的方法来进行属性修改。
NPC / 任务
NPC 系统能否在不重生的情况下实时更改 NPC（纹理、大小、属性）？
ZeroErrors：
没有理由说它不能通过更换模型或改变其变换以缩得更大来改变外观。我很确定我过去见过能够切换外观的 NPC。
如果这不起作用，一个可重现的小型 NPC 配置将让我们确认这是一个错误还是一个不应存在的限制。
临近冒险模式时，会不会有一个更丰富的 NPC 系统，带有任务系统，方便 Mod 对接，或许还有一个可视化的任务编辑器？
Slikey：
目标系统仍在代码库中，我们只是移除了它的所有使用途径。它目前算是被废弃了，但很可能会在未来的地牢中重新出现。开放的设计问题是隐式任务设计（制作什么物品、收集多少素材、然后任务完成）与显式任务（进入传送门、击败敌人、通过 HUD 显示进度）——这取决于设计团队。
我们引入的任何任务系统，Mod 开发者都将能够接入。如果你愿意，现在就可以使用目标插件。
性能
单个实例似乎主要绑定在一个 CPU 线程上，限制了每个实例的玩家数量。是否正在进行多线程/可扩展实例架构的工作？是近期还是长期计划？
ZeroErrors：
我们通常在进行性能改进，例如 MachineBreaker 在 ECS 和服务端的各种工作。一些系统已经利用了多核和并行，但对于较小规模的系统，效果可能会更差，因为可能在同步上花费更多时间。在发布前，我们不得不禁用一堆多线程运行的系统，因为对于当时我们的主要目标——单人玩家来说，性能更差了。完整多核的交付日期尚未确定，这项工作正在进行中。
我们正在积极改进这一点，如果你发现特定的性能问题，我们很高兴听到并查看。
多服务器技术：代理、分片、同步
是坚持使用传输数据包还是转向代理服务器？
ZeroErrors：
我们目前不打算提供官方的代理服务器，因为我们目前没有使用它的场景。如果协议中有某些东西导致实现代理变得困难，我很有兴趣了解更多相关问题。
目前，你可以通过附加数据传输到同一服务器，或使用域名进行切换。
我们已经发布了崩溃回退功能，你可以指定一个回退服务器，当客户端因错误断开连接时会连接到该服务器。传输数据包不支持多个地址。你也可以使用 Cloudflare 负载均衡。
你们会支持服务器分片和服务器同步吗？
ZeroErrors：
这不是我们需要直接支持的事情。跨服务器边界同步游戏玩法元素会非常迅速地变得非常复杂，所以更好的方式是希望进行特定分片方式的服务器主机以对其有意义的方式构建它。如果社区中出现了一些成熟的方案，我们可能会考虑。
Mod 开发便利性
你们会减少完成某些事情所需的调用次数吗？（例如，获取世界中的一个方块需要大约需要 10 次调用）
ZeroErrors：
确实应该在人体工学方面做一些工作。没有理由让一个如此简单的事情需要这么多步骤。对于在代码库中重复做的事情，提供便利/实用函数是有意义的。目前的复杂之处在于旧系统的大量代码仍然存在，如果团队正在迁移到直接区块访问，我们宁愿不会在即将消失的接口上投入便利 API 的开发。
其他
我们什么时候能得到统计数据功能？它们会以支持 Mod 的方式构建吗？
Slikey：
目前，我认为我们没有任何关于统计或成就的计划。记忆系统存在，章节任务即将到来，但这些更多是进度系统，而非成就系统。
我们能否改进坐骑锚点的设置方式——例如，选择一个骨骼来附着玩家？
ZeroErrors：
这确实是一个痛点，我们意识到了……但存在技术复杂性，因为目前服务端不理解动画或动画状态。因此无法知道骨骼的位置来正确附着玩家的位置、进行位置验证等。
Slikey：
目前配置中只有一个坐骑偏移量，这是一个糟糕的解决方案，理想情况下应该使用一个附着点，这样玩家会与生物本身一起动画，而不是固定在一个位置。
世界生成 v2 目前使用 2D 生物群系映射，随着立方体区块的到来，我们会得到 3D 生物群系映射吗？
ZeroErrors：
随着我们增加无限高度的代码基础，垂直方向的生物群系也很有意义，所以这肯定是我们会在过程中考虑改进的事情。
我们会很快通过 CurseForge 或内置解决方案获得模组整合包吗？
DevSlashNull：
我们正在构建并即将在更新中发布模组浏览器，并有潜力集成某种形式的捆绑体验来获取模组。模组包确实很有用，我们知道我们想做，但目前还没有计划。我预见会有一个类似 Steam 创意工坊的订阅模式，制作人将模组打包，你可以订阅它们。
随着移动系统的改动，合适的坐骑控制（例如飞行坐骑）何时会出现？
ZeroErrors：
没有日期。最近的移动系统改动是一次大的清理，以改进玩家移动处理的一般方式，我很确信这将来会扩展到坐骑相关的东西……这确实是我们想要改进的事情。
如果 Hytale 未来实现自己的技术系统，是否会咨询现有的技术模组（开发者）以实现最大兼容性？
ZeroErrors：
这可能取决于具体负责的人。如果一组插件/模组符合我们所关注的领域，我们或许会研究它们是如何工作的，但更可能不会。任何负责游戏玩法代码的人都会实现对冒险模式有意义的方案。
附加话题
共享源码的推出
Slikey：
所有技术都已准备就绪，只等几个法律障碍解决。将会有一个私有的 GitHub 组织（有点像 Unreal Engine），你可以通过账户管理门户链接并自动收到邀请，这可以防止匿名爬取。
最初将仅限查看；发布时不接受 PR。我们将在本周内向 Neil 和 Kaupenjoe 提供服务端源码，以测试工作流程。
遥测与实时配置
Slikey：
这是标准做法，主要是一项安全功能。例如，更新 5 的发布使用了实时配置，在禁用社交和服务器发现的情况下发布，待稳定后再开启这些功能。
社交整合
Slikey：
我们计划进行 Hypixel 式的深度社交整合——整个生态系统应该受益，而不是每个服务器重新发明轮子。组队系统即将上线，目标是：在未来的更新中，当小游戏/短时体验发布时，玩家可以组建队伍并开始游戏，组队可扩展到其他服务器，这样你可以作为一个队伍跨服务器排队，这将解锁快速重复可玩性。Mod 浏览器将包含与主档案系统关联的创作者档案。
