「GuildSim」個案研究

概要

GuildSim 是一個已完成的公會管理遊戲技術 Demo，亦是一項由 AI 主導的開發實驗。項目交付了可玩的管理循環和完整結案紀錄，同時清楚區分技術完成與產品驗證。

我負責訂立產品方向和運作章程、檢視可玩版本，以及作出最終產品決定。大部分實作工作由 AI coding agents 按已記錄的架構、測試和交付規則完成。

項目同時驗證兩個問題：自主 AI 工作流程能否交付可維護的 Unity 原型，以及一個精簡的公會管理循環，能否在加入更多內容和打磨之前已經足夠吸引。

可玩 Demo 面向對輕量公會管理感興趣的玩家，也適合想評估 AI 主導工作流程的開發者，了解在架構、測試和停止條件都被視為核心限制時，這種方式可以交付甚麼。

實驗由一名產品負責人配合 AI agents 進行，並受固定技術章程和既有製作限制約束。原型必須保持確定性、可測試和可建置，同時避免在核心循環證明有趣之前繼續投入。

玩家可以管理公會名冊、選擇委託、組成隊伍、準備補給、派出遠征並查看結果。這套連貫流程足以測試管理玩法的前提，同時不會把 Demo 包裝成已完成的商業遊戲。

Unity codebase 把領域規則、應用協調和呈現層分開。確定性隨機機制令結果可以重現，儲存操作以原子方式處理，而本地化、音效、驗證和建置工具亦納入交付流程。

最重要的決定，是在技術目標達成、但核心樂趣假設仍未獲證實時結束項目。保留 build、原始碼和結案證據，令它成為有用參考，同時避免因沉沒成本而繼續開發。

交付流程使用 Unity EditMode 和 PlayMode 測試、驗證檢查、自動建置 script，以及 Windows smoke-test 流程。測試集中於確定性模擬、核心流程、資料保存，以及 release candidate 能否可靠重現。

結案評估發現，決策仍然過於數值化、遠征路線欠缺變化、敘事回饋偏薄，部分資訊亦不易閱讀。這些屬於產品層面的弱點，而不是尚未完成的工程工作。

成熟的架構和通過測試，並不能證明遊戲有趣。最重要的心得，是及早驗證灰盒玩法循環、在投入呈現效果前先訂明停止條件，並把誠實結案視為一種成功的項目成果。