一段时间前从朋友那听来的关于一个RPG游戏外挂的制作方法，因为很有意思，所以总念念不忘，想着哪天必须记下来。
这个外挂是这样的：侦测游戏画面上显示着角色HP量/MP量的某一点的颜色值，若颜色值从一个方向改变（可以脑补比如从红/蓝到灰），说明血量低于一个界限了，这时外挂就会自动输入加血指令；如果反向变化，则不作任何动作。
以前从来没考虑过游戏外挂的做法，所以这是第一次听说外挂可以照这个思路来做。我觉得非常有趣，因为这是一个不知系统内部逻辑，单单对其最终输出进行处理，从而得到下一步输入选择的依据的情境。
其实现在想来，外挂就是部分地代替了人眼和人脑和人手。监测血量并决定是否加血的逻辑，对人来说实在太简单了，交给低级但也不容易出低级错误的计算机多好。
不过其实我的重点不是自动化的问题，而是这种拆解系统的方式。游戏系统内部的逻辑某种程度上说也算是个黑匣子，但不管怎样，为了完成整个游戏的过程，它就必须要为人留下输入和输出的接口，这样人机才能共同构成一个完整的游戏系统。这个外挂的思路利用了这一点，它的野心并没大到将系统内部的逻辑全部破解再加以利用，而只是简单地把握系统的部分输出（游戏图像上的点的颜色值），并设定简单明确的逻辑去进行输入，从而让人可以从这小块简单的流程中解放出来，将能力发挥到更复杂更有意思的东西上面。这简直就是模块化思想的范本。
接着我想起了前段时间在Coursera上的一门MOOC——The Data Scientist’s Toolbox 中了解到的，在数据科学中，我们对于数据所进行的分析和研究，可以按分析目的（或者说是最终结果）的不同划分为不同的类型，相应的难度也会不一样。其中最简单的是Descriptive Analysis（直译「描述分析」），目标只是去描述你所见到的数据；最难的则是 Mechanistic Analysis（直译「机制分析」），目标是充分理解产生这些数据的系统，其中每一个个体究竟发生了哪些变量的变化，而这些变化又究竟造成了哪些其他变化。在这两极之间则是其他几种分析类型的位置。
容我想个比较简单但或许不大恰当的例子，比如我看见一只梨子（大脑接收到了一些关于它的数据），Descriptive Analysis只需要我确切记下它的形状、颜色、大小等，Mechanistic Analysis则要求我弄清楚这只梨子为什么具有这样的形状、颜色、大小，以及形状、颜色、大小之间具有怎样的关系（比如梨子的大小变了，形状和颜色会变吗），此外对于这个梨子是如此，那么换一只梨子以后，我们之前的结论（我们所建立的模型）还会是正确的吗？
理想状态下我们当前希望能够得到Mechanistic Analysis级别的结果，希望能从一次飓风中清晰地、精确地捕捉到一只蝴蝶的飞舞，但是现实情况往往是，我们所能掌握的信息永远是极为不足的。比如刚才的梨子问题，光凭眼睛看能得到的数据实在是太少了；即使我们到了现在这个数据产量超大的时代又怎样呢，数据倒是多起来了，从中提取到信息的难度也变大了。这种时候，我们一定需要控制起自己的贪欲，步步为营。
此外，有时当我们衡量过投入产出以后，会觉得一个问题研究到某个深度和广度就已经能满足我们的需要了，就像那个游戏外挂一样。这时，我们当然更应该明智地把剩下的资源用在其他刀口上。
想要较好地解析一个问题系统，当然需要「打破沙锅问到底」的集中力与恒心，但我们需要一直提醒自己：在粗糙的现实之中，我们所要解决的问题必须得有一个边界，这个边界让我们不致于在深挖隧道的过程中失去了回来的路径。解析的第一原则，便是要带有限的结果回来。这是我们不得不面对的一个极限。
PS. 这里是The Data Scientist’s Toolbox里关于分析类型的PDF，里面也有一些用以说明的例子，有兴趣的话可以瞧瞧：
https://d396qusza40orc.cloudfront.net/datascitoolbox/lecture_slides/03_01_typesOfQuestions.pdf
