在很久以前, 指在那个连 AvZLib 都还没有的时代, 笔者就已涉足 AvZ 插件的开发. 从可能是历史上第一个"插件"的 AverageSpawn, 到融合了各类自用功能的 avz-more, 都是笔者所写.
从 avz-more 到 Simple AvZ, 很好地概括了笔者思考的变化. 一个插件不应该试图"涵盖一切", 无穷无尽地暴露接口, 而是有的放矢, 有针对性地解决需求.
从根本上而言, Simple AvZ 是观点化的, 也就是它有告诉你何为"好", 何为"坏"的倾向. 可是笔者不认为这是一件坏事; 恰恰是基于观点化的框架, 我们才能写出更简洁, 更可读, 亦即更优秀的代码.
以原生 AvZ 为例, 其重要倾向之一便是使用 SetTime 而非 WaitUntil. 后者也是 AvZ 自带的函数, 可许多小朋友连听都没听说过. 这并不是一件坏事.
Simple AvZ 立足于键控技术党的普遍需求, 针对"演示视频的脚本编写"进行了大规模的语法简化. 它推崇如下观点:
SetTime,Delay应完全不用或尽可能避免- 生效时机优于操作时机; 统一时间体系优于不统一
- 脚本的终极需求在短期是易写, 在长期是可读
前两点已在主要介绍里阐述. 对第三点, 在此作补充说明.
绝大多数使用场景, 也就是"演示视频的脚本"中, 脚本已经是依赖链中的最后一环. 例如, 在平常项目中我们不会随便定义 P, DD 这样又短又容易冲突的函数, 可在脚本中, 这种定义既简洁又易懂, 何乐而不为呢? 没有其他人依赖于你的脚本, 你的脚本已是最后一环. 这是一件很重要的事.
从长远角度看, 脚本最重要的需求是可读. 当别人看完你的视频后查看脚本, 或者 1 年后的你翻出自己 1 年前的脚本时, 你往往不是要对它大刀阔斧地改动, 而是查阅若干时机细节. 你不关心是不是每一个函数都前面都加了 AvZ::, 或是像 AvZ2 那样强制在前面加 A. 这些都只是框架, 是 boilerplate 而已, 你真正关心的是与游戏相关的实现细节. 我想, 这是大多数键控技术党都会有的共识.
从这个角度上说, 轨道语言天生是一个优秀的样板. 我们常常吐槽它既不科学也不精确, 可你是否曾想过, 市面上绝大多数键控脚本都比轨道语言难懂, 晦涩得多? 这是因为, 所有原生键控框架都基于命令式逻辑搭建. 它会反复问你"应该怎么做", 但玩家真正关心的是"应该发生什么".
关于 Simple AvZ 的一些思绪, 就先说这么多. 遥想 2018 年, pyvz 横空出世时, 还是由胡写的示范脚本, 可那样的时代已经过去了.
既然是键控技术党, 那么就以最符合键控技术党需求的方式编写脚本吧. 这是 Simple AvZ 想做的微小贡献.