我是从写游戏脚本入的编程这行(图)

我是从编写游戏脚本开始编程的

明天翻翻旧照片，翻到下面这张：

故事要从2012年开始，我大二的时候，梦想是把手机卖给迪信通。我的爱好是玩手机、刷系统、美化主题、参观峰会等等，还加了一些奇怪的东西。奇怪的群体。一天下午，看到群里有人说：“有谁会写手动脚本吗？请大家合作，一起启动DNF！”

DNF 我知道，游戏脚本基本没说过。当时我还不知道怎么回事，于是反手回了一句：“我会的！”想到当时侯唯一的编程经验就是在高中计算机课上用VB写了一个加减乘除估计器。 . .

过了一会儿，一个现在看起来不那么主流的头像闪了出来，没错，就在这里！不记得打开小窗后我们聊了什么，但现在想想生活真的很奇妙，一系列看似无关的事情，无关的人把你引向了一个在当时似乎是自己选择的人几年后才想起的高速公路，感觉就像一部电影，但进度条在那里。

以后，我会日夜加班，边学习边做。可能我天生就是为此而生的。在这个过程中没有乏味或痛苦。如果您不知道问题所在，请发布它。去群里“求专家”。而且我很内疚，直到现在，虽然我没有认真读过几本编程书籍，也受不了，但我还是学习了新的语言。新框架的套路是：

先使用它，如果您不知道它，请检查它。听起来这种形式只是简单的口味，但我有一些完美主义强迫症。我已经养成了对每一个我不太了解的问题都追问到底的习惯。如果我看到一个新的句型或新特性，我一定会思考它的使用场景，并在以后的代码中尽力使用它。它，即使回到以前建造，也是我的另一个学习技能。所以时间长了，自然会变得“有经验”吧？

废话太多了，题外话。最终，经过3个月的艰苦奋斗，取得了如下成果：

主程序共有 17958 行代码。之所以记得这么清楚，是因为强迫症会保留他写的所有代码。

看！这个神奇的编辑器，这个神奇的句型，相信有的老同事会认出这是当时轰动一时的键盘精灵（重点不应该在代码上，尴尬..）。键盘精灵支持的语言是vbs，而vb 唯一的编程经验居然用==，你说魔术不魔术！

现在是时候谈谈开头的图片了。这是他们当时合作的 DNF 工作室的一个角落。你见过裸屁股纹身的阿姨吗？涩会银！只是看着你当场修复错误，如果你不能修复它，你就当场杀死它！哈哈，开个玩笑~当时我看到满屋子的机器，都在运行自己的脚本，屏幕上的反派都像勤奋的黄蜂一样不停地工作，更不用说兴奋了！

不过，如此庞大的脚本对于键盘精灵来说实在是不堪重负。平均而言，机器上每分钟都有脚本失败。如果有分歧，程序会崩溃，游戏会冻结。当时还没有更好的技术手段来解决这个问题。我们不得不编写另一个脚本来监控主脚本并在主脚本或游戏崩溃时重新启动它。但可悲的是，监控脚本也崩溃了！于是我用VB写了一个程序来监控脚本。 . .

嘿，我哭得太多了！谁让我们不知道当时外界有这么多好的语言和平台，而我们却选择了键盘精灵！

我说的越多，我离题的越多，所以让我们保持简短！没多久，天语就出来了，之后基本上所有的工作室都开始换位了，和我们的合作很爽。还有一点值得一提的是，当时比特币刚刚流行起来。那个时候，我哥们怂恿我挖了一块我的。除了被我严词拒绝之外，我什至劝他不要这样做！直到现在我已经没有脸再联系了。 . 啊，生活！

文字

我已经在大大小小的公司从事网络后端工作近 4 年了，它已经成为一种天生的语言。这也是一个无聊的下午。走完流放之路，越来越空虚，越来越孤独，越来越累！这么灵光一现，既然累了，不如写个手工脚本来放松一下？键盘精灵肯定不会再是按键精灵了，这辈子都不可能再打开了，更何况我已经掌握了世界上最好的语言。那么为什么不依赖 Node.js 并让手动脚本来解决问题呢？去做吧！

首先，我在网上搜索了相关的仿制药，头很痛，但我真的不喜欢它。想想手动脚本需要的一堆API：图像和颜色识别、键盘和鼠标操作、系统命令等，自己实现所有这些真的是一个巨大的工程。于是我盯着桌面上的沙漠插件，傻笑。 . .

等等！什么是沙漠插件？为什么盯着它傻笑？

如果你做过中学数学课代表，你肯定知道：当文章中出现一把枪时，哪怕只是一笔一划，它也一定会射出箭来，否则作者就不用提了它根本没有。嗯，所以这只是我对文学手段的高超使用，导致以下内容无影无踪：

沙漠插件有哪些？

老同事一定知道，插件本身的名字甚至盖过了它当时所依赖的各种手动脚本平台，比如： 、Easy 、VB（它不是脚本平台），在事实上，它很有名！它实现了一整套与手动脚本相关的 API，所以让我告诉你，它支持你能想到的一切！所以开始考虑让节点调用它的方法！

首先它是一个用C语言编写的dll插件，规格是COM。好的，关键字完成：。所以在微软之后，我就知道可以用winax来调用了！太好了，天作之合！

然后就是它：dm.dll！没有技术浓度，只是封装。更有意义的是，它们结合在一起，放下它们，对国家和人民来说都是一件好事！哈哈哈哈，先把文档过一遍吧~顺便给个star吧？

如何编写游戏脚本？ （干货）

有现成的插件，代码怎么写就不多说了。这里主要分享一些老脚本工作者的经验。

游戏脚本不比显存好，甚至比不上数据包，基本处于行业厌恶链的最底层。但优点是：安全！因为它基本上只能做和真人玩家一样的事情，但它不怕吃苦，不怕疲劳，可以一直工作。因为没有飞行瞬移之类的特技，所以通常不会被禁止。即使我剃了一半，也很容易上手。 . .

后面不说业务能力，它本身的原理也有自己的不足，就是基于图像颜色识别和键鼠操作会带来两个问题：

首先，让我们谈谈第一点。比如现在游戏的角色，我想知道它有什么样的武器。如果人们需要打开武器栏才能看到它，那么脚本肯定也是需要的（这里我不讨论通过显存/本地缓存读取）。拿），即使因为武器栏太花哨不规则而打开，基于彩色文本的识别方法也会太复杂而被丢弃。

之后的第二点不可控是因为大量的键鼠操作会受到网络波动、客户端卡顿等外部诱因的影响，导致操作失败或失效。例如，如上所述打开武器栏。有些游戏支持快捷键。你调用命令点击鼠标，但是这个时候，可能有人突然给你发抖窗让游戏窗口不活动，也可能是客户。如果终端卡住一段时间，会导致按键指令无法正确触发武器栏的开启；即使没有快捷键，比如点击某处的图标，也可以打开。如果您阻止这种图标，您将永远无法点击它，甚至无法点击广告。 . .

所以，除非你的脚本代码可以覆盖所有场景，否则不可能仍然是粗体。基本上运行一段时间后就原地不动了，不然直接死机死机。

那么明白以上两点，虽然可以对症下药，但如果不能做到完美，也可以做到相对完美。我们还是一点一点的说：

信息获取

假设您要获取的信息是：地面上的这种武器属于哪里？ （配饰？腰带？耳环？等）。人类实际上可以通过外观识别物体，但脚本不能。愚蠢的做法是收集所有武器的特征信息，比如相对位置的颜色，或者简单的截图，来硬识别。万不得已尽量不要这样做，有三个坏处：

一个好办法是先研究一下游戏本身的交互，比如拖拽物品到公屏，公屏会显示物品的描述文字，然后通过文字识别就可以了；或者将物品拖到人物属性面板，面板上人物的对应部分会亮起，然后你可以通过识别对应部分的特征色来做到这一点。

另外，假设你现在想手动打怪物，但是游戏中的怪物都是色彩斑斓的3D炫酷模型，根本无法通过特征来识别。那么这个时候我们就去机器学习吧！只是在开玩笑。 . 虽然可以动脑子的游戏源文件。去游戏的安装目录多看一下，一般会找到游戏的贴图文件，想办法解压dnf自动喊话脚本，然后稍微了解一下dx脚本就好了，再改贴图就好了！给所有的怪物染上一种颜色，如果没有特征，我们将创造特征！如果找不到，或者无法修复怎么办？那么回到游戏本身，想想是否可以借助个别职业的特性来增加杀怪难度？比如选择无脑AOE，能过地图吗？无法再次读取内存！ （这是又一个新坑，小心！

今年我在写《流放之路》的剧本时，有一个需求：我还想控制角色刷机时拾取的物品类型。但是爆品这么多，靠硬鉴定肯定是不现实的。于是研究了一下这个游戏的设置，发现客户端本身就支持物品过滤器，那种过滤方式可以转化为动态改变物品过滤器文件，然后在设置中重新加载。

我想到的还有几点：

看不懂图认图，看不懂字不认字

此操作费时费力。 它们中的大多数可以转换为识别某个点，或者改为多个点的颜色。举个反例：比如要判断角色是否死亡，不需要识别死亡后游戏弹窗的图片dnf自动喊话脚本，只需要找一个基本没有颜色的区域即可改变，比如顶部的操作栏，只有当死亡弹窗出现时，弹窗的颜色会因为弹窗的阴影而改变。然后就可以直接比较操作栏某个位置的颜色了。

认不出来就别认出来

这看起来有点夸张，你怎么都认不出来呢？这里的意思可能是，很多识别似乎是通过估计计算出来的，不需要进行必要的识别操作。比如要判断人物的包裹是否满了？先说一个刁钻的方法：你可以不假思索地捡起一个物品，捡了很多次后发现它还在地上，那么你就可以间接推断出包裹是满的。在这里识别仍在地上的物品通常比直接识别包裹本身更简单。

但是，前面的方法只是一个小技巧。让我们深入思考一下：假设所有物品的取放操作都是由脚本完成的，那么理论上每个取放操作和包中剩余条带的数量都应该“记在心里” 有数字”，所以最极端的做法是脚本连试都不用，捡到最后一个就知道包满了！

其实这无疑会降低很多编程复杂度，追求程序本身的人也算是一种高级的尝试。让我在这里吹嘘。那个时候流放之路的变态物品系统，每个物品的大小不一致，包裹被分成多个页面，有些页面只能装特殊物品。为了节省空间，许多物品需要通过拖动来放置。复杂的操作（必须有足够的空间放置，放置的位置要保证尽可能少的空间，但是拖拽的动作对于脚本本身来说是一个极不稳定的操作），虽然我已经设法让脚本“会了” “，哇！

示例不可控

虽然脚本的所有行为都可以体现为：行为+反馈。

比如你现在想打开武器栏，那么你的行为是：点击i，反馈是：武器栏出现。 ok，那你可以根据这个封装一个行为反馈方法：

do(task, until)

对于每一步操作，行为和反馈都是严格确定的，用do方法调用，task代表行为，until代表反馈，那么前面的需求可以是这样的：

// 直到 800, 750 的坐标处出现某个颜色（装备栏出现），都不停地执行点击 i
async function openEquipment() {
  await do(() => keyPress('i'), () => isColor(800, 750, '#ffffff'))
}

其实可以为以上方法设置一个通用的延迟，设置最大重试次数等。其实每个操作只要严格遵守这个基本规范，组合起来就不怕不稳定了。

据我所知，脚本圈的很多程序员只是在每次操作前自动延迟一个经验值来提高稳定性，甚至在延迟旁边复制一行操作。我听说这将获得稳定性增益。 . .

上一部分可以看成是局部稳定性优化。如上所述，它仍然没有涵盖所有场景，并且您的 do 函数很可能会卡在某个地方。 所以让我们再想一想，既然无论如何都无法涵盖所有​​场景，那就无视它们吧！直接按照一切正常的方式写你的脚本，然后用全局控制的思路来处理所有的异常场景！

这不是废话。不能覆盖，不代表不能监管。所有异常实际上都可以表示为我的正常操作在预期时间内没有得到正确的反馈。基于此，我们来封装一个高级框架！它用于调度所有本地模块。一旦卡住了一定时间，或者主动放弃治疗（比如你在do函数里面设置了最大重试次数，只要超过重试次数，就会被视为异常） 这样主控程序会直接重启游戏，或者将游戏强行拉回可控场景，然后从场景中重新执行本地操作逻辑，理论上可以做到稳定大胆。

ok，又一个武器：wow-state——为游戏手动脚本量身定做的状态机，是整个脚本的“调度中心”。虽然是基于 Node.js 的单线程，但你也可以“同时”测量角色的血槽、掉落物品、游戏状态等来触发不同的操作。脚本的主框架部分：

清晰、简洁、优雅！

除了编写游戏脚本之外，您还能做什么？

请看下面的录像机：

传说中的羊绒！嘘~

那我们可以做点严肃的事情吗？

请阅读下面的录像机：

这是我以前做过的生意。要求是：我希望手动创建一个陌陌群，然后分享二维码。所以我写了这个脚本来支持分布式工作。可以和N个脚本一起工作，闲着没事就建个群玩，生成二维码随时待命！除非请求量太大，通常场景可以像请求普通数据一样实现，用户没有感知。他们很难想象这个二维码背后有多少技巧！啊哈哈哈哈~

所以能够编写手动脚本是一项额外的技能，它也带来了解决问题的新思路和新方法。但。 .

如果一个需求太复杂而无法实现，往往是需求本身就有问题……

相关工具