关于调试AI的闲话(1)

2011年7月7日 | 分类: AI分享 | 标签: , ,
(暂无投票)
Loading...

项目进行到后期,越来越多是在修复一些AI的错误和调整AI的行为,但不得不承认,AI有时候很难调试,我想主要是有两个原因,一是现在的引擎越来越复杂,改一点点地方,编译都会等很久,时间上效率不高(所以对于AI程序员来说,真的是非常欢迎那种引擎核心和游戏逻辑分开的架构);二是如果出现问题的话,情况不可重现,或者很难重现。由于以上原因的存在,我一直在考虑如何来改善AI的调试环境,并且使之模块化,以便在不同的引擎上可以重用。

就我上面的第一个原因,如果要提高调试AI的时间上的效率,减少编译次数是一个关键,最近听到有同事抱怨,说他们用的那个引擎,一编译就超过20分钟,不能忍啊!而AI代码里,除了逻辑部分,很多地方是一些可调整的参数,这些参数如果写死在代码里,每次调整,都要重新编译链接,那一天基本上干不了什么活了。所以有一个可以在运行时,动态调整AI参数的编辑器就很重要了。这种参数编辑器的实现方法有很多种,可以实现在同一进程中(随游戏弹一个编辑器出来),也可以通过进程间通信的各种方式,用另一个独立的编辑器来实现。

更进一步,这样参数编辑器的另一个作用,就是查看AI中的各种值的变化,也就是说这个编辑器变成了一个动态的观察器,可以实时的观察那些我们关心的数据变化,举个例子,比如在一般的RPG游戏中,有些技能会提高人物的属性,当这些属性是隐藏的,不会在UI中显示的,或者说UI显示部分还没完成的时候,就需要用到这样的观察器来观测这些属性是否正常的变化。

是编辑器,还是观察器,其实就是对AI中导出变量,哪方是只读,哪方是只写的问题(对于单个变量,不存在两方面都是只写的情况,要不就乱了:)),如果用代码来表示的话,我希望是这样的:

class AIExampleClass
{
EXPORT READONLY m_RDValue;
EXPORT WRITABLE m_WRValue;
}

我实现过一个用共享内存作为通信方式的模块,可以方便的在类中导出变量,并且在一个对应的编辑器里修改和观察。基本原理是,在游戏程序启动的时候开了一块共享内存,然后将内存分为头区域和数据区域,头区域存有所有导出变量的信息,数据区存真正的变量数据,当变量发生变化的时候(不管是从游戏端修改,还是从编辑器端修改),会将数据同步更新到共享内存中,保证两边的结果一致。

这样的做的好处是,由于是内存拷贝,所以同步的速度很快,变化很迅速,而且我封装了对于导出变量的声明,几乎可以做到和不导出时,对变量的使用方式是一致的,以实现对代码的改变的最小化,当然,这样的实现有一个缺点,由于对于编辑器而言,它看到的只是内存,所以需要对内存解析有个类似“协议”的声明,以保证正确地解析出变量的值,这个“协议”就需要和游戏的导出变量同步改变了。另外,对于“小型变量”,比如一个bool,这样的导出成本有点高,因为都需要有额外的头部信息。

有了这样的参数编辑/观察器,可以大大的提高调试AI的效率,当然,前提是,要积极使用!,以前我写过一篇叫《AI程序员的痛苦》,因为我们经常可以看到在AI代码中充斥着不知所谓的“魔数”(magical number),这样写起来是简单了,但对以后的调试,别人甚至是自己以后的维护,都是有百害而无一利的。现在,我很推崇这种对于AI参数的管理,希望对大家有所帮助!

先这些,以后再聊~

PS:关于上面说的那个共享内存的模块,我整理一下再放出,写的不好,仅供参考,如果有同学能帮着一起完善,就更是感激不尽了~~

————————————————————————
作者:Finney
Blog:AI分享站(http://www.aisharing.com/)
Email:finneytang@gmail.com
本文欢迎转载和引用,请保留本说明并注明出处
————————————————————————



发表评论 | Trackback | 已被阅读895次
目前还没有任何评论.

无觅相关文章插件,快速提升流量