公司内部希望打包web mobile后，给美术部同学自行修改替换资源看效果，再把资源替换好的目录上传，达到不需要依赖程序来换皮，但是打包后的文件名都不是源文件名，目录也变成4a 5d等等这些文件目录，该怎么弄
第一次听说给打包好后的游戏换皮 而且程序还让美术自己动 
谁想出这么牛逼的办法的，太优秀了 
用url加载美术资源
1赞
传说有的公司不是策划驱动也不是技术驱动而是美术驱动，你们公司不会就是美术驱动的吧
模仿页游，所有图片全部网络加载，就是体验不好
- 不要使用合图（使用也行，复杂点）
- 构建时，读出所有文件对应打包后的文件路径
需求有问题就应该果断干掉需求
准备好对应资源，写个插件，自动替换，你方便他也方便
就算是把工程文件直接丢给美术换皮 美术都要骂娘 除非你的项目资源管理的很好 除了公共素材外其余的都按界面分好文件夹 然后美术一个个界面重新画 而且也别指望和原来的节点结构一样
对于2这一点我也有想过，但是如何去知道构建后目录以及文件的对应形式 有没有相关的api或者思路 用什么文件作为依据 例如有没有文件记录者uuid映射好构建前后的文件目录名之类
1、构建之前记录uuid和图片名字。
2、图片加载时通过记录的uuid找到对应的文件名，再loadRemote
一般打包后的资源文件名是以打包前的文件meta的uuid重命名的，可以以这个为基点写一个映射脚本
当然也有一些其他技术栈的东西拉，就看你们 打包支不支持了：
方案如下：
- 将打包流程使用 自动打包 （如配置 jenkins 等）；
- 配置一个美术独有的 svn，目录和项目目录一致；
- 美术上传资源触发打包机制，进行打包；
- 程序需要替换资源时，只需要拷贝对应目录的资源，即可。
即： 资源时动态替换的。
这个需求也是6，上面的方案，看起来虽然可行。但是实际效果感觉会差强人意。现在的流程不都是，程序开发完，发布测试，然后美术，产品，策划过一遍，需要返工，再给技术改就行了。这个流程流畅起来也是快的。何苦在最终效果上面动刀呢。
大家都在各显神通
瀑布式开发有个不好的地方就是阻塞 程序不开发完 美术无法查看效果 又或者说 程序开发完成一部分后 可以让美术开始替换资源查看效果 然后程序继续后续的开发 此时美术因为要等程序完全开发完成才能执行下一步 导致阻塞 时间就会拉长。
因此敏捷开发油然而生，就是各部门尽可能把能让别的部门先动起来的部分先开发完，这样就可以各部门协同工作，达到各自不阻塞，而不是一个接着一个
这个跟多线程和多进程的原理有点类似，如果某个模块不依赖于别人可以独立于世，比如美术只是单纯的替换优化资源，是不需要老是找程序去替换资源，导致打扰程序工作，而是自己能够自行替换发布看效果，而程序的功能也有不依赖美术的部分，同理各个岗位都有自己解耦的模块，可以自身形成提速的工作流程
一个系统功能往往不需要所有部分都各自等待前者交付，而是可以提前动工，通过阶段性验收后，最后总体验收就会快 减少封版压力
可是引擎的其中一个作用就是大家协同开发啊 无论是多个程序开发不同模块 还是策划配置关卡测试数据 还是美术拼界面（请忽略） 同个团队拉项目到本地自己看效果难道不行吗 我不光配表整理过资源还看程序代码呢
这个涉及公司制度的问题，但凡有点规模的团队，业务有比较好的盈利空间，都要会有防止泄密这一说法，也就是任意团队成员能拿到整个项目的资料，比如美术部是无法查看技术部代码，技术部不能完全查看美术部的原工程文件，策划的工具和文档也会有相应加密，如果团队规模小，是可以。
但是，解耦这个工作本身一定是对流程有好处，因为它不再需要耦合更多别人的时间来完成自己的工作，达到工作并发的一个状态，也会是当前各个公司追求游戏工业化不可或缺的一部分
工欲善其事必先利其器，有好的流程模式能够让职责分工细致更清楚，当然也会让人更趋向于螺丝钉，这就是对公司和人都是一把双刃剑
已经实现了 具体看https://forum.cocos.org/t/topic/158273/4