Notice
寫得亂得一比，將在腦子清醒的時候重構
文檔
API文檔
文檔可以看這里，正常情況的文檔已基本穩定，異常情況的文檔還沒寫
如有問題，可以留言或CC我
游戲通信方式和流程
客戶端服務端采用HTTP請求的方式進行交互，客戶端可以通過開局接口開局或加入並抽牌，並通過出牌提交接口出牌，然后本局等待結算。客戶端可以立即開下一局。
設計考慮
原考慮和存在的問題
原本我是考慮設計一個實時進行牌局的對戰平台，湊夠四個人開局，發牌，2秒(或其他考慮RTT的合理時間)內出牌，然后服務端判牌，結算，整個過程實時進行，大家同步。
但是這樣存在一些問題。首先就是湊夠四個人開局，由於結對，我們的用戶基數只有六十幾個，讓大家在同一時間一起運行客戶端，是不太現實的。其次，實時傳輸和結算會給服務器帶來很大壓力。而且這樣也不方便測試和Debug。其中最主要的還是大家的上線時間的問題。
當前考慮
考慮到福建十三水一局游戲中每個人出牌只依賴於他所拿到的牌，且他看不到別人拿到的牌，直到結算。這樣，當一個客戶請求開局時，服務端可以先尋找他可以加入的戰局，找不到則創建，發牌，拿到出牌，保存。直到這局湊夠人數進行結算。客戶也可以一直開局，一直出牌，符合AI的能力。
這樣，將兩個過程解耦合，不但可以解決實時性的問題，還能在一定程度上解決性能問題。判牌和結算邏輯可以抽離出去，可以設計成在本局最后一個玩家出牌時運行，也可以設計成周期性運行，還可以通過消息隊列或其他"Fire and Forget"連接。由於我們的服務端不可避免的需要經常重啟，這樣的設計也可以解決臟數據（半完成的宏觀事務）的處理問題。妙啊
玩法
玩家客戶端登錄后，可以不斷請求開局接口，然后提交出牌，這些出牌會被記錄並在合適的時候結算。客戶端可以獲取戰局歷史和歷史詳情，並通過這些數據在圖形界面上回放牌局。詳見API文檔。
FAQ(Maybe)
認證問題
認證使用session機制和Header域的方式，API文檔里帶有Authorization這一節的接口均需要認證。認證的方法是在請求的HTTP頭部添加一個名為X-Auth-Token的字段，值為登錄接口返回的對象中的token字段的值，或者響應頭中X-Auth-Token字段的值。
開局數量問題
為避免未完成的牌局過多，同時考慮服務器的並發壓力，限制每個玩家未完成牌局數量。如未完成牌局過多，會被拒絕開新的局，但仍然能加入戰局。也就是說，當你未完成牌局已達上限，且沒有其他你可以加入的牌局的時候，開局接口失敗。
PSP
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 40 | 40 |
| Estimate | 估計這個任務需要多少時間 | 40 | 40 |
| Development | 開發 | 405 | 1070 |
| Analysis | 需求分析(包括學習新技術) | 75 | 60 |
| Design Spec | 生成設計文檔 | 60 | 120 |
| Design Review | 設計復審 | 60 | 200 |
| Coding Standard | 代碼規范(為開發制定合適的規范) | 60 | 120 |
| Design | 具體設計 | 120 | 210 |
| Coding | 具體編碼 | 0 | 180 |
| Code Review | 代碼復審 | 0 | 60 |
| Test | 測試(自我測試,修改,提交修改) | 30 | 120 |
| Reporting | 報告 | 70 | 80 |
| Test Report | 測試報告 | 20 | 20 |
| Size Measurement | 計算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后總結並提出過程改進計划 | 40 | 50 |
| 合計 | 515 | 1190 |