在《关于调试AI的闲话(1)》，我谈到了一个AI参数的编辑/观察器，用来实时的修改和查看参数，重新审视那篇博文的时候，我发现我还有些需要补充的地方。
首先，我遗漏了一点，就是需要把调试后的参数信息保存下来，然后当游戏中的那些导出的变量初始化的时候，需要把那下存下来的值作为初始值赋给相应的变量，当然，这样一个文件的保存，载入包括赋值的过程，没有很大的技术难点，作为补充，记录在这个地方。另外，我说的这样一个调试器，是一个相当轻量化的解决方式，很独立，可以很容易作为额外的工具，嵌入已有的引擎，当然，正如我在前一篇文章里所说的，它存在这样或者那样的缺点，所以，如果复杂一点话，可以做的更好，比如用反射（Reflection）的解决方案，将AI中用到的物件（Object）或者类整个导出，现在很多引擎都或多或少用到了反射，并提供了强大的可视化编辑器来支持。这样的解决方案和引擎的契合度会很大，挺难独立的剥离出来（当然，也不是不可能）。
好，前面说的是对AI参数方面的调试，另外一种比较流行的方式，是实时的远程命令。通过向游戏引擎发送指令，来使其运行一段预定义的代码，不知道大家有没有玩过CS，CS里面有一个命令控制台，它预定义了一系列可以使用的命令，比如，addbot，votemap等等，这种以控制命令来调整的方式，其实可以非常好的用在AI调试中，而且也是一个非常独立，和轻量化的模块，同样，也是可以用同进程（如CS），或者不同进程的方式来实现，对于不同进程，用网络传输的方式传递命令字串，是一个很方便也很好的办法，因为网络的关系，甚至可以做到跨机器调试。技术上来说，这样的远程命令难点也不是很大，无非是对命令字串的解析，将函数导出成命令的封装。
AI的调试的麻烦之处，很多时候在于编译的速度（如果你有i7+8g内存，那你很幸运），所以上面说的两种方案，都是为了最大化的减少编译次数，但是，在改变AI逻辑的时候，还是不得不重新编译和link游戏，所以，我觉得，作为一个AI程序员，如果在项目起初，如果拿到引擎很“干净”（没有任何游戏逻辑代码），如果引擎没有提供脚本支持，一定要强烈建议做一套脚本化的AI引擎（不一定是全脚本化，但一定要考虑内嵌脚本），原则上来说核心引擎和AI是可以完全分开的，核心引擎部分，在某种程度上，对于AI程序员来说，可以是完全透明的，只要给我一个tick入口，我就能写AI。:)。随便说一句，暴雪在脚本化方面做的很好，玩过星际，魔兽的人应该都会有这样感觉，他里面的AI都可以通过外部的方式来改变，确实很强大。其实仔细想想，我们为什么不可以呢？也许我们有时缺少的就是这种对于标准，规范的坚持吧。所以经常我会想，如果有幸我能面试新人，我不会要求你了解多少，知道多少，或者会多少诡异的算法，我会很看重他/她写代码的规范程度，清晰程度，这是会对整个team有益的。
有点扯远了，:)，总结下，对于影响AI调试的原因一（见前一篇），我想有以下几点能够考虑
- 使用脚本化的AI引擎，将AI逻辑与核心引擎分离
- 将需要调整或者观察的参数导出，做成一个运行时的参数编译/观察器
- 添加远程命令调用
- 升级你的电脑到i7+8g内存
好，先写到这里了，下次聊聊对于原因二的一些可以考虑的事情
相关：
————————————————————————
作者：Finney
Blog：AI分享站(http://www.aisharing.com/)
Email：finneytang@gmail.com
本文欢迎转载和引用，请保留本说明并注明出处
————————————————————————