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 |