我将之命名为 ratel,对,没错,平头哥,就是这么霸气(怂
在发这篇主题的时候,ratel 还在开发的最后阶段,已经完成了基本的交互和游戏环节,有待优化,这里放出技术栈:
项目地址:https://github.com/ainilili/ratel
整个流程不难,首先,我需要将客户端和服务端搭起来,netty 提供着简洁的 api,可以快速的部署服务端和客户端,所以这个环节没有任何难度!一个简单的结构图如下:
通讯这一块搞定,接下来要思考的问题就是如何进行互动,这个问题将会引发出更深层的问题?
作为一个正在开发的项目,更多的难以解决的疑难杂症还等待着我去发现,本帖也将持续更新至 ratel 完结。
针对于以上问题的思考之后,我决定将数据持久化在内存中(要考虑 jvm 会不会 gc 掉,所以这里使用 final 修饰 static ),服务端抽象出Room - 游戏房间
,ClientSide - 客户端信息
和Poker - 结构
这三个最主要的数据结构,网路逐渐变得复杂起来
详细结构如下
Room{ Client{ Poker{
int 唯一标识 int 唯一标识 int 大小
int 状态 int 房间标识 int 花色
map 客户端字典 str 昵称 }
list 客户端列表 list 手持牌
int 地主标识 int 状态
int 地主牌 int 类型(农民|地主)
struct 上次出手的信息 client 下手
int 上次出手人 client 上手
} }
每当一个客户端连接时,将会构造一个 Client 对象,分配一个唯一的标识供服务端识别,Room 由客户端建立,并且在此基础之上,其他客户端可以加入已创建且状态未满的房间,当游戏开始后,将会为房间中的所有客户端派发 Poker。
这种流程看似可行,按照这种模式,ratel 由 0 走到了 1
但 ratel 的重点并不止于此,各种问题(网络,安全,用户体验等)还有待解决。
ratel 开发完毕之后,大家工作之余偷偷开心一下,命令行下划划水。
根据大家的建议,对ratel的出牌方式做了一些修改,以及新增客户端退出或者异常断开的应对方案。
新的出牌规则: 3 -> 3 4 -> 4 5 -> 5 6 -> 6 7 -> 7 8 -> 8 9 -> 9 10 -> T/t/0 J -> J/j Q -> Q/q K -> K/k A -> A/a/1 2 -> 2 S(小王)-> S/s X(大王)-> X/x
例如如下牌:
Poker: ┌──┐──┐──┐──┐──┐──┐──┐──┐──┐──┐──┐──┐──┐──┐──┐──┐──┐──┐──┐──┐
│3 |5 |6 |6 |7 |8 |8 |9 |9 |9 |10|J |Q |Q |K |K |2 |2 |2 |X |
│♥ |♥ |♠ |♣ |♣ |♣ |♠ |♦ |♣ |♥ |♥ |♠ |♣ |♥ |♦ |♥ |♠ |♣ |♦ | |
└──┘──┘──┘──┘──┘──┘──┘──┘──┘──┘──┘──┘──┘──┘──┘──┘──┘──┘──┘──┘
出牌的输入是:
56789 t jqk
则输出是:
Poker: ┌──┐──┐──┐──┐──┐──┐──┐──┐──┐
│5 |6 |7 |8 |9 |10|J |Q |K |
│♥ |♠ |♣ |♣ |♦ |♥ |♠ |♣ |♦ |
└──┘──┘──┘──┘──┘──┘──┘──┘──┘
56789 t jqk
将会被解析成{'5','6','7','8','9','t','j','q','k'}并发往服务端进行命中判断及出牌
最后上图
101
XiLemon 2018-11-07 23:22:09 +08:00 via iPhone
👍🏻
|
102
khxu 2018-11-08 10:49:44 +08:00
666 楼主的想法真的很活跃
|
103
iamniconico OP @khxu 想着划水玩
|
104
q397064399 2018-11-08 14:40:38 +08:00
@iamniconico #92 是不是发错了..
|
105
wsstest 2018-11-12 15:37:51 +08:00
|
106
iamniconico OP @wsstest 加群一起玩 948365095
|
107
sybrave 2019-01-14 15:39:11 +08:00
插眼
|