山寨Besiege（二）瞎扯下项目管理

上回说要用Github维护项目，试了下上传速度为5-10k/s，用买的则是50k/s，虽然传200M的东西也不是不可能，但终感太麻烦，于是放弃了这个念头。

也许能畅快地是一个高级码农必备技能，但现在这个逼我还是不装了。

同时在本地使用版本管理系统的必要性也还不是那么强烈，我想等有需要的时候弄一个也不是什么难事，这次就打打嘴炮算了。

关于版本管理：

我倾向于用Git。虽然SVN更简单，但我的理念是新的工具总是比老的要先进些的，花费一些学习成本绝对值得。至于说Git命令行如何难用，其实TortoiseGit和TortoiseSVN界面一样一样的。

SVN有个问题，就是一旦Update后出现问题，不能马上回退到之前的状态，只能尝试Update到各历史版本，慢慢排查问题。总会有那么一些时候，你在做一个功能，中途突然策划甲跑来，说你更新下让我看看某某效果，这时假如程序乙上传了引起错误的代码，你们就都被卡住了。而Git由于可以本地版本管理，一旦发现问题，你就可以对甲说回去歇着吧，等乙解决问题了再来看，然后瞬间回到Update前的状态继续你自己的工作。这无疑更高效。

再贴点版本管理的技术细节干货：

unity文件解析以及版本控制

上文参考的第一篇老外写的一系列文章非常不错，额外贴下：

Mastering Unity Project Folder Structure

关于Unity项目管理：

我倾向于策划、程序、美术共用同一个项目，而不是分开。

我们现在的项目是分开的，导致严重的弊端。测试异常麻烦，策划做各种配置工作时，必须让程序Build一个最新版本，而且由于没有调试环境，遇到问题也是没办法只能求助于程序，而美术做出各种动作、特效后，也是没法及时看到游戏中的实际效果，只能让程序更新资源、反馈、再修改。其他诸如资源导入之类的麻烦不一一细说。

原本出于安全性的考虑，导致生产效率急剧下降，我觉得是不值的。游戏这玩意本来也没什么技术壁垒，自己的框架都不知道哪里抄来的，项目能不能顺利上线，上线后能不能赚到钱，都有很大的未知性，何苦天天藏着掖着怕别人偷呢。而且这种做法暗示团队成员之间无信任可言，对士气的打击也是极大。

至于说怕美术、策划不懂Unity，乱传资源把工程搞乱，我想也是可以通过不断沟通磨合想出各种办法解决问题的，这点不能称其为理由。不懂就学，学会为止，一直学不会的，我想不太适合做游戏开发。不管做什么工作，基本的学习能力、沟通表达能力，都是该有一定要求。