開發日誌 #1 - 初始構想與需求分析
開發契機
2025 年 9 月 27 日，三天連假的第一天，我決定開始執行這個心心念念很久的專案——Parasync 狀態同步框架。
問題背景
長期以來，我使用公司開發的連線工具製作連線遊戲，但這套工具的基礎設計一直沒有更新過，逐漸浮現出許多難以解決的問題。
現有框架的限制
公司的同步框架採用「事件同步」設計：
- 當遊戲中任何狀態改變時，開發者必須手動發送網路事件
- 每個端點需要自行接收並處理這些事件來同步狀態
遇到的困境
在實作斷線重連和中途加入遊戲這兩項功能時，事件同步的設計產生了大量工程負擔：
- 狀態重建問題：斷線後重新加入的使用者需要獲得當前遊戲的完整狀態，最直接的做法就是重新發送所有相關事件
- 開發負擔：每當工程師新增功能時，都必須同時考慮「斷線重連時需要重送哪些事件」
- 維護困難：在大型專案中，這種設計對開發非常不友善，容易遺漏或出錯
核心提問
有沒有一種方法，可以讓開發者不需要管斷線重連時的資料同步問題？
解決方案：狀態同步
經過與多位前輩和資深工程師討論後，我確定了方向：製作一個狀態同步框架。
狀態同步 vs 事件同步
狀態同步的核心概念：
- 系統直接同步遊戲中的各種狀態（參數）
- 斷線重連的使用者直接接收當前遊戲的所有狀態
- 開發者無需手動處理重送事件的邏輯
市場調查
在開始開發前，我先調查了市面上的連線框架，想看看是否已經有符合需求的輕便網路框架：
主要框架比較
- Photon：廣為人知的 Unity 連線套件
- Mirror：完全開源，從舊時代 UNet 演化而來，使用者眾多
- PurrNet：開源網路框架
- FishNet：開源網路框架，使用方式有 UNet 的影子
發現的問題
這些網路框架都有類似的功能設計，但如果要將它們導入已經存在網路系統的遊戲中（例如公司的專案），基本上很難進行技術遷移：
- 網路同步規則被整套框架限制住
- 必須掛載
NetworkObject - 必須繼承
NetworkBehaviour - 各種強制性的設計限制
這些設計讓我在遷移技術時感到寸步難行。
理想的使用方式
我希望的使用體驗是：
- 只需在要同步的物件上掛一個介面
- 在要同步的變數上加上一個
Attribute就好
開發歷程
第一次嘗試：失敗
一開始我和 AI 協作進行框架設計，但第一個版本混合了太多功能：
- 資料序列化
- 網路傳輸
- 連線方式的實作
這些功能混雜在一起，讓框架變得過於複雜。我果斷選擇重做。
第二次嘗試：仍不理想
第二次，我花更多時間和 AI 協作「設計」部分，但因為設計不夠嚴謹，最後做出了一個似是而非的系統。
第三次嘗試：成功
第三次，我花了非常多時間和 AI 進行設計，確保每一個地方的設計都符合我的需求後才開始動工。這次製作出來的結果終於比較符合我的理想狀況。
學習心得
經過三次的設計迭代，我深刻體會到：
- 設計比實作更重要：充分的前期規劃可以避免後續重工
- 需求必須明確：模糊的需求只會產生模糊的結果
- 與 AI 協作的關鍵：清楚表達需求，確認每個設計細節