关卡格式

关卡文件夹里有什么，哪些文件随关卡一起走，哪些留在设备上，以及其中的JSON如何组织

关卡文件夹

关卡就是一个文件夹。其中每个文件名都固定在FileNames中：

扩展名就是格式。文件内部不记录它。读取方检查存在的是哪个文件：level.json还是level.blob

关卡和元数据各自独立选择格式。例如内置关卡new-zero-demo在metadata.json旁边存放的是level.blob

metadata.json是有意单独存放的。目录列出一千个关卡时，只读取一千个小的元数据文件，一个关卡都不用打开

资源

资源由uri和uri_type（ResourceUriType）定位：

围绕一首歌创建关卡时得到的就是AbsolutePath。导出归档包时会把这类文件复制进去。更多：归档包与保护

封面和其他资源一样，通过LevelMeta.LevelLogo引用。是logo.png还是logo.jpg由文件本身的字节决定，而不是源图片的名称

不随关卡走的内容

这些文件位于levels文件夹旁边，从不在关卡文件夹内。打包、分享或删除关卡都不会动它们：

JSON键

JSON总是紧凑写入，没有缩进。想用眼睛读，请在文本编辑器里格式化

键的长度取决于它在关卡中出现的频率：

• 每个文件只出现一次的键用完整的snake_case：level_id、min_generation
• 重复成千上万次的键缩写成几个字母：objs、f、e、v

键占关卡文件字节数的52%，所以这是规则，而不是个人口味。所有键都声明在Names.cs中

多态值写作[tag, payload]。普通字符串是[0,{"v":"Author"}]，本地化字符串是[1,{"strs":[...]}]

ObjectId这类ID包装类型写成裸数字或字符串

标识符

整数ID的符号有含义。0始终表示未设置：

pid为0表示物体没有父级。小于-3的数字只在游戏运行时存在，从不出现在文件中

Marker、Checkpoint和BeatSegment没有ID。它们按时间位置定位：标记和检查点按帧f，节拍段按其时段sp的起始帧（节拍段从不重叠）。移动其中一个，它的地址就会改变

预制件覆盖用编号而不是JSON键来指明字段。一次放置把自己的覆盖保存在列表mod中。每个覆盖的key包含三个数字：

• id：模板内的物体，而不是它在关卡中的副本
• f：字段的固定编号
• i：列表字段中的元素，-1表示整个字段

编号永久属于该字段。重命名字段的JSON键不会破坏已保存在关卡中的覆盖

外层的“g”

每个序列化根都包在一个带两个键的封套里：

{"g":1,"v":{"level_id":"18df5f61-3aa4-4812-bf69-d357f2201bc3","vrs":"1.0", ... }}

g是模型的代（Names.Generation），v是载荷

封套可以嵌套。在Level内部，LevelSettings、GameLevel、AudioLevel、LevelResources和LevelHints各有自己的封套。代的工作方式：版本与迁移