生物群系
最后更新于1.16.210版本
WARNING
自1.18版本起,自定义生物群系在Minecraft基岩版中存在问题
WARNING
生物群系定制功能目前处于_实验性阶段_。每个使用包含生物群系定义的行为包的世界,都必须启用实验性玩法开关。目前若声明正确,功能运行良好;但若组件或属性声明错误,可能导致游戏崩溃而非仅记录错误。此外,由于继承模型引发的问题,当前自定义生物群系的架构设计尚不完善。
WARNING
截至1.16.210版本,下界生物群系生成存在漏洞。下界生物群系现通过"multinoise_generation_rules"组件进行定制,但当前自定义生物群系无法使用该组件生成。同时,在原版覆盖中使用旧的"nether_generation_rules"组件将导致该生物群系在下界无法生成。
行为包允许对生物群系进行定制。行为包既可以创建全新的自定义生物群系,也可以对已声明的生物群系(如原版生物群系)进行覆盖。生物群系与关键游戏玩法紧密关联,如生物生成、数据驱动玩法以及自定义方块的呈现。此外,生物群系还支持强大的装饰系统,可添加花草树木等自然元素,甚至塔楼房屋等建筑结构。这些装饰和结构统称为特征,它们对世界生成至关重要,但在作用范围和构建方式上(通常)与生物群系相互独立。
虽然覆盖和自定义生物群系功能大体相当,但若要打造全新游戏体验,推荐使用自定义生物群系。覆盖应保留原生物群系的特性和设计意图,仅适用于以下情况:
- 轻微的地表、高度图或气候调整
- 改变世界生成中生物群系的稀有度分布
- 新增特征或生物(仅限主题契合时)
当需要实现_任何_独特游戏体验,或对现有生物群系的调整会根本改变其本质时,应使用自定义生物群系。自定义生物群系的典型应用场景包括:
- 需要全新或独特的景观以实现特定美学效果
- 自定义特征(如新树种)需要生成空间
- 期望通过新增生物和结构创造差异化或更具挑战性的游戏体验
由于生物群系架构的疏漏,这些建议存在例外。例如,若想强制让原版主世界生物群系在更多位置生成,似乎只需覆盖原版即可,但由于生物群系注册生成的方式,这可能无法实现。这意味着需要通过多个生物群系定义文件克隆其美学特征,并各自调整生成规则。
生物群系定义
生物群系通过行为包顶级biomes目录中名为*生物群系名称*.json或*生物群系名称*.biome.json的文件声明。biomes目录内不能使用子目录分组生物群系定义,所有子目录中的定义将被忽略。
由于标识符必须与文件名匹配,不同生物群系声明包间可能发生命名冲突。避免冲突的策略之一是采用反向域名命名法。生物群系名称可包含句点实现嵌套分组,例如biomes/fancycraft.fantasy_realms.magical_springs.hills.mutated.json。其中fancycraft代表开发者,fantasy_realms是行为包名,magical_springs为顶级生物群系名称,hills和mutated是子生物群系类型,json为必需扩展名(此例省略了可选的.biome扩展名)。
若顶级
biomes目录中存在无效JSON文件,通常仅会记录错误,但也可能引发崩溃。直接放置在此目录的非JSON文件会被忽略。若目录中存在以.开头的文件,游戏当前必定崩溃。这可能导致项目配置文件甚至macOS上 notorious的.DS_Store文件引发问题。
格式
与行为包中所有结构化资源一样,生物群系定义采用JSON格式,例如:
{
"format_version": "1.13.0",
"minecraft:biome": {
"description": {
"identifier": "pumpkin_pastures"
},
"components": {
"minecraft:surface_parameters": {
"foundation_material": "minecraft:stone",
"top_material": "minecraft:grass",
"mid_material": "minecraft:dirt",
"sea_floor_depth": 4,
"sea_material": "minecraft:water",
"sea_floor_material": "minecraft:sand"
},
"minecraft:overworld_height": {
"noise_params": [0.125, 0.0625]
},
"minecraft:climate": {
"temperature": 0.375,
"downfall": 0.25,
"snow_accumulation": [0, 0.5]
},
"minecraft:overworld_generation_rules": {
"generate_for_climates": [["cold", 1]],
"hills_transformation": "pumpkin_pastures_hills",
"shore_transformation": "pumpkin_pastures"
},
"overworld": {},
"pumpkin_pastures": {},
"animal": {},
"monster": {}
}
}
}与其他附加组件元素一样,无效JSON会导致生物群系定义失败——该生物群系不会在世界中生成。遗憾的是系统不会抛出错误。使用JSON验证工具和/或语法高亮工具可轻松避免此问题。
格式版本
"format_version": "1.13.0"顶级属性"format_version"描述后续架构遵循的版本规范。生物群系当前最新的"format_version"为"1.13.0"。
1.12版本曾存在旧格式,但已被弃用且无法在新版本中使用。旧格式中生物群系标识符作为顶级对象属性的键,该属性直接包含格式版本、组件和标签。本文档仅使用
"1.13.0"格式,但您可能在其他地方见到已弃用的格式。
版本号应采用*主版本*.*次版本*.*修订号*形式,其中修订号或次版本与修订号可省略。三个标识符必须为整数,但完整版本号不必对应Minecraft真实版本。当前任何大于等于1.13.0的版本号都会指向1.13.0规范,但建议仅使用1.13.0或开发时针对的版本,因为未来版本可能影响整体架构。
生物群系规范
"minecraft:biome": {
…
}另一个顶级属性是"minecraft:biome",用于建立生物群系定义的架构。
描述
"description": {
"identifier": "pumpkin_pastures"
}"minecraft:biome"属性中的"description"属性用作生物群系的元数据。当前仅包含一个属性"identifier",用于唯一标识生物群系。该值必须与文件名匹配(不含.json或.biome.json扩展名)。例如,若标识符为prairie,则文件名必须为prairie.json或prairie.biome.json。此标识符用于从多个生物群系定义属性中引用。
与其他附加组件元素不同,生物群系标识符不接受文件名忽略的命名空间前缀(如
elysium:)。虽然可提供此类前缀,但文件名必须包含前缀和冒号——这在许多支持Minecraft的文件系统上属于无效文件名,因此不应使用这种传统命名空间系统。建议改用反向域名系统。
组件
"components": {
…
}"minecraft:biome"属性还包含"components"属性,这是生物群系定义的核心。此处声明的组件负责生物群系的定位、塑形和风格设计。
组件细节分散在本文档后续部分;由于交互复杂性,它们无法像这些包装属性那样被清晰描述或组织。
组件始终作为对象属性存在,即使是那些本应作为布尔值的组件。例如,"minecraft:ignore_automatic_features"组件属性不赋值true或false,而是赋空对象{}:
"components": {
…
"minecraft:ignore_automatic_features": {}
}虽然JSON可能无效,但"components"对象中可以使用同名属性表示组件。尽管应避免这种情况,但需注意游戏只会使用最后提供的组件实例:先前定义的组件值会被完全忽略。例如:
"components": {
…
"minecraft:overworld_height": {
"noise_type": "ocean"
},
"minecraft:overworld_height": {
"noise_params": [1.25, 0]
}
}尽管"noise_type"属性通常完全覆盖"noise_params"属性,但在此例中预设将被忽略,因为组件在"components"对象中的声明顺序决定了优先级。
在生物群系定义中使用组件时,必须提供其_所有_必需属性;否则会抛出错误且生物群系生成失败。
由于继承模型的工作机制,若生物群系定义的继承链中存在不完整组件,但这些组件组合后能提供该组件架构所需的完整属性,则该组件仍能正常工作。有趣的是,当两个组件位于同一生物群系定义文件时,此情况不成立。如前所述,即使后者组件缺少必需属性,系统仍会使用后者组件。
标签
"components": {
…
"overworld": {},
"pumpkin_pastures": {},
"animal": {},
"monster": {}
}除了构建生物群系的组件外,"components"属性还允许添加任意标签。标签以空组件形式出现,如"animal": {}。标签名称必须符合正则表达式[a-z0-9_.:]+,即:小写拉丁字母、阿拉伯数字、下划线、句点和冒号。
为保持未来兼容性,不建议创建以
minecraft:为前缀的标签,以免与未来Mojang定义的组件冲突。此外,建议为这些标签使用包特定命名空间,以最小化与其他行为包的冲突,例如"betterbiomes:arboreal"。
继承
根据行为包加载顺序,生物群系定义文件可作为初始定义或覆盖使用。行为包堆栈中最先出现的生物群系定义标志着自定义生物群系的创建;后续对同一生物群系的定义可通过继承修改或覆盖先前定义。
只有"components"属性中的组件和标签可被继承。单个组件内的属性通常也可继承。遗憾的是,某些组件或组件属性对象需要完全重新声明所有属性才能工作,这意味着覆盖时通常最好重新声明整个组件。除非新组件会干扰现有组件(如表面构建器常见情况),否则继承始终生效。
无法移除先前定义的属性。这对标签尤其麻烦,因为它们不仅用于标记生物群系位置,还驱动着生物生成等其他游戏元素。若因继承问题引发冲突,建议将生物群系的所需元素提取到新的自定义生物群系中,并尝试从世界生成中移除旧生物群系。
若覆盖先前声明的生物群系,生物群系文件可能为空(但无实际作用)。若生物群系定义(无论是初始定义还是覆盖)包含任何组件,则必须包含顶级"format_version"属性直至"identifier"属性。生物群系的初始定义必须包含至少一个组件或标签;由于几乎所有生物群系方面都有默认回退值,因此所需声明内容很少。
生成
生物群系在世界中的生成规则取决于三个因素:
- 生物群系注册的维度
- 相对于所有应用于世界的行为包中注册同一位置的其他生物群系,该生物群系在特定位置生成的潜力
- 源自世界种子的该位置不可变随机噪声表面
位置可能代表整个维度或其表面区域的子集。"位置"概念在实际文档或架构中并不存在,此处用该术语表示生物群系可选择生成的专用区域,或为单一目的独立连接的一组生物群系。
_生物群系布局并非按世界随机,而是按种子随机。_这意味着若将包含相同自定义生物群系定义的相同附加组件应用于两个相同种子的新世界,两个世界中每个维度的生物群系布局将完全一致。这对原版生成显而易见,因为相同种子总是在相同位置生成相同的原版生物群系。
当前Minecraft无法创建新维度。末地既不允许新增生物群系,也不允许移除默认生物群系,因此只能自定义主世界和下界。
Mojang提供的文档中提到
"minecraft:legacy_world_generation_rules"组件会影响旧版有限世界,但未提供该组件的架构,且原版生物群系定义均未使用它,因此其用途和行为尚不明确。
主世界
"minecraft:overworld_generation_rules": {
"generate_for_climates": [
["cold", 1]
],
"hills_transformation": "pumpkin_pastures_hills",
"shore_transformation": "pumpkin_pastures"
}生物群系主要通过"minecraft:overworld_generation_rules"组件与主世界生成交互。在此它们可注册为基础生物群系并声明其子生物群系。遗憾的是,标签系统也会介入区域的分配。
气候和区域形成独立且不可配置的位置映射,这些映射在主世界中重叠。具有特定气候位置和区域位置的生物群系只能在种子决定的这些位置映射的相关交集中生成。换句话说,生物群系只能在主世界中气候和区域类型匹配的区域生成,气候和区域绑定限制了生物群系可能生成的表面区域。生物群系可直接分配到这些交集作为基础生物群系,同时可在这些基础生物群系中声明子生物群系以实现更精细的地形细节。
生物群系通过权重竞争位置交集的可用区域。生物群系实例实际上并非根据种子预定;相反,相关位置的可用空间似乎按权重划分。因此,向位置交集添加生物群系将导致生物群系_规模缩小_而非_稀有度增加_;反之亦然。由于气候和温度映射的规模不可配置,调整生物群系权重是修改生物群系大小的唯一方法。
气候
"generate_for_climates": [
["frozen", 2],
["cold", 1]
]生物群系必须与温度类别对齐才能作为基础生物群系生成。要将生物群系提升为将在主世界生成的基础生物群系,该生物群系定义必须在"minecraft:overworld_generation_rules"组件中包含"generate_for_climates"数组属性。该数组包含形式为[*气候类型*, *权重*]的数组值,其中*气候类型*是五种气候字符串之一,*权重*是反映生物群系生成几率的整数值。生物群系按其声明区域内各气候类别的权重生成,并在其范围内生成子生物群系。
此处的气候温度与
"minecraft:climate"组件中的浮点属性"temperature"不同,后者用于风格设计而非位置确定。不过传统上出于游戏玩法考虑,二者具有相关性。
若为权重提供浮点值,该值将被截断,向下舍入至最接近的较小整数。若权重设为负值,其行为将与设为
0相同。
按温度升序排列的5种气候为:
| 气候 | 属性值 |
|---|---|
| 冰冻 | "frozen" |
| 寒冷 | "cold" |
| 温和 | "medium" |
| 微暖 | "lukewarm" |
| 温暖 | "warm" |
生物群系权重作为位置交集共享分母的分子。例如:
假设生物群系X的权重为5。目标位置中所有生物群系(包括X)的总权重为20。因此,生物群系X的生成几率为5/20,即25%。
通常可通过权重清零移除原版生物群系:在所有适用气候中将其"generate_for_climates"属性的权重设为0。然而,Minecraft实际上设有激进的回退系统来防止权重清零导致的生成失败,因此此策略可能不足以移除生物群系。取消分配或添加自定义生物群系可能是移除生物群系的必要手段。
若某气候的所有生物群系均设为不生成,Minecraft会使用其他气候的生物群系填充该气候的指定空间。回退系统甚至可能将完全权重清零或取消分配的生物群系生成到未使用的气候位置中,通常优先考虑气候分配而非区域分配。因此,建议始终为普通陆地和海洋的每种气候保留至少一个生物群系。由于稀有陆地面积较小,可忽略不计:原版生成甚至在冰冻气候中未设置稀有陆地。
Minecraft仅











