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

前言:
　　对弈类游戏的智能算法, 网上资料颇多, 大同小异. 然而书上得来终觉浅, 绝知此事要躬行. 结合了自己的工程实践, 简单汇总整理下. 一方面是对当年的经典<<PC游戏编程(人机博弈)>>表达敬意, 另一方面, 也想对自己当年的游戏编程人生做下回顾.
　　承接上三篇博文:
　　(1). 评估函数+博弈树算法
　　(2). 学习算法
　　(3). 博弈树优化
　　这篇博文着重谈谈游戏AI落地的问题, 游戏AI不是追求AI的无敌性, 而是应该迎合不同级别的用户水平. 同时游戏本身的用户体验, 是需要游戏开发者, 好好思索和斟酌的.

案例反思:
　　(1). 案例一:
　　以前写过J2ME版的中国象棋(模拟器性能好于真机的幸福时代).在模拟器上测试, 搜索深度设置为3,在时间消耗和智能表现达到很好的均衡,基本在2秒之内决策完成.
　　后来客户用真机去测试的时候, 反馈没有丝毫响应, 当时想: 糟了,是不是遇到了机器相关的问题? 后来再反馈的时候,说是等了80多秒,才走了一步.
　　这件事, 对我个人而言吸取的教训还挺大的, 有些参数不能基于经验来设置,对于不同机器和配置,需合理的选定配置值.
　　总而言之: 适配很重要, 不光在不同机器的分辨率上需要, 性能预估也需要.
　　(2). 案例二:
　　有次写完黑白棋, 一开始各种被虐(内心其实很挺开心的). 在不断的尝试各种路线后,终于找到一种方式击败电脑, 由于电脑采用了静态评估函数, 每次选最优解. 导致电脑没有反馈能力, 一直在犯同一个错误. 这个问题让我(玩家)索然无味. 体验很不好.
　　由此可见, 在智能AI中, 需要引入模糊性, 或者说是不确定.

迭代搜索:
　　再解决上述问题之前, 让我们先来讲讲迭代搜索的思路和实现方式.
　　迭代搜索逐步加深搜索深度, 进行博弈过程.

void negamax_driver(GameState S, int depth, Move best_move) {
　　// 负无穷 ~ 正无穷
　　(alpha, beta) <= (-INFINITY, INFINITY)
　　foreach ( move in candidate list ) {
　　　　S' = makemove(S);
　　　　value = -negamax(S', depth - 1, -beta, -alpha);
　　　　unmakemove(S')
　　　　// 博弈树第一层不存在alpha+beta剪枝, 用于保存最优解
　　　　if ( value > alpha ) {  
　　　　　　alpha = value;
　　　　　　tmp_best_move = move
　　　　}  
　　}
    best_move = tmp_best_move
}

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

Move iterative_deepening_search(GameState S) {
　　// 定义best_move	
　　Move best_move
　　// 遍历深度, 从 1 逐步加深
　　for ( depth = 1; ; depth++ ) {
　　　　negamax_driver(S, depth, best_move)
　　　　// 判断是否满足退出条件, 一遍为超时判断
　　　　if ( timeout() ) {
　　　　　　break;
　　　　}	
 　　}
 　　return best_move
}

　　函数iterative_deepening_search则形象描述了迭代搜索的整个过程, 逐步加深搜索深度, 然后调用负极大值搜索. 其中退出条件特别重要. 一般采用超时判断来作为退出条件的检测.
　　迭代深搜提供了一个很好的思路, 或许你会问: 迭代搜索不是存在很多的重复计算吗? 其性能会不会很糟糕吗?
　　其实不然, 我们简单算一笔账:

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

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

自动适配:
　　对于案例一, 一种解决思路是: 引入一个带超时的搜索接口. 这样对于任何硬件(CPU, 内存)条件, 既能充分利用资源达到最好的效果, 又能保证时间适度的用户体验.
　　而我们在阐述迭代搜索的原理过程, 实际上提供了很好的思路去解决这个问题.
　　对于带超时的搜索方式, 原本的迭代加深代码框架, 已能完成任务. 但其超时判断有些延后, 我们可以再做修改, 来精确控制超时.
　　(1). 超时判断添加至函数negamax开头, 即深入到每个搜索节点上
　　(2). 只要搜索节点判断超时, 就立即跳跃回调用顶层, 并宣告该深度搜索失败

bool demo(S) {
　　// 判断超时, 若超时返回 false
　　if ( timeout() ) {
　　　　return false;
　　}
　　// 任务拆分/过程递进
　　for (  successor S' in S  ) {
　　　　// 若遇到子调用汇报超时, 则立马返回
　　　　if ( !demo(S') ) {
　　　　　　return false;
　　　　}
　　　　// 正常业务处理
　　}
　　// 执行成功, 没有超时
　　return true;
}

　　该代码框架, 演示了如何立即返回调用顶层的技巧.
　　(3). 带超时的迭代搜索, 选择没有超时的最深高度求解的决策步, 作为最终的决策步.

模糊化:
　　一般的游戏AI并没学习模型, 用于反馈增强. 对于案例二的问题, 模糊化势在必行.
　　这边简单谈谈几种可行的方式:
　　(1). 引入多套评估函数, 每次随机选择一种
　　(2). 引入抖动, 在设置权重向量时, 可以随机微调个别因素权重值
　　(3). 在决策过程中, 偶尔按概率选择 次优, 次次优, 甚至其他可行步
　　这些都是避免游戏AI固定化的一种思路.

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

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