如何在游戏机制中使用AI/剧情脚本－－－－基于LUA

自从看完PIL之后，就暂时没有时间做更多的尝试，也因此没有弄明白如何将AI脚本，剧情脚本之类的嵌入到C++的硬编码中。最近看了一些AI的文章，并思考了一下，得到以下认识。

首先要说的是，并不是说AI，剧情逻辑必须非脚本语言不可，用C++也可以写，甚至更习惯一些。但是脚本语言有脚本语言的长处，动态类型以及相当人性化的数据构造方式，特别是LUA中的表类型，似乎比较擅长描述这种复杂的AI/剧情结构。当然，为了验证自己的想法，我也写了4K的LUA代码，结果觉得该脚本语言相当不容易构造简洁的内容。

AI从高自低的分别是计划，状态机，模式。我不知道这种划分是基于何种角度，但是我个人的理解是状态机最高，模式作为某个状态下的某个决策所预定义的动作序列，而计划，是为了实现某个目标的一组步骤的组合。

那么硬编码的游戏循环何时调用脚本？答案是，游戏循环执行到调度NPC的AI函数的时候，该AI函数就不再做任何硬编码，而只是简单的dostring("gameEntitys[npc](\"update\")")。就是这么简单，将所有的AI/剧情放置到脚本中。

那么，LUA中gameEntitys[npc]("update")是什么意思？简单的说，gameEntitys是一个存储所有NPC的注册表，gameEntitys[npc]将取得该npc的FMS函数，然后给该函数发送update消息告知npc当前的状态进行例行更新。

FMS函数对于每一个对象是唯一的，那么比如某一类对象有共同的AI/剧情，那么该类的每一个对象同用同样的FMS函数的话，成员变量如何维持？要知道在LUA中模拟类还是比较麻烦的。答案是upvalue，也就是所有的对象使用同样的函数来生成自身的FMS，该函数就是FMS_Creator(all_state,init_state)。

在C++编码中，NPC对象完成构造之后，就调用LUA载入对应的状态机/剧情脚本，然后调用FMS_Creator为自己创建FMS函数：

dofile("npc_ai.lua")--引入all_state,init_state

gameEntitys[npc]=FMS_Creator(all_state,init_state)当然，NPC析构之后，你也要释放LUA为你分配的资源gameEntitys[npc]=nil

已经大概说明了如何在C++中启动NPC的LUA逻辑代码了，那么如何在LUA中编写状态机呢？答案是表。每个表代表一个状态，该表下的key表示该状态接受的消息，key对应的值表示该状态接受到key所表示的消息后要执行的决策，包括相应的动作和可能的状态变迁。看代码吧，最直观的表述：

state={

name="attack",--状态名

enter={--进入该状态要执行，属于状态的消息

--func是函数，param是参数，sucess,unsucess是func执行结果所对应的状态转移

{func=print,param="openfire"},

{func=IsEnemyDie,sucess="cure"},

}

update={}--同enter,不过用于状态在每一帧的更新

exit={}--同enter，不过用于状态在每一帧的更新

other_msg={}--同enter,用于表示该状态所接受的其他消息，可以有多个

}在LUA中就是可以如此直观的表示每一个状态，其响应的消息以及函数。然后构造该npc接受的状态集合：

all_state={}

all_state[state.name]=state

init_state=state这样子，就能传递到FMS_Creator中创建出自己独一无二的状态机函数了。

那么剧情脚本呢？其实描述了状态机，剧情脚本是否已经有点眉头了呢？剧情，即为计划，每一个计划由一系列步骤所组成。类似的，对应每个计划的执行会有一个plan()函数，且为了达到独立效果，该函数将会由plan_creator(all_step,first_step)生成。

看参数，显然计划的步骤step就是类似于状态的表，不过key方面略有不同，看代码就明白：

step={

name="findbill",

cond={--执行该步骤的前提条件

--func是判断条件的函数，param是判断参数

{func=IsXXX,param="xxx"},

{func=IsStepFinished,param=some_step},

},

finish={--条件判断成功要执行的动作

{func=print,param="success"},

},

unfinish={--条件判断不成功所要执行的动作

{func=print,param="unsuccess"},

},

}

至此，要说的基本上说完了。剧情与FMS结合的方式，因为个人认为FMS最高，所以剧情的执行通过plan()，该剧情的执行函数将作为某个状态相应某个消息时函数集合的一分子。因为，总有个状态是要求按计划执行剧情完成目标的，但是，其他状态允许意外使得暂时不能执行剧情，而NPC又不至于疯掉。

需要补充的是，很遗憾LUA不能随意的使用类似于#include,#import的功能，虽然可以dofile，但是其dofile内声明的变量必须是globle的，因为localvalue的生存范围是chunk，dofile就是在一个chunk内执行代码。