前言:
对弈类游戏的智能算法, 网上资料颇多, 大同小异. 然而书上得来终觉浅, 绝知此事要躬行. 结合了自己的工程实践, 简单汇总整理下. 一方面是对当年的经典<<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要落地, 需要对算法本身做一些润色工作.