遊戲引擎剖析（八）

原文作者：Jake Simpson
譯者： 向海

第8部份: 指令碼系統

指令碼系統
　　我們從第七部分的遊戲網路問題來到了指令碼系統，因為其呈現的故事敘述機會，最近已經形成一種很大的遊戲元素。在一個需要以受控制的方式解釋的情景，預先編製的電影指令碼是解決問題的方法。在電影中，這通常用來處理或者由主角向一個夥伴解釋情形，或者敵人對英雄解釋。當然，有其它的方法來做這件事情 -- 敘事者，倒敘，等等 – 但通常是使用即時情景的人們和事件來完成。當然，遊戲是不同的，遊戲開發人員在他們平常的FPS中不應該做太多的倒敘，因為通常會需要載入新的環境或者關卡，以及新的紋理和/或模型。所有這些額外的處理和渲染能影響到主要的遊戲序列的效能。你可以重用已經儲存在記憶體裡面的情境元素來倒敘，但那樣會看上去明顯比較粗陋。

　　RavenSoft 的Star Trek Voyager: Elite Force廣泛利用了指令碼序列產生遊戲中的事件和使用遊戲引擎本身的剪輯情境。

　　在遊戲中設計指令碼情節的一個有趣趨勢是使用當前極大改進了的3D遊戲引擎自己產生剪輯情境。現在這可能像是相當地明顯，但是數年以前，當 3D 圖形卡還比較簡單的時候，剪輯情境通常使用高端3D工作站製作，得到的3D動畫然後被記錄為一個數位視訊檔案，以流式檔案儲存體在CD-ROM。你從剪輯情境的漂亮圖形畫面回到真實遊戲的相對粗陋的3D畫面，這是相當令人不愉快的失望的事情。但像Half-Life 和 Star Trek Voyager : Elite Force這樣的遊戲很好地利用了它們自己的引擎產生所有的剪輯情境，結果是剪輯情境和遊戲之間的過渡更加平滑。

　　把指令碼和人工智慧區分開來可能是個很好的主意。指令碼是你完全控制著一個給定情境，建立玩家幾乎總是沒有控制的事件，遊戲者‘沿著軌道’移動到一個給定地點，或者建立一個遊戲玩家需要解決的情形。一個好的例子可能是巨石掉在走廊上，需要遊戲玩家找到一個新的逃脫方法。

　　如今有一些不同類型的指令碼系統可供程式員或者美術師使用，而且它用非常有條理和邏輯的思想恰當地做這些。第一種是簡單的基於文本的，單線索的風格，就像我們程式員習慣的編碼。在許多情況，它實際上基於 C，儘管以一種非常簡單的形式。 大量這種類似“if this，then do that”的東西。大部分指令碼傾向在範圍內是相當線性—意味著它通常由許多在次序上彼此相接的命令組成。在世界中移動角色A指向B。當完成以後，讓他講話，完成以後，移動他指向C。相當簡單的事情。

　　然後有複雜的東西--允許多重線索，和實際上允許可變情形。可變情形是當指令碼開始時你實際上不能確知誰會出現在附近，但是你必須按這樣的方式編寫指令碼以便任何人出現在附近它都將會工作。舉例來說--一個正常的簡單指令碼會有三個傢伙，全部被預先定義，全部有一組他們將會討論的情形。一個可變的指令碼將會有三個人,你不能保證是某一個特定的人，並必須按相同的方式工作。或者在一個極端的情形中，也許只有二個，或者甚至一個傢伙將會在那裡，使得三方交談有一點困難。

　　Raven在Star Trek Voyager: Elite Force中面臨的一個很大的問題是這樣的情形，使用者可能會想要把一個角色從一條船的某個地方帶到另外一個地方，但是從A點到B點的路徑可能會隨著每次遊戲根本地改變。舉例來說，他們需要讓Munro(你所扮演的遊戲主要角色)從發動機艙室到輸送艙。 不幸的是由於遊戲的非直線性，在事件到達這一點以前你可能已經破壞了渦輪升降機，或者也許 Jeffries 管被損害不能通過。假定當指令碼開始的時候我們不知道世界的狀態，我們不得不為幾乎各種可能發生的事情編寫指令碼以便適用於這些‘如果。。。怎麼辦’的情形。而且它僅僅從那裡變得更加糟糕。我們能建立的一些情形提供了如此多可能的組合情形，以致於為了一個滿意的結論而準確測試每一個可能發生的事情幾乎是不可能的。請和在SiN, Star Trek Voyager : Elite Force or Deus Ex中工作的任何人談談。QA部門傳統地憎恨這些類型遊戲，因為這已經使他們的工作比以前更加困難了 50 倍。

　　你能夠想象為這些情形編寫指令碼是何等的困難。但那是今天的非線性遊戲路徑要求的事情，而且它為何博得了較多的開發支援從而能夠努力實現它。

Jim Dose關於指令碼系統的論述
　　去年底我訪談了Jim Dose--Ritual的前任開發人員，現在是Id Software的一個開發人員，Doom3指令碼系統（和其他一些事情）的設計者。儘管這次訪談有些久了，但仍然是很有洞察力。

　　Jim談了指令碼系統和建立一個易用且健壯的系統( 與包含設計者傳統想要使用的所有特徵相反):

　　設計一個指令碼系統最難的部份是知道何時該停止。一旦你完成了並開始運行，你發現有許多能夠利用它的系統。對於Sin，最初的主意只是要有一個比較容易的方法讓關卡設計者描述對象怎樣動態在環境中移動。在項目的後期，我們也使用它來讓聲音和遊戲事件與動畫同步，在多個關卡跟蹤任務目標，控制HUD的布局和遊戲內部電腦控制台使用者介面，描述人工智慧如何對不同的情形產生反應，以及粒子系統。

　　控制複雜度可能也是相當的困難。當你把指令碼的力量放進有創造力的人們手中時，他們開始探究他們所能做的界限。時常，他們受啟發做一些剛好輕微超出系統能力範圍的事情。很容易陷入到這種增加‘僅僅再多一個特徵’就允許他們做他們想做的事情之中。隨著語言增長，一個可能對最初的規格有意義的語言結構變得嚴重過度擴充了。在一些時候，重新思考系統變得有意義，但在那時，你可能已經積累了數量巨大的必須重新編寫的指令碼。和FAKK2一樣，Sin遭受了這樣的損失。我沒有得到對指令碼系統進行大規模徹底檢查的機會直到我為Rogue's 'Alice'.重寫了指令碼系統。

　　阿們，吉姆。-- Raven已經看到這個恰好在他們的ICARUS系統中出現了。ICARUS 實際上是一種與Jim在上面描述的相同種類的指令碼系統，而且負責在Star Trek: Voyager: Elite Force中的所有指令碼事件。它在Soldier of Fortune II和Jedi Knight II : Outcast中被重複使用。為瞭解決系統需要處理的新問題，這些問題在最初的實現中沒有被預見/不需要，指令碼系統的很多部分已經被重新編寫了。

可視化指令碼系統
　　第二種類型的指令碼是可視化指令碼系統。使用這種方法，而不是文字檔的編碼方式，實際上你能夠在真實的遊戲環境中使用真實的角色建立你的指令碼。你能夠追蹤角色在世界中行走的路徑，定義使用的動畫，並且通常得到關於你的指令碼實際上將看起來如何的更好的主意。它對我們已經討論的非線性問題沒有太大的真正的協助，但它確實可以很快速地產生最初的指令碼。

　　其次，Jim談論了可視化指令碼系統。

　　可視化指令碼系統確實有它們的用處，但往往實現更加困難，如果設計得很差，當複雜度上升時就容易讓開發人員感到困惑。舉例來說，人工智慧可以用一個流程圖似的結構來進行可視化的設計。你能非常容易地可視化地表現人的行為舉止方式，用盒子代表狀態，箭頭代錶轉化到其它狀態，指示角色能夠從一個狀態轉換到另外一個狀態的方式。

　　指令碼的一種通常使用是在遊戲世界中控制物體，指示他們他們如何在世界中移動。在一個編輯器中可視化地移動物體到關鍵位置並播放整個運動的能力對一個設計者可能會更加直觀。然而，它確實有它的極限，因為將需要另外一個介面來設計物體在它的移動中必須作出的任何決定。那種能力是把指令碼動畫片斷和類似3DS Max或者Maya 這樣的程式產生的動畫區分開來。

　　在一些時候，使用者可能需要一些方法決定一個指令碼為何沒有做他們所期望的事情。一些形式的除錯工具能使這件工作非常容易。至少，決定哪些指令碼正在運行和指令碼當前位置的一些方法必需的。在指令碼中檢查變數，開始，停止，和逐步執行的能力也是有協助的。通常，一個程式師能夠在他們的調試器中進行除錯，但這個過程要比如果有一些內建的指令碼調試器可用時花費的時間更長。

　　以上就是第8部份，在接下來的章節中我們將討論使用現成產品和定製的遊戲引擎設計工具的功過得失，然後探究遊戲控制機制，開發遊戲對象，和一些刺激有趣的事情 (武器系統)。