根據wikipedia的解釋：腳本語言（Script language，scripting language，scripting
programming
language），是爲了縮短傳統的編寫-編譯-鏈接-運行（edit-compile-link-run）過程而創建的計算機編程語言。此命名起源於
一個腳本“screenplay”，每次運行都會使對話框逐字重複。早期的腳本語言經常被稱爲批次處理語言或工作控制語言。一個腳本通常是解釋運行而非編
譯。腳本語言通常都有簡單、易學、易用的特性，目的就是希望能讓程序設計師快速完成程序的編寫工作。
對於腳本語言，想必我們這些 Java程序員都再熟悉不過，因爲我們每天都在使用的Java，從嚴格意義上講也是一種解釋型語言——畢竟class是憑藉JVM進行字節碼解釋才得以執 行，故而長期被排斥於編譯型語言的門檻之外（但是，由於Java有編譯過程，若CPU支持字節碼那麼class就可以脫離JVM限制，說Java是純粹的 解釋型語言似乎也很不妥＋︿＋……期待java cpu普及中……）。
在這個講解AVG遊戲開發的系列博文中，爲什麼會提到腳本引擎的製作及應用呢？筆者將在下面加以說明。
在遊戲開發中，我們將無可避免的遇到很多重複性工作，比如角色A-Z的創建，物品0-n的編輯，對話x->+∞的添加等等——這些並不是需要複雜的編碼，甚至僅是單純的數據錄入，但由於數據量龐大，通常也會耗費相當的時間進行設定。
如果讓您來做，要怎麼辦呢？以最直觀的方式來說，可能有些人會考慮硬編碼，直接編碼似乎能省去很多的麻煩事。
OK，或許我們完全可以採過硬編碼方式解決問題，比如建立一個對應物品的class，而後爲其添加各種對應字段。
那麼，假設現在我們在某個同人遊戲的開發中這樣幹了，並且將遊戲對外發布。三天後，問題來了，有人反映某物品——我虛構個名字，就叫[對抗網癮專用電棍] 吧。有人反映它殺傷力太低，且對[網癮]狀態無傷害加成……嗯，我們考慮後認爲有道理，怎麼辦呢？一個字——改，反正就是一兩行代碼的事情，重新編譯，打 包，發佈——簡單簡單。
這下高枕無憂了吧？可惜，出乎我們意料之外的事情又再次發生，又過了兩天，有玩家反映我們的最終BOSS[真. 紅色有角.磚家叫獸地獄鬼畜模式]的大招[終極網癮擴散]會將所有我方角色全體[網癮化]，並且會持續投擲[對抗網癮專用電棍]***我方角色，由於改版後 的[對抗網癮專用電棍]***力太強，並對[網癮]狀態有極強的傷害加成，我方角色很容易便會被BOSS團滅。
你問我這下怎麼辦？ 硬編碼的還有什麼新鮮，只能再重新編譯……用戶就是上帝，上帝讓改就改吧……但是，儘管我們非常努力，卻總有欠缺在這個遊戲中存在，如果這樣改下去，三 次、四次、十次、二十次|||，次次都需要重新編譯及發佈，就是再簡單也受不了了（做Java還好，搞C/C++的很多人都經歷過守夜等編譯結果 吧……），恐怕最終此遊戲只好停止發佈，爛尾了事。如果你將每個物品都直接編碼到遊戲當中，那麼毫無疑問你將會陷入到噩夢一般的處境。
爲什麼我們不能選擇更加簡單的方式來處理呢？既然每次重新編譯、重新發布程序那麼麻煩，幹什麼不將配置放在遊戲外面呢？實際上，我們完全可以創建一個文本文 件記錄下所有物品參數，而每次更新時，我們僅需修改此文本文件便可以改變整個遊戲中的屬性設置，再也不必事無鉅細都重新編譯、重新發布整個遊戲了。
事實上，筆者之所以耗費筆墨寫這麼一個例子，無非是爲了說明腳本應用背後的基本準則——簡化軟件製作流程，避免硬編碼。
腳本可以使你真正在遊戲引擎之外編寫代碼，然後再將這些代碼加載到遊戲引擎之中並對它加以執行。一般情況下，腳本是按照它們自己的語言格式進行編寫的，使用 何種語法完全由腳本引擎決定，腳本就好像是運行在遊戲程序內部的小程序，它們的工作原理和其他的普通程序一樣，你可以使用一個普通的文本編輯器來編寫它 們，然後在你的主程序中執行它們。腳本通常使用它們自己的編譯器或者解釋器，它們對遊戲主引擎並沒有任何影響——除非你希望它這麼做。
同時，遊戲和腳本之間通常是分離的。你可以像加載圖形、聲音，甚至早期的物體描述文件一樣加載腳本。但是，你並不能在顯示器上將它們顯示出來或者是通過喇叭把它們播放出來，取而代之的是，你可以執行它們，它們也可以和你的遊戲進行通信，而遊戲也可以作出應答。
簡單的說，如果我們將遊戲引擎和遊戲數據理解爲人與積木，那麼腳本就是用來搭建積木的圖樣；如果我們將遊戲引擎和遊戲數據理解爲海洋與大陸，那麼腳本就是通行在海洋與大陸間傳遞資源的貨輪。
遊戲腳本是遊戲引擎不可或缺的最佳搭檔。
可能您會問，既然腳本有這麼多的好處，想必製作起來很麻煩吧？
關 於這點，需要從不同的角度來加以考慮。如果我們以groovy、ruby、python、lua、angelscript這些已經成熟或接近成熟的腳本語 言爲標準來看，那麼開發一種腳本語言的確是件很複雜的事情，涉及到易用性、執行效率、安全性、資源回收、併發等等許多的“額外”問題，而且既然有 groovy、ruby、python、lua、angelscript這林林種種，我們也大可不必耗費心智來重複發明輪子。
但是，如 果我們從與遊戲引擎交互，減少遊戲代碼量的角度出發，那麼自己設計的腳本與自己遊戲引擎間的藕合性當然會較第三方的腳本爲高，代碼量也當然會更少，而且維 護管理也更爲簡便。況且交給腳本來執行的部分，通常也不會對運行效率有太高的要求，我們與大師的差異，也僅僅是體現在決定成敗的“細節”方面，單就構建腳 本解釋器本身而言，完全算不得難事，甚至簡單到一兩個小時就可以搞定一個具有初步功能的腳本引擎（別說腳本，很多80後乃至90後的程序員都開始自己寫編 譯器玩了|||……）。
比如TJS（就是做吉里吉里那個）及RGSS (Ruby Game Scripting System)等，都是爲了更加適應自身遊戲引擎而開發出來的遊戲腳本語言。
下面我將提供一個非常簡單的腳本解釋器代碼，主要功能被集中在一個Command類中。
對於腳本語言，想必我們這些 Java程序員都再熟悉不過，因爲我們每天都在使用的Java，從嚴格意義上講也是一種解釋型語言——畢竟class是憑藉JVM進行字節碼解釋才得以執 行，故而長期被排斥於編譯型語言的門檻之外（但是，由於Java有編譯過程，若CPU支持字節碼那麼class就可以脫離JVM限制，說Java是純粹的 解釋型語言似乎也很不妥＋︿＋……期待java cpu普及中……）。
在這個講解AVG遊戲開發的系列博文中，爲什麼會提到腳本引擎的製作及應用呢？筆者將在下面加以說明。
在遊戲開發中，我們將無可避免的遇到很多重複性工作，比如角色A-Z的創建，物品0-n的編輯，對話x->+∞的添加等等——這些並不是需要複雜的編碼，甚至僅是單純的數據錄入，但由於數據量龐大，通常也會耗費相當的時間進行設定。
如果讓您來做，要怎麼辦呢？以最直觀的方式來說，可能有些人會考慮硬編碼，直接編碼似乎能省去很多的麻煩事。
OK，或許我們完全可以採過硬編碼方式解決問題，比如建立一個對應物品的class，而後爲其添加各種對應字段。
那麼，假設現在我們在某個同人遊戲的開發中這樣幹了，並且將遊戲對外發布。三天後，問題來了，有人反映某物品——我虛構個名字，就叫[對抗網癮專用電棍] 吧。有人反映它殺傷力太低，且對[網癮]狀態無傷害加成……嗯，我們考慮後認爲有道理，怎麼辦呢？一個字——改，反正就是一兩行代碼的事情，重新編譯，打 包，發佈——簡單簡單。
這下高枕無憂了吧？可惜，出乎我們意料之外的事情又再次發生，又過了兩天，有玩家反映我們的最終BOSS[真. 紅色有角.磚家叫獸地獄鬼畜模式]的大招[終極網癮擴散]會將所有我方角色全體[網癮化]，並且會持續投擲[對抗網癮專用電棍]***我方角色，由於改版後 的[對抗網癮專用電棍]***力太強，並對[網癮]狀態有極強的傷害加成，我方角色很容易便會被BOSS團滅。
你問我這下怎麼辦？ 硬編碼的還有什麼新鮮，只能再重新編譯……用戶就是上帝，上帝讓改就改吧……但是，儘管我們非常努力，卻總有欠缺在這個遊戲中存在，如果這樣改下去，三 次、四次、十次、二十次|||，次次都需要重新編譯及發佈，就是再簡單也受不了了（做Java還好，搞C/C++的很多人都經歷過守夜等編譯結果 吧……），恐怕最終此遊戲只好停止發佈，爛尾了事。如果你將每個物品都直接編碼到遊戲當中，那麼毫無疑問你將會陷入到噩夢一般的處境。
爲什麼我們不能選擇更加簡單的方式來處理呢？既然每次重新編譯、重新發布程序那麼麻煩，幹什麼不將配置放在遊戲外面呢？實際上，我們完全可以創建一個文本文 件記錄下所有物品參數，而每次更新時，我們僅需修改此文本文件便可以改變整個遊戲中的屬性設置，再也不必事無鉅細都重新編譯、重新發布整個遊戲了。
事實上，筆者之所以耗費筆墨寫這麼一個例子，無非是爲了說明腳本應用背後的基本準則——簡化軟件製作流程，避免硬編碼。
腳本可以使你真正在遊戲引擎之外編寫代碼，然後再將這些代碼加載到遊戲引擎之中並對它加以執行。一般情況下，腳本是按照它們自己的語言格式進行編寫的，使用 何種語法完全由腳本引擎決定，腳本就好像是運行在遊戲程序內部的小程序，它們的工作原理和其他的普通程序一樣，你可以使用一個普通的文本編輯器來編寫它 們，然後在你的主程序中執行它們。腳本通常使用它們自己的編譯器或者解釋器，它們對遊戲主引擎並沒有任何影響——除非你希望它這麼做。
同時，遊戲和腳本之間通常是分離的。你可以像加載圖形、聲音，甚至早期的物體描述文件一樣加載腳本。但是，你並不能在顯示器上將它們顯示出來或者是通過喇叭把它們播放出來，取而代之的是，你可以執行它們，它們也可以和你的遊戲進行通信，而遊戲也可以作出應答。
簡單的說，如果我們將遊戲引擎和遊戲數據理解爲人與積木，那麼腳本就是用來搭建積木的圖樣；如果我們將遊戲引擎和遊戲數據理解爲海洋與大陸，那麼腳本就是通行在海洋與大陸間傳遞資源的貨輪。
遊戲腳本是遊戲引擎不可或缺的最佳搭檔。
可能您會問，既然腳本有這麼多的好處，想必製作起來很麻煩吧？
關 於這點，需要從不同的角度來加以考慮。如果我們以groovy、ruby、python、lua、angelscript這些已經成熟或接近成熟的腳本語 言爲標準來看，那麼開發一種腳本語言的確是件很複雜的事情，涉及到易用性、執行效率、安全性、資源回收、併發等等許多的“額外”問題，而且既然有 groovy、ruby、python、lua、angelscript這林林種種，我們也大可不必耗費心智來重複發明輪子。
但是，如 果我們從與遊戲引擎交互，減少遊戲代碼量的角度出發，那麼自己設計的腳本與自己遊戲引擎間的藕合性當然會較第三方的腳本爲高，代碼量也當然會更少，而且維 護管理也更爲簡便。況且交給腳本來執行的部分，通常也不會對運行效率有太高的要求，我們與大師的差異，也僅僅是體現在決定成敗的“細節”方面，單就構建腳 本解釋器本身而言，完全算不得難事，甚至簡單到一兩個小時就可以搞定一個具有初步功能的腳本引擎（別說腳本，很多80後乃至90後的程序員都開始自己寫編 譯器玩了|||……）。
比如TJS（就是做吉里吉里那個）及RGSS (Ruby Game Scripting System)等，都是爲了更加適應自身遊戲引擎而開發出來的遊戲腳本語言。
下面我將提供一個非常簡單的腳本解釋器代碼，主要功能被集中在一個Command類中。
爲了與遊戲相交互，此示例構建了一個順序執行的動態解釋型腳本語言，其中每一行實際上就是一組獨立的命令，無論分支或者輸入輸出都僅在程序讀取到本行時纔會活性化， 以此保證與遊戲主程序數據交互的實時性。
遊戲運行界面如下圖：
——————————————————————————————————————
天氣很熱，寫不出什麼正經東西，由於最近[叫獸]很猖獗，隨便做點東西藉機踩踩它（昨天晚上寫的，因爲太熱導致MV歸0，今天晚上才發出來|||）。
不過這星期六、日兩天TLOH基礎部分應該也能寫完了，下週估計能發。總之是個AVG+RPG+SLG的開源遊戲，劇情部分就靠發到網上情大家幫忙添加 ∩ω∩，功能我會慢慢再補，所有對它的意見反饋最終都會歸結到Loonframework-Game這個框架（簡稱LFG）上去。