其实之前就好奇其他一些项目是怎么管理美术和策划文档,今天看到游戏项目中美术资源，策划文档等这些非代码文件需要加入到版本控制中去吗？ - 知乎,决定把自己看到和听到一些组织方式总结下。

整个包结构

• 项目名称
  • 策划文档
  • 美术原始素材
  • 客户端（包含导入项目的资源资源）
  • 服务器代码
  • 其他文件

    针对多版本

    • 项目版本名称
  • 策划文档
  • 项目名称
    • 客户端
      • 不同版本的美术资源和配表
      • 不同版本的文字配表内容
  • 服务器代码
  • 其他文件

优点：只要本地选择不同渠道的美术资源和表，将复制到使用资源的目录下，就切到别的版本

缺点：在于启动客户端编译美术资源很多，客户端整个文件也很大；在引入多语言版本的，要重新调整。

客户端资源和代码分离

• 项目版本名称
  • 策划文档
  • 项目名称
    • 客户端A（处理资源）
    • 客户端B（代码和少量美术资源）
      • 表格配置
• 服务器代码…..
• 其他文件

当需要一个新的渠道和版本，只要客户端A里美术资源修改和客户端B里配置表修改

优势是：当美术客户端操作的时候，不会因为程序代码提交问题，而无法工作。保证插件和工具ok。美术和策划SVN的控制权限不同了

缺点是：需要有个客户端A资源打包的过程，然后在客户端B中使用；还有最好有专门有人负责打包的工作。

附 这个方法思路来源Unity3D研究院之两个游戏工程资源同步问题

组合方式

• 策划文档
• 项目
  • 客户端
    • 底层框架
    • 插件Dll
    • UI代码
    • 美术资源
    • 配置表格
  • 服务器代码

优点是：插件或者框架更新，不影响其他程序的工作了。只要有对应版本代码和美术资源以及配置表就新的版本包

缺点是：分散了，引入Dll。当底层框架出现BUG的时候，需要有人修改。

来自《游戏引擎架构》方法，非U3D情况

• 书的作者参与比较大的项目，资源很多,对于资源是从对应的地方下载需要的美术资源。这就涉及到GUID。

总结

除了第一种方法和来自书中的方法，其他方法都默认在其他分支上传美术原资源了。每个方法都其适用范围，作为参考思路分享。