Hytale模组开发策略与现状

大家好，我是 Slikey（Kevin Carstens），Hytale 的技术总监。

我想向各位清晰、诚实地说明当前 Hytale 模组开发的状况、短期内你们可以期待什么，以及我们对模组生态的长期规划。

这并不是一篇经过精心包装的营销文章，而是由正在开发游戏及其工具的团队成员撰写的一份状态报告，面向所有希望与我们一起构建内容的创作者。

Hytale 提供了大量工具，帮助你释放创造力。在本文中，我们将重点介绍脚本编写、程序开发、建模和配置等方面的当前进展与未来愿景。

使命：模组开发是 Hytale 的核心

我们始终致力于打造一个沉浸式的冒险体验，并在未来持续扩展它。对于模组开发者而言，幸运的是——我们正是使用随游戏一同发布的这些工具来构建 Hytale 本身的。我们的目标是：我们能做到的，你们也都能做到。

作为模组开发者，你不仅能受益于我们使用的工具，还能从我们为实现理想中的方块游戏而创作的内容中获益。

我们以“模组为核心”来构建 Hytale。游戏中绝大多数内容都可以被修改、扩展，甚至完全移除。方块、物品、NPC、世界生成、用户界面、系统逻辑和行为机制，全部都由你可以干预的数据和代码驱动。

以下是指导我们工作的几项关键原则：

• 服务端优先：Hytale 的所有模组功能均基于服务器或单人游戏主机。你应能加入任意模组服务器，而无需额外下载客户端模组或管理客户端资源包。你可以自由组合插件与资源包来自定义游戏体验，也可以依赖服务器为你提供完整体验。在单人模式下，你可以创建存档并选择该存档所使用的模组。
• 一个社区，一个客户端：我们希望避免出现每个服务器都需要不同客户端模组的碎片化生态。因此，我们不打算支持任何客户端模组。客户端应保持稳定、安全且一致，而创意与多样性则由服务器提供。
• 为长久而模组：我们承诺长期支持模组生态。我们相信，像我们一样的模组开发者一直在寻找一个不仅容忍、而且积极拥抱和支持他们的项目。
• 赋能模组开发者，同时保护玩家：我们希望模组开发者能从自己的劳动中获益，并建立一个可依赖的未来，在享有最大自由度的同时，避免玩家面临其他模组平台常见的安全与风险问题。

这是我们为自己设定的标准。虽然尚未完全达成，但这是我们的方向。

技术现实检视

现在说点直白的：我们落后于原定计划。

我们缺失了数年的开发时间，现在必须在几个月内压缩完成。
我们的工具、文档以及系统开放程度都存在明显缺口。
有些功能仅因原型阶段临时拼凑而成，从未经过打磨。

我们做出了一个明确决定：

先开放访问权限，而非等待完美。

我们在有限时间内尽可能修复和完善现有内容，然后开放接口，让你能立即开始实验，同时我们继续朝着长期模组愿景迈进。

这意味着你现在可能会遇到：

• 因缺少编辑功能而受限；
• 客户端某些行为尚未对服务器开放；
• 部分工具和系统粗糙、不一致，甚至难以使用；
• 模组成熟度极不均衡——取决于你想构建什么内容。

我们决定：即使某些功能尚未达到理想标准，只要对你有用，我们就公开它，并在公众监督下持续迭代。

我们鼓励你对我们保持问责。

请监督我们的进展。@我们、联系我们、要求答案。我们承诺保持透明，如实告知——哪怕真相是“这还不够好”或“我们还不知道”。

不要只听我们说。要求结果。给出反馈。不要保留。

社区与沟通

你不必孤军奋战。我们已在几个核心平台锚定创作者社区：

• Discord：官方 Hytale 服务器，你可以直接与我们及其他模组开发者交流。此外还有专注 UGC（用户生成内容）的社区，如 CurseForge。我们也可能加入其他 Discord 社群倾听意见。特别感谢 Discord 在搭建 Hytale 空间上给予的大力支持。
• X / Reddit：在推特或 Hytale 相关 subreddit 发帖。我们无法回复每一条消息，但会主动浏览帖子和评论以指导开发。本文许多内容正是基于这些提问。
• 文档（GitBook，建设中）：我们正在 GitBook 上构建公开的创作者文档。初期内容将不完整且不均衡，但我们会根据你的问题持续扩充。

当前模组开发现状

坦白说，我们对 Hytale 当前的模组状态并不满意。

但我们认为，若等到一切完美才开放，反而是对社区的伤害。如果你现在加入，你将成为塑造生态的一份力量，并随着概念演进而深入理解系统，从而获得长远优势。

目前，Hytale 模组主要分为四大技术类别：

1. 服务器插件（Java .jar 文件）
   • 通过编程扩展服务器功能。
   • 极其强大，可深度修改游戏体验与核心系统。
   • 可用于开发小游戏、经济系统、自定义指令、新资产类型等。
2. 数据资源（JSON 文件）
   • 驱动游戏行为并定义核心内容：
     • 方块、物品、NPC
     • 世界生成规则
     • 掉落表、战利品等
3. 美术资源（音效、模型、贴图）
   • 提供游戏元素的视觉与听觉表现。
   • 支持使用 Blockbench 创建 Hytale 兼容的模型、贴图与动画。
4. 存档文件（世界与预制件）
   • 分享完整世界或特定建筑结构。
   • 预制件用于创意工具与世界生成，可放置树木、房屋或大型地标等预建结构。

为何不添加基于文本的脚本语言？

常见问题：“Lua 或脚本系统在哪？”

简短回答：我们没有基于文本的脚本系统，也不打算添加。

原因如下：

• 文本脚本通常被引入以“帮助非程序员”（如设计师）实现自定义行为。
• 但现实中，Lua 等脚本语言仍是编程语言：
  • 程序员需同时处理两种语言，其中一种常感觉“被阉割”；
  • 设计师仍需学习真正的编程概念。
• 最终，这种方式既不够包容，又增加了双方的复杂性。
• 我们认为这是一种虚假的妥协。

我们的方向：可视化脚本

我们将采用可视化脚本替代文本脚本。

我们在 Unreal Engine 蓝图系统中的经验表明：

• 设计师在能可视化构建逻辑时，真正感到被赋能；
• 程序员在使用 Java/C# 等正式语言并暴露高层节点时，效率更高。

我们的目标是：

• 让设计师通过符合其思维方式的可视化语言掌控行为逻辑；
• 让程序员通过添加新节点和高性能实现来扩展与优化系统；
• 避免逻辑分散在多个“半成品语言”中。

我们相信，这是在不牺牲能力的前提下，最能赋能模组开发者的方式。

当前可用的工具

我们目前已提供以下工具用于创建 Hytale 内容：

• Hytale 资源编辑器（Hytale Asset Editor）
  • 用于编辑数据资源。
  • 支持大多数资源类型，但在 NPC、世界生成和交互方面仍有明显限制。
  • 将随时间逐步扩展。
• Blockbench 插件
  • 可直接在 Blockbench 中创建 Hytale 兼容的模型、贴图与动画。
  • 替代了我们过去自研的建模工具，以更好支持社区已有的创作流程。
  • 将尽快正式发布。
  • 
• 资源图编辑器（Asset Graph Editor）
  • 一款未完成的内部编辑器，曾作为世界生成、创意工具笔刷、NPC 等功能的临时解决方案。
  • 虽未达我们期望的质量标准，但足够实用，因此选择公开并持续改进。
  • 正在努力尽快发布。
• 电影制作工具（Machinima Tools）
  • 即 2018 年用于制作预告片的工具。
  • 存在一些技术问题需修复，但已能产出优秀成果。
• 创意工具（Creative Tools）
  • 一套交互式世界编辑工具，助你自由表达创意。
  • 后续将推出专门的视频/博客介绍。
  • 过去已发布过部分使用片段。

你会感受到这些工具的粗糙边缘——这在当前阶段是预料之中的，我们将依靠你的反馈来修复它们。

短期改进计划

这不是完整路线图，但涵盖了我们认为对模组开发者最紧迫、影响最大的短期问题：

开源服务器代码

• 我们深知缺乏文档导致严重阻碍，内部同样痛苦。
• 承诺在法律允许后尽快开源服务器代码，预计在游戏正式发布后 1–2 个月内。
• 目前服务器未混淆，可轻松反编译。
• 开源后你将能：
  • 在文档完善前，直接查看系统底层实现；
  • 通过阅读真实代码自行解困，而非盲目试错；
  • 若某问题令你无法忍受，可直接提交修复建议。

模组/资源包分发机制

• 因游戏尚处早期阶段，我们尚未设计完善的分发流程。
• 目前在以下方面存在摩擦：
  • 将创作打包为干净、可共享的资源包；
  • 管理插件、资源包与世界之间的依赖关系。
• 这是我们的顶级优先事项，将根据你实际的发布与分享方式快速迭代。

自定义 UI 支持

• 当前 UI 状况混乱：
  • 同时使用三种 UI 框架；
  • 正在移除其中两个，统一迁移到 NoesisGUI。
  • 特别感谢 Noesis Technologies 的鼎力支持。
• 对你的影响：
  • 已支持基于资源的 UI，但功能不完整；
  • 你现在即可开始实验；
  • 请告诉我们你想构建什么、卡在哪里，我们将优先解决。

稳定性

• 简单而痛苦的事实：
  • 存在崩溃问题；
  • 部分崩溃可能导致数据丢失。
• 我们的立场：
  • 正在积极修复所有上报的崩溃，预期将快速改善；
  • 但目前无法保证数据完整性。
  • 请假设你迟早会受到影响。
• 实用建议：
  • 频繁备份存档与重要创作；
  • 我们正在搭建自动备份方案，但尚不能保证安全；
  • 请将此阶段视为真正的“抢先体验”：有价值，但尚不适合不可替代的工作。
• 对由此造成的任何问题，我们深表歉意，并将稳定性列为最高优先级。

官方服务器网络（First-Party Server Network）

• 计划在游戏发售后，由内部团队运营一个官方服务器网络，提供类似经典 Hypixel 风格的小游戏（但目前尚未启动开发）。

为何要这么做？

• 带回熟悉的小游戏：提供你曾在我们过往作品中体验过的内容（为 Hytale 重制），以及利用 Hytale 能力打造的全新原创小游戏。
• 自食其果（Dogfood）：使用与你相同的工具和流程，真实验证并改进小游戏创作、线上运营与服务器管理。
• 收集真实数据：观察大规模服务器运行情况，优化性能、降低主机需求、减少所有人成本。
• 分享经验：将部分或全部小游戏代码与资源公开，供你学习、复用组件、采纳最佳实践。
• 降低早期风险：确保即使社区基础设施尚未成熟，也有可靠、高质量的可玩内容。我们的任务是铺路，直到能将火炬交到你手中。

我们不会做什么？

• 不会试图与你竞争：目标不是主导服务器生态或挤压模组开发者与服主。
• 不会分散冒险模式开发精力：此项工作由独立团队负责，不影响我们对冒险模式的投入。
• 不会忽视社区反馈：不会因自有服务器而偏移整体路线图，损害更广泛的创作者生态或玩家需求。

归根结底，我们的利益在于培育一个多元、繁荣的生态系统——拥有众多成功服务器和丰富体验。我们绝无动机在自己的游戏中搞垄断。

模组开发者的长期愿景

长远来看，我们的目标是提供一套完整的工具与服务，让无论起点如何的你，都能在 Hytale 中蓬勃发展。

我们希望：

• 新手模组开发者无需昂贵软件或多年经验，即可踏入游戏创作；
• 资深模组开发者能在 Hytale 上构建复杂系统、商业项目与社区；
• Hytale 能模糊“玩游戏”与“做游戏”的界限。

开源服务器 + 赏金计划

• 不仅开源服务器代码；
• 还将设立开发赏金，奖励对生态有贡献的特定改进与功能。
• 虽需时间搭建机制，但目标明确：激励共建。

节点编辑器（Node Editor）

• 当前某些资源类型（如 NPC、交互、世界生成）在原始 JSON 中配置极为痛苦。
• 我们内部已使用工具简化流程。
• 计划：
  • 为这些资源类型发布节点图风格编辑器；
  • 直接集成到 Hytale 资源编辑器中，提供统一创作套件，而非零散工具拼凑。

（附图：节点编辑器未来概念图）

可视化脚本（Visual Scripting）

• 可视化脚本是我们长期愿景的核心支柱：
  • Java 插件将继续存在且极其强大，但需编程技能并带来安全顾虑；
  • 可视化脚本将：
    • 提供沙盒化、安全的逻辑共享环境；
    • 为各级模组开发者提供易学易改的体验；
    • 允许程序员通过高性能节点扩展系统。
• 长期目标：
  • 将可视化脚本直接嵌入 3D 世界：
    • 在游戏中连接拉杆、门、刷怪笼、触发器等元素；
    • 直接在 Hytale 内构建复杂的冒险地图与遭遇战；
  • 借鉴如 DOOM SnapMap 等系统，同时深度集成到我们的资源与脚本体系中。

结语

我们非常明确地处于模组开发的“抢先体验”阶段。

• 工具参差不齐；
• 文档残缺不全；
• 有些流程流畅，有些令人沮丧；
• 存在崩溃风险，若不备份，你可能会丢数据。

我们不假装这些不存在。

但与此同时：

• 这些正是我们用来构建 Hytale 本身的工具；
• 在许多情况下，我们一边开发工具，一边制作内容，始终将模组支持纳入考量；
• 我们知道这条路可行——因为它已经产出了你今天看到的游戏。

我们对你的承诺：

• 将一步步持续改进模组体验；
• 聚焦于易学性、入门引导，以及从新手到专家的成长路径；
• 对哪些功能就绪、哪些尚未完成、下一步优先做什么，保持透明；
• 当你告诉我们痛点所在，我们会认真倾听。

如果你愿意在这个阶段加入我们——带着 bug、粗糙边缘和一切不完美——你将不只是在为 Hytale 制作模组，你将亲手塑造 Hytale 模组生态的未来。

我知道本文遗漏了许多细节，你可能比之前有更多疑问。我将于2025 年 11 月 22 日（星期六）中午 12 点 EST（下午 5 点 GMT） 在 Hytale Discord 服务器的 Modding / Creative > #discussion频道进行一小时问答，尽可能回复大家的问题。

在你心中的 Orbis 世界见，