说说游戏制作的build系统

如今的大牌游戏都是动则10G、20G的，build系统已经成了一个创新的新领域。暴雪在GDC2013上就讲了他们自主研发的分布式build系统。

游戏的build不只要build程序代码，还包括各种美工资源的预处理，比如资源提取、校验、格式转换、组合等。而且这些资源普遍比较大，比如一个纹理图片的原始图片文件就可能有10M，模型的原始文件比如fbx或collada。Build系统会根据需要从原始资源提炼出不同分辨率的版本，以适应不同性能的客户端，而且各个分辨率级别的定位，也会随着市场的变化而需要调整。

当然，其实这里所说的build系统已经超出了狭义build的范畴，自动化测试、打包和监控面板等都在其内，也就是常说的CI（持续集成）系统。习惯上仍然叫build系统一是因为历史比CI这个词悠久，二是因为build部分是重中之重。

不同于源码的build，一个游戏项目的总原始资源量可能要上百G，而且有不少XML等适合中间处理的格式，加上复杂的算法，比如mesh简化、光照预计算、生成用于physics的model等，整个build一次所需的时间可想而知。所以，build过程通常需要集群来跑。嘛，三台破机器也可以算个小集群啦。

说起集群，性价比高的无非就是linux集群了。Windows集群成本太高，除非用D版，而且性能确实比linux差。但事实上也很难完全避免Windows，毕竟它是一个主要的目标发布平台，不少工具是必须在Windows的节点上跑的。

既然在说集群，这个build工具就已经排除普通的build工具了，而必须是分布式build了。不过呢，这个我也不熟，有兴趣的自己研究，可以去看暴雪在GDC2013的Slides。我要说的，是更傻瓜一点的，直接用脚本写，尤其是集群很小时。比较常见的是用Python。一是因为整个build中有不少小工具就是Python写的，用同一个语言可以减少学习量和集成难度。二是Python的工具包很全面，什么都能干，做个监控build状态的web service都行。三是Python跨平台，linux、Windows、Mac上都一样跑。当然，通常也未必是象BAT脚本那样直接写命令序列，毕竟还是需要文件最近更新时间检查、拓扑排序等build优化功能的。这个有别人用脚本写好的Framework，其实自己写一个也不难，没多少行代码。有个框架的好处是，把build逻辑和build机制分离，当需要优化时，可以通过修改框架来演化成自动负载平衡的分布式build系统。

当然，大杂烩集成也是条不错的路，可以充分利用已有CI工具，比如Jenkins什么的，不过有小钱钱的话弄个TeamCity啥的要舒服很多。