如何設計一套可復用的客端框架，讓每款新遊戲只需開發差異化的部分
從三層式架構的設計動機出發，說明通用引擎層、老虎機框架層與遊戲應用層的職責切分，以及如何用有限狀態機管理一局 Spin 的完整生命週期，實現「一次開發、多次復用」的開發模式。
開發一款老虎機遊戲的客端，遠不只是「畫面上有幾個滾輪在轉」這麼簡單。 從技術角度來看，一個成熟的老虎機客端至少需要解決以下幾大核心挑戰：
這些挑戰彼此並不獨立。本文先處理最根本的兩個結構性問題： 程式碼如何分層，以及一局遊戲的流程如何被有秩序地描述。
為了在持續產出新遊戲的同時，保持程式碼品質與開發效率， 我們採用了三層式架構來組織整個客端系統：
最底層是與遊戲類型無關的通用能力，例如渲染管線、資源載入器、音效播放、 通訊協議封裝、事件系統、計時器與動畫補間工具等。 這一層的程式碼適用於任何類型的遊戲，不僅限於老虎機。
中間層封裝了老虎機品類共通的邏輯：滾輪引擎、狀態機、中獎展示排程、 賠付線繪製、自動遊戲控制器、歷史紀錄面板等。 所有老虎機遊戲共享這一層的程式碼，當框架修復了一個問題或優化了效能，所有遊戲都會受益。 遊戲數量越多，每次改善的回報越大。
最上層才是每款遊戲獨有的內容：主題美術素材、特殊玩法機制（例如擴展百搭、 累積式獎池觸發條件等）、自訂動畫與音效。 開發一款新遊戲時，工程師只需專注於這一層，大幅縮短開發週期。
分層架構最容易失守之處，是判斷一段新邏輯該放在哪一層。我們依循三個判準：
這套分層架構並非一開始就是完美的形態，而是經歷了多次演進：
老虎機的每一局遊戲看似簡單，按下按鈕、滾輪轉動、顯示結果，但背後的狀態管理卻相當複雜。 我們使用有限狀態機（Finite State Machine）來管理一局遊戲的完整生命週期：
最直覺的做法是用布林旗標記錄現況：是否正在旋轉、是否已收到結果、是否正在播放中獎動畫。 但五個獨立旗標就有三十二種組合，其中絕大多數是不該存在的非法狀態，程式碼裡卻沒有地方明確禁止它們。 狀態機把合法狀態縮限到有限且可列舉，並把轉換規則寫死。 不該發生的轉換會在當下被攔截，而不是等玩家看到異常畫面才被發現。
狀態機的設計允許在任意兩個階段之間插入自訂邏輯。 例如，某款遊戲在停輪後需要觸發「符號變換」動畫，只需在「停輪寫入結果」與「中獎展示」之間 註冊一個額外的狀態處理器，完全不需要修改框架層的程式碼。
這個機制依賴觀察者模式：每個階段進出時都會發出事件，上層訂閱後即可插入節點。 關鍵在於插入的節點必須能非同步地宣告完成。狀態機會等它回報完成才繼續推進， 因此數秒長的自訂動畫也能自然嵌入生命週期，框架層完全不需要預先知道它的存在。
老虎機經常涉及多流程切換：主遊戲與免費遊戲之間的轉場、 特殊玩法模式的進入與退出。我們讓每種流程擁有獨立的狀態機實例， 彼此透過明確的進入／退出事件溝通，避免流程之間的狀態污染。
生命週期也不會總是順利走完：玩家可能中途按下快速停止，網路可能在等待結果時斷開。 因此每個階段都要標記自己是否可被中斷。展示類階段通常可跳過， 涉及資料一致性的階段則必須完整執行。被跳過的階段不是直接丟棄，而是被要求「立即完成」， 確保跳過後的畫面與正常流程一致。
分層與狀態機構成了客端的骨架。骨架之上還有兩組值得深入的主題：滾輪的動畫曲線與停輪控制， 以及通訊、資源與介面層級這些支撐系統。我們在同系列的另外兩篇文章中分別展開。