写这个主要是备忘，供未来的自己用，而不是试图说服任何人任何事，只是简单陈述自己的想法而已。
最近几周，我整明白了PE的编译方式并开始使用，但说来也惭愧，这东西人家三年前就做好了，而且作者其实也并非消失不见，只是当年沉迷于打阵，是一点没想去研究这东西。（
现在我们已经看到了，在运行效率上PE完爆AvZ，拉开两个数量级的差距，也完爆任何基于原版游戏的框架。
在之前我们说，技术的发展高度，取决于【验证工具】的发展高度。例如，你想要研究砸率，那么必须要先有砸率的验证工具。在六代，由于这方面的工具不完善（基本是游戏内开极红自己测，和朴素砸率计算两种方法），前者大部分懒得做，后者虽然简单但错误百出，就导致砸率变成一团浆糊的黑箱。

PE的意义在于，在技术层面上，以后就再也不用开游戏了，毕竟所有数据相关的逻辑都在PE里，想干啥就可以干啥。
这使得我们有一个做【终极验证工具】的方法。也就是说，给定一种解法，可以直接丢进PE里跑，然后评估其各项稳定性。
诚然，在此之前，用AvZ跳帧可以做同样的事情，但这里必须再次强调，AvZ跳帧的效率只有PE的百分之一。以前跑10w次选卡，动辄要四五个小时（还是多开的情况下），但PE只需要几分钟，绝对是降维打击。

说到这里，就不禁有一个有趣的想法——要不要试图让AvZ脚本兼容于PE？
这个说法看似是有道理的。AvZ脚本源码是c++，是图灵完整的，亦即你可以写任何语句，包括非常复杂的自定义智能判断，上不封顶。只要你不嫌代码复杂（且写码水平高超），就可以写出复杂度极高的解法。目前最高复杂度的也就是无炮挂机，以及炮阵的挂机脚本。
但当你仔细一想，对于无炮和自然出怪炮阵而言，手写的代码真的就能解决问题吗？上次我写能跑70F的智能无炮挂机，就有1000行之多，而且其中还有三十多个bug，需要一一调试。这还是偏规则化的阵（通过C4-io强行把无炮当炮阵打），更不必说其它情况更复杂的无炮了。超多炮也基本是如此，如果要解自然出怪，那么要考虑的因素太多了，甚至需要根据出怪组合分类讨论。很多时候我们只能写出一个理论解，然后计算理论上的破阵概率，但是真要写成脚本就困难许多，更别说验证了。

这里其实就有一个复杂度的陷阱。脚本毕竟是要人一行行写出来的，那么一旦问题复杂（无炮或自然出怪炮阵），势必就会难以写出脚本。如果没有脚本，那PE再快再强，也就用不上了，不是吗？
所以最终来说，我们其实并不需要写一个兼容接口，让PE能接受【任意】脚本。我们完全可以只接受【只使用若干特定操作】的脚本，即用炮，用卡，智能用卡这三种，就可以覆盖绝大多数需求。如果有哪个阵解要用到比这还复杂的语句，那它的解法必然是极其复杂的，而这种复杂的脚本并不会成为主流。
所以对于PE，以后的发展目标就是尽可能完善seml。seml虽然不具备图灵完整性，但是它已经支持了最常见的操作（用炮，用卡，智能用卡）。以后就可以写出seml，一键评估相应指标（砸率，炸率），并且可能还可以附加生成AvZ代码（seml和 Simple AvZ 的语法是相似的）。

一个问题是，有没有必要加一个从AvZ代码转成seml的功能？我觉得没有。主要原因是，AvZ代码里可以包含任意内容，可以有许多奇怪的头文件，而且每个人有自己的写法。要分析这些源码的话，难度并不小，而且很可能转换出来的seml也有错误。由于seml写起来极其简洁，如果手里有旧脚本想要测炸率/砸率，那么自行写一遍seml，应该说是最合理的解法了。
另一个问题是，那更复杂的阵型怎么办呢？这其实就要说到，PE最大的意义在于它给了ML vs Zombies 一个机会。当然，要实现这一点，需要真正懂ML的技术牛人，但要真正解决【给定任意阵型，求最优解法及期望存活f数】这个终极问题，不用ML是不可能的。这背后的计算已经远超人类可及的范围，但现在有PE，就已经为ML铺好了路。
最后还是得声明，以上都是从纯技术角度出发的。阵仍然可以有其它表达，而且应该有其它表达，并非只考虑所谓技术。要不然就会做出针无尽那种食之无味的无聊作品出来。技术验证只是手段，阵才是目的。

最后多说一句。有了PE之后，AvZ的作用肯定会下降。应该如何看待呢？
说实话这是个伪命题。AvZ最初要解决的问题很纯粹，就是要ice3而已。至于其它地方的1cs精度，说实话大部分阵用不到。即使你要用到，也完全可以写一个拉长波长的脚本，确保录制成功率，并通过精确计算说明波长可以压缩至何种程度。
说到底，演示视频只是演示罢了。好的解法永远是好的解法，视频打得再“粗糙”又何妨。（反过来说，一个粗糙的解法，视频打得再精致又能怎样）。
之后有两个例外。一是挂机，一是测试。从技术角度上说，这两件事是混同的，都是反复执行同一段逻辑，确保在大样本下某种解法可行。这里最重要的推手是跳帧。如果没有跳帧而只是用游戏内20倍速，那么挂机也好测试也好都难以掀起什么波澜（观赏性挂机除外，但都说是观赏性了，自然和技术关系不大）。
但这说到底是权宜之计。虽然目前还没讨论出具体原因，但我们已经看到，AvZ和纯粹计算的效率相比有这巨大的鸿沟，也就是上文提到的两个数量级。这也不是AvZ的锅，而是原版游戏就这样，在目前技术下没有办法使基于原生游戏的任何框架跑得像PE那样快。有了PE，那么大批量数据测试的工作就可以从AvZ上撤走了，只用AvZ作为基础测试，确保PE在该项任务下没有bug，然后直接用PE跑就完事。
任何键控框架，自始至终的核心目标都是【2f演示视频】，这是始终没有变过的。至于你说要把AvZ弄得花里胡哨，加上一堆功能，还贯彻命名空间什么的，说实话我完全不关心。这些对于2f演示视频的作用太小了，还不如一个Simple AvZ来得实在。甚至你可以说不用Simple AvZ又如何。确实不会如何啊，我在2021年写了一共177个AvZ脚本，当时也没什么Simple AvZ，就凭一个avz_more不也全部搞定了。
这也是为什么我之前说，如果seml要支持AvZ，那么很可能只支持AvZ 1. 因为在我看来，AvZ 1 已经是 fit for particular purpose，之后再加什么功能都改变不了这一点。要写更复杂的脚本（如无炮挂机/自然出怪解法），靠键控框架是不够的，这点本文上面已经讨论过了。不妨一说，16年的testla最开始做无炮键控的时候，是用lua的协程，和今天的思路一模一样（什么遥遥领先）。但是最后不还是要往ML上发展，毕竟协程写得再好也无法真正做到泛用性的挂机（更无法证明哪个解是最优的，毕竟那种代码调试难度是地狱级的，你怎么证明是代码水平不够高，还是解法本身不够好？想想就头痛）。所以每个工具有每个工具的意义，做好自己的分内事就可以了，don't try to solve all problems with one solution.

/阿狸飞过

顶。

顶。