世界生成问答 2024/11/15

本次问答活动在Bedrock附加包Discord举行。数名Mojang/Microsoft员工参与并解答了关于自定义方块与物品API的问题。所有问题均来自社区征集。

关于定位地图的计划？ ​

• 问：我注意到自定义拼图结构可以使用定位地图，但是否有计划提供更"官方"的支持（比如自定义图标/地图名称）？
• 答：我们已关注到这个需求，但短期内暂无开发计划。

是否计划将原版结构迁移至当前拼图系统？ ​

• 问：如果未来能修改所有原版结构（如村庄、掠夺者前哨站等）就太棒了。据我所知它们使用的是旧版拼图系统或完全不同的机制。若能像试炼密室和遗迹那样迁移到当前拼图系统，社区绝对会非常欢迎这种能让玩家修改所有原版结构的功能。
• 答：我们确实希望将更多原版结构迁移到新系统，但这不在短期或中期计划内。当前可用的原版结构只有试炼密室和遗迹。你们最希望优先看到哪个结构迁移？
• 补充说明：需要说明的是，本次问答参与者无法代表原版开发团队及其意图。

下界与末地的自定义生物群系 ​

• 问：当自定义生物群系功能回归基岩版时，是否会增强对下界和末地的支持？据我所知，末地从未有过自定义生物群系...
• 答：资源包中的client_biome设置（用于视觉效果和音效）现在应该适用于所有生物群系，包括下界和末地。至于影响行为和世界生成的部分，我们也认为应该支持这些维度，但目前没有相关开发计划。

是否为自定义生物群系添加环境粒子效果？ ​

• 问：当自定义生物群系还存在时，唯一能直接添加的粒子效果就是下界粒子。未来能否支持为生物群系设置任何自定义粒子？
• 答：我们过去曾研究过自定义环境粒子效果，这个功能确实值得考虑。非常欢迎分享你们计划如何使用这个功能的具体案例。

自定义维度 ​

• 问：能否为未来主题的附加包添加创建新维度的能力？包括从高度限制到维度生成系统的完整编辑功能，就像Java版那样。在Java版中创建自定义维度非常简单，基岩版也很需要这个功能。

• 答：我们完全理解自定义维度对创作者的重要性，但当前工作重点是世界生成的诸多基础元素。

  短期内，我们正着力扩展特征功能和拼图结构，增强各项能力，为更完善的生物群系自定义铺路。

/place feature命令 ​

• 问：未来会推出通过命令放置特征的功能吗？
• 答：这已在我们的短期开发计划中！

能否扩大拼图结构的区块宽度限制？ ​

• 问：128的尺寸太小了，我的市场项目需要6倍于此的尺寸。如果不能通用调整，能否支持按拼图结构单独设置？
• 答：128并非严格限制。生成区块时我们会检查8个区块范围以确保大型结构能正确生成。但出于性能考虑，超过128可能会有些风险。另外需要说明的是，这个数值是半径而非直径！也就是说实际总宽度是——你猜对了——256。😄

Molang会有性能优化吗？ ​

• 问：使用Molang的3D噪声函数进行自定义地形生成时，即使只使用1种方块类型和1个特征规则，也经常导致世界加载需要5分钟以上，这实在太夸张了。
• 答：我们正在特别研究q.noise的性能问题，考虑是否可以通过缓存等机制优化。建议现阶段尽量避免大量使用该函数。

为什么拼图功能开发耗时这么久？ ​

• 问：拼图方块存在已久...为什么它长期处于半成品状态？当初是出于什么原因搁置了这项功能？

  又是什么促使你们最终决定让创作者使用它们？

• 答：坦白说过去我们有时会开发平台功能但未能及时完善——比如节日创作者功能。多数情况下这意味着我们需要改进功能上线的流程，有时也需要及时终止没有前景的实验。我们正在努力改善这类情况，当然不可能尽善尽美。

  关于为何现在开发拼图功能：我们有一系列待开发的功能清单，现在正着手处理基础世界生成元素。在开放这些功能前，通常需要先进行大量底层更新以确保稳定性、性能和兼容性。

自定义结构中的刷怪点 ​

• 问：旧版结构框架的缺陷之一是无法放置实体或创建刷怪点（就像下界要塞、海底神殿等结构的持续刷怪机制）。我通常使用会自毁的 ticking 方块来刷怪，但这会引发其他问题。

  随着拼图结构变得可用，我们现在可以在结构中放置实体了。但世界生成框架是否有计划支持刷怪点功能？

• 答：大家好！非常喜欢当前的讨论。这个功能正在开发中！鉴于生物生成系统较为敏感（咳嗽刷怪塔），我们需要确保万无一失。这意味着需要更多测试。请期待实验版即将推出的新内容！

• 追问：这是否意味着刷怪率会与Java版保持一致？

• 答：这正是目标！进入实验版后（很快），我们需要大家帮忙测试以确保世界平衡性，包括对刷怪塔的影响/改进。

结构冲突问题 ​

• 问：人们常用的变通方案（如通过命令方块生成结构）容易导致结构冲突，特别是地下结构。比如试炼密室可能与其他结构交叉导致破坏。希望拼图方块能提供防止冲突的功能。
• 答：这确实在我们的关注列表中，但目前没有具体开发计划，因为底层存在更复杂的问题需要解决。

目录结构问题 ​

• 问：新拼图系统将所有相关文件放在worldgen目录下。有计划将structures、features、feature_rules和biomes也移入该目录吗？拼图集合放在worldgen是出于Java版兼容性考虑吗？
• 答：我们将拼图相关文件逻辑归类。"worldgen"作为文件夹名称确实有些奇怪（毕竟特征和特征规则不在其中），未来可能会调整其他文件位置，但目前没有迁移计划。

拼图方块能否用于生成巨型矿脉？ ​

• 问：拼图方块适合创建类似巨型铁/铜矿脉的结构吗？还是部分暴露的团块特征更合适？
• 答：现有的minecraft:ore_feature已支持自定义矿脉，这个功能是否无法满足你的需求？

世界生成中的脚本集成 ​

• 问：有计划在世界生成中集成脚本吗？例如根据世界事件修改结构布局或内容的脚本。

• 答：我们正在探索脚本与世界生成的结合方式，但要注意让脚本"接管"区块生成的主要部分会严重影响性能。三重循环的方块设置很快就会变得缓慢 🙂

  或许可以在某些环节调用脚本做"决策"。不过短期内脚本不会加入世界生成路线图。

  两年前我尝试用脚本构建地牢生成器demo时，就发现很难处理方块放置的时间切片和区块加载语义问题。

  虽然现在脚本对生成器函数有了更好支持，在高端设备上或许可行。我知道社区已经有人做出了很酷的尝试。

• 补充回答：一个有趣的构想是采用webworker模型，在其他线程运行JavaScript来处理世界生成等任务。

  可以提供一个专门的世界生成API模块。目前只是构想，但未来或许能实现！

开发团队最期待创作者用新工具做出什么？ ​

• 答：我超级期待各种地牢、传说和史诗故事！太多可能性即将被解锁.. 👀

结构旋转功能 ​

• 问：会支持拼图结构的旋转吗？如何确保结构与特定地形（如山坡/河流）正确对齐？是简单的条件处理还是更复杂的机制？
• 答：我们已收到创作者在上次预览中的反馈！你具体设想的使用场景是？
• 追问：随机旋转是必备功能——除非每个结构朝北有什么深层设定。另一个问题是自定义方块本身不会旋转。
• 答：明白了。关于结构旋转的讨论已经有过，我会提议将其加入待改进清单！

为何不开放conditional_list和sculk_patch_feature？ ​

• 问：conditional_list被移除了，为何不恢复？sculk_patch_feature又为何一直不可用？
• 答：conditional_list需要更多工作来完善，我们正在评估优先级。sculk_patch_feature过于原版专属，未来可能考虑更通用的替代方案。
• 追问：这是否意味着你们反对未来添加原版专属的特征类型？毕竟树特征就存在。
• 答：一般来说，我们会在"通用平台功能"、"类原版功能"和"过于原版专属而需要重新设计"之间划一条模糊的界限。目前这就是我们的判断标准 🙂

会补全Java版的拼图功能吗？ ​

• 问：Java版拼图结构有部分功能在基岩版缺失：
  • 从结构放置特征（即minecraft:feature_pool_element）
  • 模板池别名（Java版用这个机制选择试炼密室的刷怪笼类型，基岩版如何实现？）
• 答：你们注意到了新版拼图系统有生成覆盖功能，但尚未实现数据驱动。团队正在简化生成规则，之后会全面开放这个系统。
• 追问：是指整个生成系统（包括实体BP JSON中的spawn_category和spawn_rules文件夹）吗？是先简化再扩展功能？
• 答：没错！和所有重构工作一样，必须从基础系统开始。我们即将实现与Java版持平的生物生成系统。同时简化生成规则，确保最终开放的功能更清晰易用！

世界更新选项 ​

• 问：能否提供更智能的世界更新方式？当更新包含新结构时，玩家必须探索新区块才能找到它们，有些甚至会被已有区块"吞噬"。

  能否检测未更改/仅探索/轻微修改的区块，为其生成新结构？

• 答：我们考虑过！但要避免各种副作用非常困难（正如你们提到的）。我们很好奇：如果实现这个功能，你们会用于测试还是实际游戏世界？

自定义超平坦生成器 ​

• 问：Java版有自定义超平坦生成器，基岩版却没有（反馈网站上有高票请求）。这个功能对市场和各类玩法都很有用。

  如果实现，会支持生物群系和结构吗？

• 答：目前不在路线图上。如果要移植Java版功能，我们需要像硬核模式那样进行基岩版专属设计。

基于方块的放置特征规则 ​

• 问：我想创建一种岩石，希望它只替换位于石头方块上方的空气方块。如果能添加place_above和place_under等特征规则就太好了。
• 答：你可以使用minecraft:single_block_feature的may_attach_to "top" & "bottom"选项。如果这不够灵活，可以结合aggregate_feature或sequential_feature实现更复杂的效果。

通过命令或附加包修改生物群系 ​

• 问：未来能否在游戏中直接或通过附加包修改生物群系？比如/fill biome命令实时改变天气类型（雪/雨等）和生物生成。
• 答：我们研究过Java版的fillbiome命令，但基岩版需要先解决许多底层问题。

世界生成改进的核心理念？ ​

• 问：很好奇团队如何看待世界生成改进（数据驱动的生物群系、维度、拼图系统等）？

  是追求快速推出测试版，还是稳步推进？会担心预览版破坏存档吗？

  （长期来看）世界生成会走向完全自定义吗？哪些部分优先开发？

  开发过程中遇到哪些障碍（技术难点、长期/短期权衡等）？

  基岩版与Java版的世界生成开发思路有何异同？

• 答：很多子问题！我回答几个重点：

  我们坚持迭代开发模式，定期推出小功能收集反馈。

  预览版会尽量避免破坏存档，但不像正式版那么严格。预览版始终存在更高风险。

  长期原则是：创作者应该能实现我们（Mojang）在原版游戏中能做到的一切。这是个远大目标，需要逐步实现。

  基岩版与Java版的主要差异在于：

  • 多平台支持与性能差异
  • 向后兼容性与多附加包兼容性 这要求我们在基岩版上投入更多设计精力。

世界生成路线图 ​

• 问：普通玩家能知道Mojang的工作计划，但非市场创作者只能通过询问或更新公告获取信息。希望能提供1年期的路线图（不介意延期），让我们能提前学习准备。

• 答：世界生成的路线图会比较长。我们从基础元素开始（改进方块特征等），然后是特征和拼图结构，接着是生物群系功能。

  原版生物群系系统非常复杂，解决方案具有挑战性，但我们正在积极开发。希望明年能分享更多设计细节。

  关于生物群系的技术需求：噪声图、比例、天气、雾效、音效等。我们的目标是构建兼顾创作者需求的健壮系统。欢迎列出你们最需要的5-10项生物群系功能！

修复结构模板特征尺寸限制？ ​

• 问：实际限制是48x48（由于区块限制），有计划修复或扩大这个限制吗？
• 答：基于区块大小和世界生成机制，提升这个限制比较困难。建议大型结构使用拼图结构系统。

为何没有生成结构开关？ ​

• 问：自定义世界生成开发是否与基岩版缺少"生成结构"开关有关？使用附加包时我常希望能修改/移除原版结构。
• 答：要真正解锁世界生成自定义的潜力，我们需要自定义生物群系功能。这将允许我们通过API修改原本难以触及的世界生成部分。

子区块计划？ ​

• 问：考虑过将特征生成迁移到子区块系统吗？特别是对大型边界维度的支持？重写世界生成系统虽困难但值得投入。
• 答：目前通过feature_rule的坐标范围功能可以手动实现。需要创建4个特征规则来覆盖16x16区域。子区块相关功能暂不在路线图上。

市场内容支持结构与矿物生成？ ​

• 问：计划在市场内容中添加结构与矿物生成功能吗？
• 答：是的，我们计划允许市场附加包使用特征/特征规则。可能会有性能方面的限制，但也难以通过政策完全规避过度使用。需要观察实际使用模式。

更多自定义特征类型？ ​

• 问：会扩展可自定义的特征类型吗？比如创建自定义骨粉催生区域或钟乳石柱特征（而非使用结构）。
• 答：暂无新增特征类型的计划，但现有特征组合已能实现这些效果（如用sequential_feature模拟钟乳石柱）。/place feature命令已在短期计划中！

拼图系统稳定计划 ​

• 问：拼图系统未来2-4个月会退出实验状态吗？API还需要很多调整。
• 答：我们正根据社区反馈进行调整。各位拼图建造者请尽情测试！没有压力测试就无法发现问题。

处理器列表的扩展应用 ​

• 问：处理器列表非常棒！能否将其应用于：
  • /fill命令及相关脚本API
  • /structure命令及相关脚本API
  • 结构模板特征（或所有特征类型）
  • 独立使用（像/fill那样转换指定区域） 这将极大增强区块处理能力。
• 答：绝妙的主意！虽然当前路线图中没有，但我们会认真记录这个建议 <:bao_bee:937587347124535346>

拼图文件结构为何如此奇怪？ ​

• 问：几周前实现的拼图系统几乎是Java版的直接移植。很好奇为何采用这种晦涩的Java风格接口，而非更直观的设计？ 具体问题包括：
  • 为何将随机测试与方块测试捆绑在minecraft:random_block_match？
  • 为何不直接在minecraft:block_match添加默认值为1的probability参数？
  • 仅想通过input_predicate绑定战利品时为何必须设置output_state？
  • 基础判断条件{"predicate_type": "minecraft:always_true"}过于冗长
  • location_predicate与position_predicate命名易混淆但含义完全不同 虽然处理器列表概念很棒，但这绝对是基岩版当前最令人困惑的文件架构。
• 答：感谢深刻见解！我们会将意见带给团队 🫡