一、前言：回顧來時路
歷經了 28 天的程式碼實戰、UI 跑版除錯與系統重構，我們的《平民王冠》終於從一個只有基礎概念的課堂專案，蛻變成一款具備完整遊戲迴圈、存讀檔機制與成就系統的 2D 敘事遊戲。
在倒數第二天的今天，我們不再鑽研單一技術點，而是以全面視角一起來回顧這 30 天來專案架構的演進，並盤點我們是如何把當初「因為覺得太難而放棄」的功能，一步步親手實作出來。
二、前後對照：從滿江紅的 Failed 到全數 Passed
還記得在 Day 1 時，我秀出了一張課堂專案時期的 STD（軟體需求規格）測試結果表嗎？
圖一、當初課程專題交出去的 STD-測試結果
當時的我們，看著這張表幾乎充滿了無力感。只要一想到存檔、結局紀錄、歷史軌跡，直覺反應就是：「這需要架設複雜的資料庫，對我們來說太困難了，時間也不夠。」於是，我們選擇了妥協，讓遊戲淪為一個無法紀錄玩家心血的半成品。
然而，經過這 30 天的鐵人賽洗禮，這張表迎來了截然不同的面貌：
圖二、經過28天修改與優化處理的 STD-測試結果
這不僅僅是表格上狀態的改變，更是整個專案從半成品走向完成品的最佳證明。
三、30 天技術架構總檢閱
為了解決上述的需求，這 30 天我們建立了一個分層明確、易於擴充的遊戲架構。以下是五大核心模組的技術演進總結：
1. 聲音與系統底層 (Day 3 - Day 5)
我們捨棄了最陽春的 AudioSource 拖曳播放，導入了 AudioManager 單例模式 與 AudioMixer。這讓遊戲的 BGM 與 SFX 有了統一的管理入口。更重要的是，結合 PlayerPrefs，我們做到了音量設定的持久化，讓玩家不需要每次打開遊戲都重新拉動 Slider。
圖三、統一管理音效的滑桿
2. 劇情與數值核心 (Day 6 - Day 14)
2D 敘事遊戲的靈魂在於劇情流轉。我們開發了 StoryFlowManager 來控制劇情分歧與立繪切換，並運用黑屏打字機效果（TypewriterEffect）增添敘事氛圍。同時，建立了跨場景的 PlayerStatsManager，利用 DontDestroyOnLoad 確保玩家的數值（如金錢、民怨）在場景切換間不會遺失，為後續的多重結局判定打下基礎。
圖四、貫穿全遊戲的重點-金錢、聲譽數值
3. 存檔生態系與 JSON 的救贖 (Day 15 - Day 18)
這是整個專案最大的技術突破點。我們徹底拋棄了「存檔必須依賴關聯式資料庫（SQL）」的先入為主觀念，轉而擁抱輕量化的 C# JSON 序列化（JsonUtility）。 透過建立資料模型類別，我們實現了手動 JSON 紀錄點（Save Point）與自動存檔（AutoSavePoint）的協程控制，完美解決了 UR-03 與 SC-01 的問題。
圖四、存檔功能
4. 成就系統與視覺化回饋 (Day 23 - Day 25)
遊戲的核心驅動力之一就是成就解鎖。我們採用了 ScriptableObject 來建立獨立的成就資料模型，確保資料與邏輯分離；在主選單與遊戲內實作了 灰階視覺化（未解鎖顯示問號與灰階）、動態 Prefab 生成，以及觸發時的彈窗通知回饋（Popup UI），讓玩家每一次達成關鍵結局或道具互動時，都有極佳的成就感回饋。
圖五、成就彈窗通知
圖六、待發現的成就列表
5. 全域常駐 UI 與跨平台優化 (Day 19-22, Day 26 - Day 28)
透過 PersistentCanvas 與常駐控制總成（PersistentMenuController），解決了跨場景選單呼叫的問題。期間更經歷了無數次 UI 跑版除錯，精通了 Canvas Scaler 與 Grid Layout Group 的自適應調校。最後透過記憶體洩漏排查（NullReference 優化）與 Build Settings 配置，順利將專案跨平台打包至 PC 與 WebGL。
四、今日小結
看著專案資料夾裡那一排排整齊的腳本、Prefab，以及最終成功 Build 出來的執行檔，這 30 天的技術累積已經化為實實在在的成果。我不僅修補了課堂專案的遺憾，更建立了一套未來隨時可以復用的 2D 遊戲底層架構。
技術的版圖已經拼湊完成，但這趟旅程帶給我的，遠不止程式碼上的進步。明天的最後一篇文章，我將放下程式碼，和大家聊聊這 30 天來最深刻的心路歷程——那些關於「打破自我設限」與「工程師心態蛻變」的故事。
話說，有沒有眼尖的人發現我前面是固定模板XD 今天的內容可以說是我的遊戲進化史，所以就不需要上傳到分支啦~btw你各位明天就是最後一天啦!敬請期待!
iThome鐵人賽
看影片追技術