大體上我們的玩法有兩種模式，一種是小桌，比如斗地主，一局游戲需要2~6個人；另一種是大桌，所有用戶都可以在一桌來玩。
所以“桌”是一個比較核心的概念，玩法服務器的結構也是圍繞這個核心來展開的。
以桌為核心的玩法架構
上圖是這個架構設計的核心要素，GameTable類位於這個設計的核心；左側GameTableManager是一個桌的集合類，里面邏輯並不多；table類包含桌的核心數據，包括玩家、當前局的狀態等，這個類在具體玩法中一般需要派生。
GameStateMachine類是一個狀態機，棋牌的游戲流程是一個狀態在管理，由消息驅動，后面會細講。GameTableThread是table的消息處理線程，保證了每個table的消息都是單線程處理，沒有並發。
玩法狀態機
GameStateMachine是一個狀態機的管理器，其實就是一組狀態實例的集合；這些狀態全部都繼承自AbstractTableState。玩法需要多少個狀態，與玩法本身的規則相關，一個狀態對應了一組當前可以處理的消息。為了簡化狀態的代碼，我們抽取了GameRequestProcessor這樣的工具類。
最后，建議每個玩法都包含一個異常狀態和一個等待狀態。異常狀態用來處理狀態機異常狀況，清理數據，保證優雅退出；等待狀態是牌局開始的第一個狀態，檢查牌局是否具備了開始的條件。
消息的處理流程
游戲的過程其實就是消息處理的過程，所有的消息會被封裝成TableMessage實例，推送到tableThread，后者再轉發給當前的State。
SwitchState消息一般是狀態機自己產生的；TimeOut消息是計時系統產生的；Request是來自客戶端的消息；Join雖然也是來自客戶端，但是特殊一點，要先交給匹配系統MatchSystem；
Kick消息一般來自Redis消息通道，用戶被封禁時產生；Quit消息是網關發來的；MagicCommand是內部指令，也來自Redis消息通道；Dummy是一個啞消息，無特別含義。
BigRoom
上面有一個模塊叫做BigRoom，這個模塊是玩法服務器與網關對接的模塊，同時初始化了玩法運行的一個上下文環境。由於歷史原因，命名不是特別好。