The world at your fingertips — 天涯明月刀幕後（9）工具

腳本

趁著小方重做整個動畫系統，策劃黃教授也蠢蠢欲動。

在mmo遊戲中，戰鬥系統的邏輯描述是一個工作量的重頭。大量的Buff、動畫、特效信息，按照時間軸排列，分別被配置和整合，將美術、程序、策劃的想法融合到一起。

舊版本的戰鬥邏輯內嵌在xml裡面，戰鬥的各種基本功能是程序根據策劃需求開發的，策劃通過XML配置，將各種功能整合形成各種人物的技能。

技術策劃黃教授是一個掌控欲極強的男人，為了獲得更強的能力來征服世界，他想要更好的武器，他需要腳本。腳本作為膠水語言，很適合用作整合各種功能，有一定的靈活性，也不至於增加太多的複雜性。我們的第一想法是整合一個Lua之類的語言就好了，但是黃教授不要。他表示Lua顯示不出他的能耐，人人都會的東西，不容易有壁壘，對他今後在項目中的地位會有影響。

所以黃教授又像當年設計動作框架、重構戰鬥體系一樣，說我們自己做一個極簡的腳本吧。全部語法從簡，只有簡單的表達式和跳轉，配合各種方便策劃的shortcuts，能少打字就少打字。編譯模塊內置，直接做到數據文件轉換過程中，腳本可以熱更新，不用調試和debug，反正沒打算給別人用。

雖然這個需求有點荒謬，但想想能做個初步的腳本編譯模塊還是很有趣的。這時候引擎團隊加上邏輯團隊也有十個多人了，我的工作也逐漸從每天想怎麼搞定編程的任務，變成了如何把這些兄弟們的工作排滿。更多的間接層次，帶來了更多的腦力負擔，其實並不好玩，但項目要做大做強，別無他法。

這個任務規模不大，做起來不費事，勝固然可喜，敗也可以無憂，大不了讓黃教授還用老方法工作，這個正是求之不得的理想任務。想著想著，我就順手把這事情記到了pending task pool裡面。

過了兩天，項目事情稍空一點，轉念一想，這麼有趣的事情，而且整體規模不大，怎麼能交給別人做呢，當然要自己來搞啦。搞砸了就搞砸了，Leader是最適合做這種不在關鍵路徑上的任務的。

說干就干。大學畢業多年，編譯原理早忘光了，但想想黃教授要的並不複雜，直接用狀態機搞語法分析吧。先上去寫代碼，發現不太對，搞不出來。老老實實拿了一張紙，畫狀態關係跳轉，思考結構該如何組織。

因為這個語法比較簡單，一會就畫出來了，按狀態機編程，很快搞定了。周末回去想想，有點意思，翻了一下編譯原理的材料，其實自己瞎湊做了一個DFA。原來大學裡面學的編譯原理沒有那麼複雜，雖然當時也沒認真學習，事後自己也可以推導的。

後續就是讓所有模塊都數據驅動，把詞法分析需要用到的語法描述放到XML文件中，然後把輸出的結果也放到XML中，就順利完成了詞法分析、語法檢查等功能，且和原來的對象序列化直接結合，完美。

輸出方面偷了一個懶，並沒有編譯成位元組碼，直接寫小解釋器運行這些邏輯吧，先應付了燃眉之急，其他都可以日後再說。我鄭重的把輸出位元組碼並執行這件事寫到了To Do List，總有一天我會做的，我恨恨的想。不見天日的任務很快會被遺忘，特別是後續的維護工作轉給其他同學之後，不出意外，這個工作就逐漸被淡忘了。

再後面的事情就變得無聊起來，我需要工程化的解決所有問題，確保各種情況下策劃都能使用這個工具。所有的事情都是開始有趣，收尾無聊，好比開學的時候都是躊躇滿志，期末考試的時候如喪考妣。

策劃喜歡用Excel來編輯數據，遊戲引擎自然不會讀Excel格式，而是讀XML數據和Binary數據。於是我們要做XML和Excel數據互相轉換，開始研究office的自動化編程。兩種數據格式的語法描述能力不同，所以要有各種工程角度的取捨和權衡，並配合策劃工作流程做細緻的設計，再考慮多人協作的工作流，還要做一些雙向的轉換同步。便於開發的輔助功能也不能忘記，時不時策劃還要在Excel裡面做點注釋，這個信息也不能在轉換XML後丟失，雖然遊戲引擎並不需要這些數據，但工具流程必須考慮。

黃教授真是磨人的小妖精，天天有需求，日日纏著我。我找了個借口，趕緊把做了八成的功能轉給其他同學維護，從此斷了和他的羈絆，相忘於江湖。

布料

天刀早期的版本，布料得到了玩家的一致肯定，玩家身上的衣服，隨著戰鬥、輕功等動畫，會自然飄動，一方面會更自然，另一方面也降低了3D動畫的工作量，相關動作製作的時候就不需要考慮服裝飄動了。這裡用了Nvidia的Apex Clothing技術，是一個比較完善的解決方案了。

但是開發布料全過程並不如此順利。

優先擺在我們面前的困難，是Apex Clothing並不成熟，也在開發中。雖然Apex Clothing已經有不錯的demo展出，但開放的API版本還是不夠完善，經常需要NVidia的深度支持才可以搞定。還好我們和Nvidia的關係一直不錯，雙方也有好的合作意願，希望能把這個技術更好的應用在遊戲中，所以推進還是比較順利。

對於中間件等技術，一直有的一個問題就是先有雞還是先有蛋。項目會表示，我們很願意用前沿技術啊，等你們的版本穩定了，我們一定用，先讓隔壁家的項目試試水吧。技術開發團隊會忽悠，說你們現在不用就來不及啦，隔壁誰誰誰馬上就有某某某遊戲要用上了，少壯不努力老大徒傷悲，過去不投入，將來必是悔之晚矣。這樣的一般將來過去完成時，往往特別有說服力，讓項目心馳神往，目眩神迷，一衝動就用上了新的技術。

在考慮引入新鮮技術的時候，一定要考察合作廠商意願，有沒有可能深度合作，開放源碼的中間件是最好的，真出了問題也能自己定位問題，如果是封閉源碼的組件，就必須有很好的合作關係，才有可能順利應用。產品的環境比demo複雜一萬倍，再好的組件，沒有經過2-3個產品的實際應用，終究還是溫室的花朵，經不起風吹雨淋。

其次的問題是引擎整合。目前Nvidia已經在Unreal等大型引擎中，整合了Clothing組件，但當時是沒有的，而且我們是自研引擎，也只能自己來整合整套SDK了。從團隊裡面捉了一個做過PhysX相關工作的同學，就開始做Clothing。整個引擎框架當時還不夠成熟，物理沒有，渲染模塊也女大十八變，一天一個樣，在浮沙築高台，難度可想而知。負責的程序同學天天被抽，日日被逼，終於奮起反抗，提了離職，成為天刀客戶端的離職第一人。好在走之前，總算把布料大致放了進去，雖然性能不理想，結構非常亂，但勉強能work了。

最後我們發現，怎麼和想像的不一樣，布料整合在系統裡面了，但還是沒有辦法調試出好的效果。於是又把問題定位到技術美術。技術美術是一個神奇的工種，擁有跨界的知識，站在美術食物鏈的頂端，藐視眾生。在布料系統的開發中，技術美術的作用不容小視，和Nvidia多次深入溝通，研究如何調試出好的參數，中間來回迭代多輪，這才在最終拿出了大家都滿意的效果。

越到後期，團隊的協同增效越明顯。已經不怎麼存在依靠單一團隊就可以搞定的技術，那些容易搞定的，早已被搞定。剩下的，基本都是需要多團隊協同，加上跨界人才從中協調，才有可能開發出來的特性。為了開發最後20%的特性，可能需要80%的人力，二八法則怎麼都成立。最艱難的是，在走通所有流程前，這個工作怎麼看都是遙不可及的，需要一點運氣和堅持。回想天刀開發過程中被砍掉的不少features，對比布料系統，非常感慨。布料系統也一直徘徊在要不要砍掉的邊緣，對那些不幸的特性，是不是當時我們再堅持一下，結果就會有所不同呢？

Editor

早期的天刀用了原先MMO的地圖編輯器，因為場景比較小，問題也不大。

但那個地圖編輯器架構並不合理，渲染模塊和主體引擎的渲染不一致，導致後續開發渲染效果，很可能要編輯器做一份，引擎做一份，浪費了工作量。另外之前的工具集也過於零散，大量功能散落在不同的工具中，如果這些工具之間沒有足夠好的規劃，共享模塊，也會帶來渲染模塊一樣的問題，即代碼模塊的重複開發。

顯然，這是一個歷史遺留的問題，大量的工具集來自於不同時期的不同項目，每一個項目並沒有太多的時間來整合，就忙著繼續開發新的遊戲內容。工具碎片化帶來了維護的高成本和重複開發，也帶來了使用體驗上的割裂。

往另一個極端看，UE、Unity為代表的大、中型引擎，喜歡所謂的All-in-One式樣的引擎，重型引擎，什麼功能都有，使用體驗順暢，追求一站式解決問題。重複開發問題是沒有了，但並不能完全解決開發效率問題。越大的引擎，編譯鏈接時間也越長，開發一個功能涉及的模塊也越多，也可能造成程序員過多的腦力負擔。

其實還是一個度的問題，如何在兩個極端中找平衡，是一個沒有標準答案的問題。

具體到天刀當時的情況，雖然舊版本工具集也勉強能用，但可預見的將來，維護成本必然會越來越高，並不符合開發團隊的長期利益。但我們也沒有技術宅的架構強迫症，一切要為工程服務，適當的妥協是可以考慮的。我們決定先整合所有地圖編輯器模塊，做個新的編輯器。模型導入導出模塊，需要考慮給外包公司用，還是獨立開發，以免暴露太多內部工具。當然，兩個系統必須要共享一樣的渲染和底層模塊。

事實上，是不是要從頭做引擎，做決定之初是非常猶豫的，最重要的原因就是考慮到編輯器開發的巨大工作量，可能會拖慢整個項目的進展。但架不住怨念的日積月累，今天有人抱怨一下舊引擎的不堪，明天有人在舊框架下抽掉一塊磚，漸漸的，我們就發現與其天天活在哀怨里，不如奮起反擊，推翻這不合理的技術架構。

我們就這麼開始了編輯器的開發，小李天天加班到死，Tough哥努力貢獻著渲染功能，時不時抽空幫忙做點編輯器模塊，包哥搞資源瀏覽器模塊，我抽空把底層對象架構整理一下，順便做點對編輯器友好的導入導出、copy/paste功能、多對象屬性編輯之類的工作，也維護了一些通用的控制項。

在多年的開發中，編輯器開發始終承擔了極其繁重的任務，所有的新特性，都往往和編輯器有所關聯。開發人員做出新的功能，經過技術美術或者技術策劃的初步驗證，通過了，就需要編輯器提供量產的工具支持。沒有什麼一蹴而就的成功，一切龐然大物的誕生，都來自點點滴滴的進步。在美術的焦急催促中，在策劃的翹首以盼中，在程序的眾志成城中，編輯器慢慢成型，逐漸把以往繁複冗餘的工具集替換。然而，只有遊戲開發不結束，編輯器永遠不會有被完成的那一天，就像建築工地的腳手架，編輯器始終伴隨著產品的成長。

岔開說幾句，在國外的遊戲行業，工具程序員受到非常大的認可，而在國內，工具程序員並不被重視。我想原因還是在於國內遊戲行業並不足夠成熟，大量項目的開發流程和技術還停留在簡單的初步競爭（不包括商業化，這個國內是最強的）。在這樣一個環境中，功能的有沒有，重要性遠遠大於質量好不好以及效率高不高。而在國外遊戲行業，已經進入了比較成熟的階段，競爭也比較激烈，對遊戲產品本身提出了更高的要求。工具是促進多人協作的最重要的因素之一，大型團隊如果沒有好的工具，根本無法支撐巨型遊戲的開發。在這樣的競爭下，能不能提高團隊的效率，往往是一個重要的考慮因素，所以工具開發就被提到了相當的高度。