來源不清，隨筆

本帖最後由 依克西昂 於 2010-12-9 18:06 編輯

以前提到要寫一篇關於腳本語言技術的文章，我也確實認真的寫了，只是完成以後我發現，這篇文章實

在是太「專業」了一些。且不說讀者是否可以理解，單就趣味而言，這篇文章也是索然無味。
我想，其實腳本語言並不是遊戲開發中的專有技術，而是廣泛應用於各類軟件項目的一種技術。若是單獨

介紹這種技術，未免會遠離與遊戲相關的話題。因此我決定從新立題，以專門介紹腳本語言在遊戲開發

中所起到的做用爲立意，重寫這篇文章。因而，便有了如下這篇拙文。還望你們多多指正。
做爲引擎技術中的一項分支技術，腳本語言是一個很是重要的模塊。那麼，這種技術對於遊戲業的發展

起到了什麼影響？請耐下新來聽我慢慢講述這個過程。
我想各位都知道，早期的遊戲製做人、監製、或者說的時髦些叫作導演也好，至少是半個程序員，並且

每每仍是懂得「彙編語言」這種「甲骨文」的那種。由於那時候的開發工具和環境都十分簡陋，若是一

個製做人想要實現本身想法，最直接的方式就是本身把代碼寫出來！但，假使這位製做人（好比宮本茂

先生）對於編程一竅不通，那麼他只能儘量地和負責程序編寫工做的同事進行溝通，讓程序員經過代

碼將製做人的想法描述出來。當然，程序員可能沒法很好地理解制做人的意圖，最初編寫的遊戲運行結

果可能和製做人的描述有所區別。不過這並非什麼大問題，製做人能夠進一步和程序員進行溝通，對

程序進行修改。若是這種溝通工做作得足夠好的話，毫無疑問，製做人的意圖最終會準確地表如今遊戲

中。
至少在PS以前，製做人和程序員都在以這樣的方式良好地合做着。而後，SS和PS來了，3D來了，大容量

CD來了，空前複雜的遊戲邏輯來了，而後，問題隨之而來了。
咱們能夠想象一下，問題最先是在這樣的一種情形下爆發的：
某天下午，咱們製做人愉快地來到了程序員的辦公桌旁，像往常同樣問道：「程序君，請你修改一下勇

者手中寶劍的做用，我但願當這把寶劍砍中敵人的時候，會使敵人產生中毒的效果。」
程序員：「咕~~，事實上這可能要花些時間，你可能要等上3個小時後才能看到結果。」
製做人：「什麼！3個小時！！我只是改動一把寶劍的做用就要花上3個小時！！！但是昨天你把寶劍的

攻擊力從15改成34的時候只花了幾分鐘而已啊。」
程序員：「是的，那只是改動一個數值而已，我只須要修改一下數據文件而已。可是，‘產生中毒效果

’是一個‘邏輯事件’，若是我要修改該‘邏輯事件’的話，就必須從新編譯程序，這個編譯過程可能

要花費3個小時。」
製做人：「爲何？爲何修改該數據不須要從新編譯，而修改該邏輯事件’卻要從新編譯？」
程序員：「這個問題很難用一兩句話解釋清楚。」（出於一樣的緣由，我也不打算向各位解釋這個問題

，不然這篇文章恐怕會變成一篇超過5萬字的技術論文。）
製做人：「但也不至於要3個小時吧，以前開發SFC項目的時候，你每次不是隻花了十幾分鍾就編譯好了

麼？」
程序員：「這個問題也很難用一兩句話解釋清楚。」（同上）
製做人：「哦，天啊，若是改動一點點邏輯都要這麼長時間的話，咱們怎麼調試遊戲呢！！！」
事實上，以上的情景是一個十分極端的例子，但凡一個合格的製做公司，都不可能到了PS時代還在延續

SFC時代的開發方式。但，這個例子確實反映當時遊戲開發中的一個廣泛問題：因爲遊戲愈來愈複雜，編

譯一個遊戲所要花費的時間也就愈來愈長。因爲當時技術的落後，程序員每每會把遊戲中的「邏輯事件

」直接寫在代碼中。這樣一來，當「邏輯事件」改變時，代碼就必須改寫，而改寫後的代碼就必須從新

編譯。如此一來，每一次改動「邏輯事件」都意味着漫長的編譯過程。
諸位玩過「暗黑破壞神」的玩家能夠想象一下，暗黑中的武器平衡性都通過了漫長的測試和調試。若是

暗黑採用的是以前的例子描述的方式來開發的話，那麼上百件武器的每一次調整都要經歷漫長的編譯過

程，這是多麼恐怖的事情......
而腳本語言就是爲了解決這個問題而被引入到遊戲開發技術中來的，關於腳本語言的實現原理，我不在

這裏作詳細的說明。各位只要知道，有了腳本語言以後，遊戲中的邏輯事件能夠做爲一種資源被加載。

簡單地說，「會使敵人產生中毒的效果」這個事件再也不是寫在遊戲的代碼中，而是寫在一個獨立的文件

中。當遊戲中的勇者使用寶劍的時候，遊戲的核心程序中的「腳本語言解釋器」會去讀取這把寶劍所對

應的事件文件，若是事件文件中寫着「會使敵人產生中毒的效果」，那麼寶劍就會得到「會使敵人產生

中毒的效果」的能力。而若是製做人突發奇想，想要這把寶劍可以使敵人被傳送到某地，那麼程序員只

要將這個文件中的內容改成「可以使敵人被傳送到某地」便可，而不用從新編譯整個程序。這一功能極

大地方便了遊戲的調試和開發，能夠想象若是沒有這種技術，複雜的遊戲幾乎沒有被開發出來的可能性

。（這裏我要說明一下，雖然我以前以暗黑爲例，但暗黑採用的不是腳本語言技術，實際上解決一個問

題有不少種方法，腳本語言也並不是適用於所用狀況的「萬用技術」。）
說道這裏，若是你是一個思惟敏捷的人，應該會很容易想到，其實不僅是寶劍的屬性，遊戲中的全部邏

輯均可以用腳原本描述。那麼當全部的邏輯都被以腳原本描述的時候，遊戲程序中剩餘的核心代碼還剩

下些什麼呢？應該只有繪圖，聲音播放，輸入輸出等功能了，固然，必定還包括一個用於解讀這些腳本

語言的模塊。如此一來，剩下的這些核心代碼不就正是一個「引擎」了麼！因而，很天然地，引擎技術

將腳本語言做爲一個子模塊引入了進來了。有了這一技術，引擎更是如虎添翼。若是抽象地解釋這一做

用，你們可能很難理解。你們能夠回憶一下CS，這個遊戲是有兩個高中生在暑假完成的。兩個高中生爲

什麼可以在如此短短的時間內使用當時第一流的3D引擎完成一個如此複雜且有有趣的遊戲呢。緣由就在

於CS所使用的HL引擎引入了一套很是完善的腳本語言。有了腳本語言以後。這兩位高中生再也不要考慮如

何合理地調用引擎中的各類接口，而只要用腳本語言描述本身所要製做的遊戲中所包含的規則便可。HL

引擎中的腳本語言解釋器會加載這些規則，並向引擎的核心層解釋這些邏輯。核心層根據遊戲邏輯去自

動處理複雜的底層操做。
以前的一篇文章中說過，引擎屏蔽了硬件層和一些最底層的複雜操做，而腳本語言進一步屏蔽了引擎的

最底層的複雜操做。因而，如今的遊戲開發者只要描述遊戲的規則便可，並且因爲腳本語言遠比傳統語

言簡單，因此只有一點程序基礎的人，均可以用腳本語言編寫出複雜的遊戲來。這不但使得傳統遊戲開

發行業大大受益，也是的大量的獨立製做人得以蓬勃發展。能夠說，沒有腳本語言，就沒有今天種類如

此豐富數量如此之多的遊戲。
最後想說一點，和全部的技術同樣，腳本語言也有缺點，最明顯的一點就是，使用腳本語言大的遊戲，運行效率相對較低。由於腳本

語言解釋器會消耗大量的系統。雖然，這些消耗對於PS3或360級別的主機只是九牛一毛，可是對於NDS等

掌機或移動平臺來講仍是不小的。不過這已經再也不本文討論範圍以內。談到這些也只是想讓你們瞭解到

，如今對於遊戲的優化已經不可能像FC時代那樣1k內存那樣的死磕了。事實上，有時候爲了遊戲的總體

效果和開發的便捷性，必須犧牲一部分性能。

http://192.168.0.22/avatar_real/pic/0/0/112/0/0/0/113/114/115/0/116/0/0/0/0_0_112_0_0_0_113_114_115_0_116_0_0_0.swf?v=0