nebula2的指令碼系統實現了乙個面向c++的指令碼介面, 它把指令碼命令直接對映到了c++方法. 從技術角度來說, 這是乙個簡捷的思路, 但是對於需要把遊戲邏輯和行為指令碼化的關卡設計師來說, nebula2的指令碼系統太底層和透明了.
關卡邏輯指令碼一般來說構架於比c++介面更高階的層次上, 直接把指令碼命令對映到c++方法會把指令碼層次弄得錯綜複雜. bug甚至會比同樣的c++**更多, 因為指令碼語言一般缺少強型別檢查和」編譯時」的錯誤檢測, 所以在本應在c++編譯時發現的bug會在指令碼執行時才發現(這對於不同的指令碼語言有所不同). 這是我們從project nomads中得出的經驗, 它就是用nebula2的指令碼系統驅動的.
所以教訓就是: 把你的指令碼架構在乙個正確的抽象層上, 並且: 把你的c++介面對映到一種指令碼語言是沒有意義的, 因為那樣你不如從一開始直接用c++來做這些東西.
相應的, 新的nebula3指令碼哲學為關卡設計師提供一些在」正確的抽象層」的(大多是限於特定應用)積木. 當然, 「正解的抽象層」 很難來定義, 因為這要在靈活性跟易用性之間找到乙個平衡( 例如, 乙個」pickup」 命令是不是應該把角色移動到拾取範圍內呢? )
除了太底層以外, nebula2的指令碼系統也有一些其它的缺點:
下面是nebual3的底層指令碼的大概:
這個觀念比nebula2更為簡單, 最重要的是, 它不會跟nebula3的其它部分交織在一起. 甚至可以通過改變乙個#define來編譯乙個沒有指令碼支援的nebula3.
當然, 書寫指令碼命令的c++**跟nebula2一樣煩人, 這是nidl的由來. nidl的是全稱是」nebula inte***ce definition language」. 基本思想是通過為指令碼命令定義乙個簡單的xml schema並把xml描述編譯成派生了script::command的c++**, 來儘量減少書寫指令碼命令的重複性工作.
對於乙個指令碼命令必不可少的資訊有:
還有一些非必須, 但是可以帶來便利性的資訊:
大部分的指令碼命令翻譯成了大約7行的xml-nidl**. 這些xml檔案再用」nidlc」nidl編譯器工具編譯為c++**. 這個預處理是visualstudio完全整合的, 所以使用nidl檔案不會為程式設計師代來任何困難.
為了減少亂七八糟的檔案(編譯生成的), 相關的指令碼命令被組織到乙個叫作庫的集合中. 乙個庫由乙個單獨的nidl-xml檔案表示, 並且它只會被翻譯乙個c++標頭檔案和乙個c++源**檔案. 指令碼庫可以在程式啟動時註冊到scriptserver, 所以如果你的應用程式不需要指令碼訪問檔案的話, 僅僅不註冊io指令碼庫就可以了. 這會減小可執行檔案的體積, 因為聯結器會把沒有用到的指令碼庫丟棄掉.
最後, nebula3放棄了tcl作為標準的指令碼語言, 而採用了執行時**更加小巧的lua. lua已經成為遊戲指令碼的準規範, 這也使得尋找熟練的lua關卡設計師更加容易.
37 指令碼系統之令牌流
檔案是由分開的不同文字塊組成的。這些文字可用作命令 屬性名稱 字串 數字等。所使用的這些內容有乙個共同點，即它們是用分隔符分開的。分開的每一組文字稱為乙個令牌。檔案可以由許多令牌組成，每個令牌都有自己的用途和含義。在不考慮出現令牌原因的情況下，令牌只是一些文字。如果願意的話，有時可以將檔案分隔成一系...
quake3的指令碼系統
quake3使用虛擬機器的方式或者共享庫的方式，實現引擎和具體遊戲的解耦。引擎檔案為quake3.exe 而遊戲實現又分為client server,ui 三部分，格式及其實現方式為dll和qvm 引擎中和 客戶端有關的函式字首為cl 伺服器有關的函式字首為sv ui有關的函式字首為ui 遊戲程式中...
quake3的指令碼系統
quake3使用虛擬機器的方式或者共享庫的方式，實現引擎和具體遊戲的解耦。引擎檔案為quake3.exe 而遊戲實現又分為client server,ui 三部分，格式及其實現方式為dll和qvm 引擎中和 客戶端有關的函式字首為cl 伺服器有關的函式字首為sv ui有關的函式字首為ui 遊戲程式中...