创作者方针与发布规范

这一页整理自《包教程》的“基岩版创作者方针”章节，并结合当前版本实践做了现代化改写。目标很简单：让你的包更稳定、更容易维护，也更不容易在版本更新后突然失效。

先做“减法”：目录与路径

发布前先清理包目录，只保留会被游戏实际读取的文件。

• 不要把工程源文件直接打进包（例如PSD、工程备份、二次压缩包、临时导出文件）。
• 不要把“包里再套一个包”的目录结构带进发布包。
• 删除未使用资源，避免验证成本和兼容风险上升。

路径长度建议保持保守：

• 从包根目录到文件的完整路径尽量控制在70字符以内；
• 单个路径片段（文件夹名或文件名）尽量小于60字符；
• 资源包或行为包根目录名尽量短（建议10字符以内）。

为什么要这么严格

不同平台的文件系统限制并不一致。路径越短，跨平台导入失败和资源缺失的概率越低。

定义文件尽量“最小改动”

对于blocks.json、sound_definitions.json等定义文件，推荐只保留你要改的字段，不要整段复制原版再改几行。

这样做有两个好处：

1. 游戏版本更新时，原版其余字段的变化不会被你旧副本“锁死”；
2. 你的包更轻，冲突更少，定位问题更快。

原文还列出了一批不建议改写的高风险文件，例如font/emoticons.json、items_client.json、items_offsets_client.json和shaders目录内容。即使在当前版本中部分文件可覆盖，也建议把它们视为高风险改动点，除非你已经做过充分的跨版本测试。

函数与命令：先保证可维护，再追求复杂

函数部分建议长期坚持这几条：

• 所有函数放在命名空间子目录下，避免包栈冲突；
• 文件与目录使用小写命名，不留空格；
• 递归调用要节制，避免深递归造成性能尖峰；
• min_engine_version按实际目标版本填写，不要盲目写旧值。

命令部分建议：

• 避免把大量命令放进每刻循环；
• 大区域/fill、/clone这类重命令尽量拆分到多刻执行；
• 选择器条件不要依赖会被本地化影响的显示文本。

关于旧文档中的“每刻30条命令”

这是旧保守经验值，不是现代版本的硬限制。请以你的目标设备实测结果为准，用内容日志和帧时间表现来调参。

客户端资源：稳定优先

• 模型微小部件过多会明显增加低端设备负担，细节与性能要平衡。
• 长音频（如背景音乐）更适合流式加载；短音频（如音效）更适合常驻内存。
• 音频先裁掉头尾静音，减少无效体积。
• UI修改建议从“贴图替换”开始，再逐步进入布局和控件结构改动；直接改动复杂界面的控件树风险最高。

世界机制：控制复杂度

• 避免同刻生成过多实体。
• 红石系统尽量不要把关键交互压在区块边界上。
• 常加载区域只保留必要部分，不用时及时卸载。

这些做法都指向同一件事：降低更新冲击和设备差异带来的不确定性。

发布前快速检查表

• 目录中无工程垃圾文件、无嵌套包。
• 路径命名简短、统一、全小写。
• 定义文件仅包含必要改动。
• 函数按命名空间分层，关键逻辑可读。
• 高频命令已做频率控制或分帧执行。
• UI和渲染相关改动已做跨版本回归测试。
• 常加载区域、实体密度、红石结构已完成性能验证。

做到这些之后，再进入打包与分发，返工成本会低很多。