在游戲中形形色色的劇情，任務(wù)的觸發(fā)可以在游戲循環(huán)中使用硬編碼來(lái)觸發(fā)，這樣做的弊端是所有的劇情任務(wù)等元素就算策劃完成了文檔最后還是要由程序員來(lái)輸
入。在以前的項(xiàng)目中這些劇情和任務(wù)被寫在了數(shù)據(jù)庫(kù)中，在相應(yīng)的表中，當(dāng)游戲循環(huán)中檢測(cè)到你與NPC對(duì)話或者有相似的觸發(fā)行為則會(huì)交付相應(yīng)的檢查處理函數(shù)去
處理，這個(gè)處理函數(shù)先會(huì)檢查是否有相關(guān)觸發(fā)事件，如果有，則根據(jù)相應(yīng)的事件類型去做相應(yīng)的處理，比如劇情對(duì)話是一種類型，任務(wù)是一種類型，這個(gè)處理的函數(shù)
我們姑且叫它解析器。
每個(gè)復(fù)雜點(diǎn)的RPG游戲都應(yīng)該有自己的腳本，剛才提到的那種把相關(guān)事件寫在數(shù)據(jù)庫(kù)的做法可以說(shuō)是把所有具體的事件條目記錄在數(shù)據(jù)表中，解析器根據(jù)條目類型
來(lái)才處理相應(yīng)的事件，最近粗略的看了一下當(dāng)下流行LUA語(yǔ)言，其語(yǔ)法等等都是作者定義的標(biāo)準(zhǔn)，好比微軟提供給我們的API，不同的是API是應(yīng)用接口，直
接使用，而LUA等定義的函數(shù)要經(jīng)過(guò)作者的腳本系統(tǒng)的解析器來(lái)使其工作，我們游戲中使用LUA等腳本系統(tǒng)是因?yàn)樗膹V泛使用和節(jié)約成本的考慮（自己寫一個(gè)
強(qiáng)大的解析系統(tǒng)也是可以的），但是在游戲中的很多功能我們想使用腳本來(lái)幫助完成該如何做呢？這里我并沒有深入接觸過(guò)，只能說(shuō)說(shuō)自己的設(shè)想，在游戲循環(huán)中碰
到需要檢測(cè)腳本的地方我們可以調(diào)用LUA來(lái)讀取相應(yīng)的腳本文件，我們讀進(jìn)來(lái)了這些腳本文件中可能有我們自定義的腳本函數(shù)，比如我們?cè)谀_本中寫了
SetPos(int x,int
y)這樣的函數(shù)來(lái)表示設(shè)置角色位置，那么LUA中肯定是沒有SetPos這樣的函數(shù)的，LUA的解析器也解析不了，我想這樣的函數(shù)的解析工作可能還是要放
在代碼中實(shí)現(xiàn)，又或許再次利用LUA調(diào)用用來(lái)解析此類函數(shù)的腳本文件，這樣腳本讀取一條，解析一條，然后交給引擎來(lái)交互。
那么利用LUA這類腳本語(yǔ)言的最大好處就是將一些邏輯實(shí)現(xiàn)交由LUA來(lái)解析完成后和游戲引擎交互，做一個(gè)由腳本驅(qū)動(dòng)的游戲則可以在保留底層的情況下開放給
更多的開發(fā)者用以擴(kuò)充，聽聞BIGWORLD和UNREAL等引擎都是基于腳本系統(tǒng)的，底層的代碼應(yīng)該是不會(huì)輕易的暴露，如此能保證節(jié)約開發(fā)成本和高效。
以上是我目前對(duì)腳本的一些理解，最近開了下Programming in
LUA,那些語(yǔ)法的東西看看也挺沒意思，無(wú)非是人家約定俗成的東西，最后還是要交給LUA的去解析成為可以運(yùn)行的代碼，如果工期充裕為什么不自己做一個(gè)腳
本系統(tǒng)呢？目前對(duì)這方面還是存在困惑，以前的經(jīng)驗(yàn)就是借助前面所提的數(shù)據(jù)表來(lái)實(shí)現(xiàn)一些游戲交互，在LUA等流行腳本方面并沒有很深的研究，還望各位前輩能
夠指點(diǎn)迷津，也許自己對(duì)LUA的交互模式理解并不到位，歡迎各位拍磚！