对弈类游戏的人工智能设计(4)——游戏AI的落地

这篇博文着重谈谈游戏AI落地的问题， 游戏AI不是追求AI的无敌性， 而是应该迎合不同级别的用户水平。 同时游戏本身的用户体验， 是需要游戏开发者， 好好思索和斟酌的。

案例反思:

案例一：

以前写过J2ME版的中国象棋(模拟器性能好于真机的幸福时代)。在模拟器上测试， 搜索深度设置为3，在时间消耗和智能表现达到很好的均衡，基本在2秒之内决策完成。

后来客户用真机去测试的时候， 反馈没有丝毫响应， 当时想: 糟了，是不是遇到了机器相关的问题? 后来再反馈的时候，说是等了80多秒，才走了一步。

这件事， 对我个人而言吸取的教训还挺大的， 有些参数不能基于经验来设置，对于不同机器和配置，需合理的选定配置值。

总而言之: 适配很重要， 不光在不同机器的分辨率上需要， 性能预估也需要。

案例二：

有次写完黑白棋， 一开始各种被虐(内心其实很挺开心的)。 在不断的尝试各种路线后，终于找到一种方式击败电脑， 由于电脑采用了静态评估函数， 每次选最优解。 导致电脑没有反馈能力， 一直在犯同一个错误。 这个问题让我(玩家)索然无味。 体验很不好。

由此可见， 在智能AI中， 需要引入模糊性， 或者说是不确定。

迭代搜索：

再解决上述问题之前，让我们先来讲讲迭代搜索的思路和实现方式。

迭代搜索逐步加深搜索深度， 进行博弈过程。
 

1. void negamax_driver(GameState S, int depth, Move best_move) {
2. // 负无穷 ~ 正无穷
3. (alpha, beta) <= (-INFINITY, INFINITY)
4. foreach ( move in candidate list ) {
5. S' = makemove(S);
6. value = -negamax(S', depth - 1, -beta, -alpha);
7. unmakemove(S')
8. // 博弈树第一层不存在alpha+beta剪枝, 用于保存最优解
9. if ( value > alpha ) {
10. alpha = value;
11. tmp_best_move = move
12. }
13. }
14.     best_move = tmp_best_move
15. }

复制代码

函数negamax_driver不同于negamax函数， 它是极大极小搜索的第一层， 其不存在alpha+beta剪枝， 而且用于保存实际最优的解。 因此单独抽取出来。
 

1. Move iterative_deepening_search(GameState S) {
2. // 定义best_move   
3. Move best_move
4. // 遍历深度, 从 1 逐步加深
5. for ( depth = 1; ; depth++ ) {
6. negamax_driver(S, depth, best_move)
7. // 判断是否满足退出条件, 一遍为超时判断
8. if ( timeout() ) {
9. break;
10. }  
11. }
12. return best_move
13. }

复制代码

函数iterative_deepening_search则形象描述了迭代搜索的整个过程， 逐步加深搜索深度， 然后调用负极大值搜索。 其中退出条件特别重要。 一般采用超时判断来作为退出条件的检测。

迭代深搜提供了一个很好的思路， 或许你会问: 迭代搜索不是存在很多的重复计算吗? 其性能会不会很糟糕吗?

其实不然， 我们简单算一笔账:
 

1. 假设F(n)为深度n的性能消耗, m为可候选步数.
2. 递推归纳公式为:
3. F(n+1) = m * F(n)(m 远大于2)
4. 对于单独进行深度为n的性能消耗为:
5. F(n) = m^(n-1) * F(1)
6. 进行1~n的迭代深搜性能代价为:
7. S(n) = F(1) + F(2) + ... + F(n) = F(n) * (1 + 1/m + .. + 1/m^(n - 1))
8. 幂级数的极限:
9. S(n) = F(n) * m / (m - 1)             (n 趋向无限大, m >> 2)
10. 结论:
11. F(n) < S(n) < m / (m - 1) * F(n)

复制代码

由此我们可得: 迭代深搜和一般深搜相比， 其性能多消耗的那部分， 基本可忽略。

自动适配：

对于案例一， 一种解决思路是: 引入一个带超时的搜索接口。 这样对于任何硬件(CPU， 内存)条件， 既能充分利用资源达到最好的效果， 又能保证时间适度的用户体验。

而我们在阐述迭代搜索的原理过程， 实际上提供了很好的思路去解决这个问题。

对于带超时的搜索方式， 原本的迭代加深代码框架， 手机游戏账号购买平台已能完成任务。 但其超时判断有些延后， 我们可以再做修改， 来精确控制超时。

(1)超时判断添加至函数negamax开头， 即深入到每个搜索节点上

(2)只要搜索节点判断超时， 就立即跳跃回调用顶层， 并宣告该深度搜索失败

1. bool demo(S) {
2. // 判断超时, 若超时返回 false
3. if ( timeout() ) {
4. return false;
5. }
6. // 任务拆分/过程递进
7. for (  successor S' in S  ) {
8. // 若遇到子调用汇报超时, 则立马返回
9. if ( !demo(S') ) {
10. return false;
11. }
12. // 正常业务处理
13. }
14. // 执行成功, 没有超时
15. return true;
16. }

复制代码

该代码框架， 演示了如何立即返回调用顶层的技巧。

(3)带超时的迭代搜索， 选择没有超时的最深高度求解的决策步， 作为最终的决策步。

模糊化：

一般的游戏AI并没学习模型， 用于反馈增强。 对于案例二的问题， 模糊化势在必行。

这边简单谈谈几种可行的方式:

(1)引入多套评估函数， 每次随机选择一种

(2)引入抖动， 在设置权重向量时， 可以随机微调个别因素权重值

(3)在决策过程中， 偶尔按概率选择 次优， 次次优， 甚至其他可行步

这些都是避免游戏AI固定化的一种思路。

总结：

本文讲解了对应案例一， 案例二的合理解决方案。 游戏AI要落地， 需要对算法本身做一些润色工作。

写在最后：

如果你觉得这篇文章对你有帮助， 请小小打赏下。 其实我想试试， 看看写博客能否给自己带来一点小小的收益。 无论多少， 都是对楼主一种由衷的肯定。