— AI分享站

Archive
AI分享

自开博以来,经常会有网友发信给我,询问一些关于AI方面的问题,一般我都会尽力一一回答,也希望我的这些经验,对网友有些帮助,我想,有些问题可能是大家都会有的,所以,这一次,我会把一些网友的提问,和我的回答列在这个地方,供更多的同学参考,也欢迎一起讨论,才疏学浅,不吝赐教。

Q:你好,我在你的博客上看了你的一些关于行为树的文章,写得很好,让我受益匪浅。我想实践一下怎么用,在网上找了一个相关的库libbehavior(https://code.google.com/p/libbehavior/),想用这个库做个小例子,它里面有一些演示程序,但牵涉到很多库,不好学习,我就想将一个简单的状态机示例程序源码改成用行为树实现,发现还是很茫然,不知道你是否有空给些提示,谢谢!

A:我下载了程序简单看了下,libbehavior好像已经实现了一个可用的behavior tree了,虽然可能还不够完善,但基本的行为树的样子已经有了,你可以考虑基于他这个,然后根据自己的需求添加。 不知道你有没有看到它里面的sample,我从Scenario3.h里摘录了一段建行为树的例子来说明下,我还画了一张示意图作为参考

 1: //opponent->brain是一个ParallelNode,并行的节点
 2: //在并行节点上添加第一个子节点,行为是转向目标TurnTowardsTarget
 3: opponent->brain->addChild(new TurnTowardsTarget(1));
 4: //建立一个随机节点作为第二个子节点,下面三个序列节点应该会随机选一个执行
 5: ProbabilityNode* pNode = new ProbabilityNode();
 6: //在这个随机节点上,建立一个序列节点
 7: pNode->addChild((new SequentialNode())
 8:         //在序列节点上建立第一个子节点,感觉这个应该是个判断条件
 9:          ->addChild(new BoolCondition<GameObject>(&GameObject::alignedWithPlayer,true))
 10:         //在序列节点上建立第二个子节点,行为是射击Fire
 11:          ->addChild(new Fire())
 12:         //在序列节点上建立第二个子节点,行为是等待CD,防止太频繁
 13:          ->addChild(new Cooldown(500)),5.0);
 14: //在这个随机节点上,再建立一个序列节点,下面的子节点就不说明了
 15: pNode->addChild((new SequentialNode())
 16:          ->addChild(new FloatCondition<GameObject>(&Ship::getXPosition,LESS_THAN_FP,200,1))
 17:          ->addChild(new GotoPoint(point(300,50),500))
 18:          ->addChild(new Cooldown(200)))
 19: //在这个随机节点上,再建立一个序列节点,下面的子节点就不说明了
 20: pNode->addChild((new SequentialNode())
 21:          ->addChild(new FloatCondition<GameObject>(&Ship::getXPosition,GREATER_OR_CLOSE,200,1))
 22:          ->addChild(new GotoPoint(point(100,50),500))
 23:          ->addChild(new Cooldown(200)));
 24: //在这个随机节点的上面做一个循环节点,把上面的行为无限循环
 25: opponent->brain
 26:     ->addChild((new RepeatNode(-1))
 27:         ->addChild(pNode));

Scenario3BevTree

 

所以如果你要把状态机改成行为树的话,可以考虑用我说过的Selector节点+Precondition的方式(libbehavior里好像是叫PriorityNode,但它好像没有Preconditon的概念),因为状态机里不是要跳转嘛,你原先每一个state都会有进入条件的,比如下面这个

 1: if (pMiner->PocketsFull())
 2: {
 3:     pMiner->ChangeState(VisitBankAndDepositGold::Instance());
 4: }

这样的话,你可以把pMiner->PocketsFull()作为VisitBankAndDepositGold的Precondition挂在一个Selector节点下面,然后让Selector节点帮助你选择应该进入那个状态。我建议,你可以先看看libbehavior每一个Scenario的行为树创建部分的代码,这样应该会有点感觉,另外,可以边参考我网上的文章,边来看libbehavior\BehaviorTree-src里的源码,会好理解很多 :) ,希望对你有所帮助!欢迎继续来信交流!(状态机和行为树之间转换可以参看这里这里

Q:看了你写的一系列文章,写的真不错。我也最进在游戏行业,做AI相关的工作。涉及一些游戏AI设计的问题,能否指教一下。目前我们游戏AI设计的部分考虑NPC的AI部分可配置成AI执行脚本文件方式。我考虑是可以设计AI框架,依据游戏对象的配置,框架决定加载相应的脚本引擎。我看 《浅谈层次化的AI架构》 不错,你能不能分享一下AI设计中如何分离AI框架和AI脚本内容的呢。分离的话,感觉状态转换是应该在AI脚本中完成的吧? 暴露AI引擎的API接口的通用设计一般是怎么样的呢?学习中...., 谢谢。

A:如果想在脚本中写很多AI逻辑的话,如何调试是个比较麻烦的事情,需要比较好的调试接口。我用过一种做法,你可以试试看,就是用脚本做AI的配置,逻辑还是在C++端。C++提供一个个AI逻辑模块,然后在脚本端把它配置起来,因为我用的是行为树(可以参看我博客上关于行为树的相关文章),所以比较容易配置。接口的话,首先最好是引擎能支持反射,然后就能方便的导出函数和变量直接给脚本用,至少我用lua做脚本语言,这样是可行的。

Q:您好。今天再搜索层次状态机相关资料的时候进入了您的博客。本人只在游戏中使用过简单的FSM,属于AI初学者,阅读了几篇文章后产生了几个问题:

  • HFSM和行为树到底是什么关系。我对行为树和状态机的区别还是把握不了……
  • 您有一文章说:大部分的AI,都可以分成“决策”和“行为”,二者通过一个双缓冲的“请求层”通信,但是这篇文章您没有举例子,我非常模糊。
  • 对“并行节点”我还是很模糊……您可以给我举个例子吗……麻烦了…。

A:谢谢,针对每一个问题,我的回答如下:

  • HFSM和行为树其实没什么关系,是两种不同的AI结构,区别的话,可以看我在这里的评论http://www.aisharing.com/archives/90#comment-111
  • 有人和你提出了一样的问题,可以参看我这里的回复,http://www.aisharing.com/archives/86#comment-115
  • 比如一个并行节点下有A和B两个节点,那在一次循环里,如果前提满足的话,既会执行A,又会执行B,举个实际的例子,比如要描述“又吃又喝”,就可以用并行节点:)

Q:最近在学习行为树,有幸拜读了您几篇关于行为树的文章,感觉收获颇多。刚开始接触行为树,所知有限,特来请教几个问题:

  • 关于以下代码,在文章评论中,您回复说 input 是传入行为树的参数,那么 request 是指输入的事件吗?比如移动事件、死亡事件等。 如果是事件,那您实例代码的行为树是事件驱动的,还是Tick驱动?
 1: action = root.FindNextAction(input);
 2: if action is not empty then
 3:     action.Execute(request,  input)  //request是输出的请求
 4: else
 5:     print “no action is available”
  • 在FSM中,状态进入和退出时可以做相对应的事情,比如进入某个状态身上挂个循环特效,退出该状态将这个特效移除,在行为树上,怎么实现同样的功能?
  • 按我现在对行为树的理解,感觉行为树就是将FSM中的状态变成了子树,挂在行为树的相应位置,通过行为树的节点完成状态的迁移。但是,在您文章的总结中提到:"在AI设计过程中,一般来说,我们并不是先有状态机,再去转化成行为树的,当我们选择用行为树的时候,我们就要充分的理解控制节点,前提,节点等概念,并试着用行为树的逻辑方式去思考和设计。",看后对自己将状态视为子树的理解产生了很大的怀疑,您能详细地解释下这句话吗?不知是否可以提供一张您平时设计的较复杂些的行为树供我学习之用?

A:谢谢,针对每一个问题,我的回答如下:

  • request是输出的请求,也就是行为树的输出,就像你说的,像移动,死亡等,可以看看我博客上关于分层次的AI架构的相关文章,整个行为树的决策还是在Tick中更新的。
  • 一般我在做行为树的Execute时会分成三个阶段,onEnter() ,onExecute(),onExit(),在第一次进入这个节点的时候,会调用onEnter,在从这个节点切换出去的时候,会调用onExit()。每个行为树的节点,我都会做成这种1P(前提Precondition) + 3E(Enter, Execute, Exit)的结构
  • 行为树的思考方式是指,对于每一个节点我都需要明确知道它的进入条件是什么,它要做的事情是什么。把跳转逻辑写到控制节点中,用控制节点来控制行为树的选择流程。和状态机不同的是,对于行为树的节点,一般不需要知道它是从哪个节点过来的,它只是需要关心,满足什么条件(前提)可以进入这个节点,这些条件的判断依据都是通过行为树的输入参数传入的,所以行为树和黑板的组合是很好用的,可以看看我博客上关于黑板和行为树结合的文章
  • 项目里的行为树图不太好给,呵呵,而且需要解释才能明白。复杂的话,一般就会用到序列节点,并行节点等等。行为树的好处就是只要定义了进入前提,就可以加入到现有的行为树中,这样就越来越复杂了~,不过,这也就是行为树的好处了 :)

Q:Hi,在我们现在的项目里面涉及到AI的一些东西,之前学习了关于你写得行为树,正好可以发挥一下,现在有一个问题,就是关于怪物行走,怪物行走我们这边的做法就是发目标A*路径给客户端通知其他玩家,然后,怪物每秒刷一步就走一步...这样的做法...我想问问...你们那边关于怪物行走是如何实现的呢?巡逻和追击 两个地方行为怎么做互斥?

A:针对你的问题,我在想哦,对于怪物移动的话,可以分两个部分,一般的移动,就是你说的巡逻,可以不需要用A*,因为毕竟A*的开销是比较大的,因为怪物一般的移动不会太复杂,而且一般是在一定的区域内移动(当然这是看你们怎么设计了),可以在区域内设置几个路点,然后每过一段时间选择临近的路点就可以了,也就是仅仅做一步的“寻路”。如果是要追击玩家的话,可以尝试用到A*。

网页游戏我没做过,其他游戏里,我们用到过同步位置信息的方式,也就是每隔一段时间同步一次位置,然后两次同步之间的移动,都是客户端本地模拟。如果模拟后的位置和服务器上的位置有偏差,简单的做法是瞬移到服务器上的位置,好一点的话就是平滑的从客户端现在的位置移动到服务器上的位置。

巡逻和追击我觉得比较大的不同是,巡逻中是没有目标敌人的,而追击是存在目标敌人的,所以这样就可以做到互斥了。

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

Read More

(ecto真不好用,居然写得东西都没了,害我只能把这篇文章再写了一遍,郁闷啊,跪求一个mac下的支持wordpress的离线博客编辑软件)

提到参数,在我们写程序的时候,作为一个常用的提醒是,一般都会避免去使用“魔数”(Magic Number),因为它含义不清,比如if(i>5){...},如果没有任何注释的话,很难有人会理解这个“5”是什么意思。在AI中,这样静态的参数的使用更频繁,有时为了定义一些阈值,有时为了可以给游戏设计人员调整AI行为等等,当这些参数慢慢多起来的时候,就需要更好的来管理,修改和查看,所以,如何设计一个好的参数系统就很有必要了。这个想法也源自我上一个项目的一些教训,在上个项目中,我们最后一共定义了超过1600个参数,由于历史原因,由一个简单的参数系统来维护,但实际操作中,这样的简单系统存在很多问题,首先参数没有很好的文档化,导致游戏设计人员很难搞清楚这个参数到底是干什么的,最后需要程序员的不停参与,工作的粘合度就提高了,另外也没有做到逻辑的关联,无法了解这些参数之间的相互关系。总之,这样那样的问题促成了我对于设计一个新的参数系统的想法。

相较与原来那个参数系统的种种问题,对于一个新的参数系统,我希望它能有如下的特性:

  • 仅支持静态的参数:对于游戏来说是只读的,也就是游戏在运行时不允许修改这些参数,但可以通过外部工具进行调试
  • 支持文档化
  • 支持实时的修改:不需要重新启动游戏
  • 支持序列化到文件:可以将调整好的参数存成文件,以便下一次启动游戏时生效
  • 支持逻辑关联
  • 支持自动的合法性检查
  • 高效和便捷的定义和调用

以上列出的大部分特性还是比较容易理解的,对于第5点,我特别的说明一下,假设有一个参数A,当A的值发生变化的时候,逻辑上,参数(B1, B2, B3, … , Bn)也会相应发生变化,那我们就称A和(B1, B2, B3, … , Bn)有“逻辑关联”,也就是A的变化会影响到(B1, B2, B3, … , Bn)的值,反之不成立,也就是说,逻辑关联是单向的。举个例子,比如我们有一个可以调整游戏难度的参数,它关联到敌人的血量,攻击值,防御值,当把游戏难度调成“高”时,血量,攻击值,防御值会加倍,当把游戏的难度调成“低”时,血量,攻击值,防御值会减半。在我们原来的参数系统中,这种逻辑关联是隐含的,也就是说所有的参数并没有直接的相互关联,他们的结构是“平面化”的,彼此相互独立,所以当游戏设计人员想调高游戏难度的时候,他就需要记得相应的要去调整血量,攻击值,防御值。这样很容易造成错误和疏漏,而且这种隐含的逻辑关联无处可循,只能存与程序员活或者游戏设计人员的脑海中。

针对我们的需求,我定义了一个参数P所需要包含的各个部分

  • 可识别的名称
  • 当前值:该参数当前的值(一定是合法值),供游戏读取
  • 参数类型:表示这个参数是离散型的,还是连续型的
  • 上下限数组:给连续型参数检查合法性使用,如果值不在取值区间中,则为不合法的参数值,用数组的原因,主要是可能有多个取值区间,[Vmin1, Vmax1], [Vmin2, Vmax2], … , [Vminn, Vmaxn]
  • 候选值数组:给离散型参数检查合法性使用,如果值不在候选值数组中,则为不合法的参数值。
  • 参数描述:对于该参数的简要描述
  • 趋势描述:对于该参数的变化所带来的影响的简要描述
  • 逻辑关联项数组:该参数所影响的参数项列表(P1, P2, … , Pn)
  • 被逻辑关联项数组:能影响该参数的参数项列表(P1, P2, … , Pn)

作为补充说明,对于上下限的定义,还需要有一个标志来表示是开区间还是闭区间。在逻辑关联项的数组中,和每个参数项还需要绑定一个非常重要的“关联方式”的实现。关联方式是非常灵活的,可能非常简单,就像我们前面举的那个例子,仅仅是加倍和减半,但有时可能非常复杂,有更多的逻辑计算,所以,我想可以调用一段代码来计算关联方式,可以是虚函数,也可以是一段脚本。更新关联项的方式是递归的,直到所有的关联项都被更新为止。文档化有几个部分组成,一个是名称,要求要可以识别,一个是两段描述,这两个部分很难做到要写成什么格式(文档的东西一般都是自觉自愿),但作为规范是要求定义参数的人能详细填写的,另一个部分就是关联项和合法性提示,这个可以用代码来生成文档信息(试想一下开发环境中的代码提示功能)。

我想,有了这样一个参数结构的定义,要实现一个参数系统来满足我上面的要求,并不是一件很难的事情,当然现在的这些只是我一个粗略的想法,还没有实现,有兴趣的同学可以实现一个,我有时间的话,也会做一个出来,因为它很独立,可以作为第三方库用在任何的引擎中,实现技巧的话,我想用“反射”(Reflection)做的话,对于序列化,对于做一个可视化的编辑器,对于文档化,都是挺有帮助的,值得一试。

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

Read More

记得以前我在博客中,提到过一种层次化的AI架构,这种架构的核心就是定义了“请求层”的概念,用来分隔决策和行为,并通过行为请求来清晰的定义了决策和行为之间的输入输出关系,不过,当我们仔细审视这个结构的时候,发现其中貌似缺失了对于某种情况的处理,这就是我今天要谈到,如何处理“被动式的行为请求”

一般来说,我们通常所认为的决策是一种“主动式(Active)的行为请求”,比如,我按了个键,玩家所控制的角色就是做出某些行为,或者AI通过对于当前情况的判断,做出了下一步的行为决策,所以说,主动式的行为请求,就是表达了一种“我想要去做什么”的语义。在游戏中,大部分的行为都是输入主动式的行为,那FPS(第一人称射击)类游戏来说,它可能包含的主动式行为有,移动,跳跃,射击,与游戏场景中物体的交互(拾取物品,开门)等等,当玩家和NPC在行动的时候,就是在这些已经定义的主动式行为中,做出决策。在我们以前提到的那种层次化的AI架构中,可以很好的满足这些需求。

但在游戏中,还是一些行为并不在主动式的行为中,比如死亡,当角色生命值等于0的时候,游戏系统就会触发这个行为请求,它不是由玩家或者NPC所发起的,而是有游戏系统判断出某些条件满足的时候,自动触发并赋予角色的行为请求。这一类的请求,我们就可以称之为“被动式(Passive)的行为请求”,在谈如何处理前,我们可以先看看这种请求有什么样的特点。

首先它可能会覆盖原本的主动式的行为请求。比如玩家想要快跑向前走,那他就会发出一个“快速移动”的行为请求,但就在这个时候,角色正好被横在路中间的一根树干绊了一下,当游戏系统检测到这个事件的时候,就会触发一个“绊倒”的行为请求,期望做一个摔倒的行为。显然,“绊倒”这个行为不是玩家主动做出的,是属于被动式的请求,而且这个请求应该被立刻响应(要不就不真实了),所以,当比较这两个请求的时候,我们就会用“绊倒”覆盖掉原先的“快速移动”,将其作为当前请求传给行为层。那我这里为什么说是“可能会覆盖”呢?因为并不是所有的被动请求都需要被响应的,这取决于当前产生的主动和被动,这两个请求的优先级设定,这种优先级设定一般来说会来自与游戏设计的需要。假设,我们在游戏中有一个行为是“超级移动”,这种行为很强大,效果也很炫,是游戏的一个很大的卖点和可玩点,所以游戏设计者就希望尽量能让玩家触发出这种行为,以提到游戏的游戏性和画面效果,所以当玩家触发“超级移动”的时候,我们可能就会忽略掉同时触发的“绊倒”这个行为请求。

其次,它是触发式的,所以意味着同一时刻它可能会有多个。试想一下,对于主动式请求来说,因为角色不可能分身嘛(除非是超人游戏),所以一般来说,同一时刻主动请求只会有一个,也就说,你不可能既想做这个,又想做那个。而被动式请求,就完全不同,在同一时刻,可能会有多个条件被满足,然后同时触发了多个被动行为请求,比如在被绊倒的那一刻,你中了一枪,然后生命值正好减到0(真倒霉。。),所以同时就产生了“绊倒”,“死亡”两个被动请求。那我们就面对,多个请求需要权衡的情况,在上述的例子里,显然,“死亡”的优先级应该是最高的,所以它会成为最后的请求被送到行为层。

还有一个特点就是关于被动请求产生源,在角色与角色交互的时候会非常容易产生被动式的行为请求。举个FIFA的例子(对此我研究了很多 :) ),在足球游戏中,我们可以看到很多球员间交互的例子,比如碰撞后的摔倒,争头球的挤位,带球过程中的拉扯,躲避铲球的跳跃,等等,这些都是被动式的行为请求,是玩家不可操控的,而且这些请求,不像我前面举到的例子,是单个人身上的,而是属于一种“相互作用(Interaction)”的行为请求。它的触发和处理,都会牵涉到两个,甚至多个人的判断。

谈完了特点,接下去来思考下如何来处理这些请求。当然,处理的方案多种多样,我先抛砖引玉的谈谈我想到的两种结构。还是基于原有的层次化的AI架构模型,做一些小的修改。第一种方案采用的是比较直观的集中化的处理。先定义一个结构表示当前时刻所有产生的行为请求。

 1: struct CandidateRequests
 2: {
 3:     Request        m_ActiveRequest;      //主动请求,假设同一时刻只有一个 
 4:     Array<Request> m_PassiveRequests;    //被动请求,同一时刻可以有多个
 5: }

然后,我们定义一个模块来负责处理这个结构,并产生一个最终的行为请求,值得注意的是,我们把当前正在处理的请求也作为考虑的因素之一,传入这个函数中。

 1: class RequestFinalizedModule
 2: {
 3: public:
 4:     static Request GetFinalRequest(
 5:                 const Entity& entity,
 6:                 const Request& curReq,
 7:                 const CandidateRequests& nextReq)
 8:     {
 9:         //添加选择的规则,根据当前请求和下一时刻的候选请求,抉择出最终应该做的行为
 10:     }
 11: }

集中式的处理方式将所以处理的可能性放到一个函数中,这样的好处是便于排查可能导致的选择不正确的问题,而且对于原有的结构没有什么更改,仅仅是在决策和请求层之间加了一个处理模块。缺点就是这块的代码,随着优先级关系的复杂,会显的相对比较乱,不过将脏代码堆在一个地方,也是一种不错的设计 :) ,下面是修改后的架构图

layered-ai-architecture_modified

另一种方案是让游戏系统不直接触发被动式请求,而是触发一些标记,然后AI在决策的时候将这些标记作为决策参考信息的一部分,最终做出一个合理的行为决策,这种方案延伸了决策部分的定义,使其即能产生主动式请求,也能产生被动式请求。如果用行为树的话,可以非常好的表示出这种优先级的关系,如下图:

bt-flag-passive-action

这种方式的优点是可以用到行为树本身对于优先级处理的优势,而不需要额外的添加模块,只需修改原本行为树的设计即可,作为游戏信息的一部分,也可以沿用原有的收集游戏信息的相关模块,做适当的扩展就可以了。缺点是,由于我们将原有的触发式的模式,变成了轮询式的,所以,可能会降低行为树的些许效率,而且对于行为树的设计也提出了更高的要求。不过从架构上来看,是比较清晰,并且能很好的融入原有的设计。修改的架构图如下:

layered-ai-architecture_modified_2

好,就聊到这里了,不知道大家有什么想法,欢迎一起留言讨论。

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

Read More

最近在做项目前期的一些调研的工作,研究并参考了几个引擎和框架的设计,包括内部引擎,商业引擎,和开源引擎,通过比较和学习后,觉得对于游戏中的实体实现,用“组合”的设计模式会比用“继承”的更为便利,想到我早些时候的一个项目里用到的一个引擎,也是实现了组合式的实体,而且对于AI程序员来说也是和“游戏实体”打交道最多的,一个好的设计可以大大的提高代码的质量和可维护性。所以,我觉得很有必要在这里记录一下,也和大家一起分享一下我的一些心得。

在学习面向对象编程的时候,一个很重要的概念就是“万物皆对象”,我们可以把现实世界的物体抽象成一个个的Object,并且通过继承的方式实现多样化的对象集。这个是面向对象编程的一些很重要的概念。我想学过的同学都应该对此非常的熟悉。

游戏中也是一样的,一般游戏内都会抽象出一个称之为“游戏实体”(Entity)的类,当然也有直接叫Object的,不管名字怎么样,概念上是相通的,总之都是对于游戏中可能的任何物体一种提炼。在引擎中用继承的方式扩展Entity是一种比较常见和直观的方式,可以充分利用到面向对象编程中的多态的优势,虽然可能大家都比较熟悉这种方式,但我想还是用一个比较简单的例子来帮助理解,假设我们仅仅做三个类层次的话,可以从Entity这个基类中先继承出,静态实体(Static Entity)和动态实体(Dynamic Entity),静态实体表示没有运动信息的实体,比如一些静态的建筑,地图的网格等等,动态实体表示带运动信息的实体,比如人物,机械,怪物等等,这个作为第二个层次,最下面的一个层次可以是具体的物件,就像我上面所具的那些例子。

继承的好处是直观,而且分工合作也不错,大家的协作可以互不干扰,但“继承式”的实体结构有一个问题,我想用过此类模式的同学应该也有所体会,就是随着开发的进行,基类的“体积”会日益庞大,因为当我们发现子类间有一些共通的地方时,我们可以选择的办法之一,就是把这个共通的地方写到他们共有的基类里面去,我们用上面的例子举例的话,当“人物”和“怪物”有一些属性是共通的时候,我们就不得不把这些代码移到“动态实体”这个类中,当然这还不是最糟,当“人物”和“建筑”有共通的东西时,我们就只能把代码写到最高层的“Entity”中了,而且这些共通的代码可能“怪物”这个类并不需要,但因为它也继承自Entity,所以也“被迫”的包含了这些代码。所以基类代码的可维护性就变的很差,虽然,好的继承关系的设计可以一定程度上缓解这样的问题,但并不能从根本上解决。

为了解决这样的问题,所以,现在很多的引擎架构里,都提出了“组合式”实体的概念,“组合式”的概念就类似与小孩搭积木,通过用不同部件来“组合”出不同的物体。

比如,对于“静态的建筑”这个实体来说,它可以由“空间属性模块”,“显示模块”组成,“空间属性模块”包括了位置,朝向等信息,“显示模块”包括了这个建筑的模型,贴图等和渲染相关的信息。那对于“人物”这个实体来说,他的模块就更多了,除了“空间属性模块”,“显示模块”,还会包括,“人物AI模块”,“动画模块”,“物理模块”等等。对于“怪物”来说,它可能包含了和“人物”差不多的信息,但我们会给它一个“怪物AI的模块,而不是“人物AI模块”。但这时,也许游戏设计师需要一个“高级的人形怪物”,它更聪明,需要有像人一样的AI,如果按照原来“继承式”的设计方式,我们可能需要从“怪物”这个类里继承,然后再从“人物”这个类里拷贝AI部分的代码,或者将这部分代码移到“动态实体”类中,以便于在两个类中共用,但在“组合式”的设计中,我们要做的,仅仅是将那些模块重新组合,用“人物的AI模块”来替代原来的“怪物AI模块”,这样我们就得到了一个全新的实体。

这就是“组合式”实体概念,这些用来“组合”的元件,称之为“组件(Component)”,或者“轨道(Track)”,这些组件是可继承的,所以从本质上来说,它将基于实体的继承,转移到了“组件”的继承上,将实体和属性分开,达到了简化实体类的作用。明白了它的概念,那从实现上来说就更简单了,我们可以在实体类中,包含一个存有组件基类指针的数组,然后在构建实体的时候,将相关的组件添加进来就可以了。然后在更新实体的时候,将所有在这个实体上的组件一并更新即可,代码我就不在这里写了。

“组件式”实体的概念和实现并不是很复杂,但效果却是惊人的,它用一个简单的设计模式,使得代码更易维护,而且,不同的程序员可以更合理的分工实现各自的组件部分。像AI程序员,就可以专注与对于AI组件的开发了,比如,可以做一系列的AI组件,对应不同的难度的AI,只要将这些组件和实体相连,就可以实现虽然怪物的外观相同(因为“显示组件”是一样的),但AI截然不同的效果了。对于3D程序员也是这样,比如,我可以先做一个真实效果的渲染组件,但可能我还想试试卡通渲染效果,那只要再实现一个这样的组件,将原来那个替换掉就可以了。

当然,“组合式”实体的开发中,也有些问题值得大家思考,最重要的一个问题就是,“如何在组件间传递数据?",最实际的一个例子就是,“空间组件”中存有实体的位置信息,那其他的组件开发者肯定是需要得到这些信息的,所以在组件间传递数据的功能是必不可少的,我不推荐直接开放诸如GetComponent这种直接得到组件指针的接口,那如何安全而有效的传递数据呢,这个仁者见仁,智者见智问题就留给大家讨论了。

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

Read More

第一部分

上次我们说到,游戏中的运动系统一般有两种方式,“动画配合运动”以及“运动配合动画”。对于第一种方式,由于是采用运动函数或者经验数据表,所以可以很简单的将“未来时间”带入其中,来预测未来某一时刻的运动结果。但对于第二种情况,因为所有的运动结果都是从动画中取得的,如果不知道动画信息,就无法知道相应的运动结果,所以,简单的将时间带入是不能作出预测的,对于这样的情况,如果我们要做预测的话,就不得不将动画的因素考虑在里面。

举个简单的例子,一个人做一个跑动中转身停下的行为,假设他当前时刻T1,处于A1位置,速度是V1,朝向是F1(假设和速度方向一致),他的目标状态是速度是0(没有速度),朝向是F2,位置不指定。这时当我们给出未来时间T2,应该怎样来做这个运动预测呢?

PredictableLocomotionEx

和第一种运动系统不同的是,这里我们需要一个额外的模块,称之为“动画选择模块”。在我们实际要去完成这个运动目标的时候,我们会用“动画选择模块”去选出每一步的动画,比如最直观就是“直线跑”,然后会产生一个“急停”使速度从V1到0,最后是“原地转身”使朝向从F1到F2,当这些动画做完后,我们就可以得到这个人最终的“目标位置”。由于是运动配合动画的,所以对于他的最终位置,我们完全是靠这些动画实际的运行结果而得到的。

PredictableLocomotionAnimseq

当我们要做预测的时候,显然我们也是需要用“动画选择模块”做预先的动画预测的,所以,在设计可预测的运动系统的时候,就需要将“动画选择模块”独立出来。如下图所示:

PredictableLocomotionSystem

动画选择模块的输入是“当前状态”和“目标状态”,输出是一个动画的序列,这就有点像以前我们讨论过的“计划器”(Planner),相当于为我们的运动做了一个计划(对于这样的计划器的实现,就不在这次的讨论中了)。有了这样的计划后,当我们将时间T2带入,就可以通过读取动画信息的方式来获得T2时刻的运动信息了,见下图,AT指动画的时间(Animation Duration)

PredictableLocomotionTimeSeq

对于给定的“当前状态”和“目标状态”,都会有一组动画序列与之对应,所以如果是基于目前的运动状态所作的预测,那我们可以重用我们已有的动画序列来提高效率。如果是对于假想的运动状态的预测,那我们就需要用“动画选择模块”重新做一个新的动画序列,然后再得出未来时间的运动状态,这也是为什么我们需要独立的“动画选择模块”的原因,但如果频繁做较长步骤的假想预测,可能会产生一些性能上的问题,这是需要注意的地方,当然,这也取决于“动画选择模块”实现的复杂度和动画的丰富程度,比如在上个例子中,如果我们有一个“急停转身”的动画,那我们就可以减少动画序列的个数,也就是减少了计划的步长了。

另外,在实践中,我们会采用两种运动方式混用的情况,比如对于“直线跑”,我们会用运动函数来实现,而对于“转身”,“急停”这样的行为,我们会采用第二种方式来实现,对于这样的运动系统,也可以用到这样的“计划器”,只是这个计划中的某一步换用函数方式罢了,对于上面例子,我们可以参考下图:

PredictableLocomotionTimeSeq2

除了预测未来时间的运动状态外,可能我们还会预测到达某一个状态所要用到的时间,当我们有了上面的系统后,这也会非常容易做到,比如上面的例子,如果我们要预测他到“目标状态”需要多少时间,那我们只需要把动画序列中每一个动画的时间求和就可以了,T = T1 + AT(Run) + AT(Scram) + AT(Turn)。

可预测的运动系统对于某些游戏可能是一个非常重要的系统,希望上面的讨论对大家有所帮助。

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

Read More

前端时间举家出游了一次,加上国庆期间一直跑东跑西,博客的更新就一直没跟上,距上一篇文章也是好久了呢,有时感觉一个人维护也有点小累,所以如果大家有好的想法,好的分享,也可以投稿给我,我想能有这样一个分享的平台,让志同道合的朋友一起讨论学习,也算是为中国游戏技术的发展贡献点绵薄之力,虽然我是付不起稿费的,但看着文章的浏览数和回复也是挺有成就感的事情,对吧 :)

好,言归正传,这次想大家来讨论讨论如何来做一个“可预测的运动系统”。首先来说说什么是游戏里的运动系统。

对于游戏里某一个智能体(就是带AI的物体),当AI决策结束,并且告诉行为层要干什么,行为层就会让它“动”起来,动的过程中可能是没有动画的,比如一辆车会前进,会后退,也可能是有动画的,比如一个人会走,会跳。显然一辆车的运动方式和一个人的运动方式是不同,那具体控制它如何运动,就是有专门的“运动系统”来负责了。

严格意义上来说,“运动系统”的实现并不在AI的范畴内,而是属于“游戏物理引擎”部分,但在某些时候,作为AI程序员,会对运动系统提出一些特殊的要求,比如今天我们会说到的“可预测性”,这些要求会用来来辅助AI系统的决策。在我现在的项目中,我们对预测的要求相当高,希望在决策的时候能做一个精确的运动预测,但比较遗憾的是,现有的引擎由于这样那样的原因,并不能提供这样一个精准预测,预测结果和运行结果存在较大的差距,所以我在抱怨的同时(因为我用的最多嘛),也在思考如何做这样一个系统,把想到的一些东西也记录在这里。

一个比较简单的“可预测的运动系统”就是匀速直线运动,我们可以根据匀速直线运动的公式,来预测将来任意时刻的位置,速度等运动信息。当然,游戏里的运动系统要复杂的多。一般来说,游戏里的运动可以大致分为两种:

  • 动画配合运动
  • 运动配合动画

第一种就是运动和动画是分离的,我可以用任何的运动函数来移动物体,动画只是配上去的效果而已,这种方式有动画和没有动画,对于它的运动效果来说是不变的,动画只是一种锦上添花的表现,因为运动方式都是自己定义的,所以我们可以很容易控制它运动效果,但缺点是,可能会产生“滑步”的现象,就是人感觉在太空漫步一样,可以想象我们用跑步的速度配一个走路动画的效果。

第二种是物体的运动效果是跟着动画的,如果动画中移动了1米,那我在播放这个动画的时候,这个物体也就移动了1米,这种方式就不存在一个所谓的“运动函数”的概念,因为都是动画数据驱动的,所以运动系统基本上就是从动画中取得当前物体的位置,这样的好处就是避免了“滑步”的问题,但是对于程序员来说,它不可控,完全取决于数据。

所以,当我们想要做一个“可预测的运动系统”的时候,就不得不考虑上面的两种情况,因为在不同的游戏中,运动系统的实现是不同的,有的用了第一种,有的用了第二种,有的是在第一和第二中之间切换的。

为了更好的表述“可预测的运动系统”,我需要定义一个运动状态的结构来描述当前物体的运动状态:

 1: struct PhyXState
 2: {
 3:     Vec3 m_v3Position;
 4:     Vec3 m_v3Velocity;
 5:     Vec2 m_v2Facing;
 6: };

这个结构里包括位置(3维向量),速度(3维向量)和朝向(2维向量),这是描述物体运动状态的三个基本量,对于通用的“可预测的运动系统”来说,它的输入输出就可以这样来描述:

PredictableLocomotionSystem1

输入是当前状态(Current PhyXState),目标状态(Target PhyXState),当前时间(Current Time)和想要预测的未来时间(Future Time),输出就是在未来时间的状态(PhyXState at Future Time)。特别要指出的是,如果预测的运动状态是基于当前的运动行为,那我们可以不传入“目标状态”,“当前状态”和“当前时间”,仅仅传入“未来时间”即可,因为对于当前运动行为而言,其内部已经保存了“目标状态”,“当前状态”和“当前时间”了。但作为通用描述,还是将这三项列在其中。

我们仔细考虑的话,会发现,其实运动系统天生是带有些许预测功能的,当每一帧在更新的时候,就是向运动系统传入了这些参数,然后得出了当前运动物体应该处于的运动状态,在这些参数中唯一值得注意的是“未来时间”,在正常的游戏循环中,“未来时间”是被指定为:

未来时间 = 当前时间 + 步长(Time Step)

也许你会觉得问题似乎是解决了,因为这样的话,不是就可以精确预测任意时候的运动状态了吗?

但回想一下我上面所说的游戏里用的两种运动方式,那问题就并不是这么简单了,对于第一种运动系统,确实不怎么修改就可以实现精确的预测,因为这种运动系统一般是基于数学函数,或者经验数据表(就是预先算出不同输入下的运动数据值,然后通过查表的方式来返回结果),要做的仅仅是封装一个接口,但对于第二种,或者对于混用的运动系统,我们就需要考虑更多的问题了,……。

(待续)

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

Read More

第一部分见这里

模式3:根据条件跳转到多个状态,包括自跳转

这是在状态机里最常见的模式,由于是基于条件的跳转,所以可以非常方便的用选择节点和前提的组合来描述,特别值得注意的是,对于自跳转而言,其实就是维持了当前的状态,所以,在构建行为树的时候,我们不需要特别考虑自跳转的转换。如下图所描述了,我们先用序列节点来保证跳转的上下文(可以参考模式2中的相关内容),这里用到的另一个技巧是,我们会在状态a结束的时候,在黑板中记录其结束的原因,以供后续的选择节点来选择。另外,我们在第二层选择节点第一次用到了非优先级的选择节点,和带优先级的选择节点不同,它每次都会从上一次所能运行的节点来运行,而不是每次都从头开始选择。

Fsm2BtPattern3

当然,和模式2类似的是,我们也可以不用序列节点,而是单纯的用选择节点,这样的话,作为默认状态的状态a就需要处在选择节点的最后一个,因为仅当所有跳转条件都不满足的时候,我们才会维持在当前的状态。如上图的下面那颗行为树那样。请仔细查看,我在前三个节点对于前提的定义,除了本身的跳转条件外,还加上了一个额外的条件,InAXState,它保证了仅在上一次运行的是A状态或自身的时候,我们才会运行当前的节点,这样就保证了和原本状态机描述是一致的。

模式4:循环跳转

在状态机中存在这样一种模式,在状态a中,根据某条件1,会跳转到状态b中,而在状态b的时候,又会根据某条件2,跳转到状态a,产生了这样一个跳转的“环”。显而易见的是,行为树是一种树形结构,而带环的状态机是一种图的结构,所以对于这种情况,我想了下,觉得需要引入一种新的选择节点,我称之为动态优先级选择节点(Dynamic Priority Selector),这种选择节点的工作原理是,永远把当前运行的节点作为最低优先级的节点来处理。如下图

Fsm2BtPattern4

当我们在节点a的时候,我们会先判断b的前提,当b的前提满足的时候,我们会运行节点b,下一帧再进来的时候,由于现在运行的是节点b,那它就是最低优先级的,所以,我们会先判断节点a的前提,满足的话,就运行节点a,不满足则继续运行节点b,依次类推。下面是我写的相关代码,可以给大家参考。

 1: void DynamicPrioritySelector::Test(const Blackboard& in) const
 2: {
 3:     bool hasRunningChild = IsValid(m_iCurrentRunningChildIndex);
 4:     int nextRunningChild = -1;
 5:     for(int i = 0; i < m_ChildNodes.Count(); ++i)
 6:     {
 7:         if(hasRunningChild &&
 8:            m_iCurrentRunningChildIndex == i)
 9:         {
 10:             continue;
 11:         }
 12:         else
 13:         {
 14:             if(m_ChildNodes[i]->Test(in))
 15:             {
 16:                 nextRunningChild = i;
 17:                 break;
 18:             }
 19:         }
 20:     }
 21:     if(IsValid(nextRunningChild))
 22:     {
 23:         m_iCurrentRunningChildIndex = nextRunningChild;
 24:     }
 25:     else
 26:     {
 27:         //最后测试当前运行的子节点
 28:         if(hasRunningChild)
 29:         {
 30:             if(!m_ChildNodes[m_iCurrentRunningChildIndex]->Test(in))
 31:             {
 32:                 m_iCurrentRunningChildIndex = -1;
 33:             }
 34:         }
 35:     }
 36:     return IsValid(m_iCurrentRunningChildIndex);
 37: }

总结

从上面4种模式的转化方式中,我们好像会有种感觉,用行为树的表达好像并没有状态机的表述清晰,显的比较复杂,罗嗦。这主要是因为我们用行为树对状态机做了直接的转化,并想要尽力的去维持状态机的语义的缘故。其实,在AI设计过程中,一般来说,我们并不是先有状态机,再去转化成行为树的,当我们选择用行为树的时候,我们就要充分的理解控制节点,前提,节点等概念,并试着用行为树的逻辑方式去思考和设计。

不过,有时,我们也许想用行为树改造一个已有的状态机系统,那这时就可以用我上面提到的这些模式来尝试着去转换,当然在实际转换的过程中,我的建议是,先理清并列出每一个状态跳转的条件,查看哪些是带上下文的跳转,哪些是不带上下文的跳转,哪些是单纯的序列跳转(比如,从状态A,到状态B,到状态C,类似这样的单线跳转,常见于流程控制中),哪些跳转是可以合并的等等,然后再用行为树的控制节点,把这些状态都串联起来,当发现有些跳转用已有的控制节点不能很好的描述的时候,可以像我上面那样,添加新的控制节点。

这四种模式,是我现在能想到的,可能不全,如果大家有问题,可以在后面留言,有指教的也欢迎一起讨论。

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

Read More

选这次主题,要感谢一位网友的来信,他询问了一些如何将有限状态机转成行为树的问题,当时,我回信给了一些建议,但后来我仔细想了一下,觉得可能说得还不够全面,所以我就想通过这篇文章,来整理出一些比较典型的转化“模板”,给有这方面疑惑的朋友一些帮助,如果有朋友有一些自己的见解的,可以在后面留言,我们一起讨论。

有限状态机维护了一张图,图的节点是一个个的状态,节点和节点的连线是状态间根据一定的规则做的状态转换,每一个状态内的逻辑都可以简要描述为:

如果满足条件1,则跳转到状态1
如果满足条件2,则跳转到状态2
...
否则,不做跳转,维持当前状态

稍作整理的话,我们可以对状态机的几种跳转的情况一一描述出来,然后看看如果将这些情况用行为树来表示的话,可以怎么做。这就是我前面说的“转化模板”,当然我不能保证我下面列出的是状态机的所有可能情况,如果大家在实践中发现还有其他的情况,欢迎留言,我随时更新。

在这之前,我们可以先回忆一些关于行为树的一些概念(可以参考12

  • 控制节点:选择节点,序列节点,并行节点,等等
  • 行为节点:两种运行状态,“运行中”和“完成”
  • 前提条件

模式1:当处在任何状态中,一旦某条件满足,即跳转到某个特定的状态。

比如,在状态机中的一些错误处理,经常会用到上面的这种模式,当状态在运行过程中,发生了某些异常,那一般,我们会把状态机跳转到某个异常状态。这种情况,我们可以用到带优先级的选择节点(Priority Selector)方式,如下图,可以看到,我们把状态c作为行为树里的行为节点,跳转条件(Condition1)作为这个节点的前提(Precondition)。

Fsm2BtPattern1

再用上面举到的错误处理的例子,在状态机中,我们一般会这样写:

 1: STATE A::Update()
 2: {
 3:     ...
 4:     if(error)
 5:     {
 6:         return TO_ERROR_STATE();
 7:     }
 8:     ...
 9:     return UNCHANGED_STATE();
 10: }

转换到行为树中,我们会通过外部的黑板来做通信(可以参考这里),在行为节点a中,我们会这样写

 1: EXECUTE_STATE A::Execute(BlackBoard& out)
 2: {
 3:     ...
 4:     if(error)
 5:     {
 6:         out.error = error;
 7:         return EXECUTE_STATE_FINISH;
 8:     }
 9:     ...
 10:     return EXECUTE_STATE_RUNNING;
 11: }

然后对于节点c的前提里,我们来读取黑板里的error值

 1: bool Condition1::IsTrue(const BlackBoard& in) const
 2: {
 3:     return in.error == true;
 4: }

模式2:对于同一个跳转条件,处在不同的状态会有不同的跳转

比如,我们有两个状态,a和b,他们都对同一个跳转条件作出响应,但和模式1不同的是,a对跳转到状态c,而b会跳转到状态d,换句话说,这是一种带有上下文的状态跳转方式。对于这种情况,可以用到序列节点的相关特性,如下图

Fsm2BtPattern2

序列节点中,当前一个节点运行完成后,会执行下一个节点,利用此特性,在上图中可以看到,我们在a中,当满足条件Condition1的时候,则返回“完成”,那行为树就会自动跳转到c节点中,参考代码如下:

 1: EXECUTE_STATE A::Execute(BlackBoard& out)
 2: {
 3:     ...
 4:     if(condition1 == true)
 5:     {
 6:         return EXECUTE_STATE_FINISH;
 7:     }
 8:     ...
 9:     return EXECUTE_STATE_RUNNING;
 10: }

对于这种模式的另一种转化,可以不用序列节点,还是用到选择和前提的组合,但我们在前提中加上一个当前状态的附加条件,如下图

Fsm2BtPattern2 (1)

在第二层的前提中,我们可以这样写

 1: bool InACState::IsTrue(const BlackBoard& in)
 2: {
 3:     return in.current_running_node = A::GetID() ||
 4:            in.current_running_node = C::GetID();
 5: }
 6:
 7: bool InBDState::IsTrue(const BlackBoard& in)
 8: {
 9:     return in.current_running_node = B::GetID() ||
 10:            in.current_running_node = D::GetID();
 11: }

这样对于c的前提就是Condition1和InACState的“与”(回想一下前提的相关内容)。由于我们保留了上下文的信息,所以通过对于前提的组合,我们就转化了这种模式的状态机。

(待续…)

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

Read More

LOD(Level Of Detail)是3D渲染中用到的概念,按照wikipedia上的翻译,可以译为“细节层次”,它是一种根据与观察点的距离,来减低物体或者模型的复杂度来提升渲染效率的优化技术,因为显而易见的是,当一个物体离我们很远的时候,我们不需要用很复杂的多边形来绘制,只要用一个粗略模型或者低精度的贴图即可,所以在3D渲染中,这是一个很常见的优化技术。

对于AI来说,当一个AI对象离我们很远的时候,其实,它做出什么样的决策,做出什么样的行为,我们并不能“感觉的”到,虽然它的行为可能会对游戏世界有影响,但玩家一般只会专注于离自己比较近的AI行为,所以我们在AI的优化中,也可以采用这种“LOD”的技术,来提升AI部分的运行效率。

我在玩真三国无双的时候,对此非常有感触,虽然我并不知道他是否在AI层做了LOD,但类似于这种大场景,超多NPC的游戏,AI层的LOD的优化技术就非常适合。同样的NPC,当他离玩家不同的距离的时候,我们就可以赋予它不同的AI行为,如下表所示:

  1. 近:攻击,防御,追踪,掩护,包围,等待,...
  2. 中:追踪,包围,等待,...
  3. 远:等待,...
一般来说,AI候选的行为越多,它决策所花费的时间也越多,根据这样的假设,我们就可以通过限制AI行为的方式,来起到提升效率的作用。上面说的是一种LOD的方式,还有一种实现方式是减少AI的决策频率,这也是我以前讨论过的AI中的懒惰问题,比如如下表:
 
  1. 近:攻击,防御,追踪,掩护,包围,等待,...(0.1秒决策一次)
  2. 中:攻击,防御,追踪,掩护,包围,等待,...(1秒决策一次)
  3. 远:攻击,防御,追踪,掩护,包围,等待,...(5秒决策一次)

我们可以根据需要来混合使用上面两种方式。说到这里,我想大家脑海中会有一个自己的代码实现框架,我也想了一种,可以用到我经常说的行为树的方式来实现,行为树最好的就是可以任意的添加行为分支,所以可以说,对于第一种的LOD实现是天生支持的,我们只要建立三个行为分支表示近,中,远,并且在这三个分支下,挂上不同的候选行为,这样,我们就建立了一棵带LOD优化功能的行为树,如下图:

 
Lod1
 
对于第二种LOD实现,我们可以创建一种新的控制节点(回忆一下控制节点的概念),可以称之为LazyNode,这是一个一元的节点,它的功能就是维护一个时钟,当时间一到就执行它的子节点。同样的,我们用LazyNode,也建立近,中,远三个行为分支,然后在下面挂上相关的行为子节点,如下图:
 
Lod1 (1)
可以看到,如果我们用行为树,就不需要用什么附加的模块来做LOD优化,而是用行为树强大的扩展能力把这些直接整合进了AI结构中,这种不破坏结构,从架构层面的优化方式,是我相当推崇的。
LOD是一种懒人化的优化方式,无论是概念还是实现都非常简单,当然,所有这些都是以不破坏游戏性为前提的,有时,我们有可能需要远处的AI做一些复杂的决策,比如,在即时战略游戏中,虽然我们AI离我们很远,但它确实需要做一些完整决策,在这种情况下,LOD可能并不是很适用,所以,AI中的一些问题没有一成不变的解决方案,实际情况,实际分析是相当之重要的 :) ,大家对AI优化有什么心得呢,欢迎大家留言讨论。
 
 
————————————————————————
作者:Finney
Blog:AI分享站(http://www.aisharing.com/)
Email:finneytang@gmail.com
本文欢迎转载和引用,请保留本说明并注明出处
————————————————————————
Read More

游戏AI在做决策的时候,最重要的参考依据就是当前游戏世界信息,这其实和人做判断的时候是一样的,我们在做出一个决定的时候,脑中会闪过很多我们已经收集的信息,包括所见,所听,直觉(基于以往的经验)等等。所以,我们如何去抽象游戏世界信息,并收集起来以供AI使用,也是非常值得我们去思考和探讨的问题。

当然,不同的AI决策,对于游戏世界的信息需求是完全不同的,不同的游戏,对于游戏世界的抽象方式也不完全相同,因此,关于游戏信息收集的实现是一种“游戏特定”(Game specific)的问题。说句题外话,正是由于AI中充满了很多“游戏特定”的问题,所以AI不像渲染,声音,网络等其他游戏模块,它很难做成一个“引擎”,不过也正是因为每个游戏的AI需求都不同,因此AI编程也充满了魅力和创造力 :)

虽然存在这样或者那样的不同,但就像我一开始分析的,无论是否存在一个单独的模块来收集并存储游戏世界信息,这确实是AI程序中必不可少的单元。这次我想和大家探讨一个我一直在考虑的想法,虽然在我做过的项目中还没有完全用到(零星的用到一点,没有抽象成单独的模块),不过作为一个思维笔记记下来,还是很有必要的。

假设我们写一个篮球游戏中控球队员的AI,如果我们不考虑复杂的战术配合,一般来说,控球队员要么带球突破,要么直接投篮,要么传球给会造成威胁的空位球员,考虑到篮球场上瞬息万变情况来,如果单纯的if-else,会很难罗列出全部的条件,所以我们可能会采用模糊AI的决策逻辑,比如分数系统,不过,由于今天我们讨论的是收集和存储游戏世界信息的问题,所以对于AI决策相关的东西,我们暂且不讨论。我们仅仅来看,在这个问题中,AI决策时候可能需要知道哪些游戏世界信息:

  1. 场上己方球员的分布
  2. 场上对方球员的分布
  3. 球场上哪里比较有威胁(靠近篮筐的地方)
  4. 球场上哪里比较不安全(比如有强力防守队员,或者防守队员人数很多)
  5. 场地的构成(三分线位置,三秒区)
  6. 球员的相关信息(比如球员能力,位置,当前行为等等)
  7. ……

如果把上面的信息分个类别的话,可以分成以下4种

  • 静态实体信息(比如5)
  • 静态抽象信息(比如3)
  • 动态实体信息(比如1,6)
  • 动态抽象信息(比如4)

静态和动态的概念比较好理解,“静态”就是值不随着游戏的进行而变化的信息,“动态”就是随着游戏的进行会一直改变的信息,像场地信息就是静态的,不会改变的,像场上对方球员分布就是属于动态信息,因为他们的位置是一直变动的。而我这边提到的“实体”信息,指的是“真是存在”的信息,“抽象”是指“自定义”的参考信息。像场地信息,就是实体信息,因为类似三分线位置都是实际存在的信息,但像球场上哪里有威胁,那就是我们根据需要,自己定义的信息了,可以不断的调整和修正。

我借鉴了3D渲染中“帧缓冲区”(Frame Buffer)的概念,想用一种类似的方式来存储游戏世界信息,因为我们看到上面我们需要收集的信息中,不管是静态还是动态,实体还是抽象,很多都是和游戏地图相关的(除了6),所以我们就可以用一种“图”的方式来存储信息,称之为“游戏信息图”(Game World Info Map)。

首先我们按需求将游戏地图栅格化,比10×10,当然,粒度的大小取决于对于精度和效率的平衡。每一个格子就相当于“帧缓冲区”中的像素,然后我们可以创建多个这样的“图”,和创建多个“帧缓冲区”一样。每个图都代表上述信息中的一项内容,图中的每个格子都根据信息的内容填入0.0 ~1.0的值。

例如,我们要建立一个“场地威胁图”,我们定义0表示完全没有危险,1表示薄雾浓云愁永昼威胁值最高,那我们就可以这张图的相应的格子中填入相应的值,而且因为这是静态信息,所以只需要在游戏开始时填入就可以了,当我们填完每一个格子的时候,我们就得到了这样一张“场地威胁图”。对于动态信息的情况,我们需要在每一帧(或者每几帧)对“图”中的信息做一次更新,比如“场地危险图”,就是这样的动态“信息图”,需要根据防守队员的情况来实时更新。这样当我们填完所有的“图”信息后,AI决策时就可以知道任意时刻,在地图上的任意点上的相关信息了。

小地图的情况(如上例)可以直接做栅格化,但对于地图比较大的情况,如果直接栅格化的话,更新起来性能太低,这种情况可以考虑采用层次化的图模型,先将地图分成大块的格子,在大的格子里再细分成小格子,当查看距离近的信息的,采用精细的格子信息,查看远处的时候,采用粗略的信息,这样就可以在效率上取得一些平衡。

用“图”来表示世界信息的另一个好处是,可以方便的将信息绘制出来(在地图上,或者在外部的调试工具中),而不用面对一大堆的数据,如果再将不同的值配以不同的颜色来显示的话,那将大大的降低AI调试的难度。

可以看到,其实“图”的概念,就是对于游戏世界信息中和地图有关的信息的抽象,像我前段时间提到的“势力图”(Influence Map),就是“信息图”的一种应用。“信息图”的想法并不是我的独创,其实可能大家或多或少以前在编写游戏AI的时候也用到过,但我觉得整理一下的话,可以作为一种比较通用的结构来提炼出来,在AI中加以运用。希望对大家有所帮助。

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

Read More