自從看完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="open?fire"},
????{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="find?bill",
??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的，因為local value的生存范圍是chunk，dofile就是在一個chunk內執行代碼。
posted on 2006-10-30 21:50
LOGOS 閱讀(5505)
評論(6) 編輯 收藏 引用