說說遊戲製作的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啥的要舒服很多。