第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部份，在接下來的章節中我們將討論使用現成產品和定制的游戲引擎設計工具的功過得失，然后探究游戲控制機制，開發游戲對象，和一些刺激有趣的事情 (武器系統)。