從斷線重連到記憶體釋放，撐起遊戲穩定度的底層設計
解析客端與伺服器的即時通訊設計、斷線重連的狀態還原機制、大量資源的分階段載入與記憶體釋放策略、多語系在地化的實作考量，以及 UI 層級與彈窗堆疊的管理架構。
一款遊戲是否經得起真實環境的考驗，取決於三個玩家幾乎不會注意到的系統： 通訊層、資源層、介面層級管理。它們做得好時完全沒有存在感，做不好時每個缺陷都會被放大。
其中通訊是整個遊戲體驗的關鍵基礎設施。不同於一般 Web 應用的請求—回應模式， 老虎機遊戲需要持久連線來保證即時性與狀態一致性。
客端與伺服器之間通過 WebSocket 建立長連線，並定期交換心跳封包以偵測連線是否健康； 若在超時時間內未收到回應，則判定連線已斷開並啟動重連流程。 間隔的選擇是個取捨：太長會延遲數秒才察覺斷線，太短則在行動網路下產生不必要的耗電。 我們讓心跳與實際流量互斥。間隔內若已有正常封包往返，這次心跳就跳過。
這個流程看似簡單，但細節中隱藏著多種邊界情境：
這三種情境有一個共通的設計原則：讓所有關鍵操作具備冪等性。 同一請求無論送出幾次、回應無論收到幾次，最終呈現給玩家的結果都必須一致。 把冪等性設計在協議層，遠比在每一處呼叫點各自防禦來得可靠。
斷線在行動網路環境中極為常見：切換基地台、進入電梯、網路瞬斷。 良好的重連策略必須能無感恢復遊戲狀態。核心機制如下：
恢復的難點其實不在資料而在演出：直接把最終畫面貼上去很突兀， 整段重播又會讓已知道結果的玩家覺得冗長。我們依斷線發生的階段決定策略： 展示階段之前斷線就完整重播，之後斷線則快進到終態。
客端所有數值均採用整數運算，以最小單位為基本刻度避免浮點數的累積誤差， 只有顯示時才轉換為帶小數點的格式。這個原則必須貫徹到每個中間環節，包括數字滾動動畫的插值。
一款老虎機遊戲的資源量可能相當龐大：數百張圖片精靈（包含不同解析度的版本）、 骨骼動畫資料、音效檔案、字型檔案等，如何高效管理直接影響載入速度與記憶體佔用。 資源載入採用分階段漸進式策略：
延遲載入需要一道保險：若特殊功能被觸發時資源尚未就緒，流程不能中斷， 而是插入一段可延長的過場演出來爭取時間。這也是為什麼場景轉換動畫通常設計成可無縫循環。
老虎機的資源需求並非單一集合，而是隨著遊戲流程切換而變動：
每一次流程切換同時也是一次資源切換：進入免費遊戲要載入專屬背景與符號變體， 退出時則要決定哪些釋放、哪些保留在快取中。判準是觸發頻率： 高頻流程的資源留在記憶體，低頻的特殊玩法資源在退出時釋放。
配合三層式架構，資源系統也支援三層覆蓋：
載入器查找時從遊戲層開始逐層向下回退，讓開發者只需替換需要自訂的部分，其餘自動繼承上層預設值。
多語系支援遠不止「替換文字」這麼簡單，它涉及以下多個維度：
音效對老虎機遊戲體驗的影響經常被低估，精心設計的音效系統能大幅提升沉浸感與回饋感。 我們的音效架構將所有聲音分為三個獨立的聲道管理：
三個聲道擁有獨立的音量控制，玩家可以分別調整。
音效系統與遊戲狀態機深度整合，確保聲音與畫面的精準同步：
停輪聲效的對齊有個實務細節：聲音應該對齊滾輪接觸目標位置的瞬間， 而不是整段動畫的結束時刻。過衝與回彈發生在接觸之後，晚放就會慢半拍。
場景切換時，音效系統會執行交叉淡入淡出：當前場景的背景音樂在設定時間內漸弱， 同時新場景的音樂漸強，交叉曲線可獨立設定以確保過渡自然。
另一個常見問題是疊加：快速節奏中同一音效可能極短時間內被觸發多次（例如連續的中獎線展示）， 多個實例疊加會產生刺耳的音量暴增。音效系統以三種機制防止：
老虎機遊戲的介面層級管理比一般應用程式更複雜：各種元素會在不同時機出現和消失， 它們之間存在嚴格的層級關係與互斥規則。我們採用四層架構：
層級之間存在嚴格的互斥鎖定規則，防止多個浮層同時出現造成混亂：
這套機制確保介面在任何情境下都保持有序、可預測。 即使在極端情況下，例如大獎慶祝動畫播放期間斷線，通訊層的錯誤訊息會穿透到最上層， 慶祝動畫則被凍結而非中止，待玩家確認後從凍結處續播。三個支撐系統在這一刻的協作， 正是整套架構真正被驗證的地方。
這些支撐系統之所以能彼此協作而不糾纏，前提是有一套清楚的分層架構與狀態機定義； 而它們所服務的視覺主體，也就是滾輪的動畫曲線與停輪節奏，則有自己獨立的設計方法。 這兩個主題我們在同系列的另外兩篇文章中分別展開。