关于MUD图形客户端的探讨

yunlan

MUD图形客户端的讨论由来已久，这里发布一下自己的一些胡思乱想。


第一个问题是：我们需要怎样的图形客户端（下面简称为“图端”），或者换个角度来说，图端的适用性如何？
这个问题的一个选项是，一个通用于各种MUD，起码是各种中文MUD游戏的图端。另一个选项是，一个北侠专用的图端，至于其他MUD，能用也好，不能用也罢，不去关心它。
这是个很基础性的问题，因为不同MUD，有很多设置不相同，通用型的图端难度无疑要远大于专用型的图端。
我们考虑一个问题：其他MUD能否用这个图端，跟我们有多大的关系？
这么一想，一批人就会直接给出答案：做一个北侠专用的图端足矣。
且慢，还有一个很重要的问题没说：北侠专用的图端，这意味着，要开发一个全新的客户端软件，这个工程量可不小；而通用图端，意味着对现有工具比如MUSH的修改设置，工程量就小得多。
这么一说，又有另一批人会给出答案：那就只好用通用的图端了。
好吧，且慢again。。。用通用的图端，带来的另一个问题，就是需要对服务器进行大手术，就像wiz说过的，协议都需要修改，这个工程量……也不小。
现在的困境就是：要么通用图端：客户端小工程、服务器大工程；要么专用图端：服务器小工程、客户端大工程。似乎没有其他的选择了……
臭鸡蛋飞过来了：这也不行那也不行，让你丫的卖关子！
好吧，别打别打。我想说的是，不管怎么选择，要实现图端都不是件简单的事，哪种方案都可以，看wiz们怎么选择了。
这里想探讨的是专用图端的办法。下面就专用图端的方案继续分析一下。


第二个问题是：怎样解决协议的问题？
有wiz说过需要修改协议，其实我觉得在第一个问题答案的前提下，大可不必对协议动大手术，完全可以参考MXP的做法。
MXP其实没有对协议做太大的改动，只是在里面增加了一点东西，比如我们常用的福米，MXP做的工作主要是两点：
一是，在Login的时候加了一个MXP验证，也就是向客户端发送一条特殊格式的消息，消息格式大概是：
#27[1z support ...
#27是指ASCII码为27号的那个字符，用文本看不到。
支持MXP的客户端，收到这个消息之后会给予回复，服务器就明白了。不支持MXP的客户端，自然没有回复信息，服务器等待5秒之后没有收到回复，就按客户端不支持MXP处理了。
二是，支持MXP的客户端，服务器在需要发送福米图片时，就按照MXP协议发送特殊格式的消息，消息格式大概是：
#27[1z image FName=xxx url=xxx ... >
不支持MXP的客户端，服务器只好直接发送图片url地址，让客户端去处理了。
参考MXP机制，我们也可以定义一个PKUXKX MUD Graphical Protocol，简称PMGP。
在Login的时候，加一个PMGP验证，向客户端发一条特殊格式的消息，格式参考MXP，把里面的1z换成别的什么字符，我假定是2z。
有规定格式的回复，就是支持PMGP，否则就是不支持。当然，估计全世界就咱们自己搞的图端支持这个。
不支持的客户端不说了，一切照旧，该咋样咋样。
发现支持PMGP的图端，除了平常发送给客户端的文字之外，考虑参考MXP发送福米图片数据的方式，用特殊格式发送一些数据的客户端。比如：
#27[2z hp=1000 effhp=1200 maxhp=1500 ...
发送这个把hp数据发给图端，图端检测到收到 #27[2z 打头的信息，就知道了：哦，这是特殊信息，用事先约定的格式解读它，获取信息，然后不把它作为文字信息呈现给用户，而是刷新相应的图形信息，比如更新血条里的数据。
本来这些东西可以用hp或者hpbrief命令通过触发器解决，但是很显然通过触发器去解析的效率肯定是比不上图端内置的程序。这么做更重要的一点是为了解决下一个问题。


第三个问题：关于消息推送机制。
MUD现状，有一些信息是服务器主动推送给客户端的，不管客户端是否向服务器请求数据，都会收到此类信息。比如有人杀你，你就会收到XX想杀死你的信息。
还有一些信息是请求制的，除非客户端主动发送命令给服务器请求数据，否则服务器绝对不会主动推送此类信息。比如最常用的hp、sc、sk等等，你不输入命令，服务器绝对不会推送信息给你。
对于第一类信息，没有什么太大的问题，图端和zmud、mush都可以依照自己的规则处理。
而第二类信息，却是关系到图端成功与否的关键。
很明显，你在玩wow的时候，只要受到了伤害，左上角的血条是一定会扣血的，受到了治疗也必然会加血。
而对于图端来说，如果不改变机制，除非你主动向服务器发送hp请求，服务器是不会告诉你现在你的血量是多少，你的血条永远处于原有状态，这是绝对不能容忍的问题。
当然，你可以用定时或不定时的发送hp命令刷新血条数据，但是这又有一个问题，那就是你不知道该什么时候刷新数据。
刷新时间长了，血条不能真实体现实际情况，刷新时间短了，两次刷新之间状态没有任何改变，平白浪费了服务器的处理时间。
靠客户端的努力，最多是缓解，但是永远不可能从根本上解决这个问题。
所以这里就考虑到服务器需要动的手术了：当服务器端某个ID的状态进行修改时，比如调用id->set("hp",xxx)时，在类似函数中增加一个功能：当客户端使用图端时，主动向其推送一条特殊格式命令，比如：
#27[2z hp=xxx
于是客户端的数据就实现了与服务器的真实同步。


总结一下，用上述机制实现图端的工作机制：
1、客户端：需要设计全新的北侠专用图端，这个图端既要支持MUD客户端原有的各种功能，比如trigger、alias，又要支持与北侠服务器之间的PMGP。
2、服务器端：需要设计一套PMGP各种消息的格式，并增加Login时的PMGP验证；需要增加全消息主动推送机制，该机制非必需，但是增加该机制才能实现图端的完美化，不需要一步到位，可以逐步完善。


最后是风险预估：
1、客户端：无安全风险，最大的风险是工作量大，烂尾流产……
2、服务器端：第一个风险，全消息主动推送机制，可能给网络增加很多通信流量，估计可能有30%-50%，是否能够承受存在风险；
第二个风险，全消息主动推送机制推送的信息可能被其他客户端的Trigger利用，导致原有的一些控制机制失效。这个问题相对好解决，只要把主动推送机制推送的信息做一下简单加密，甚至都不用加密，只要做个转换，转换成无法被zmud/cmud/mush捕获的文字就OK了。图端因为是用内置程序而不是用Trigger来解析这些信息的，所以不会受影响。
其他风险……还在想。


因为手上关于MUD的资料太少，很多地方是靠想象的，纯供闲聊探讨。



北大侠客行MUD，中国最好的MUD

huye

顶

hijacker

都没有wiz来回复下这个帖子，看来图形化是不在日程上了

zgbl

都没有wiz来回复下这个帖子，看来图形化是不在日程上了
hijacker 发表于 2013-5-17 20:28

    发的位置不好，闲聊快板沉的太快了，我转了下位置

jason

都没有wiz来回复下这个帖子，看来图形化是不在日程上了
hijacker 发表于 2013-5-17 08:28 PM

    Idea is nothing, execution is everything!

dsleeper

`

sunyc

修改mush 是目前最好的方式  图形客户端 的含义不一定会要全部图形化 而是把信息流分开 比如说单开一个窗口显示 HP  等等  单开一个窗口显示聊天信息等等

sunyc

但是Mush这个维护者我跟他聊过 他对多字节程序不太懂 我还push了他半天才勉强把 utf-8 中文发送支持给加上了

jason

但是Mush这个维护者我跟他聊过 他对多字节程序不太懂 我还push了他半天才勉强把 utf-8 中文发送支持给加上了 ...
sunyc 发表于 2013-7-5 01:42 AM

    mush支持utf8啊

sunyc

回复 10# jason


  mush原来只支持 utf8 接受 不支持utf-8发送  后来勉强给加上了