这个工具，或在这个工具之下建立一个层次，制作成 C/S 结构，并直接集成版本管理工具的功能。即，Server 负责收集美术提交的原始资源。最好能直接让美术提交 max 文件，由工具去收集相关的贴图，然后置入数据库。Server 按照 engine 需要，转换制作成 engine 能用的格式。如果要服务于多个 engine 也没有问题。
美术开发人员，通过 tag 去标识他们上传的资源。比如可以自动把作者 id 作为 tag 打上。这些 tag 仅供事后检索使用。Server 同时也负责合并相同共用的贴图等。最终为每个独立资源生成唯一的 uuid 。我想说，这套东西可能很接近 Alien Brain ，但我需要的是和 Engine 其它部分集成的更好的 Alien Brain 。
其它工具在使用资源的时候，一律引用 uuid 。当然，在工具使用过程中，使用者检索资源的时候，是通过 tag 。但底层引用则使用 uuid 。在资源管理的层次的 Client ，除了负责上传资源原始文件外，也负责建立本地 cache ，提交检索请求。甚至提供浏览。一切工具需要加载资源，都通过 IPC 协议去获取数据。也可以退一步，由这个 Client 同步到新版的资源文件，并返回 cache 中的文件名。
当然，最终的游戏也可以通过相同的资源获取协议达到及时网络加载的特性；同样也可以不用这个特性，从由资源管理器最终打包好的资源包中读取。
这个系统设计成和 Engine 以及其它工具尽量功能正交化。适合独立开发维护。本文只是一个思路，设计方案还需要斟酌。
嗯，总结一下需求要点：
美术资源和程序代码不一样。不是每个人都需要一份完整的数据仓库的最新版镜像。需求只在他所维护的一部分素材以及当前项目需要的一部分。而整个美术素材仓库往往很大，没必要同步同步下来。这是和 svn 这样的版本管理工具处理的问题不同的。
美术资源原始素材和最终运行环境用到的数据不同，好比源代码和目标文件。协同开发时，程序员需要其它程序员的源代码帮助编译调错。但美术人员几乎不会用到其它人员的原始文件。因为场景中的一颗树和一张桌子中间没有什么会相互影响的东西。
美术资源大多交叉关联，并非树状结构。一个模型很可能由许多文件构成，但开发人员往往只关心顶层的个体。且在使用这些个体的时候，对它是什么更关心，对它在文件系统的那个位置不太关心。tag 会是对人更友好的检索方法。
开发工具多为自行开发，或有二次开发需求，以适合自己的游戏项目。集成少量资源管理接口难度不大。