碎碎念

游戏测试过程中，使用GM（GameManager）是再正常不过的一个操作。

测试用GM功能与魔兽争霸在全局聊天输入"Who Is Your Daddy"，GTA系列调出控制台输入各种CheatCode的功能相比，本质上没有区别。

他们令游戏内容的执行变得更加简便，继而提升整个游戏表现效率。作为一个玩家，使用GM或是各种作弊方式，多数是为了更加新鲜、爽快甚至猎奇的体验；而作为一个游戏测试或者游戏开发者，GM只是在测试调试过程中，为了绕开纷繁复杂的交叉逻辑或避免机械化的操作而做的金手指。

别再觉得咱们是在玩游戏了~ QAQ

在接下来的文章里，我主要的内容是谈谈自己对GM指令的见解以及项目过程中的经验，而不是游戏安全方面（作弊/反作弊）的睾端话题，所以对游戏安全感兴趣的同学，让你们失望了，是小王太弱了！

GM的应用场景

GM主要的应用场景，主要可以分为两类：1.游戏开发场景；2.游戏运营场景

以下是针对应用场景的分析脑图，抛砖引玉：

开发环境

针对开发环境，GM的主要目的是为了便于游戏的功能验证和调试。

所以当使用GM时，测试人员必须是确认GM并不会影响自己的测试需求。比方说：本次测试需求本身需要验证通过“新的交互功能流程”，完成任务获奖。这时候你再去用GM指令直接完成任务并获奖，就不对了。

大家可能会觉得这也太笨了。这个例子本身有些极端，而作为测试，你需要风险意识，不仅是对开发人员，开发过程，甚至是你自己。扯远了。

介于GM指令的特点（集成各种游戏操作，可以绕过正常游戏流程繁琐的逻辑限制），关于搭建游戏的自动化测试，为了实现玩家的各种自动化行为，很大程度上可以依赖GM功能。

运营环境

而针对游戏运营场景，GM功能更多的是去支持网络游戏在营期间针对玩家们的一些公共行为。比方说违规行为的禁言，封号，周期更新的全局邮件奖励，以及针对可预测的游戏事故做一些技术或运营层面的应急处理功能。这方面主要会让服务器程序及运维等职能去实现。

GM使用方式

说完了GM的应用场景，再来给大家介绍一下GM功能主要使用的一些方式

①控制台指令执行

这种方式是游戏测试职能的常用GM使用方式，也是我个人比较习惯的使用方式。

简而言之，这种执行方式就像是文章开头所说的“WhoIsYourDaddy”，在游戏测试环境下，打开特殊的控制台。输入设定好的指令“WhoIsYourDaddy”，即可你操控的单位即进入人挡杀人佛挡杀佛的状态；或是像最基本的AddItem，加上物品ID和数量，AddMoney等等顾名思义的指令，在游戏测试过程中再稀疏平常不过。

指令执行的好处是：一旦你熟练使用，介于指令的灵活属性，你能轻松地定义和执行更多且复杂的GM参数和操作。在开发环境甚至你想要实现的游戏环境下，你就像一位全能的法师，不断地吟唱着各种咒语让你在游戏内呼风唤雨。

②集成按钮执行

某些项目或是情况下，集成按钮执行也相当受欢迎。

因为它更加无脑，只要你会调出控制台，然后认识控制台按钮的文字并且点击按钮即可实现你想要的操作。

按钮执行几乎是开发环境下能够做到的最傻瓜的GM执行方式

它很方便，你甚至不需要去背指令信息，只要你能够理解按钮上写的是啥！

但是当指令量变大，或是想要去定义更加复杂的GM内容时，控制台琳琅满目的按钮就变成了累赘，按钮难以支持个性化参数，你不得不针对各种新的参数需求去反复的添加冗余的按钮。在这时指令执行的优势便体现出来了。

③WEB端搭建GM平台

在WEB端搭建一个功能完备且使用便捷的GM平台，通常是为了不熟悉游戏开发环境运营职能者而开发的一个运营向GM平台。在此不赘述。既然到了WEB端，你可以把它作为一个新的工程对待，只是这个工程需要与游戏工程的内容相互对接。

在网易工作经历时，有位服务端大佬似乎是一个人搭起了当时参与的项目的完整GM平台（不限于运营向的功能，开发用了都说好），相当牛逼。比如：对应服务器/客户端实时LOG，玩家信息查询，GM执行平台，客户端镜像等等。

GM指令执行框架开发经验

简单介绍下背景

服务器和网络这块的知识过于贫乏，我做不到如大佬完整的搭建起一个强大的GM功能平台的行为

不过最近因为众所周知的原因，得以接触新项目的GM功能，并且尝试进行了一系列客户端工具级别的优化。

项目主要是基于Unity插件SRDebugger的Console，制作一系列GM按钮，按钮执行各种GM/调试功能，在我用时我已经觉得按钮令人眼花缭乱；虽然也支持指令输出，指令是用Switch..Case去判断执行的，且指令只支持客户端GMRPC相关的功能，指令相当稀少。总之就觉得没有之前的好用，也不便于扩展（习惯用那套东西了....罪过）。所以以此为理由，下定决心，尝试做一些优化，几乎没有对工程插件以及旧有代码进行删除或改动，而是在此基础上去优化一些代码逻辑，便于指令执行以及之后的GM功能拓展。

对比

简单介绍一下优化前的GMConsole情况：

SRDebugger插件本身是一个功能很强大的Unity Console插件，可以利用这个Console快速了解当前硬件的基本信息（System），获取实时的客户端LOG（Console）以及客户端性能数据（Profile），同时支持在Console内部自定义Console界面及功能（Options）

插件文档：http://www.stompyrobot.uk/tools/srdebugger/documentation

当时已经定义好的GMCommand类放置了各种GM功能，但绝大多数都使用按钮去执行，按钮量已经远远大于上面的图的数量，说实话这个广告图的按钮已经看得我有些不适了。

虽然支持指令执行，但指令执行时，指令执行的区域同样是混在这一群按钮中间。

而在优化后，我重新梳理一下代码以及交互的逻辑及表现：

首先，通过新建GMAttribute和GMUtils类彻底解放switch..case模式下，理论上无止尽的case数。

利用C#反射机制，在GMUtils中进行：

1.分析并整理GMCommand整体信息

2.分析玩家指令，并处理指令信息

3.根据分析情况决定实际GM的执行逻辑和表现

GMCommand专心的去做GM相关的功能细节，可以支持GMRPC的协议发送，也可以支持纯客户端的一些操作，GM功能、GM指令以及自动化测试之间变得更加的灵活

对SROptions的界面使用/排版也进行了优化，指令执行可以独立于整个Option界面外，相对的更加的整洁且易用，也根据SRDebugger本身支持的功能尽可能优化指令的执行方式。

实现的新功能

满足多参数指令（基本功能优化）

“指令 + 空格 + 正确的参数1 + 空格 + ..... + 正确的参数n”的指令格式，选择发送指令，即可执行需求的GM指令操作（优化，正则做的比前人稍微复杂一丢丢罢了）

增加新的GM指令的行为本身变得更EZ了，继续吐槽Switch...case的局限性

参数均为可选参数（存在默认值）时，可以不输入参数，直接执行带参数的指令

GM指令可以重载（P.S：重载时同参数数量但参数类型不同的情况，目前不支持，不要这么做QAQ，也不支持大小写不同导致的重名重参，简直痛苦。）

在Unity环境下，Ctrl+G可以在本地桌面生成并打开一份当前工程最新版本的“GM指令文档.html”，即便不记指令，说明书总会用

缺陷，或是仍待优化的点

由于SRDebugger的功能局限，难以实现用户输入智能匹配的功能。所以为了折中，目前支持追溯前十条发送过的功能。

重名重载相关的BUG点

可以考虑向大佬学习，搭建平台？估计得请服务器吃饭了，所以是我想多了QAQ.......

大家可以帮我想想，写了好久，有些没耐心了。就这样吧。

唯一能确认的则是自己的渺小。以上均为抛砖引玉，甚至微不足道的一些工作经验之谈。