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