游戏辅助开发系列之一如何设计一个游戏辅助

程序员王马

已于 2024-04-22 22:55:07 修改

阅读量2.5k

点赞数 35

分类专栏：游戏辅助文章标签：游戏

于 2023-12-13 00:49:35 首次发布

本文链接：https://blog.csdn.net/m0_72813396/article/details/134961571

版权

游戏辅助专栏收录该内容

14 篇文章 10 订阅

订阅专栏

本文探讨了游戏辅助的设计原理，包括游戏操作的分类、机械臂、鼠标宏和软件辅助的特点，以及如何通过脚本和硬件设备实现信息识别和动作反馈。作者强调了设计时需站在开发者角度，并解答了一些常见问题。

摘要由CSDN通过智能技术生成

一. 游戏中的操作

开发游戏辅助之前，先来对游戏的过程进行一个分类和汇总。我们简单将游戏分为回合制游戏和即时类游戏两种类型，其中回合制是指玩家在游戏中有一定的来回型行为的游戏，例如曾经的石器时代、梦幻西游等；即时类游戏则是玩家以处理突发状况为主要游戏手段的，例如CS或者魔兽之类的。

这里我省略了游戏本身的讲解和分析，直接来说结论：所有的电子游戏本质上会分为“信息识别“和“动作反馈”这两个主要的机制组成，很多复杂的机制，例如副本、打团等都是有这两种简单的机制无限重叠形成的，这一部分重叠我们可以理解为游戏的实际控制流。

那么游戏中的操作就会被划分为三类: 一类是信息的识别，包括图像、文字、声音这三类；一类是动作反馈，包括鼠标和键盘的动作；第三类就是如何让游戏辅助去将游戏进行下去。

在制作游戏辅助的时候，要站在游戏开发和策划的角度来看，只有这样才能更好的理解游戏为什么这么设计，以及如何将我们的设计下沉到编码中去。

这里额外的引入两个概念，状态和闭环。

状态(status)是一个事物的抽象概念，例如游戏的角色可以有多个状态，游戏任务也可以理解为多个状态等，对状态的更新会引发不同的控制流。

闭环(loop)则是描述控制流的，无论进行什么操作，我们都将描述成一个封闭的循环，例如副本，我们可以理解为进入副本前将角色的状态进行更新(补充角色的HP和MP)，然后进入副本执行完流程，在离开副本前再次将状态进行更新，这就形成了一个闭环。

二.游戏辅助的形式

目前游戏市场主要是手游和端游，它们分别对应Android和Windows平台，但是游戏辅助的开发平台和游戏的平台并没有很强的关联性。

目前我主要研究过三种游戏辅助，分别是机械臂辅助、鼠标宏辅助、纯软件辅助。它们分别用于不同的场景，这里我们从设计的角度先来看看这三类辅助的特点。

机械臂辅助的问题在于成本，它属于物理挂，也是这三类中成本最高的一种，原因在于它几乎完全使用电机和摄像头来分别进行“动作”和”识别”，这两者带来的硬件成本会比较高！我曾经在市面上见到过5000+的五轴机器人，它搭配了一个500万像素的相机，5个步进电机以及一套6轴的控制卡，当时我第一反应是这个要多高的利润才能支持这种东西商业化，然而后续发现事实证明这玩意真卖出去了，并且还卖了几百套，果然这个世界非常疯狂。

但是机械臂带来的最大好处就是，它在根本上规避了检测，这个思路是非常重要的！因为游戏厂家如果仅仅在游戏本身技术上，是没有办法检测到真实世界中的机器人的！当然游戏厂家使用了行为类检测，可以在一定程度上对抗机器人辅助，毕竟机器人和真人终究是有差别的。

鼠标宏辅助的问题在于它将辅助摆在明面上了，通过对鼠标行为的重载，它可以实现很多短时间内复杂的鼠标键盘操作，但是鼠标宏本身属于摆开卖，这也意味着它明牌被检测的概率非常大。

鼠标宏辅助本身相当于将机器人辅助中的电机部分和控制部分省略了，毕竟用机械臂控制鼠标键盘和直接在鼠标键盘的层次上开发是一码事，甚至很多鼠标宏脚本集成了对图像的采集和处理，所以可以理解为鼠标宏辅助是将机械臂辅助成本大幅度降低的一种辅助。

软件辅助本身是更激进的辅助，鼠标宏是建立在物理鼠标上的，软件辅助则更进一步，毕竟在操作系统层面上，操作来源于机械臂、鼠标宏、软件都不重要。

这里还有另外的层次，有人魔改了虚拟机，然后让游戏在虚拟机中运行，在虚拟机之外去输出鼠标和键盘的控制，从而也实现了对游戏进行物理隔绝的方案。

三.如何设计游戏辅助

当了解了常见的游戏辅助的特点之后，我们就可以开始来设计游戏辅助了。

下面这张图会从始至终贯穿开发过程:

无论哪一种类型的游戏辅助，都可以在逻辑上分成思维/视觉/行为三个主要的模块，视觉中枢和行为中枢会作用与反作用于计算机/手机。

在接下来的讨论中，我们分别使用脚本(思维中枢)、HID设备(行为中枢)，Cam设备(视觉中枢)，因为它们正好是最终模块封装的结果，行为中枢部分无论使用机械臂还是鼠标宏，最终都是归结到HID设备的输入，其它两个部分也是一样。

a. 游戏辅助的动作反馈(HID设备)如何设计？

由于我们用什么办法最终还是会落实到鼠标键盘操作上来的，所以我们直接看鼠标键盘的行为就可以了，它的行为被分为移动、左键、右键，键盘的行为则是N个快捷键的组合。

鼠标到PC的最终传输的格式如下:

1. 鼠标发送给PC的数据每次4个字节 
BYTE1 BYTE2 BYTE3 BYTE4 
定义分别是： 
BYTE1 -- 
       |--bit7:   1   表示   Y   坐标的变化量超出－256   ~   255的范围,0表示没有溢出  
       |--bit6:   1   表示   X   坐标的变化量超出－256   ~   255的范围，0表示没有溢出  
       |--bit5:   Y   坐标变化的符号位，1表示负数，即鼠标向下移动  
       |--bit4:   X   坐标变化的符号位，1表示负数，即鼠标向左移动  
       |--bit3:     恒为1  
       |--bit2:     1表示中键按下  
       |--bit1:     1表示右键按下  
       |--bit0:     1表示左键按下  ；

BYTE2 -- X坐标变化量，与byte的bit4组成9位符号数,负数表示向左移，正数表右移。用补码表示变化量 ；

BYTE3 -- Y坐标变化量，与BYTE1的bit5组成9位符号数，负数表示向下移，正数表上移，用补码表示变化量 。

BYTE4 -- 滚轮变化。

2. 键盘发送给PC的数据每次8个字节

BYTE1 BYTE2 BYTE3 BYTE4 BYTE5 BYTE6 BYTE7 BYTE8

定义分别是：

BYTE1 –

|–bit0:   Left Control是否按下，按下为1

|–bit1:   Left Shift  是否按下，按下为1

|–bit2:   Left Alt    是否按下，按下为1

|–bit3:   Left GUI    是否按下，按下为1

|–bit4:   Right Control是否按下，按下为1

|–bit5:   Right Shift 是否按下，按下为1

|–bit6:   Right Alt   是否按下，按下为1

|–bit7:   Right GUI   是否按下，按下为1

BYTE2 — 保留位

BYTE3–BYTE8 — 这六个为普通按键

如果使用机械手的方式，那么最划算就是触摸屏，那样的话根本不需要考虑如果构造鼠标消息，因为触摸屏本身就会生成鼠标消息，只需要保证正确的执行move行为和push行为即可。

如果使用HID设备的方式，那么还是需要额外填充鼠标键盘结构的消息的。

在后面的代码示例中，我们可以看到如何设计和实现它们。

b. 游戏辅助的信息识别(Cam部分)如何设计？

1. 图像识别:

可以使用Opencv库，目前我是用的是opencv 2410版本，可以使用更高的版本；

2. 文字识别：

可以使用tessract ocr,也是一个开源文字识别库；

3. 图像采集

可以使用VirtualCam，这是一个用于将图像和视频转换的库，这个库是我自己写的，后期会开源；当然，如果是端游，那么可以直接截屏；如果是在Android上的手游，那么也可以使用一些截屏工具；另外更加硬核的方式就是直接使用相机进行图像采集。

在视觉信息识别中，最难的反而是机械手方案的相机采集，这部分其实是人为增加难度，要保障使用物理相机能精确的拍照很困难，这里我的方案是使用屏幕镜像来绕过，目的是得到图像，而不是非要拍照获取。

所以对于PC我额外封装了截屏的代码，对于Android则是直接使用屏幕镜像的方案。

检测和定位使用OpenCV即可，实际上我们不需要非常高深和清晰的检测定位方案，毕竟从游戏设计的角度看，不可能设计得太复杂，当然这事情也有例外，就是在即时战斗中，识别会是一个难题，因为即时战略的速度太快了。

四.常见的问题解答:

1. 是否一定要使用脚本语言？

答案是否，其实使用python之类的语言主要是编码会不是那么复杂，但是本质上来说，如果是机械手和纯软件的方案，那么可以使用应用程序的方式来开发，没关系的，游戏公司不可能跨越物理设备来取证的。

但是python确实也有优点，就是熟悉的人会做起来很快。

2. 能否直接给一个可以用的？

不行，我很不希望我花很多时间开发的辅助随便就放出来，可以按照步骤一步一步去设计，但是我本人并不是买卖游戏辅助的，也不鼓励大家买卖。