<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Mud客户端倒腾]]></title><description><![CDATA[欢迎自己倒腾mud客户端的一起沟通]]></description><link>https://forum.hellclient.com/category/13</link><generator>RSS for Node</generator><lastBuildDate>Wed, 15 Apr 2026 09:42:18 GMT</lastBuildDate><atom:link href="https://forum.hellclient.com/category/13.rss" rel="self" type="application/rss+xml"/><pubDate>Wed, 07 Jan 2026 12:46:47 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[自制Mud客户端开发-基础篇]]></title><description><![CDATA[大部分Mud玩家，在有能力制作一个可用的机器人后，都会起自己制作客户端的念头。让自己的机器人在自己的客户端里刷刷的跑，能给一个Mud爱好者带来极大的满足感。
在科技发展到现在，各种语言和框架层出不穷，电脑的硬件也极度丰富，外加AI技术的发展，写一个Mud客户端对普通爱好者已经不是一个遥不可及的事情了。
这系列文章，就是集合我在制作Hellclient时的一些心得体会，希望能给其他同好带来帮助。
而本文，个人希望，类似于武侠小说中的武功总纲，体现出大体框架，然后通过一篇篇细节文章，把整个自建客户端的关键点串起来。
首先，我们要明确，一个Mud客户端要解决几个问题。
我归纳下来，主要是以下几个方面

与Mud服务器的信息交互(telnet/ansi)
用户的快速工具(触发，别名，计时器)
合适的机器配置格式(比如变量)
脚本引擎
用户界面
扩展性

Telnet/ANSI库
telnet可以说是一个老旧的成熟的协议了。大部分的语言都有telnet库，没有telnet库的小众语言利用AI照着现成语言的库抄一个也不算难事。
对于Mud来说，主要是处理一些指令，和subnegotiation协议拓展出来的指令就行。
而ANSI的话，也是定义了另一套显示控制的指令。
从我个人经验来看，telnet和ansi的原始数据在客户端能应该需要一个中间模型(model),能快速的供界面渲染和引擎调用。有些客户端直接渲染，再从渲染完的结果倒过来取数据。个人觉得这样不好，会极大的增加脚本制作的复杂度。
触发/别名/计时器
这三个东西代表了一起机器主要要处理的问题:

服务器返回的响应
用户的输入
时间的流逝

对这个核心，我的思路也有过很多变化。就目前的思路来说：

客户端的触发/别名/计时器，应该从好用，易用的角度出发，让用户能很方便的添加临时功能。
脚本引擎应该抽象出 服务器交互/用户输入/时间层出来，不受客户端限制，不利用客户端的特殊功能。

当然，这只是建议，和一个状态下的想法。整体还是要根据你做客户端的目的来开发。
机器配置
在很多客户端里，变量是和触发/别名/计时器评级的概念。
从我的理解来说，并不是这样。
变量(机器配置)应该是和脚本直接绑定的。
按现代开发的概念，变量至少是 一个Config文件，决定了机器的启动设置。
如果是变量名对应变量值的形式，它更接近于环境变量 这个概念。
同时，个人建议，也是我Hellclient的做法，变量要有备注或注释的空间，可以让用户理解变量怎么使用。
脚本引擎
在真实世界中，嵌入式脚本引擎其实只有两个玩家，javascript和lua。
Lua是老牌玩家，各个语言都有lua的实现或者Binding,语法简单速度快。有可能的话建议使用luajit库，性能还是很不错的。
Javascript又是另一个话题。Javascript是目前使用最广泛的脚本语言，npm上有大量的js库。但嵌入js库不是很容易的一件事情。本质来说，js生态就是v8生态。但不是每个语言都能很容易的嵌入v8引擎。hellclient嵌入v8也是将一个半废弃状态的库进行了一定的魔改。还遇到了Windows下的msys和vc编译器兼容的问题。
所以，个人意见，能方便的用v8的(比如C#有微软官方ClearScript支持，建议一定要支持javascript,lua的话，建议都可以支持一下。
用户界面
就目前的现状来说，除非你使用特殊的技术栈或者技术，不然大部分情况下的软件开发都是跨平台，Windows/Linux/Mac全支持的。
具体到用户界面的形式，其实是3种
浏览器
浏览器形式的(主要是electron,少数如tarui会使用系统自带浏览器) 最大的优势是界面多样话，自定义方便，美观迅速。
缺点是非nodejs方案会多引入与浏览器的交互，性能有上限。而nodejs本身的单线程模型要改造的话工程量很大，强如微软也在vscode里堆了一堆C代码。
客户端
客户端的方案的话，其实主要是qt和skia 两个图形库的方案。qt基本绑定c++,不是那么容易上手(pyqt选手另论)。skia的话，有flutter/dart和avalonia/c# 两员大将，都是不错的方案。
客户端型界面最大的优势是性能有保证。缺点是实现美观/华丽的界面麻烦
无头模式
无头模式就是指提供接口，供网页/其他客户端显示。
理论上说，无头模式一般都会实现一个网页界面。
但他和网页界面的区别是，无头模式由于要支持多种终端，无法充分利用网页界面的华丽/可制定性强，在界面上有很大的妥协。
无头模式的特点是：
1.轻量级，可扩展性高，适合云端运行，通过网页/客户端/app等多种形式连接。
2.界面受限，需要维护多个程序。
Hellclient就是无头模式的客户端。
扩展性
扩展性其实主要就是3个方案

动态链接库(so/dll)
通过lua加载动态链接库可以很容易的对lua进行扩展。性能和功能都是最强大的。但同样的对开发人员的要求也是最高的，安全性上也容易出问题。
Com技术
如果你把自己局限在Windows平台，使用C++/C#开发，activex/com技术是极为强大的。mush本身除了lua的语言也都是通过activex来实现的。但com技术已经是一个事实上逐渐被非主流化的技术，不是很建议绑定的Com技术上
http/websocket技术
通过基于http的api 接口或者websocket实时调用。这个方案在性能上会有所损失，但同时有能够云化集群化的优点。Hellclient就是基于这种方案来提供扩展性。

我的建议
Hellclient是使用go写，采用无头模式，通过http/websocket进行扩展的。
如果让我从头来过，我可能会换成c#，因为go在windows平台下嵌入v8有点蛋疼。
我推荐的语言选型为

c# 综合的王者
flutter/dart 桌面/app全能
electorn/nodejs electorn也是目前桌面端很主流的选择
python web/pyqt方案 这个只适合自用，发布打包都太麻烦了

]]></description><link>https://forum.hellclient.com/topic/5/自制mud客户端开发-基础篇</link><guid isPermaLink="true">https://forum.hellclient.com/topic/5/自制mud客户端开发-基础篇</guid><dc:creator><![CDATA[jarlyyn]]></dc:creator><pubDate>Wed, 07 Jan 2026 12:46:47 GMT</pubDate></item></channel></rss>