自從看完P(guān)IL之后，就暫時沒有時間做更多的嘗試，也因此沒有弄明白如何將AI腳本，劇情腳本之類的嵌入到C++的硬編碼中。最近看了一些AI的文章，并思考了一下，得到以下認(rèn)識。
首先要說的是，并不是說AI，劇情邏輯必須非腳本語言不可，用C++也可以寫，甚至更習(xí)慣一些。但是腳本語言有腳本語言的長處，動態(tài)類型以及相當(dāng)人性化的數(shù)據(jù)構(gòu)造方式，特別是LUA中的表類型，似乎比較擅長描述這種復(fù)雜的AI/劇情結(jié)構(gòu)。當(dāng)然，為了驗證自己的想法，我也寫了4K的LUA代碼，結(jié)果覺得該腳本語言相當(dāng)不容易構(gòu)造簡潔的內(nèi)容。
AI從高自低的分別是計劃，狀態(tài)機(jī)，模式。我不知道這種劃分是基于何種角度，但是我個人的理解是狀態(tài)機(jī)最高，模式作為某個狀態(tài)下的某個決策所預(yù)定義的動作序列，而計劃，是為了實現(xiàn)某個目標(biāo)的一組步驟的組合。
那么硬編碼的游戲循環(huán)何時調(diào)用腳本？答案是，游戲循環(huán)執(zhí)行到調(diào)度NPC的AI函數(shù)的時候，該AI函數(shù)就不再做任何硬編碼，而只是簡單的dostring("gameEntitys[npc](\"update\")")。就是這么簡單，將所有的AI/劇情放置到腳本中。
那么，LUA中 gameEntitys[npc]("update")是什么意思？簡單的說，gameEntitys是一個存儲所有NPC的注冊表，gameEntitys[npc]將取得該npc的FMS函數(shù)，然后給該函數(shù)發(fā)送update消息告知npc當(dāng)前的狀態(tài)進(jìn)行例行更新。
FMS函數(shù)對于每一個對象是唯一的，那么比如某一類對象有共同的AI/劇情，那么該類的每一個對象同用同樣的FMS函數(shù)的話，成員變量如何維持？要知道在LUA中模擬類還是比較麻煩的。答案是upvalue，也就是所有的對象使用同樣的函數(shù)來生成自身的FMS，該函數(shù)就是FMS_Creator(all_state, init_state)。
在C++編碼中，NPC對象完成構(gòu)造之后，就調(diào)用LUA載入對應(yīng)的狀態(tài)機(jī)/劇情腳本，然后調(diào)用FMS_Creator為自己創(chuàng)建FMS函數(shù)：
dofile("npc_ai.lua")?--引入all_state,init_state
gameEntitys[npc]=FMS_Creator(all_state,?init_state)當(dāng)然，NPC析構(gòu)之后，你也要釋放LUA為你分配的資源
gameEntitys[npc]=nil 已經(jīng)大概說明了如何在C++中啟動NPC的LUA邏輯代碼了，那么如何在LUA中編寫狀態(tài)機(jī)呢？答案是表。每個表代表一個狀態(tài)，該表下的key表示該狀態(tài)接受的消息，key對應(yīng)的值表示該狀態(tài)接受到key所表示的消息后要執(zhí)行的決策，包括相應(yīng)的動作和可能的狀態(tài)變遷。看代碼吧，最直觀的表述：
state?=?{
??name?=?"attack",?--狀態(tài)名
??enter?=?{??--進(jìn)入該狀態(tài)要執(zhí)行，屬于狀態(tài)的消息
?????--func是函數(shù)，param是參數(shù)，sucess,unsucess是func執(zhí)行結(jié)果所對應(yīng)的狀態(tài)轉(zhuǎn)移
????{func=print,?param="open?fire"},
????{func=IsEnemyDie,?sucess="cure"},
??}
??update={}??--同enter,不過用于狀態(tài)在每一幀的更新
??exit?=?{}??--同enter，不過用于狀態(tài)在每一幀的更新
??other_msg?=?{}??--同enter,用于表示該狀態(tài)所接受的其他消息，可以有多個
} 在LUA中就是可以如此直觀的表示每一個狀態(tài)，其響應(yīng)的消息以及函數(shù)。然后構(gòu)造該npc接受的狀態(tài)集合：
all_state?=?{}
all_state[state.name]=state
init_state=state 這樣子，就能傳遞到FMS_Creator中創(chuàng)建出自己獨一無二的狀態(tài)機(jī)函數(shù)了。
那么劇情腳本呢？其實描述了狀態(tài)機(jī)，劇情腳本是否已經(jīng)有點眉頭了呢？劇情，即為計劃，每一個計劃由一系列步驟所組成。類似的，對應(yīng)每個計劃的執(zhí)行會有一個plan()函數(shù)，且為了達(dá)到獨立效果，該函數(shù)將會由plan_creator(all_step, first_step)生成。
看參數(shù)，顯然計劃的步驟step就是類似于狀態(tài)的表，不過key方面略有不同，看代碼就明白：
step?=?{
??name="find?bill",
??cond?=?{?--執(zhí)行該步驟的前提條件
?????--func是判斷條件的函數(shù)，param是判斷參數(shù)
?????{func=IsXXX,?param="xxx"},
????{func=IsStepFinished,?param=some_step},
??},
??finish?=?{??--條件判斷成功要執(zhí)行的動作
????{func=print,?param="success"},
??},
??unfinish?=?{??--條件判斷不成功所要執(zhí)行的動作
????{func=print,?param="unsuccess"},
??},
} 至此，要說的基本上說完了。劇情與FMS結(jié)合的方式，因為個人認(rèn)為FMS最高，所以劇情的執(zhí)行通過plan()，該劇情的執(zhí)行函數(shù)將作為某個狀態(tài)相應(yīng)某個消息時函數(shù)集合的一分子。因為，總有個狀態(tài)是要求按計劃執(zhí)行劇情完成目標(biāo)的，但是，其他狀態(tài)允許意外使得暫時不能執(zhí)行劇情，而NPC又不至于瘋掉。
需要補(bǔ)充的是，很遺憾LUA不能隨意的使用類似于#include,#import的功能，雖然可以dofile，但是其dofile內(nèi)聲明的變量必須是globle的，因為local value的生存范圍是chunk，dofile就是在一個chunk內(nèi)執(zhí)行代碼。
posted on 2006-10-30 21:50
LOGOS 閱讀(5493)
評論(6) 編輯 收藏 引用