自《戴森球計劃：黑霧崛起》去年在TGS上的內容展示以來，我們已收到了大量來自玩家的支援和鼓勵，這讓我們非常的興奮，並在團隊的一頓火力輸出下，越來越多關於戰鬥的內容也被加入到遊戲當中來，先上幾張高清大圖：
這段時間除了戰鬥系統的開發以外，我們還為大家帶來了新的配送物流玩法，更高階的化工廠，能存貨的四向分流器和更便利的傳送帶功能等等。
為了在開發戰鬥的同時能夠給大家提供儘可能多的新內容，我們內部在早期將 黑霧崛起 和 遊戲內容更新 分成了兩個專案分支（Branch）同步開發：“戰鬥分支”和“內容更新分支”。在開發過程中，我們需要定期將“內容更新分支”所做的改動合併到“戰鬥分支”中來，從而讓戰鬥模式在釋出後能夠繼承之前所有的更新，同時也避免了戰鬥模式的資源提前洩露。
然而壞訊息是：戰鬥系統作為獨立專案分支跑了一年多，在內容上已經和主分支產生了大量的程式碼和資源衝突，而每次解決這些衝突都會佔用我們大量的精力，有時甚至還需要刻意去避免改動公共資源和底層程式碼，這讓我們無法專注於戰鬥系統的開發。為了讓戰鬥模式早點和大家見面，我們決定全面切換到戰鬥分支，所以在戰鬥模式推出之前，只能修改部分舊內容，而無法再提供新內容更新了。
這樣一來，我們才有機會對戰鬥系統程式碼和一些底層進行重構。因為在零零碎碎地加入了一堆內容後，遊戲效能瓶頸開始凸顯，我的老機器還能跑到十幀甚至九幀，最終在幀率不支的情況下，我們決定推翻一些無法優化、不夠靈活的程式碼，在實現過一次過後，大家也有了一些經驗，也願意嘗試更好的方案。雖然過程比較艱難，但是必須得保證我們最初的目標：加入戰鬥後遊戲必須流暢。
（順便提升了一下配置）在我們的理念中，策劃和程式不能是兩個獨立思考的部門，“策劃只管提需求，然後程式來實現”。像遇到這樣的效能問題時，這種流水線式做法根本不管用，策劃要麼會堅持說：“我不管，你程式必須得整出來”，要不然就會放棄說：“算了，現在技術還達不到”。
在戴森球計劃中，玩家的工廠物件規模動不動就上十萬百萬，效能無疑是需要重視的。而一個遊戲的效能最終上限是從策劃設計時就定下了，然後再是靠程式的技術水平去努力達到它。所以我們要求策劃在設計時就利用好這些僅存的效能空間來實現儘可能多的可能性。在經歷了一次玩法驗證之後，我們給出了一個設計目標，下圖展示了在設想中玩家通關前和黑霧的戰鬥力對比。
此外我們比較清楚：如果黑霧擠佔了玩家的發展空間（和CPU算力），玩家勢必會消滅它們，所以黑霧和玩家工廠的活動大致呈此消彼長的關係。我利用這些特性制定了一個效能優化目標：
如果玩家玩到後期，選擇“養著黑霧不打”，那剩餘的大量黑霧巢穴開銷一定會成為很大的負擔，而此時黑霧的整個生產體系（太空巢穴、地面基地）對於玩家來講是非敏感的，更新頻率並不需要像玩家工廠那麼高。
（黑霧的擴張邏輯）經過考慮後，我們將黑霧巢穴的更新邏輯設定為每60邏輯幀更新一次，此外，所有巢穴的更新儘量平均的分佈在每一幀，避免大量邏輯集中在一幀內更新。例如玩家選擇了60個恆星的開局，那每一邏輯幀將輪流更新一個行星系的黑霧巢穴。以下是簡單的負載均衡程式碼：
上面看似簡單的想法卻帶來了其他的麻煩：如果黑霧每60幀更新一次，那除了建築以外的其他戰鬥單位怎麼辦？太空中的運輸單位怎麼辦？黑霧地面建築的動畫該怎麼銜接？
（太空單位的艦隊方陣）
GIF
（地面單位群體行動）這種情況必須得祭出大招：利用GPU來處理一些運算。
就像物流運輸機的優化那樣，CPU根本不用計算運輸機從A點（xA,yA,zA）出發，到達B點（xB,yB,zB）卸貨，中間經過的這條弧線，以及機身旋轉、上升下降的過程、尾焰特效如何變化等等，CPU要做的僅僅就是累加一個t值。
而將比較複雜的數學運算工作交給GPU：
以下是大量物流運輸機的效能測試存檔，有興趣的話可以下載試試看：
http://8.140.162.132/dspsaves/Performance_1_Dronesphere_Test.dsv
（21,000物流運輸機同時更新）
由於敵方戰鬥單位99%的時間都是在執行閒逛行為（Wandering Behavior），所以從設計上可以讓它們的軌跡更具有可計算性，即可以使用引數方程來表示其運動軌跡，這樣就可以像優化物流運輸機那樣優化絕大多數正在閒逛的敵人了。
接下來我們計劃當它們進入攻擊狀態時，或是退出攻擊狀態返回閒逛時，在GPU演算和CPU演算之間進行無縫切換。
這樣做同樣存在一些難點，比如在攻擊這群敵人時，自由目標彈道很難找到合適的攻擊目標。這的確讓簡單問題複雜化了，不過相比全CPU模擬帶來的效能“災難”，我們必須先這麼做，再解決後面的問題。複雜度不能被消滅，效能優化就是把執行時的複雜度轉移到程式碼的複雜度上。
（現在還沒有做出來.jpg）
除此之外，我們還發現在以最高難度建立新遊戲後，由於64個行星系的黑霧建築總數多達200k（這還只是建築），即使在邏輯開銷已經被壓至3ms以下，黑霧在存檔中的資料量仍有50M左右。
對於新開的存檔而言，玩家是感受不到其他行星系黑霧的存在的，這樣的存檔大小比較難以接受。但同時，我們也認為即使是遠處的黑霧也必須按照一定規則來發展，並且這些規則的確定性（Determinism）結果在之後會逐漸變得十分重要。就像遊戲中“真實宇宙”的一貫執行邏輯那樣，玩家並不會因為離開星球，而讓星球上的工廠失去邏輯的確定性。
為此我必須將黑霧生長的邏輯和資料分成多個具有確定性的LOD（Level of Details），並指定各級間的切換規則。
而為了保持一定的確定性，我重新翻版了巢穴生長過程的設計，使其在不受干擾的情況下，根據確定的年齡和隨機數種子可以實時烘焙出一個確定的巢穴生長版圖。這樣的話，即使每個巢穴包含多達2000個建築和單位，我們至少能將遠處未相遇的巢穴轉化為“年齡”、“隨機數種子”等若干頭部資料。同時仍然生成中繼站和火種，以確保未相遇的黑霧仍然可以向外擴張。
（最簡資料形式）
（藍、紅、黃框分別是三個等級的邏輯LOD）
目前，戰鬥系統的程式碼重構還在進行中，已基本完成了上圖中藍色和紅色兩個等級，黑霧巢穴的自我複製和擴張部分也已基本完成。等到重構完成，接下來我們還將繼續著手比較複雜的戰鬥部分優化。
模型製作方面，還需要完善敵我雙方每個建築的摧毀效果和所有黑霧建築的LOD，以及每個LOD對應的動畫。
GIF
對於一些需要大量渲染的複雜效果，仍需要改用shader來進行模擬。比較典型的一個例子是彈道的擊中特效：
GIF
如果直接使用引擎提供的粒子系統，將無法支援大量特效例項，我們需要利用之前開發日誌提到的方法，逐一將製作好的粒子系統改成用shader來模擬這些擊中特效。下面是其中一個做好的擊中效果：
GIF
（請各位玩家放心，這只是在做測試）在本篇開發日誌的最後再次說明一下，喜歡安心種田的玩家是可以徹底關閉黑霧的，除此之外，玩家還可以詳細的設定黑霧的一些難度引數。
（以上選項僅基於目前的設計，並非最終版）最後，向大家小小地報個喜：戴森球計劃製作人3號已經落地啦！
母女平安，還在醫院，左手抱娃，右手程式碼。
今天的開發日誌就到這裡了，感謝閱讀！
如果對過往的《開發日誌》感興趣，可以點選這裡回顧：https://steamcommunity.com/games/1366540/announcements/detail/3069734283121827113
