构建资源
资源构建过程 是指将所有游戏资产(包括模型、纹理、关卡及其相关设置和游戏逻辑)打包成二进制文件的过程。此方法有助于减少需要下载的文件数,从而加快下载过程,同时保持数据量不变。它还可以保护我们的资产不被玩家用于意外目的。
游戏本身不会直接与我们创建的原始资产(如模型、纹理或关卡设置)交互。相反,它只与编译的二进制文件交互。加载关卡时,将获取、解压缩必要的包,并从中提取所需的信息。
本文概述了如何构建资源、关卡和设置。
.folder.blk中的参数影响构建过程
资源构建过程受 .folder.blk 文件中定义的规则控制。
See also
有关更多信息,请参阅 .folder.blk.
例如,以下块指定.tiff纹理的压缩参数。
virtual_res_blk{
find:t="^(.*)\.tiff$" // 搜索任何 .tiff 文件
className:t="tex" // 分配 “texture” 类
contents{ // 处理细节
convert:b=yes;fmt:t="DXT1|DXT5" // 转换;使用 DXT1 或 DXT5 格式(如果存在 Alpha)
mipFilter:t="filterKaiser";mipFilterAlpha:r=40;mipFilterStretch:r=2 // 使用 Kaiser 滤波器的 mipmap 压缩(锐化);具有两个参数
addrU:t="wrap";addrV:t="wrap" // 定义纹理平铺行为,Wrap = 重复纹理。
hqMip:i=0;mqMip:i=1;lqMip:i=2 // 根据图形质量定义显示的 MIP 级别;
// hq (高质量) 使用原始纹理,
// mq 使用 MIP 级别 1(50% 压缩),LQ 使用 MIP 级别 2(75% 压缩)。
}
}
有许多这样的处理块。下面,我们将研究关键因素。
全局导出参数
export{
package:t="*" // 指定要将资产构建到的包
// (资源包是资产分组的最高级别)
forcePackage:t="*" // 某些包可能会通过硬编码逻辑自动重命名。
// 此参数强制使用特定名称。如果要确保某些资产仅构建到一个位置,请使用此选项。
ddsxTexPackPrefix:t="tanks/" // 在构建资源中指定将存储纹理包的目录(包是包中分组的下一个级别)。
// 在此示例中,坦克的纹理包将内置到 “tanks” 目录中,而不是 general 目录中。
ddsxTexPack:t="*name_src" // 指定纹理包的名称。如果使用 “*name_src”,则名称将从包含纹理的目录中派生。
gameResPack:t="aces.grp" // 指定资源包的名称。如果使用 “*name_src”,则名称将从包含纹理的文件夹中派生。
splitNotSeparate:b=true // 指示不应在基本客户端和完整客户端之间拆分纹理。
// 在基本客户端中,纹理缩小到 512 像素,因此玩家可以下载少量数据并更快地开始游戏。为了保持视觉质量,某些纹理(如坦克或机库的纹理)不会缩小,而是保持正常质量。此标志设置为 true 以防止缩减。默认值为 false,可以省略。
}
这些只是几个例子。让我们深入研究一下主要参数。
关于 Packs 和 Packages
资源的层次结构可以如下所示:
实质上,一个项目可以包含多个包,每个包可以包含多个包。
什么是包?
包 通常用作我们想要分发到玩家环境或从玩家环境中删除的资源的容器。例如,我们可以将特定位置及其资产捆绑到特定事件的包中。 玩家下载它,享受活动一周,活动结束后,该资源包将从他们的资源中删除。
程序包还可用于发布或销售附加组件。他们不需要玩家预先下载 20 GB 的资源,他们可以从最少的设置开始并快速进入游戏。稍后,他们可以购买其他内容并从相关软件包下载必要的数据。
See also
有关更多信息,请参阅 包.
什么是包?
pack 是实际构建资源的包的一个组件。将资源划分为资源包的逻辑非常简单:
加载某个位置时,应获取尽可能少的包数以优化加载时间。
理想情况下,每个包的大小应介于 10 MB 到 100 MB 之间(绝对最大值为 100 MB),以确保高效解包。
通常,我们将相似的资产归为一组;例如,所有 Vehicle 属性都可能放入名为vehicles的包中。碉堡、战壕、掩体和路障等防御结构可以归类为称为fortifications的包。
如果一个包变得太大,我们会将其分解为更小的组。例如,车辆可以进一步分为buses, trucks, 和 cars等包。
本地构建
创建新资源时,需要在游戏中对其进行本地测试。本地客户端和玩家的客户端一样,只理解构建的资源,因此需要在测试之前构建它们。
有三种类型的 builds:
Full Build:构建所有资源。
Partial Pack Build:构建包含所需资源的特定 Pack。当仅修改了少数资产时,使用此方法 - 快速且高效。
Partial Package Build:构建整个 package(一组 Pack)。 尽管这是一个较长的过程,但在某些情况下可能更方便,例如在基于 daNetGame 的游戏中,以这种方式打包资源可能比构建单个包更可取。
本地完整 daBuild
daBuild 是通过dabuild.cmd批处理文件执行的程序。
Important
运行dabuild.cmd将构建所有资源 – 此过程可能需要数小时。如果您只需要构建单个资源进行快速测试,请改用 dabuild_test.bat。
构建和错误
理论上,所有资产都应该没有错误。然而,资产管理最初严重依赖人工检查,导致人为错误并允许问题溜走。随着时间的推移,daBuild 中添加了更多的自动检查,这意味着以前构建没有问题的旧资产现在可能会触发错误。如果在构建包时发生错误,则该包的构建过程将停止,并且不会构建后续资产。错误仅在构建过程中检测到,但它们也会中断构建过程,这使得识别和修复包中所有资产的问题非常耗时。
为了解决这个问题,引入了-keep_building_after_error标志。如果之前的构建导致错误,则可以在 batch file 命令的末尾添加此标志,以允许 daBuild 在记录错误的同时继续构建所有资源。
Note
-keep_building_after_error标志不应用于忽略错误。特定资源的构建过程仍将中断,但它会继续处理包中的下一个资源,而不是在出现第一个错误时停止。收集错误数据后,修复资产并在没有此标志的情况下运行构建,以确保 daBuild 成功完成且没有问题。
本地包构建
Important
使用 daBuild 构建 pack 将编译所有符合指定模式的 pack。
例如,如果你有一个 vehicles 包和一个 vehicles_modern 包,构建 vehicles 将编译这两个包,除非你指定了确切的包扩展名(例如,vehicles.grp 仅针对该包)。
另外,请注意,daBuild 将根据包名称构建包。例如,如果main包中有多个包,并且使用main模式运行构建,它将在main包中构建所有包。**这将构建 main 包中的所有包,而不是main包本身。
发生这种情况是因为最终的包名称始终包含包名称作为前缀。例如,main 包中的vehicles包最终将被命名为 main_vehicles。
要构建一个特定的包,请在任何文本编辑器中打开dabuild_test.bat,你会看到如下一行:
..\..\tools\dagor3_cdk\bin64\dabuild-dev.exe -target:PC ..\application.blk -packs_re:usa_gm -Q
将usa_gm替换为您需要构建的包的名称。包由离资源最近的.folder.blk文件确定,其中包含如下行:
export{
ddsxTexPack:t="gm_lvl_assets.dxp.bin"
gameResPack:t="gm_lvl_assets.grp"
}
gm_lvl_assets 是将构建资源的包名称的一个示例。可能会有所不同 – 请参阅您的具体设置。
Important
请注意,有两种类型的包:
ddsxTexPack: 导出纹理gameResPack: 导出模型
可以将纹理导出到一个包,将模型导出到另一个包。 例如:
```
export{
ddsxTexPack:t="gm_lvl_assets.dxp.bin"
gameResPack:t="locations.grp"
}
```
您需要构建与已修改的资源相对应的 Pack。如果您更改了纹理,请构建纹理包。如果您更改了模型,请构建模型包。如果两者都已更改,则构建两个包。
本地包构建
与 Pack 不同,Package 更全面,指的是可以通过 “toggle” 启用或禁用的自包含资源卷。
例如,在 War Thunder 中:
pkg_main(或简称*):导出所有资源的默认包。pkg_dev: 包含应构建但不分发给玩家的资源。tomoe: 用于在禁止原始形式的国家/地区修改某些符号的软件包。偶尔也会使用事件包。
在基于 daNetGame 的游戏中,每个位置都是自己的包,可以独立分发给玩家。
在 .folder.blk 文件中,包条目如下所示:
export{
package:t="tomoe"
}
在 War Thunder 中,本地包构建并不常见,因为包很少,通常会改为构建包。但是,在基于 daNetGame 的游戏中,这是一个非常有用的功能。此类 build 有两个选项。
选项 1:构建特定软件包
在 daBuild 批处理文件中,写入:
..\..\tools\dagor3_cdk\bin64\dabuild-dev.exe -target:PC ..\application.blk -package:package_name -Q
将package_name替换为您需要构建的包的名称。这将使用验证和检查构建整个包。
Note
Package 构建以特定的 package 为目标,这与 pack 不同,它基于模式工作。除非您尝试构建纹理,否则这通常不是问题。
例如,package_name 和 package_name_hq(用于特写视图的高质量纹理) 是不同的包。使用-package:package_name构建包将仅编译标准纹理,而不会编译高质量纹理。这可能会导致您的更改以低质量的纹理显示,但在近距离查看时会恢复,因为高质量的纹理尚未更新。
为避免这种情况,您应该:
使用一个批处理文件按顺序构建两个包:
-package:package_name -package:package_name_hq
或
创建两个单独的批处理文件:一个用于主资源包(非 HQ 纹理),另一个专门用于 HQ 纹理。
选项 2:构建特定包及其依赖项
在基于 daNetGame 的游戏中,包通常具有交叉引用。当 “common” 包中的某些内容发生更改时,您需要确保在引用它的所有其他包中一切正常。您可以构建 “common” 包及其依赖包,而不是进行完整构建(这非常耗时),这样要快得多。
为此,请在daBuild批处理文件中写入以下内容:
..\..\tools\dagor3_cdk\bin64\dabuild-dev.exe -target:PC ..\application.blk -package_and_deps:package_name -Q
package_and_deps是指包及其依赖项。
在 settings.blk 中切换包
有时,您可能需要启用或禁用程序包来测试特定方案(例如,禁用程序包以验证游戏是否在没有程序包的情况下运行)。这是在 settings.blk 文件中配置的。
See also
有关更多信息,请参阅 settings.blk.
对于所有项目,在修改包列表后,必须重新构建 .vromfs.bin 文件。
在 War Thunder 中,在位于<engine_root>/<project_name>/develop/gameBase/_pc/settings.blk的文件中启用或禁用包:
addons{
folder:t = "content.hq/hq_tex"
folder:t = "content.hq/pkg_cockpits"
folder:t = "content/pkg_china"
folder:t = "content.hq/pkg_china_hq"
folder:t = "content/pkg_dev"
folder:t = "content.hq/pkg_dev_hq"
folder:t = "content/hc_pacific"
folder:t = "content/pkg_user"
folder:t = "content/pkg_local"
folder:t = "content/tomoe"
folder:t = "content.hq/tomoe_hq"
folder:t = "content.hq/uhq_vehicles"
folder:t = "content.hq/uhq_aircraft"
folder:t = "content.hq/uhq_environment"
}
addons_no_check{
folder:t = "content.hq/hq_tex"
folder:t = "content.hq/pkg_cockpits"
folder:t = "content/pkg_china"
folder:t = "content.hq/pkg_china_hq"
folder:t = "content/pkg_dev"
folder:t = "content.hq/pkg_dev_hq"
folder:t = "content/hc_pacific"
folder:t = "content/pkg_user"
folder:t = "content/pkg_local"
folder:t = "content/tomoe"
folder:t = "content.hq/tomoe_hq"
folder:t = "content.hq/uhq_vehicles"
folder:t = "content.hq/uhq_aircraft"
folder:t = "content.hq/uhq_environment"
}
要禁用一个包,只需注释掉两个块中的相关行,然后重建 .vromfs.bin 文件。
请务必注意,此文件仅负责启用或禁用游戏中的包;它不处理包的创建。
由 daBuild 构建的包的要求在packages{}块的application.blk 文件中定义。
See also
有关更多信息,请参阅 application.blk.
特定资产的本地构建
带有-build:<asset>[:<out_file>]参数的daBuild命令允许您在指定文件中构建单个资产。此命令不会更新包,这意味着更新的资源不会添加到任何包中。
Asset Viewer 中的本地资源构建
还可以使用 Asset Viewer 构建资源,这通常可以加快流程,因为通过批处理文件的daBuild有时会出现不可预测的滞后。
See also
有关如何使用 Asset Viewer 进行构建的更多信息,请参阅 Asset Viewer:构建资源.
本地 Vromfs 构建
VROMFS 是 “Virtual Read-Only Memory File System”的缩写。本质上,vromfs 文件是我们游戏的“虚拟配置盘”。 它们包含游戏的所有非硬编码作设置。
在创建资产时,您主要需要在配置资产销毁或微调游戏内车辆的行为时构建 vromfs。在其他情况下,通常不需要构建 vromfs。
请务必记住,默认情况下,vromf 在每个任务开始时通过网络传送,允许每个任务进行不同的设置。如果你想在本地测试某些内容,请确保你的config.blk文件在 debug{} 块中有以下行:offlineBinaries:b=yes。或者,如果网络功能与您无关,您可以使用disableNetwork:b=yes。
为了提高安全性,您可能希望同时包含两者。
构建 Vromfs 的方法
使用
create_vrsroms.batcreate_vrsroms.bat文件位于<engine_root>/<project_name>/develop/gameBase目录中。此方法非常有用,因为它会立即通过引发错误来指示设置是否存在问题。
此外,它还在同一目录中提供本地日志 (
log_vrom) ,这有助于识别和解决任何问题。使用
aces_dev.exe从技术上讲,这个工具不构建 vromfs。但是,如果您在
config.blk的debug{}块中设置了vromfsPriority:b=no,则所有配置文件将直接从develop/gameBase读取,而不是从 vromfs 读取。 这种方法有几个优点:无需在每次更改后等待 vromfs 构建,并且错误以更易读的格式记录。此外,此方法允许您将强大的
trackEnvChanges:b=yes行添加到您的config.blk中,使您能够直接在游戏中调整设置。虽然这并不适用于所有设置,但它对于调整天气或视觉元素特别有用,因为您无需重新启动客户端即可实时查看更改。
根据您的经验选择方法。游戏中的方法可能不太方便,但有时必须确保所有内容的行为与生产中的行为完全相同。
在 Open daEditor 和客户端中本地构建资源和 vromfs
您可以构建资源和 vromfs,而 daEditor 处于打开状态(尽管资源构建可能会导致 daEditor崩溃)。
但是,当客户端打开时,无法构建 resources 和 vromfs。
如果您发现在关闭客户端后资源没有构建,或者它们似乎在构建,但更改没有反映在游戏中,请打开任务管理器并终止任何挥之不去的 aces_dev.exe进程。
本地导出
如果您正在开发通过任务加载的游戏内战车,则可以跳过此部分。
但是,如果要为地图创建对象,则需要将它们放置在地图上并导出关卡以在游戏中测试它们。此过程通过 daEditor 完成。
在以下情况下,需要导出关卡:
您正在使用预制件。预制件仅在关卡重新导出期间包含在游戏中。
您添加了以前不在关卡中的新资产,或者从该位置中删除了某些内容。
对象生成中发生了一些变化,需要更新它们的位置。
如果您只是修改渲染实例或纹理,则无需重新导出关卡 - 这样做只会浪费时间。
放置完所有对象后,保存关卡并按照以下步骤作:
打开 Project 菜单。
选择 Export to Game (PC format)(如果需要)。
在所有后续对话框中单击 OK。
保存关卡二进制文件。
关卡构建完成后,启动游戏并验证对象。