遊戲燈塔專案《魔女鍊藥》開發回顧

16 April, 2025 - Tags: GameBeacon, game dev, Unity

這次專案是我第三次在燈塔內與人合作開發，回顧這三個月的過程，我認為對自己影響最大的大概是在 tech stack 的選擇上有比前面兩次來得舒服，引入了 VContainer 來做 DI，另外 加上 MessagePipe 來傳遞 events。而且得益於專案規模夠小， 所以我不大需要嚴謹地切分 lifetime scope 就可以讓各個系統蠻容易存取所需資料，在開發功能的時候我覺得 程式寫起來順手許多。話說在這種 scale 下，或許也不一定要使用這些套件，嘗試 Unity Atoms 這種基於 SO 的架構我想也會是個不錯的經驗，然而目前看起來已經許久沒更新了，不確定是否有適合的替代方案。 但我猜若需求只有 DI 跟 event-driven 的話，自己手寫可能也不會到真的沒辦法完成。

然而就最後的結果來看，我認為開發的速度還是有蠻大的改進空間。在回顧這次專案的過程中，我發現有幾個值得檢討 與改進的面向。

落實 issue tracking

以軟體專案來說，我還是比較習慣基於開好的 issue 來做事，我沒有具體的數據可以說明沒做會對效率有多少影響， 但有跟組員聊到說其實他會不確定我到底寫完了哪些功能，我想若是有好好把遊戲的設計都轉化成可執行的 issue， 並且限縮到適當的 scope，應該可以多少改善這個狀況。以這次專案的開發狀況來說，雖然在開案時有開了幾個 issue， 但列的不夠詳細，基本上是以整個完整的系統當作 scope，所以其實不大好聚焦一次要做哪些功能。另外還有一個問題 是不大確定誰該負責來整理這些 issue，雖然我直覺上認為這應該是企劃負責，但這似乎又偏向工程師在規劃功能開發時 慣用的做法。回顧我過往經驗大多是在只有工程師的團隊內做事，所以蠻自然的就是由該專案 PM 負責，但這個人是否 該由企劃擔任我想還需要多累積一些經驗我才會有比較明確的答案。

針對專案 spec 確認不夠仔細

除了 issue 的管理之外，專案規格的確認也是影響開發效率的重要因素。我認為沒有事先開好 issue 造成了我在實作 一些功能的時候才發現 spec 缺乏需要的資訊，來回確認也就拖慢了開發的節奏。雖然這件事直覺上可以透過將企劃寫得 更詳盡來解決，但我認為責任不該完全在企劃身上，畢竟在職能專業不同的情況下，對於實作一項功能所需的資訊也會有 不同認知，身為負責實作的人我就不應該怠惰而沒有做好事先規劃，僅憑開會當下的短暫時間思考過後就認為這個可做。 當然這不代表企劃的詳細程度應該要無限上綱，完整到看過就一定可以規劃好如何執行。投入撰寫企劃時間與後續省下 溝通的時間之間要如何取捨，我想就是需要靠團隊磨合培養默契來決定的。只是這次專案我認為有再詳細一點確認應會 更接近理想狀態。

做好 CI

回到「不確定完成了多少功能」這個現象，我認為其中一個原因就是產品的交付流程不夠好，直白一點就是我們根本 沒做，所有進度就是保持在企劃案跟 unity 專案的狀態，並沒有產出遊戲的執行檔再往下交付（但以這專案的性質來說， 往下其實也只是 build 出來讓我們幾個跑看看，不會有專門的 QA）。要解決這個問題的話，以我個人來說自然會比較 傾向要建置好 CI pipeline，至少在需要的時候可以穩定產出執行檔。但是 unity 在這方面又相對麻煩，以前在 Blue Rose 嘗試過一次遇到一些難解的問題後就沒有再深入研究了，也就造成了我並沒有在此次專案開發中積極推動 CI pipeline 的建置，畢竟我預期在一個短期專案內要研究如何解決這些問題的成本過高。但若是選用某些方案，例如說 godot 的話我想就不是問題了，在 2024 的 GGJ 中我是有寫好 CI 去自動 build 各平台執行檔放在 artifacts 的。

嘗試 pair programming

除了交付流程的問題，我認為在前面開發階段也是可以做得更好。像是我已經知道海星並沒有使用相關套件的經驗了， 那在專案前期我應該就可以多嘗試看看以 pair programming 的方式來 sync 彼此對於專案架構的認知，還有套件的 使用方式與慣例，理想上應該可以讓專案啟動得更加順利。如果擔心沒有辦法喬出共同時間的話，我想約在開會前後的 一小段時間可能就會達成還不錯的效果了。

結論

雖然上面列出了不少可以改進的地方，但我覺得對我來說最大的敵人或許是時間吧，有觀察到自己蠻多進度是在死線前 才開始推進（包括這篇回顧），這通常表示自己已經不大能負荷目前的工作了。我想這點應該也是蠻多 indie 會遭遇到 的困境，畢竟若是在兼職開發的情況下，難免會因為主業太忙而沒辦法兼顧，若是用愛發電的話這問題應會更加嚴重。 但這種問題應該就難以在專案內的範圍解決了，應該只能期許自己在投入開發的時候更聚焦，捨棄掉其他次要的選項來 提升時間的利用效率對自己以及團隊成員都會更好。