基于 Linux 系统调用的联机贪吃蛇
背景
有一段时间对 Linux 特别感兴趣(现在也一直拿来当桌面系统),因此利用实验课的机会着手开发了一个小游戏,是一个可以多人联机的贪吃蛇游戏,看起来挺 low 的,但是涉及到了 Linux 课上所学的大部分知识,答辩后也得到了不错的结果。代码不是特别规范,下面强行分享一波。
完整代码
系统设计
蛇
蛇的保存结构为双向链表,优点是可以从尾部向头部遍历,在移动的时候方便修改尾部节点。
为了节省空间,我没有记录每一段蛇身的位置,而是记录了蛇头、蛇尾及每一个转折点,初始化时蛇只有蛇头和蛇尾。
1 | typedef struct Snake { |
每次移动时只需要增长头部及收缩尾部,当蛇转向时,需要新建一个头部,在收缩尾部时,需要判断尾部是否到达了转折点:
1 | /* 蛇的增长(头部) */ |
这种实现方法也存在缺点,在碰撞检测的时候会需要更多的计算量。
食物
食物的主体是一个点。
1 | typedef struct Food { |
食物每隔一段时间会出现在界面边界内的任意地方,食物对象有一个 count 域,每次时钟滴答会更新这个域,当达到 0 的时候就会重新刷新食物的位置(这个逻辑应该和以前玩的 Nokia 小板砖上的贪吃蛇一样):
1 | void food_locate(Food *food) { |
碰撞检测
凡是可以用方向键的游戏基本都少不了碰撞检测,贪吃蛇中涉及到的碰撞检测包括蛇对食物的、蛇与蛇的(包括自己对自己的碰撞)。
计算蛇是否与食物相撞,需要先计算出蛇在行进方向上的下个位置是否有食物,如果有食物则将食物的位置信息删除,并增长蛇体。
1 | /* 判断蛇是否吃到食物 |
计算蛇是否与蛇相撞,需要判断蛇头的下一位置是否与另一条蛇的一截身体相重合。
1 | /* 判断蛇1是否会撞上蛇2 |
代码里没有考虑到平局的情况,但这只需要多加几条判断即可。
通信
客户端和服务端采用 socket 方式通信,创建 socket 后会返回一个文件描述符,传输数据相当于向文件进行读写,一切都是文件,这也是*nix 哲学的一部分。一个 socket 由一个线程来控制,这样能够提高系统整体的效率,总共开启了三个线程分别操作三个 socket:
- login_sock,接收登录请求,并将蛇的 id 返回,每个客户端对应一个蛇 id,操作时需要将蛇的 id 传给服务端;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20/* 初始化蛇,并将最新的蛇id返回 */
void process_login(int fd) {
int id = -1;
FILE *fp = fdopen(fd, "w");
pthread_mutex_lock(&snakes_lock);
// puts("process_login locked");
/* 找出下一个可用id */
while(snakes[++id]);
/* 分配空间并传回其id */
snakes[id] = newSnake();
// puts("process_login unlocked");
pthread_mutex_unlock(&snakes_lock);
fprintf(fp, "%d", id);
printf("login: %d\n", id);
fclose(fp);
} - op_sock,接收用户的操作请求,更新对应蛇的属性;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29/* 读取操作,并调整对应的蛇
* id dir
*/
void process_op(int fd) {
FILE *fp = fdopen(fd, "r");
int id;
int cmd;
fscanf(fp, "%d %d", &id, &cmd);
// printf("snake %d move: %d\n", id, newDir);
fclose(fp);
pthread_mutex_lock(&snakes_lock);
// puts("process_op locked");
/* 接受命令(调整方向/退出),为什么要判断是否存在呢,
是因为服务端蛇死亡后,客户端可能来不及反应 */
if(snakes[id]) {
if(cmd == 27) {
printf("%d号蛇退出\n", id);
deleteSnake(snakes[id]);
snakes[id] = NULL;
} else {
snake_redir(snakes[id], cmd);
}
}
// puts("process_op unlocked");
pthread_mutex_unlock(&snakes_lock);
} - obj_sock,向客户端输出当前食物和所有蛇的位置,客户端接收后绘制出来,也就是说,客户端不会做蛇的运动等计算性工作,而只是将当前的画面画出来。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38/* 接受请求,返回食物和蛇的数据
* 第一行为食物,之后的是蛇,比如:
* x y
* id x y x y x y
* id x y x y
*/
void process_obj(int fd) {
FILE *fp = fdopen(fd, "w");
if(food->pos) {
fprintf(fp, "%d %d\n", food->pos->x, food->pos->y);
} else {
fprintf(fp, "-1 -1\n");
}
pthread_mutex_lock(&snakes_lock);
// puts("process_obj locked");
/* 蛇体 */
int id;
for(id = 0; id < MAX_SNAKE; id++) {
if(snakes[id]) {
fprintf(fp, "%d", id);
Body *head = snakes[id]->head,
*next = snake_body_first(snakes[id]);
fprintf(fp, " %d %d", head->pos->x, head->pos->y);
while(next) {
fprintf(fp, " %d %d", next->pos->x, next->pos->y);
head = next;
next = head->next;
}
fprintf(fp, "\n");
}
}
fclose(fp);
// puts("process_obj unlocked");
pthread_mutex_unlock(&snakes_lock);
}
Client 端与 Server 端的通信过程如下图所示。
线程同步
上面介绍的三种线程处理函数都涉及到了线程互斥锁的占有和释放(pthread_mutex_lock、pthread_mutex_unlock),主要是为了保证对蛇的并发操作的安全性。
异步非阻塞通信
前面提到的 socket 是一种同步阻塞的通信模式,在请求发起后,客户端和服务端需要等待直到数据传输完毕才能继续进行下一步操作,效率是偏低的。
同样的情况还体现在客户端接收用户输入的时候,代码里在实现客户端键盘输入时采取了异步非阻塞的模式,相对 getch 等阻塞方法来说效率更高,但是编程难度也更大。
现在登录多个客户端后,频繁地操作仍会有界面闪烁的问题,可以考虑将客户端和服务器之间的通信也换成异步非阻塞的模式。
界面
Client 端使用 curses 库来绘制界面,需要先安装 curses 库:
1 | sudo apt-get update |
上面第二个 curses 库是支持全角的,可以在画面上输出中文字符。
画蛇时需要遍历整个链表,每两个节点画一条线段。
1 | /* 画蛇 |
需要注意的是每次画完后需要调用 move(LINES - 1, COLS - 1)将光标移动到界面以外,然后 refresh()刷新界面。
总结
- 在*nix 中一切都是文件,包括普通的文件读写、socket、设备等,所以写 IO 程序是相对容易的,但是要注意选择适当的 IO 模型,可以考虑采用 select、epoll、aio 等方式提高通信效率;
- 规范很重要,项目应该遵循一定的结构(我没做好),应该为关键代码都加上注释,这样读起来会更方便;