85 lines
7.6 KiB
Markdown
85 lines
7.6 KiB
Markdown
---
|
||
front: https://nie.res.netease.com/r/pic/20211104/69055361-2e7a-452f-8b1a-f23e1262a03a.jpg
|
||
hard: 入门
|
||
time: 10分钟
|
||
---
|
||
|
||
# 了解附加包的功能
|
||
|
||
通过附加包，我们可以实现对我的世界各种功能的修改。而前面我们知道，我的世界开发工作台里的编辑器也可以可视化地支持我们对我的世界进行一键式修改。那么，这两者又有什么不同呢？事实上，在编辑器的“AddOn组件”中操作各种功能修改的过程的本质就是一个制作和修改附加包，从而进一步对我的世界游戏进行修改的过程。只不过，编辑器中的修改更加可视化，也更加简便。但是同时相对地，在编辑器中修改的扩展性、灵活性和结果的复杂性都比直接操作文件进行修改低很多。因此，如果我们要制作一些大型的、复杂的、功能全面的附加包，我们还是需要学会如何通过直接操作文件的方式进行内容与功能的修改。
|
||
|
||
## 定义文件
|
||
|
||
我们介绍一类在附加包中需要经常接触到的文件，那便是**定义文件**（**Definition File**）。定义文件是一种能够通过其中包含的数据来定义游戏中各种内容的文件类型，通常都是JSON文件，也就是我们所见到的`.json`扩展名的文件。
|
||
|
||
这些JSON格式的定义文件都采用了一种可带注释的JSON格式。所以如果要看懂并且正确书写定义文件，我们需要先了解**JSON**（**JavaScript Object Notation**，**JavaScript对象表示法**）的格式。这一块知识各位开发者可以在网络上自行了解。
|
||
|
||
事实上，在上一章的挑战节中，我们在小节开头接触到原版的`Vanilla_Resource_Pack/entity/slime.entity.json`和`Vanilla_Behavior_Pack/entities/slime.json`便是实体的两个定义文件。`slime.entity.json`定义了客户端实体的渲染、模型、纹理等属性，而`slime.json`定义了同一个实体的服务端组件、事件等内容。
|
||
|
||
定义文件决定了大部分游戏玩法的“初始状态”和少部分“伪逻辑”（比如实体的动画）。也正因如此，定义文件中的内容往往仅仅被称为是一种静态的**数据**（**Data**），而通过这种数据新增或更改的内容、为这种数据提供的接口和组件都被称为是**数据驱动**（**Data-Driven**）的。
|
||
|
||
## 脚本文件
|
||
|
||
**脚本文件**（**Script File**）是仅次于定义文件的最重要的文件类型。脚本文件指那些可以被我的世界基岩引擎加载的脚本。在我的世界国际版中，开发者们通常会使用JavaScript脚本，但是在我的世界中国版中，我们可以使用另一种中国版独占且接口功能强大的脚本——**Python**脚本。我的世界中国版中的Python脚本的接口又被称作**模组API**（**Mod API**）。这是中国版开发组精心打造的我的世界模组接口，富有非常强大的功能，并且和数据驱动接口紧密结合，在充分发挥数据驱动接口的功能的同时为其添加”真正“的逻辑，通过“真正”的事件系统和组件工厂实现更加强大的游戏玩法。
|
||
|
||
脚本文件的内容一般都被称为**脚本**（**Script**），而通过脚本新增或更改的内容、为脚本提供的接口和组件都被称为是**脚本使能**（**Script-Enabled**）的。
|
||
|
||
数据驱动内容和脚本使能内容紧密结合，可以使附加包作为一个游戏模组拥有相当高的功能上限。
|
||
|
||
## 依赖行为包的功能
|
||
|
||
下面我们一起了解主要有哪些功能是依赖于行为包的。
|
||
|
||
### 实体、物品和方块的服务端内容
|
||
|
||
实体、物品和方块都是由两个定义文件定义的，一个位于资源包，负责客户端内容，一个位于行为包，负责服务端内容。其中，位于服务端的定义文件往往更加重要，因为服务端定义文件占据了实体、物品和方块的主要游戏表现形式。我们在游戏中看到的各种功能、行为、游戏玩法其实大部分都源自他们的服务端行为。
|
||
|
||
同时，如果我们要给他们加上脚本逻辑，那么这些脚本也全部位于服务端。所以，实体、物品和方块在行为包的部分尤为重要。
|
||
|
||
### 维度、生物群系和特征
|
||
|
||
维度、生物群系和地物的定义也全部位于行为包，因为他们决定了世界生成，而世界生成全部都是在服务端完成的。**维度**（**Dimension**）是一种类似于主世界、下界和末路之地的世界概念；**生物群系**（**Biome**）是决定了类似于哪里是草原、森林、海洋，哪里生成各种生物，以及哪里生成各种地物的的世界概念；而**特征**（**Feature**，又译**地物**）则是一种类似于大到遗迹建筑、小到矿石矿脉的在世界中零散分布的实物。
|
||
|
||
### 预设和零件
|
||
|
||
**预设**（**Preset**）是一种预先设定好的可以是方块、实体、玩家或世界的抽象结构，但是可以通过实例化变为世界中真实存在的事物或逻辑。**零件**（**Part**）是一种可以挂接在预设上的逻辑脚本，可以跟随预设发挥作用。这两类的文件全部都应存储在行为包中。
|
||
|
||
### 模组API脚本
|
||
|
||
前面我们介绍了中国版独占的一种脚本——模组API的Python脚本。所有的模组API脚本全应位于行为包中。
|
||
|
||
### 其他内容
|
||
|
||
配方、交易、战利品表和逻辑编辑器中的宏、逻辑蓝图也全都是由行为包来定义和存储的。
|
||
|
||
## 依赖资源包的功能
|
||
|
||
下面我们一起了解主要有哪些功能是依赖于资源包的。
|
||
|
||
### 纹理贴图
|
||
|
||
所有的纹理贴图，不论是覆盖原版纹理的贴图文件，还是为了自定义新的玩法而加入的文件，全都应存储在资源包对应的文件夹中。只有这样，客户端才能找到对应的纹理并将其渲染。
|
||
|
||
### 着色器（光影）
|
||
|
||
所有的**着色器**（**Shader**，俗称**光影**）都是在资源包中定义和实现的。这是因为着色器是用来提供给渲染器进行渲染的，而渲染器的渲染是仅发生于客户端的内容。
|
||
|
||
### UI
|
||
|
||
虽然微软正在研发我的世界的新型UI，但是目前在游戏中广泛采用的依旧是一种沿用了很多年的由JSON驱动的UI格式，我们通常称其为**JSON UI**。JSON UI的定义文件全部位于资源包内，通过基岩引擎解析来发挥作用。
|
||
|
||
但是，在资源包内定义的UI事实上几乎没有什么逻辑。原版的JSON UI空间大部分都需要绑定硬编码的功能来实现逻辑，但是我们可以使用模组API来为我们自定义的UI添加逻辑。不过，由于使用了模组API，UI逻辑相关的脚本文件全部都应位于行为包内，还请各位开发者谨记。
|
||
|
||
### 实体、物品和方块的客户端内容
|
||
|
||
这部分内容往往是实体、物品和方块用于绑定纹理（Texture）、模型和材质（Material）的，而材质会进一步将它们关联到着色器上，方便游戏内的渲染。
|
||
|
||
当然，物品中也有一些组件是客户端独占的组件，它们被写在物品的客户端定义文件中。
|
||
|
||
### 模型
|
||
|
||
显然，模型是用来渲染的。游戏中实体、方块真正的碰撞箱往往与模型不同，大部分时候都比模型要简陋一些，大多是一个大的或一些小立方体的组合，这可以方便服务端的计算。而更为精细的模型则是用来输出在玩家的屏幕上的，服务端无需得知此类精细的信息。所以模型也被安置在了资源包中。
|
||
|
||
### 其他内容
|
||
|
||
粒子和特效定义、字体文件及其定义、声音文件（音效和音乐）等内容都是用于在客户端计算和输出的内容，他们都应位于资源包中。 |