The world at your fingertips - 天涯明月刀幕後8（重啟）

前言

離上次更新已經半年了。先是有個人工作方向調整，比較忙，想歇一陣子，當時並沒沒想過會要停更；歇著歇著，就沒了力氣，夜更長，事更多，人更喪，再不想更新。人世間的意外和驚喜，莫過於此。好在我迷途知返，熵增不由人，但總有當下，可以把握。

拖著不更新還有很大的一個原因，就是從這一篇開始，會寫到更多的技術內容，這些東西不容易寫得輕鬆有趣，這也是我遲遲無法落筆的重要原因。整個系列的方向，可能會從惡搞敘事，轉向技術流水賬，時間線也記不清了，可能有錯亂現象。不糾結了，後面幾篇，會更偏向程序員一些，聊一些技術上的判斷和我們做過的取捨。

上回說到難得的一段修整時間，調整方向，招聘、重構等等。這篇會涉及到更多技術相關內容。

這次我們打算做一個完整一點的Demo，有稍大的場景，也要探索一下後續遊戲發展的方向，無論是技術上，還是產品層面。

我們打算在半年不到的時間裡面，做一個單人副本，有一個小規模的場景，有很多敵人，有數個boss，有兩個角色，不同的技能。 相當於大規模Production之前的最後準備，完善內容生產線，增加新的特性，找到合適的需求。

對於更完善的生產線，有很多因素需要考慮，無外乎就是特性開發效率，內容製作效率，多團隊協作效率，質量和品質控制等。

更快

要想富先修路，古老的道理指導著我們前進的方向。要想碼得快，編譯不能慢。程序團隊在大規模開工前，先做了一件提升效率的事情：團購了一批SSD硬碟。

國內公司的理念，和國外公司非常不同。也許國外人力成本貴，也許國外競爭更激烈，也許國外電腦成本更低，我所見的幾個遊戲公司，都用著非常高端的電腦。比如在2000年進入UBI的時候，先領了一台PIII 700的電腦，512M內存，20』高端顯示器，Voodoo 2 SLI的顯卡。而我們當時的主流機器，也只是PII 400的水準，內存128M，17寸顯示器。公司的工作電腦遠超當時主流機器，這讓我的工作和下班後的娛樂變成一種享受。

但換了公司以後，領完電腦大吃一驚，居然比自己家的電腦配置還要低，無法想像。大家對這一現象有很多解釋，典型的解釋就是用低配置電腦，就更接近用戶電腦，程序員就容易注意到性能問題，保證開發出用戶體驗良好的程序。但這個對於遊戲開發，其實是說不過去的。遊戲開發有更多的工具，動不動就要用滿內存跑編輯器和遊戲，說不定還要多開，美術人員開個3DSMAX或者Photoshop又是大量的內存佔用。性能總是不夠用的，低配電腦浪費生產力，大把的時間都用在了等待編譯和工具啟動上。至於說配發低端電腦以便貼近用戶電腦，確保性能不出問題，也只是自欺欺人，完全可以對有優化工作需求的同事，單獨配發低端電腦，供他們調試使用。

於是公司在制度上打了一個補丁，表示低配電腦是辦公用機，提供了額外的渠道，可以申請高配電腦。高配電腦性能高了不少，但還是消費級PC中還過得去的配置，算不上發燒級的電腦。

我們無奈的接受了公司的規則，但日常工作中，低配置電腦對編譯、工具等帶來的影響也是切實存在的。

在這個裡程碑開始前，項目的規模已經慢慢變大了，第三方組件、工具集、sdk等源代碼和開發庫，拖家帶口，住到了我們產品的Perforce，編譯時間也慢慢增加，提高開發效率成為刻不容緩的事。

天刀開發的早期，tough哥滿懷革命理想，表示做技術決策什麼的最方便了，如果有兩個不同的選擇，我們吃不準，那就都做出來比較一下嘛。

早期的確有不少技術是這樣做的，tough哥是工作狂人，他的生活中只有上班和睡覺，老婆和孩子應該都是充話費送的。大量特性是可以依靠拚死加班搞出來的，tough哥是一個永不疲倦的發動機，大喊著Charge，沖向無盡的Bug大軍。當時項目規模小，迭代速度也非常快，客觀上也助長了tough哥的霸氣。

但做了一年半後，代碼規模也在慢慢擴大，大家也不知不覺遠離了大躍進的口號。開發效率逐漸降低成為一個頭痛的問題。項目規模變大了以後，每次開發新特性，如何和舊有特性和平相處，成了一個新的課題，反覆的迭代，編譯需要的時間，也無法被忽略。

工作狀況還是不容樂觀的，沒有額外精力去優化底層邏輯。因為要逐漸向量產轉型，所以更多的資源都會被投入到開發特性上，沒有辦法做細緻的提升。

SSD硬碟在那時候進入了大家的視線，據說可以極大降低尋道時間，進而影響編譯、程序啟動等方方面面，讓電腦煥然一新。有感於內部流程繁瑣，大家就自費團購了一堆SSD，我的項目我作主。當時SSD相當昂貴，64G就要1k左右，但提速效果極其顯著，完整編譯在傳統HDD上需要38分鐘，SSD編譯只需要12分鐘。Link時間和軟體啟動時間都有非常大的提升。換上電腦，生產力確實有了巨大的提高，心情也更好了。

更強

搞完硬體，開始抓軟體，兩手都要硬。這裡聊聊動畫和技術決策的問題。

在前兩次的版本中，小方一直在樸素的動畫系統上工作，管理起來各種不便，也缺乏足夠的靈活度，一切動畫邏輯都需要程序來寫。而且早期的核心戰鬥迭代多，變化快，每次規劃新版本，就是小方重寫戰鬥框架的開始。這次他又面臨進一步推翻的可能性，實在是吃不消了。

我們就開始討論，有沒有比較好的動畫解決方案。

在第六篇中我們聊過天刀引擎的一些原則，其中一條是能用中間件，絕不自己寫。具體到動畫系統上來說，非不為也，實不能也，大家對怎麼做一個高端的動畫系統並沒有太多的了解，於是我們就把目光放到外部，尋找可用的技術。

我們評估了一些技術，Natural Motion的Morpheme技術進入了視野。整套方案非常出色，考慮了美術製作和邏輯製作分離，兩方面可以分開開發，充分解耦合，也有詳實的案例，在動畫製作上給了我們很多的啟發。但不足也有，小方又要把自己做過的動畫系統全部推翻重做了，而且整套方案非常昂貴，有一定的學習曲線，我們不確定動畫同學能否掌握。

天刀開發過程中，好多次面對這樣兩難的選擇，需要在信息不完備的情況下做出技術選擇。我們能做的非常有限，先盡其所能，收集更多的信息，做更多的評估，權衡更多的利弊得失，降低整個技術方案的不確定性。然後總會有那麼一個時間點，需要做出決定。往後看，是不堪回首的往事，小方的血淚，老於的挑剔，歷歷在目；向前看，新技術似乎做出了承諾，能解決所有的問題，天藍了花開了，可以提早下班了。隱藏在迷霧深處的，是更多的不確定性。

信息不完備情況下的決策，非常依賴決策人的經驗，有很大的風險，相當於一次賭博。如果人力資源充分，我們可以有fallback方案，一部分人嘗試新方案，另一部分人繼續做原來的方案，這樣發現情況不妙還來得及退回原點。可惜當時並沒有這麼奢侈的團隊配置，我們面臨著二選一的問題。

沒有必然正確的決定，項目的進度，已經沒有辦法進一步拖延了，我還是決定切換到新技術。好在這一次我們運氣不錯，morpheme引入後，很好的解耦合了動畫和程序技術，管理起複雜的動畫節點，降低了開發難度，也讓動畫表現更豐富。評估一陣子後，再三延遲評估周期後，我們終於開始走採購流程。

有了morpheme系統後，動畫美術對整個流程有了一定的控制能力，擁有了自由度，只需要在前期和策劃程序約定好動畫的轉換，就可以在後期獨立微調動畫表現，對動畫間的transition也有一定的控制力度。程序層面也有了更多的自由度，可以把大量精力放在更高層的管理，而不用關心底層的具體動畫實現。一定要說缺點的話，內存佔用、性能等會比原來略差，在後期帶來了一定的優化成本，載入系統也不夠理想，數據零散雜亂，效率較低。好在runtime的全部源碼都交付，有什麼不滿意，自己改就是了。沒有什麼是免費的，出來混總要還，把問題分化，從一個製作流程問題變成一個性能優化問題，並不是什麼壞事，至少後者我們會更有把握，有資深程序員就能做好。

這是一次非常成功的嘗試，雖然陣痛也不小。小方再一次重構所有的動畫體系。這個級別的重構，和軟體工程中講得重構還不太一樣。軟體工程中說的重構，往往有完善單元測試保駕護航，做點代碼調整，讓結構更合理，以便提升質量以及未來維護效率。我們這個重構，其實是重做，只是為了照顧小方的情緒，我們勉強說是重構。

所有的巨大調整，都會伴隨著流程重新梳理。美術開發突然發現自己光給齣動畫不夠了，還要去圖形化邏輯界面調整節點和參數，程序突然發現不能硬編碼了，什麼動畫在做之前都要和策劃、美術有完整的約定，策劃突然發現有時候也要去看看動畫，配置點動畫參數了。新的工作，意味著新的分工，新的疆域，模糊了以往的界限。開發者們努力重新適應流程，能完整使用起來整套流程，已經是很久以後的事情了。但即使如此，在開發的當時，切換動畫系統依然給我們帶來了巨大的好處。

題外話：數年後，驚聞mopheme不再對外授權，也是一聲嘆息。好的技術，並不足以支撐一家小企業活得滋潤。我們看見了太多中間件和引擎的隕落，比如scaleform，比如simplgon。新一代的中間件崛起，發展，然後沒落，生生不息。殘酷的生態，詛咒著開發者，凡你會的，必會消亡，終身學習是躲不開的宿命。