以黃昏寫實風格為主的塔防遊戲《SciFi-Tower》

我以前是一個 CSO（Counter-Strike Online）重度遊戲愛好者，CSO 是一款古老的、第一人稱視角的射擊遊戲，裡面有許多有趣的模式相當吸引我，儘管玩家們罵聲連連，但它畢竟是許多人的童年，可能是因為這樣，這款遊戲到現在仍屹立不搖。CSO 也是我的童年，遊戲渲染出的滄桑、絕望的氛圍佔滿我的回憶，末日的靈感不停灌入我的感官，也許是這款遊戲畫質不高，反而有一種戰爭歷史感，老實說我更喜歡灰暗的陰雨勝於天晴，因為灰暗總能帶來一些額外的安心感。

其中有一種遊戲模式是，一開始玩家會在一個避難所內，白天玩家必須逛地圖尋找資源，然後建造砲塔抵禦夜晚的殭屍，直到擊敗地圖上的 Boss 才算過關。我與 阿瑋 都非常喜歡這種建造砲塔、抵禦殭屍的遊戲模式，於是這款塔防遊戲《SciFi-Tower》就誕生了。

這是一段非常有趣的緣分，阿瑋是我在遊玩另一個遊戲模式（跟上面提到的模式不一樣！）遇到的網友，這個模式讓我們 合作做了幾張地圖，合作期間我開始對開發遊戲感興趣，所以我同時自學 Unity 遊戲引擎，但我對美術一竅不通，於是我厚著臉皮詢問阿瑋是否要一起合作做遊戲，沒想到我們的想法是一樣的。

開發專案

在我詢問阿瑋是否合作開發時，其實我已經用之前買的遊戲素材，做了一些砲塔與怪物互動的 Prototyping，當時想模仿那款我們都熱愛的遊戲模式，因為雖然很好玩上癮，但地圖就那幾張、砲塔就那幾種，完全不夠我玩，所以我想模仿那款遊戲帶來的情境，並期望做出更多變化。

Unity 有時會發布大特價，讓開發者能以幾乎一折的價格購買 20~30 種遊戲素材，當時熱衷於學習遊戲的我，只要看到活動有賣不錯的素材，就一定買爆，就像把遊戲素材當作蒐集品一樣，回頭來看應該花了一萬多在買素材，真的是瘋了。

而阿瑋也希望創造一些作品集，所以他決定做 3D 建模並搭建場景，當時我們完全不理會模型可能帶來的遊戲效能，因為有比好更重要，優化再好、內容再大的專案如果沒做出來都是白搭，所以都是初學者的我們決定什麼都不顧慮，先有專案再說。很快的我們有了一版場景，是一個以基地為主角的場景，再搭上我先前買的 Modern Style UI 後，我們很快的有一版主頁面，我在畫面上加了一些 Post Processing，例如增加光暈效果、以及增加暗角讓圖片更趨近現實，此外我也加入一些 Volumetric Fog 彌補地面的亮度不足的問題，這個專案的渲染並不是 URP 而是 built-in，所以這些功能都需要透過套件完成，最後加入一些動畫並讓相機緩緩轉動，增加觀眾的帶入感。

之後我開始把那一堆 Prototyping 放到場景上，很快的就做好一個最基本的 Demo，包含砲塔與怪物的互動、怪物路徑以及建造系統，到這裡我們花了將近 4 個月，包括學習不同套件與改善畫面。

更改企劃路線

我原本以為可以很順利的做下去，達到「地圖自由」的願景，但當時已經在研究所做專案，我開始撥不出時間在這個專案上，除了已做完的功能外，我還有日夜系統、第一人稱角色、技能等功能尚未完成。

所以我開始轉換路線，思考什麼樣的遊戲規模比較適合獨立開發者，之後我們決定保留塔防遊戲的防守概念，並試圖將塔防遊戲概念變為可移動、劇情導向的，以打破傳統塔防遊戲固守陣地的特色。這麼做是為了減少開發量，因為這會讓遊戲規模變得很有彈性，如果開發時間不足，我們可以開發短一點的劇情作為試玩版；若玩家覺得不錯，我們可以試著增加劇情。所以我們嘗試在遊戲中引入過場動畫，並加入劇情任務，到這裡我們做了一個有劇情的 Demo 版本，可以看到玩家必須透過放置砲塔不斷解鎖劇情。

再次更改企劃

透過放置砲塔不斷解鎖劇情的方式，的確可以根據工作量調整劇情，但這麼做會讓遊戲平衡變得困難，因為原因有幾點：

• 隨著砲塔建造範圍越來越大，怪物的重生點與路線就更要審慎評估。
• 必須生成對應難度的怪物數量來制衡越來越多的砲塔，但當砲塔失守，龐大的怪物會讓玩家喘不過氣。
• 新增的路線可能會影響舊路線的遊戲平衡。
• 玩家需專注在新劇情上，卻又必須顧慮舊的砲塔，遊戲玩法的細節設定很複雜。

所以評估後，我們決定保留用砲塔動態解鎖劇情的設定，但改為用一台移動的主機具替代，主機具會在固定路線行駛，玩家可以在機具上放置砲塔，而路線上可能會有事件與障礙，我們可以根據工作量並做出不同的路線，如下圖，我們稱障礙與事件為一個段落區間，主機具到達段落前會不停地慢慢行駛，直到解決後才能繼續前進。這個玩法的優點是只需處理建造系統與怪物砲塔的互動即可，其他功能都不難做，因此我們決定往這個方向出發，並做了一台簡單版的主機具。

我們希望玩家可以享受一邊防守機具、一邊觀賞移動時的風景。

多人開發下的困境

就讀研究所的這段期間，為解決時間不足的問題，我們有找其他開發者一起合作，共享這份專案的成果，但這也產生很多問題，例如工作分配、專案版本控制等問題。因此我開始使用在研究所學到的專案管理知識，將其運用在遊戲專案中，我開始習慣在 GitHub 上列 Issue，並秩序地透過 Pull Request 審核與合併更動，我也開始習慣寫 Unit Test 與 e2e Test，並在建立 Pull Request 時留下 Documentation，避免下次開發專案時不知道之前寫了什麼。Unity 有相對完整的測試環境，我搭配 GitHub 的 CI/CD 對專案進行自動化測試，詳情可以查看連結：在 GitHub 上為《SciFi-Tower》專案搭建 Unit Test、Integration Test 的 CI/CD 自動化流程（for Windows）。

這些開發者夥伴也因個人規劃而漸漸停止開發，我認為不停更改企劃、時間不夠可能是夥伴降低開發意願的主因，說實話有些難過和可惜。