Hellclient 社区

Hellclient是一款使用go语言开发为运行在vps上设计，支持javascript/lua脚本，通过websocket协议，通过web界面或者Hellclient UI软件访问的容器向Mud客户端。 项目地址为 https://github.com/jarlyyn/hellclient

Hellclient UI是一款由Dart/Flutter 开发的，支持Android/iOS/Windows/Linux/Mac等各平台的Hellclient客户端专用控制软件。 项目地址:https://github.com/hellclient-scripts

单例模式，是设计模式的一种。它是一种创建型设计模式，它的核心目标是确保一个类只有一个实例，并提供一个全局访问点来获取这个唯一的实例。 听着很牛吧？别管这个，这是被强OOP祸害的语言的鬼话。 单例模式本质就是，全局变量。 好了，使用lua的同学们放下手。全局变量不是你不用加local 来限制使用作用范围的意思。 单例可以通过全局变量来实现，但它强调的还是独一无二性，在英语里要加上the 定冠词那种(嗯，就是黑客帝国的the one)。 说明是一个特殊，独一无二的个体。 在代码开发中，很常见的一种模式是，将整个程序的功能，抽象成一个Applcation,然后建立一个全局单例 Applcation:Instance 来进行代码的开发。 在Javascript的管理，就是建立一个全局的app对象，Lua作为脚本语言，也可以适用这套模式。 那么，问题来了，我们为什么要用这个全局变量(单例)呢？ 限制其他全局变量使用。 使用全局变量，就是能方便的在任何代码里进行数据分享/互相调用。 有需要就开一个全局变量，看似开发能快很多，但很快就会让代码失去可维护性，随便动一个变量都生怕整个程序崩了。 当我们有一个特殊的全局变量后，很自然的，我们需要调用的东西都会从这个全局变量(单例上找)，不应该再开全局变量。 从这个角度来说，这个单例，就是我们整个机器人的the one 定义应用程序的根(root) 我看过很多全自动机器人代码。有一些，嗯，怎么说呢，让我感觉很乱，无从下手。 代码都是一个个平级的.lua/.js文件，互相之前会相互应用，要看很久才能推测出大概的功能划分。 按数据结构的说法，这些机器人的代码互相之间的关系是一个图(Graph),两两之间都可能有关联，很自由，很强大。 但对于我等普通人来说，难以驾驭。 相对而言，以我的能力，更能处理以数据结构的 树(tree) 的形式来组织的代码。 即从一个根room开始，不停分支，对应着一个一个的节点，和树杈一样。 我们在使用电脑时，最常见的树结构就是目录树，通过一个一个目录来对文件进行组织。 只有了一个固定的根，我们才能很容易的定义文件的代码的结构和组织结构。 给代码一个独一无二的挂载点。 上一个部分讲到了目录这个例子，那么我们扯远点说说Linux的文件管理。 linux下，讲究万物皆文件。不管你是设备，文件系统，文件，目录，都可以用mount的方式挂在到相对于根(root)目录的指定位置下。 那么，当我们使用单例App时，其实也是一样，把我们的代码/对外的结构，添加到单例和他的自元素上，就相当于做一个mount操作。 这时，每个挂载上去的代码，都成了一个单例(单例中的特定部分)，都能很方便的找到。 在一般情况下，可能这个优势还不明显。 在javascript和lua中弱类型的脚本语言中，很难精确的定位到一个代码的位置。 那么，你觉得在你的代码中，是找到一个较 room的变量在哪里定义使用方便，还是一个App.Core.Map.Room 方便呢？ 代码分组 还是文件目录的例子。 我们一般会怎么组织文件？ 先把全放桌面的豪放流请下去。最常见的，其实是是按文件的用途或者特点，分为 文档，视频，照片，作业，学习资料什么的。 同样，既然我们把单例作为文件数来使用，我们也可以把代码和数据进行分区。 比如，主业务逻辑可以放在App.Core.XXX下，代码可以放在App.Data.XXX下，工具函数可以放在App.Utils.xxx下 这样在写代码时，可以一目了然，方便理解和组织。 总结 对于代码来说，全局变量(单例)是必不可少的，但是太多的单例会让代码复杂度指数上升。通过定义一个合适的根单例，我们能更好的组织代码，提可高维护性。

大部分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方案 这个只适合自用，发布打包都太麻烦了

欢迎您访问Hellclient社区。 这里是Hellclient客户端及相关mud软件和脚本的沟通社区。欢迎在这里对Hellclient软件，和Mud相关的软件开发和脚本制作进行沟通。 在这里，我们会以下讨论的规范要求每一个用户 仅讨论软件的使用问题和Mud的技术问题。 不要对别的用户，Mud，和机器人进行评论。Mud本身已经是一个粉丝向的小圈子了，大家都是非专业的玩家，请互相保持友好。 由于 Mud 圈本身的互相借鉴和借用的现象很严重，所以本社区不支持任何资料的上传。有代码或程序分享的需要，请上传至github/coding/gitee等平台。 请不要分享破解或者攻击软件/服务器/游戏的经验。 尊重您玩的Mud的规矩，不要讨论和分享针对某个Mud使用，又不被Mud Owner允许的功能。 不建议使用您在游戏里的常用ID,把您在游戏的恩怨情仇蔓延于此。 热爱国家，遵纪守法，不违背公序良俗。 说的有点多，希望我们的社区能能给每一个访问者带来快乐和收获。