在前面的教程中有说过服务端的数据需要转成JSON格式传输,这里进一步具体介绍一下怎么修改。
手机MUD开发和传统的MUD游戏最大的不同点就是前后端分离了,内容怎么显示,以什么样式显示是客户的事,服务端只用负责发必要的数据发送给客户端就好,不需要关注样式,但是需要给数据标记,方便客户端处理,我们有以下JSON格式发送数据:
{"code" : code, "data" :{"msg" : msg, ...}}
需要注意的是,MUD服务器发数据到客户端并不是一条一条的发,而是发送数据流,我们收到的数据并不是我们以为的一条一条的收,哪怕数据JSON格式化了,收到的可能是多条JSON连在一起,为了方便,我们可以把数据加一个结束符,如@@:
{"code":201,"data":{"msg":"重新连线完毕。"}}@@
{"code":20010,"data":{"name":"西大街","msg":"这是一条宽阔的青石板街道,向东西两头延伸。西大街是衙门所在,行人稀少,静悄悄地很是冷清。东边是一个热闹的广场。南边是一家扇庄。北边就是衙门了。"}}@@
{"code":20011,"data":{"msg":["north:衙门大门","south:西花扇庄","east:中央广场","west:西大街"]}}@@
{"code":20020,"data":{"type":"sys","msg":"【系统报告】连线精灵:小泥巴(mudren)由[1.203.173.114]重新连线进入。"}}@@
返回值说明
JSON格式的返回值code主要是方便客户端开发处理,可以尽可能的细化,具体客户端是否需要另说。以下只是简单的示例。
登录注册
| code | 说明 | 提示 |
|---|---|---|
| 200 | 系统普通消息 | 客户端无需显示 |
| 201 | 玩家登录成功或角色创建成功 | 加载游戏场景 |
| 202 | 系统提示消息 | 客户端提示用户 |
| 203 | ||
| 204 | 账户注册成功消息和角色未注册消息 | 加载角色创建场景 |
| 205 | ||
| 206 |
游戏场景加载
| code | 说明 | 提示 |
|---|---|---|
| 2000 | 对象被系统回收 | |
| 2001 | 生物对象移动到当前环境 | 客户端处理界面对象列表 |
| 2002 | 非生物对象移动到当前环境 | 客户端处理界面对象列表 |
| 2003 | 生物对象离开当前环境 | 客户端处理界面对象列表 |
| 2004 | 非生物对象离开当前环境 | 客户端处理界面对象列表 |
游戏场景消息
| code | 说明 | 提示 |
|---|---|---|
| 20000 | 一般消息 | |
| 20001 | 窗外景色 | |
| 20002 | 季节天时 | |
| 20099 | 弹窗消息 | |
| 20010 | 环境描述 | |
| 20011 | 环境出口 | |
| 20012 | 环境信息 | |
| 20013 | 环境指令 | |
| 20014 | 环境对象 | |
| 20020 | 聊天消息 | |
| 20030 | 战斗消息 |
MUDLIB修改
MUDLIB中要修改的地方并不是非常多,主要有几点:
- LOGIN_D 登录流程的调整
- look 指令返回内容的JSON化
- F_MESSAGE 默认消息的JSON化
- 其它指令和消息处理
LOGIN_D
因为常规游戏中我们登录注册流程是一条一条的发送指令互交,而在手机MUD上,我们应该一次性发送数据,这就需要修改LOGIN_D的处理。

因为LOGIN_D改动非常大,个人建议直接新建一个文件重写相关代码,比如APP_LOGIN_D,这里不再给代码演示。示例可参考:https://gitee.com/mudren/yhmud/blob/mapp/adm/daemons/app_login_d.c
look指令
look指令也是需要大改的,在移动端开发中look指令返回的数据都需要做格式封装,移动开发中有部分指令基本需要重写,我们可以新写一个app_look指令,处理数据。如正常游戏中这样的内容:
西大街 - /d/city/xidajie1
这是一条宽阔的青石板街道,向东西两头延伸。西大街是
衙门所在,行人稀少,静悄悄地很是冷清。东边是一个热闹的
广场。南边是一家扇庄。北边就是衙门了。
【寒冬】夜幕笼罩著大地,风沙刺骨。
这里明显的方向有 north、south、east 和 west。
需要重写look指令类似以下返回:
{"code":20010,"data":{"name":"西大街","msg":"这是一条宽阔的青石板街道,向东西两头延
伸。西大街是衙门所在,行人稀少,静悄悄地很是冷清。东边是一个热闹的广场。南边是一家扇庄。北边就是衙门了。"}}@@
{"code":20011,"data":{"msg":["north:衙门大门","south:西花扇庄","east:中央广场","west:西大街"]}}@@
F_MESSAGE 处理
游戏中基本所有消息都是通过message方法处理的,write、tell_room等其实都能过SEFUN用message统一处理了,对没有单独JSON处理的数据,我们只用在F_MESSAGE中统一做JSON封装即可,修改void receive_message(string msgclass, string msg)函数,类似如下:
// 消息格式封装
if (strsrch(msg, "code") < 0)
{
// 可增加判断
msg = "{\"code\":20000,\"data\":{\"msg\":\"" + msg + "\",\"type\":\"" + msgclass + "\"}}@@\n";
}
receive(msg);
其它消息
如常用的hp、score、skills,对这些指令的处理反而比较简单,以hp为例,在PC游戏中显示如下内容:

这本质上是做了显示格式处理的,而客户端MUD开发,我们不管处理,也不需要按这种内容返回,对hp、score等在客户端可以统一属性面板,我们只用写一个指令app_data直接返回玩家的dbase就行,代码如下:
list = ob->query_entire_dbase();
tlist = ob->query_entire_temp_dbase();
if (!spec || spec == "-d")
{
text = json_encode(list);
}
if (spec == "-t")
{
text = json_encode(tlist);
}
text = "{\"code\":20099,\"data\":{\"msg\":" + text + "}}@@\n";
message("data", text, me);
其它内容也一样,使用json_encode模拟外部函数,先mapping格式的数据根据需要转成json发送到客户端灵活处理。找到对应的功能模块即可,如战斗守护进程。