工程目录结构 Project Folder Structure

游戏工程的目录结构不是一个非常显性并且被重视的事情，但对于具备一定规模的项目，不合理的工程目录结构会导致一些问题，比如：

• 场景间耦合，A场景引用了存在B场景的资源
• 迭代速度慢，难以持续集成，资源打包时间变长（须打包大目录下的较大Bundle）
• 整体资源量失控，更新包数据量变大

例子

随便猜的一些目录结构的例子，不代表实际情况

好的				不太好的

一个方案

• 通用资源库，如果一个资源被多个场景引用，该资源应该位于通用资源库中
  • 可以设置一个通用材质库，类似调色板
• 资源素材位置统一，同一组（如Bricks）/ 同一个（Brick001A）资源的相关素材（网格、材制、贴图）放在同一个目录下
  • 按同一组资源进行管理，可以更方便管理有局部共用资源的情况，如某场景的共用贴图和材质，可以在本地目录中共用，不需要放入通用资源库
  • 按同一个资源进行管理，可以以更小的单位分离资源，当变体(Brick001A)与原型(Brick001)有共用素材的时候，仅关联原型的素材
• 公共资源修改流程/权限。明确一个修改是修改地图，还是修改（公共）资源；如果是修改公共资源，需要先确认该资源修改会造成什么影响，被哪些场景使用，是应该修改，还是应该新增一个资源
  • 确须修改某个地图内的公共资源，但又不能修改其它受影响的地图的情况，可以考虑新增资源，如新增某一资源的v2、v3版本
• 场景地图分工程，分版本库，仅关联本地图实际用到的通用资源目录
• 地形资源按照生态进行分类

通用材质库	通用预制库	生态分类

好处

• 美术能够持续集成
• 资源打包时间缩短
• 更新包数据量变小（通常仅需更新该资源本身）
• 整体资源量得到控制
• 场景工程可以独立开发（可以整包某个单独场景）
• 迭代效率提升（更轻量灵活，减少冲突）

更合理的目录结构，优化打包及加载性能
美术成本更可控：内部研发，核对策划需求，资产控制都更可控

风险

如果是在项目中期进行结构变更，可能面临以下风险：

• 需要一段较长时间（1~2个月）的修复期
• 以目录路径为前提的脚本工具等需要更新
• 美术需要时间熟悉适应新的目录结构及相关规范