絕地-眾神之詛咒-1.研發過程回憶錄

這兩篇絕地-眾神之詛咒的文章 2008/11 在 ChinaAVG 所發表的回憶錄, 當初花了很多時間寫的, 現在把文章貼回自己的 Blog 灌水, 主要是想用 Google 的 Blog 來備份文章.

------------------------------------------------------------------------------------------------------

由於事情已過了十多年之久, 所以只能憑一些記憶寫下整個研發過程, 能寫多少就算多少吧, 內文也許會有很多 "當時" "那時候" 之類的用語, 用意是來比較當時與現在因時空與環境的不同, 所以在研發過程上也會有些許的差異.

本回憶錄將會分為兩篇文章, 第一篇主要著重在製作過程的描述, 讓大家知道 絕地-眾神之詛咒 從無到有的製作過程; 第二篇會較偏向技術面, 在研發過程中所遇到的一些難題及技術上的問題, 並且如何去克服它, 以及使用到的一些獨特技巧與技術.

--------------------------------------------------------------------






(圖: 遊戲標題選單畫面)

絕地-眾神之詛咒從 1993年開始研發, 費時一年十個月, 在整個製作期間裡臺灣也不乏有國產自製的美式冒險遊戲上市, 不過因為研發團隊對遊戲品質的要求相當的高及嚴格, 每個部份及細節也都希望做到最好; 而且整個研發的過程也不能說是完全的很順利, 因此發售日期一拖再拖, 但也終究是完成了, 最後終於在 1995年正式發售.

這是一家新公司, 整個團隊的人來自四面八方, 只有少數是剛出社會的社會人士, 其餘大都是半工半讀的大專或大學夜校學生, 包含我自己也是個半工半讀的學生; 那時候做遊戲的人真的是在為自己的興趣圓一個夢想, 每一個遊戲人都想要的夢想, 只是這個浪漫想法就現今的角度來看, 那時候還真是太不切實際了, 忽略了一家公司要生存下去最重要的就是要公司賺錢; 就這樣, 一群經驗不足或無經驗的人湊合著只為了圓一個夢想, 而公司老闆比我們更外行, 所以他也認為這月亮真的是圓的, 而且很圓很圓.

公司剛成立之初我們並沒有決定要做什麼樣類型的遊戲, 直到有一天忽然有人提了個案 "我們來做個美式冒險遊戲吧!", 那時候正逢美式冒險遊戲的黃金時期, 在台灣市面上已有很多不同的風格與玩法的作品, 而且也都很優秀, 比如說猴島小英雄 (Monkey Island), 迷霧之島 (Myst), 國王密使 (King's Quest), 幻想空間 (Leisure Suit Larry), 黑暗之蠱 (Dark Seed)...等等很多很多, 在絕地的研發期間也有一些突破性的冒險遊戲上市, 如第七訪客 (The 7th Guest), 第十一小時 (The 11th Hour0)...等等.

因為如此, 理所當然的我們也認為美式冒險遊戲市場是一片的光明璀燦, 甚至當時 Westwood 所研發的凱蘭迪亞傳奇一代 (The Legend of Kyrandia) 在台灣異軍突起而且相當的紅, 遊戲也非常的好玩並也有中文化, 因此我們更深信美式冒險遊戲在台灣也可以賣的很好, 不過我們並不以此為滿足, 我們的野心更大, 我們要打入國際市場!

萬事起頭難, 更何況是從零開始, 整個遊戲從無到有的過程更是艱辛, 決定做美式冒險遊戲後的第一個問題就是 "我們要做個什麼樣的美式冒險遊戲?", 要創造一個屬於自己的遊戲風格並不容易, 最後我們決定以當時在台灣甚至全球紅的發紫的凱蘭迪亞傳奇(一代)做為我們的學習範本, 也就是說 "我們來做個像凱蘭迪亞傳奇一樣的美式冒險遊戲吧! 而且我們還要超越它!!"; 不過我們還算有點志氣一點, 我們並不打算抄的一模一樣, 也就是說我們不抄襲, 我們只模仿, 吸收它的優點, 改良它的缺點, 並且還溶入凱蘭迪亞傳奇所沒有的遊戲元素, 也加入屬於我們自己的創意;

其實絕地上市後被質疑為凱蘭迪亞傳奇Like 時我們並不引以為意, 因為事實上也是如此, 我們覺得遊戲好玩就好, 而且國外大公司也都模仿來模仿去的, 也不是只有我們而已, 又有何不可? 只要不是完全抄襲就好. (說到模仿, 沒有人可以比 Blizzard 更厲害的了, Blizzard 有哪一款遊戲不是從模仿別人開始的?)

當時我們並沒有企劃, 企劃人才出奇的缺, 也就是說, 絕地從一開始到結束都沒有專人專職的企劃, 很多事情都是大家互相討論及分擔, 不久後找來了一個就讀新聞系的學生來負責劇本的外包工作, 為了要入打國際市場, 因此也很明確的告知編劇我們要的是一個連外國人也能接受的題材, 當時我們也很明確的就指定凱蘭迪亞傳奇是一個標準的參考範本.

劇本並非一次定案, 期間還有經過多次的修改, 除了編劇本身自己不滿意之外, 我們也認為某些部份無法使用遊戲的方式來表現, 經過多次反覆的編修之後終於拍板定案. 要特別說明的是遊戲的劇本本身並沒有任何的宗教思想, 其用意只是用來強調世界的形成, 另一個原因就是為了要打入際國際市場, 所以才採用了一個大家比較都能接受的方式.

研發初期因為外包關係無法時常見面, 因此造成與編劇溝通不良, 編劇就此離開團隊, 劇本是有了, 不過只有基本的世界觀及一些重要性的人物及對白, 還有很多東西都還沒有, 如配角, 謎題...等等, 因此大家就開始集思廣益, 七嘴八舌的討論起遊戲所欠缺的內容, 這也造就了這款遊中最弱的一環的產生, 也就是某些的謎題是為了謎題而產生, 而不是因為劇情本身的需要而產生, 如果要說我對絕地唯一挑惕的地方應該就是指這一部份了. 不過, 當你看完這篇文章後再去重頭玩個一次, 然後稍為留意一下, 你就會發覺到某些謎題與謎題之間有一些巧妙性的串連及安排.

整個遊戲的企劃內容也是在邊做邊改下完成, 直到中後期才有一個完整的定案, 我們也參考了其它遊戲一個謎題有多重解法的製作方式, 目地就是希望可以增加謎題的靈活度, 可以為玩家帶來不同的樂趣. 另外, 在其它方面我們也花費了很多的心思與苦心, 我們希望讓玩家在遊戲中每個地方可以玩得很有趣, 很順手, 而不是在折磨玩家, 這些用心良苦的設計都會在後面一一提到, 大家也可以感受到研發一款美式冒險遊戲是有多麼的不容易.

在編劇動工之時, 其它人員也要開始準備前置工作, 就先從美術開始說起吧.

美術首先面臨到的就是畫面風格問題, 我們一致認為凱蘭迪亞傳奇的風格相當的好, 是個不錯的學習榜樣, 所以絕地本身內部的畫風會如此一致原因, 有一部分要歸功於因為我們有一個參考範本, 這也才不會造成你有你的風格, 我有我的 Style, 這是一個遊戲的大忌.

風格解決後再來就是調色盤的問題, 才試畫幾張圖美術就大喊調色盤顏色不夠用, 因為當時使用的解析度是 320x200 256色, 只有 256 個顏色可以用, 和現在的 high color (高彩), true color(全彩) 根本不能比, 畫面要成像的東西這麼多, 尤其是場景那麼多, 256色要能夠讓所有的場景都能夠表現其不同的特色這的確是一個天大的難題, 因此為了那 256色可是傷透我的腦筋, 再加上 0 號色及色彩循環色盤所需要用的顏色, 算一算一下就又少了 17 個顏色.

於是我就把歪腦筋動到凱蘭迪亞傳奇上, 沒辦法, 經驗不足只好看看別人怎麼做, 抓了幾張圖之後發現 Westwood 真是不簡單, 真是太天才了, 除了 0 號色及色彩循環色盤外, 他還保留了 16色讓美術人員可以依不同的場景而更換不同的顏色, 如此一來我們的問題就解決了, 不過美術人員說 16色不夠, 因此我們可隨場景更動的調色盤比凱蘭迪亞傳奇還多, 如沒記錯應該有 32色, 不過這也表示, Westwood 的美術比我們還強.

顏色不夠的問題解決了, 再來就是那些不會隨著場景變化的固定顏色色盤問題, 這些色盤該用哪些顏色? 該怎麼分配? 這可就傷透美術人員的腦袋了, 然後, 我們又把歪腦筋動到凱蘭迪亞傳奇上, 抓了很多圖, 一張接著一張抓, 越看越覺得不可思議, 越看也越覺得恐怖, Westwood 的美術真的是強到沒話說, 強到太可怕, 連我們的美術人員都很懷疑, 那些顏色的色調是真的用人工調出來的嗎? 因為有點寫實又有點卡通, 而且色盤的分佈實在是太完美了, 該有的顏色都有, 不只美術人員, 連我也是越看越神奇, Westwood 的美術真的是可怕到一個境界.

美術有試著調出我們需要的色盤, 不過怎麼調都不滿意, 所以...我們商量了一下, 決定借用一下人家的色盤, 然後把某些不必要的給刪除, 並且空出隨場景變化所需要的色盤及色彩循環色盤, 所以大家會覺得絕地是凱蘭迪亞傳奇Like 這也是原因之一, 因為大部份的色調是一樣的.

(圖: 凱蘭迪亞傳奇)

(圖: 絕地-眾神之詛咒)

在後期, 因為測試而抓圖, 後來覺得色盤的順序和凱蘭迪亞傳奇實在是太接近了, 為了避免不必要的麻煩, 所以在圖形及色盤的轉檔過程中故意打亂色盤的順序, 至少不要讓別人一眼就能看出來這兩套遊戲的色盤是如此的相近.

(圖: 左為打亂前, 右為打亂後)

主角是一個冒險遊戲的靈魂, 也是命脈, 他代表著一個冒險遊戲的中心, 整個遊戲世界都是經由他牽動著; 主角也是玩家與遊戲世界中直接的互動與溝通途徑, 所以造型配色等等格外的重要.

主角的造型與配色也是經由多次的討論及修改, 並且經由大家的投票表決而成, 很多人認為主角和凱蘭迪亞傳奇有幾分神似, 尤其是主角身上的背心, 不過美術人員的解釋是, 因為主角是個旅行畫家, 所以身上穿的是一件旅行背心, 而那件旅行背心裡面有很多小口袋, 口袋裡面則放了很多與繪畫有關的工具 (後面會提到).

配角的部份就沒有經過大家的討論, 而是由各自負責的人員依照劇本自行設計造型等等, 這部份就不多提了, 因為我也不清楚.

(圖: 主角)

場景是讓玩家感受冒險遊戲最直接的一個視覺成像, 也是一個電腦螢幕上佔畫面最大面積的圖形, 由於當時大家經驗都不足, 也覺得繪製手稿太過於費時, 因此就沒有所謂手繪彩稿這種東西, 所有的場景都是美術看著劇本而自行發揮的.

美術直接在紙上隨意打個草搞, 把應該要有的重點畫出來, 然後直接就在電腦上繪製; 另外, 因為美術只自己做自己的部份, 沒有互相溝通, 因而導至部份的場景有些突兀, 甚至銜接不上因而重新修改, 不過這不能怪美術, 因為我們沒有企劃為我們整理劇本應該要有的場景, 分鏡..等等.

其中有一個場景在繪製過後還有經過影像處理軟體處理過, 如神殿外面的光暈就是由影像處理軟體加上去的.

整個遊戲除了遊戲部份片頭及片尾外, 所有全部的圖形都是由美術手持數位筆在繪圖版上, 使用 DP II 一個點一個點手繪而成, 冒險遊戲所耗的圖量是最大的, 他不像 RPG 地圖可以使用拼接而成, 因為冒險遊戲每個場景都有其不同的特色;而且每個人物的動作也不相同, 尤其是在絕地中所有的角色都是唯一的, 所以更沒有辦法像 RPG 一樣可以共用角色的圖形, 這個美術工程之浩大可真是累壞美術人員了, 更不用提還有之後的修改, 去背...等等的繁雜的工作 (後面還會談到技術性的問題).

物品、界面及選單, 也是玩家最直接也最常用的項目之一, 凱蘭迪亞傳奇的直覺性操作是傳統美式冒險遊戲的一大突破, 這點我們學了起來, 不過我們很不喜歡凱蘭迪亞傳奇(一代及二代)的物品欄設計方式, 一代物品欄不夠放, 所以只好丟在地上, 萬一要用到時還要千里遙遙的跑回去撿, 二代的物品欄也不好用, 不夠直覺, 因此我們決定改良這個缺點.

我們採用物品欄使用額外開啟的方式, 我記得最早的版本是在主界面下方有個專門開啟物品欄的圖示, 不過後來這個方法被我推翻了, 因為滑鼠右鍵沒有使用到, 所以建議使用滑鼠右鍵就可以開啟物品欄, 並且為了避免滑鼠在物品欄與場景之間繁覆的移來移去, 還為玩家設計了貼心的點哪裡就開在哪裡, 而不是使用開在固定位置的方式; 另外, 因為物品無法丟棄及丟在場景上, 所以物品欄容量上限的設計是無限的, 也避免了物品欄可能會不夠用的窘境.

(圖: 物品界面)

還有, 因為絕地的主界面不需要物品欄, 所以場景畫面的高度是比凱蘭迪亞傳奇還高的.

上面說到主角設定時有提到, 美術人員為主角的旅行背心裡面設計了許多小口袋, 這些口袋是用來放置旅行畫家所需要的一些與繪畫有關的工具, 而這些工具也就是整個遊戲的所有界面及選單, 這看似用心良苦的設計玩家應該沒發現到吧, 玩家只知道界面是與繪圖有關的工具, 並不知道這些東西是由主角身上的背心所拿出來的. 當初也有想到為主角多設計一個從背心拿東西出來的動作, 不過討論一下後覺得太繁瑣就被大家一致否決.

(圖: 系統界面)

(圖: 遊戲選項界面)

(圖: 讀取進度界面 )

片頭及片尾動畫是到後期才開始繪製, 絕地研發期間第七訪客 (The 7th Guest) 的出現讓我們所有人的眼睛為之一亮, 它的畫面是使用 3DS Prerender 的方式, 因此美術也決定所有的動畫也要使用 3DS 來繪製, 不過因為動畫量太大, 而且當時 3DS 要求的硬體配備規格相當的高, 某些效果也不易使用 3D來呈現, 所以片頭動畫就變成有 3D 也有 2D 的情況, 不過大致上還可以接受, 畫面沒有衝突的很厲害, 而片尾動畫就是全程 3D Prerender 動畫, 那時候的 3DS 還沒有像現在的 3DS Max那麼強, 不過當時第七訪客所呈現的 3D 技術也不是我們能比得上的, 美術人員只是想突破做一些不太一樣的東西.

(圖: 手繪片頭動畫, 正式版本裡中央的小島被移除, 移除原因忘了, 而那個小島就是 '絕地')



(圖: 片尾 3D Prerender 動畫, 字是程式即時畫上去的, 當時 DOS 下還無法播放 AVI 檔.)

為了讓絕地玩起來和凱蘭迪亞傳奇有些區別, 也順便突顯絕地和傳統美式冒險遊戲有所不同, 因此我們決定加入另一種類型冒險遊戲才有的謎題, 那就是 Puzzle Game (益智遊戲), 如迷霧之島 (Myst), 第七訪客 (The 7th Guest)...等等, 不過數量不多, 因為這不是這遊戲的重點, 只是為了要增添與傳統美式冒險遊戲些許不同的解謎樂趣, 我們當然也玩了很多這類型的遊戲, 並且參考他們怎麼做, 然後如何的表現在遊戲之中; 因為小遊戲有過場動畫, 而且不是很復雜的動畫, 所以美術也決定所有的小遊戲的內容及動畫全部使用 3DS Prerender 來繪製.

小遊戲我記得有 5 個吧, 全部都是集思廣益而成, 大家出不同的點子, 但是必須要能符合遊戲劇情的需要, 提出來後再經由大家的互相討論及表決, 只是大家都只出點子及制定遊戲規則, 最後苦的人可是我了, 除了某些是由亂數佈局之外, 為了要讓玩家玩的有變化一點, 因此所有的小遊戲都有兩種以上的解法, , 大家可知道我那時可是煞費了多少的苦心...(泣).

每個小遊戲都有個 Reset 按鈕, 這也是一個貼心的設計, 可以讓玩家在小遊戲中立刻重新再試一次, 而不用退回至主遊戲後再進入小遊戲, 這個一進一出的過程非常的厄長, 會有這樣的設計也是因為我們受夠了第七訪客 (The 7th Guest), 每次要再來一次都必須先退出小遊戲至主遊戲, 然候再觀看那厄長的動畫再次進入小遊戲中, 所以我們就決定不要犯了與別人相同的錯誤, 所以才會有了 Reset 這個按鈕.

其中有幾個小遊戲有固定兩個開場佈局, 而那個 Reset 按鈕的另一項功能, 就是可以讓玩家從兩種佈局中選擇自己想要的來挑戰, 最初的設計並不是這樣, 而是採用亂數的方式去挑選其中之一, 不過每次當我想重新挑戰, 然後都必須不停的按那個 Reset 按鈕切換成我想要的佈局時, 我就決定把這擾人的亂數設計給拿掉, 因為連設計者都會感到厭煩, 那就更不用提玩家也會有相同的感覺了.

(圖: 玩法很特別的一個小遊戲)

絕地也加入了傳統美式冒險遊戲少有的世界地圖概念, 讓玩家方便的穿梭之前去過的場景, 因為我們在玩凱蘭迪亞傳奇的時候, 大家也受夠了它在新舊場景間來來去去遙遠的路程, 這很耗費時間, 而且走多了就會覺得很厭煩也毫無新鮮感; 絕地在遊戲初期不太需要東奔西跑, 所以這項福利要到中期後才能享受得到, 並且這樣的設計也很符合遊戲劇情需要及物品的功能設計, 是一舉數得的好點子.

(圖: 世界地圖可以方便的往返以前去過的重要據點)

美式冒險遊戲少不了過場動畫, 舉凡謎題, 過場劇情等等都是, 由於早期的繪圖軟體沒有圖層 (Layer) 的概念, 因此為了讓人物或特效等等動畫能夠在畫面上正確的位置上演示出來, 美術人員都是直接在畫好的場景上繪製過場動畫, 然候再很辛苦的一張一張的去背, 光是這去背的過程就讓美術人員耗掉很多的時間, 去背好的動畫還要在周圍填上0號色, 這樣動畫才會有透空, 也才能與背景結合.

以上圖為例, 這泡泡是會飄動的, 從左邊飄到右邊, 所以泡泡的圖是一連串的, 總共 15 張圖. 要特別說明的是, 這泡泡只是最簡單的例子, 在絕地中還有很多構圖更複雜的場景, 去背的工夫更不是只有像泡泡這麼簡單而已,

這又是一連串的泡泡過場動畫, 必須把主角畫到泡泡裡去, 為了讓畫面生動一點, 所以主角還會有些動作, 泡泡也會有相對應的變化, 所以不是將主角剪下然後貼上到泡泡這麼單純; 因此光這泡泡與主角動畫就花了美術人員不少時間, 這還只是冰山一角的一個例子. 除此之外, 有很多場景的過場動畫還不只一個而已.

不過就以現在的工具再來製作同樣的東西應該可以省下很多時間, 畢竟以前的繪圖軟體並沒有圖層 (Layer) 的功能, 所以去背往往都很辛苦與費時, 有了圖層之後就等於省了這道功夫, 不但效果會比去背好, 工作效率也會提高不少, 當然, 美術人員的心情也會愉快不少, 因為去背對美術來說是項很枯燥乏味又單調無趣的工作.

因為去背工作實在是太繁瑣, 所以美術後來就想到了一個偷懶的方法, 只要是過場動畫的場景中沒有其它的動態物件 (例如兔子) 或背景動畫 (例如雲), 那麼過場動畫就不需要去背, 直接將動畫的區塊截取下來就好, 而且因為圖形都會經過程式壓縮過, 所以對軟碟版的容量也不會有太大的影響.

主角的死亡問題也是有經過討論, 最初大家討論的版本是讓主角不會死亡的, 因為在凱蘭迪亞傳奇中主角毫無預警的死亡讓我們有點反感, 若你沒有時常存檔的習慣, 一但主角死亡後你就必須再回到之前的進度再重新來一次; 不過為了增加一些難度, 所以絕地後來也加入了讓主角也會有死亡的設計, 並且也認為主角有各式各樣的死亡方式也蠻有趣的.

不過會讓主角死亡的地方並不多, 因為我們不想折磨玩家, 另一方面, 在絕地中還加入了一個貼心的設計, 絕地不像凱蘭迪亞傳奇是毫無預警的方式讓主角死亡, 我們會警告玩家, 沒記錯的話應該所有會發生死亡的事件都會有二次警告, 這警告可以從主角的對話中得知, 第一次警告, 第二次再警告, 第三次...可別說我們沒有提醒玩家喔.

絕地的音樂是外包給個人工作室製作, 由於凱蘭迪亞傳奇的音樂非常好聽及耐聽, 音樂的風格與畫面也搭配的很好, 所以當初我們就和外包指定我們要想的音樂風格是要像凱蘭迪亞傳奇一樣的; 我們邊玩邊給他聽幾首凱蘭迪亞傳奇場景的音樂後 (他不玩 Game的), 他就回去製作絕地的配樂, 過沒多久, 他送來了第一首 Sample 曲要我們聽聽看, 這 Sample 曲將決定絕地的配樂主旋律及風格, 之後所做的配樂都會依照這個型版去編寫, 所以這 Sample 曲特別重要, Sample 曲試聽的結果是大家都很滿意, 音樂的風格和我們的畫面也很搭.

這首 Sample 成了絕地的主題曲, 也是在所有的配樂中我最喜歡的一首. 絕地的音樂除了少部份幾首之外, 其餘的音樂都是被製作可循環播放型的. 這首主題曲被安排在水源封印解開後, 走出去的那的那片森林就可以聽得到.

音效部份起初我們是找市面上 3C賣場所販售的音效庫光碟, 聽了很多張光碟之後並沒有找到合適的, 後來我們從美國買了一整套的專業級音效庫光碟, 這套音效庫被廣泛的使用在好萊塢的電影之中, 可想而之價錢也是不誹的; 絕地大部份的音效都是來至這套專業級的音效庫中, 不過某些音效還是找不到適合的, 尤其是像魔法這類的音效, 因此我們就請製作音樂的外包使用 MIDI 幫我們彈出我們需要的一些音效.

中文語音我們是租了一間錄音室, 然後請錄音室幫我們找專業的聲優來錄製中文語音, 一共找來了一男一女, 其中男的一人扮演四個角色; 錄製過程中我也見識到了專業聲優的本事, 聲音可以說變就變, 真的很厲害, 某些地方重覆錄了好幾次, 除了抓感覺之外, 也順便調整每個角色與聲音的協調性, 我沒記錯的話一共錄了一個多小時, 那錄音室的租金與聲優的費用也真的很不便宜.

程式部份偏向技術面較多, 所以就留在第二篇再來說明.

前面提了, 絕地是要打國際市場的, 因此當遊戲完成之時中文及英文版是同時完成的, 有 1.44吋軟碟版及 CD-ROM 版, 只有 CD-ROM 中文版才有片頭及片尾語音, 而且為了不浪費 CD的容量, 我還特地挑選了幾首好聽的音樂錄製成 Cd音軌, 將 CD 塞的滿滿的; 英文版我記得有賣出去一些, 不過套數好像不多, 因為那時候絕地的畫面已跟不上美國市場, 且美式冒險遊戲正在退燒之中; 此外, 絕地還有芬蘭語版, 簽約的套數還蠻多的, 芬蘭的代理公司也很大手筆, 他們找人為絕地錄製全程語音, 因此芬蘭版的絕地是全程語音版, 為此程式還特地修改了些原始碼才得已實現全程語音的需求.

(圖: 遊戲標題畫面)

(圖: 中英文選單)

(圖: 中文遊戲標題)

(圖: 英文遊戲標題)

絕地的銷售量問題大家應該也很有興趣, 實際套數不清楚, 不過整體沒有賠, 不過只有小賺而已, 其實絕地在台灣賣的並不好, 因為美式冒險遊戲那時候退燒了, 所以大部份的收入都是來自英文及芬蘭語版; 我們所有的研發人員也有拿到小小的分紅獎金, 拿到獎金固然高興, 不過最高興的是好不容易做完了這一款遊戲, 因為所有的人都累壞了, 大家從來都不知道做一款美式冒險遊戲工程是如此的浩大.

絕地的整個研發過程以現在的眼光看來是非常粗糙的, 原因有很多, 所有人員對遊戲的製作經驗不足, 並且是第一次製作美式冒險遊戲, 遊戲製作的參考資料也是極為稀少, 也更不用說會有如何製作傳統美式冒險遊戲的資料可以參考, 當時網路也不發達, 要取得任何有關遊戲製作的資訊非常不易, 只能用土法煉鋼的方式慢慢摸索...等等, 很多很多.

以現在的經驗, 技術, 工具要來再製作像這樣的一款傳統美式冒險遊戲會比以前容易許多, 不過只是解決了技術上的問題, 龐大的圖形需求還是無法避免.

如果你要問我絕地有沒有如我們期望的超越凱蘭迪亞傳奇(一代), 我會告訴你-沒有, 因為 Westwood 實在是太強了, 不論是企劃, 程式, 美術, 音樂, 音效等等, 都不是我們可以輕易超越的, 畢竟 Westwood 是擁有堅強實力且經驗豐富的遊戲製作團隊, 而我們只是一群半工半讀毫無經驗的學生而已, 年輕嘛, 有夢最美, 畢竟我們也都盡了全力, 也很滿意作品最後的成果.

絕地-眾神之詛咒 也是我進入遊戲界以來到現在最滿意的作品.

(圖: 中文版外包裝紙盒封面及背面)

(圖: 左為芬蘭語版 CD 外盒, 右文中文版 CD外盒)

(圖: 上為中文版 CD, 下為芬蘭語版 CD)

(圖: 左為芬蘭語版 CD 外盒背面, 右文中文版 CD外盒背面)

(圖: 說明書的某一頁, 整本全彩印刷, 那時候全彩印刷並不便宜)

(圖: 我花很多時間寫的問題與排除Q&A, 一共寫了滿滿的四頁, 竭盡所能的將玩家有可能會遇到的問題都寫出來並給予排除障礙的方法,)

未完, 待續,


第二篇會較偏向技術面, 在研發過程中所遇到的一些難題及技術上的問題, 並且如何去克服它, 以及使用到的一些獨特技巧與技術.

讓 2D Server 變成偽 3D Server

Server 會使用數格子的原因其來有自, 不過數格子的方式已不太能滿足現今 3D MMORPG 的需求, 不但功能被限制住了, 很多可以做的很精彩的 Gameplay 也被綁死, 在數據精細度上也不夠, 因此如果要讓 Gameplay 豐富一點的話, Server 就必須做一些改變.

如果 Server 是 2D 數格子的架構, 並且也沒有浮點數的情況下, 該如何讓 2D Server 變成偽 3D Server 呢? 下面將詳細的解說做法, 雖然沒有實作, 不過應該是可行的, 而且是在 Server 不需大修改, 只要小小的增加新功能的情況下即可完成, 這方法也適用在所有的 2D Server.

所謂的數格子就是如同很久以前的 2D RPG 遊戲一樣, 走一步就是一格, 打怪的距離是用格子計算, 施法的距離也是用格子計算, 這些在 2D MMORPG 中都算正常, 但是在 3D MMORPG 中可就不一樣了.

如上圖, 這是一張由上往下看的俯視圖, 紅色代表敵人, 藍色代表玩家, 兩個都是近戰系的攻擊方式, 假設攻擊距離是 2, 敵人可以打到玩家, 玩家也可以打到敵人, 看起來是很正常.

如上圖, 當視角切換到側面的時候觀看, 一個在山頂, 一個在山谷, 使用目測就可以很清楚的判斷兩者的距離絕對是超過攻擊距離, 但是為何彼此還能夠互打呢? 這就是 2D Server 直接拿來做成 3D MMORPG 所產生的結果.

這個 Bug 可以避免, 比如說把敵人種遠一點, 或是中間有阻檔牆等等都可以輕易解決, 但是這樣的結果卻大大了限制住 3D MMORPG 應該可以有的 Gameplay.

現在有一個可以彌補這個缺陷的方式, 就是我們讓 2D Server 變成偽 3D Server, 會稱為偽 3D是因為它並不是真正的 3D, 而是我們透過一些方法來讓它真的很像 3D;

想像一下 2D Server, 角色是存在於一格一格的格子之中, 就如同一個棋盤一般. 

現在把這格子給 3D 化, 角色存在的位置就代表一個小立方體.

再想像一下, 如果角色是存在於一個 n x n 格的立方體陣中呢? 或是你可以想像成一個 nxn 格的魔術方塊中.

這就是為什麼要稱為偽 3D Server的原因, 因為角色的 Z 軸也是使用數格子的方式來計算.

為了樣讓 Server 有 Z 軸資料, 所以場景編輯器在輸出場景資料的時候也必須輸出一個高度圖 (Height Map), 這個高度圖是一個 2維陣列,

HeightMap[n][n] = { {5, 2, 5, 2, 5....} …. }

陣列裡每個值就是代表每一格格子的高度.

除了地表的高度之外, 阻檔物的高度也必須計算在內, 因為除了距離之外, 我們還可以讓 Gameplay 更豐富一點 (後面會提到), 有一點必須注意, 因為高度是使用格子的方式在計算, 所以在某些情況下高度要使用四捨五入的方式來計算.

如上圖, 當高度在格子的一半以下時則以不足的條件捨去, 反之若大於一半則無條件增加一格, 會這樣做的原因是因為格子很大, 難免會有高度落於格子的之間, 會使用四捨五入的方式是因為可以讓玩家在視覺上的誤差減到最小, 如此就可以避免感覺距離夠卻打不到, 或是距離明明有差卻還被打到的感覺.

當 Server 有了高度圖後就要開始處理計算的問題, 在任何的距離運算都必須把高度納入運算之中, 有兩種方法, 一種是每次運算時依角色的 x,y 去取得當時的高度, 另一種則是角色的資料本身就有代表高度的 z 值.

在此建議使用後者, 為角色新增一個 z 值, 因為前者的方法每次計算距離時都要去取得高度, 而後者則只有在角色移動的時候才需要去取得高度更新至 z 值, 之後計算距離時只要把 z 值直接拿來使用即可, 當計算一多時, 兩者之間效能上就會有很大的差異.

假設有一個 Vertor3 的 class, 裡面有 x,y,z 值, 細部就不說明了, 只列出兩個重要的函式.

inline int Vector3::Length()

{

　return x * x + y * y + z * z;

}

inline int Vector3::Distance(const Vector3 &kPos)

{

　return (*this - kPos).Length();

}

求得 A 至 B 的距離 nDistance, 這個 nDistance 代表的是 A 至 B 共有幾格的距離,

int nDistance = A.Distance(B);

為了運算速度考量, Length 中並沒有開平方根, 因此攻擊距離 nAttackRange 必須相乘.

if ( nDistance <= nAttackRange * nAttackRange)

{

　// 攻擊.

}

有了 z 軸後就不會有低形高低落差時可以互打的情況, 也為 Gameplay 增色不少. 


既然有了高度圖, 如果只拿來當作距離運算的話豈不太浪費了, 高度圖能做的還不止如此.

如上圖, 在 2D Server 角色走一步後就可從山谷瞬間移至山頂, 所以在中山頂與山谷之間必須要有阻檔牆, 或是完全交由 Client 算, 高度圖在此還有一個功能, 就是可以當做高低落差來使用.

當現在的格子高度與下一步的高度差太多時, 上坡時就可以限制無法移動, 但是下坡時依然可以移動, 而且也省去了做阻檔牆的工時, 除此之外, 這高度也不限於只能在地形上使用, 地上若有障礙物 (如石塊, 桌子..etc) 一樣適用, 甚至還可以做到和 3D Server 一樣的效果, 就是角色可以跳至障礙物上, 而且在障礙物上依然可以進行戰鬥.

這個除了可以拿來給玩家角色使用外, 還可以當作敵人在做路徑搜尋時的碰撞使用, 就不會產生敵人從山谷瞬間移至山頂的情況, 此時只要判斷 z 的差距即可.

此外高度圖還另有妙用, 可以做出媲美 3D Server 的視覺阻檔效果.

如上圖, 在這些地形下其實是不應該被攻擊的, 或者說攻擊不到彼此, 因為地形或地物阻礙了攻擊, 雖然說這效果一般都是以浮點向量運算來達成, 不過數格子的偽 3D一樣可以做到.

先求得 A 至 B 的距離, 這個 nDistance 代表的是 A 至 B 共有幾格的距離,

int nDistance = Sqrt(A.Distance(B)); // 這裡的 Distance 必須要開根號.

有了距離就可以求得 A 至 B 的斜率 S, 但是若 Server 沒有浮點數的話, 斜率就會變得不精準, 在此就要使用定點浮點數的技巧 (不要使用乘法, 速度較慢).

X0000000 00000000 00000000 0fffffff

Server 的數值型態為Int 32 bit 有號數, 扣除最左邊一個正負號 X還有 31 bits, 為了求稍微精準一點, 我們小數 f 取兩位, 也就是 0.99 = 7 bits, 最後剩餘的 0 共有 24 bits = -16777214 ~ 16777215 這個數值區間對於 2D Server 來說是夠用了, 因此

Vector3 A1 = A << 7; // 除了空出右邊 7 bits 之外, 也順便將左邊一位正負號去除, 若有需要請自行加回來.

Vector3 B1 = B << 7;

Vector3 S = (B1 – A1) / (nDistance << 7); // nDistance 要先求出然後才能轉換成定點浮點數.

為什麼 nDistance 要先求出然後才能轉換成定點浮點數? 因為效能問題, nDistance 所代表的是 A 至 B 點有幾格, Server是數格子的, Server 的資料也是以格子計算, 所以一次只要數一格就好, 不需要細到數半格或是 0.2 格之類的.

int nAttack = 1; // 0 = 不攻擊, 1 = 攻擊.

Vector3 kPos = A1;

Vector3 kNewPos;

for (i = 0; i < nDistance; i ++)

{

　kPos += S; // 加上斜率.

　kNewPos = kPos >> 7; // 定點浮點數轉回長整數.

　nHeight = GetHeightMap(kNewPos .x, kNewPos.y); 

　// 角色攻擊高度應該要高於角色原點(腳底)的高度, 甚至可以依身高而有所不同.

　if (角色所在高度 + 角色攻擊高度 < nHeight) // 小於 nHeight 表示該點是在障礙物之中.

　{

　　nAttack = 0;

　　break;

　}

}

if (1 == nAttack)

{

　// 攻擊.

}

高度圖為 2D Server 完成了幾件事,

1. 解決了高低落差時的攻擊距離問題.

2. 解決了障礙物高低落差時的角色行走問題, 甚至可以跳躍, 也可以摔死.

3. 增加了角色攻擊的障礙物判定.

1, 2 都是解決問題, 3 則是增加了更豐富的變化,

MMORPG 中的敵我感知系統

自從電腦遊戲誕生以來, 有許多的遊戲開發者無不絞盡腦汁的想要寫出能夠接近人類思維的 AI 系統, 希望 AI 夠聰明, 反應夠快, 能夠應付各種狀況, 有著和人類一樣的五種感官(視覺, 聽決, 嗅覺, 味覺, 觸覺), 在這麼多的 AI系統中, 敵我感知系統應該算是最廣泛分佈在各種類型的遊戲之中, 但是由於 MMORPG 的 Server 端需要應付大量的 GamePlay 運算及資料處理, 所以在敵我感知系統這一塊算是最弱的項目之一.

從最早的 2D MMORPG開始說起, 那時候的敵我感知系統被簡化到只偵測敵人的接近範圍, 這算是最簡單, 最基本, 也是一直被大量的遊戲並延用之今的一種方法, 它有一個專屬的名詞 - 生命感知, 隨著時間的演進, 漸漸的, 生命感知有些許的進步, 能夠分辨不同的屬性, 陣營, 敵我強弱...等等.

MMORPG 最早的生命感知應該是 1997 年Ultima Online 的 2維(2D) 數格子的方式, 這種方式至今仍有一些遊戲在使用中, 後來為了增加遊戲的精密度, 除了地圖的碰撞之外, 數格子的生命感知已漸漸的被淘汰, 大都已改成向量運算, 從早期的長整數向量到現在大量使用的浮點數向量, 除了精密度提升之外, 也為 GamePlay 帶來了更多的可能性.

如果說Ultima Online 是圖形化 MMORPG 的鼻祖, 那麼1999年 EverQuest 可以算是 MMORPG 的革命者, 這款經典遊戲裡有許多概念依然被現今大量的 MMORPG 所沿用著, 同時也是第一款將敵我感知推升到 3維(3D) 的 MMORPG, 3D化的敵我感知系統更為遊戲帶來了極為豐富的變化.

在 EverQuest 的敵我感知系統中除了生命感知之外, 還有一個非常重要的感知系統, 那就是視覺感知, 簡單的說就是隱形 (和我們一般熟知的盜賊潛行不一樣), 也許它不是第一個有隱形功能的 MMORPG, 不過我認為它是第一個將隱形功能發揮到極至的 MMORPG, 甚至是最後一個, 因為到目前為止我仍然沒有玩到能夠超越它這個系統的 MMORPG.

敵我都會隱形, 但是更重要的是, 不論敵我也都有可視隱形的能力, 這些隱形或可視隱形的能力, 對於敵人來說可能是天性, 也就是這種敵人天生本來就有這種能力, 或者是因為法術的加持; 而對玩家角色來說, 這些能力可能來自於某些職業的法術, 或是一些特殊裝備的附屬能力.

除此之外, SOE 還為 EverQuest 玩家的法術系統設計了一個不穩定因素 (只會影響部份法術), 也就是玩家的隱形術有可能比預期的時間還早消失, 而這個不穩定因素來自於施展隱形術玩家的某項屬性(還會透過一些公式計算), 這個屬性關係到了施法者施展所有法術的穩定性.

可以想像有時候為了穿越一大片敵人或是穿越一個高等區域時, 身上的隱形術有可能消失或是被看穿的刺激感嗎? 或是在某個區域裡, 只有某種法師型的敵人擁有可視隱形的能力, 因此玩家在穿越時就會刻意的避開這些敵人. 或是因為不小心現形或被看穿了, 但是敵人等級低所以不太想理, 然後拖了一大串的火車到處跑的狀觀場面與刺激感 (拖太多也是會被打死的...), 也有因為自己拖火車碾死其它玩家的場面....(樂~), 當然也有自己被其它玩家火車給碾死的慘痛經驗... (怒!!!)

EQ 的視覺感知帶來了什麼? 它為 GamePlay帶來了很多的變化, 也為玩家帶來了很多的驚喜, 這真的很難用三言兩語來說盡, 相信有深入玩過的人應該都會很懷念那種驚喜的感覺.... XD

2002 年 Final Fantasy XI Online 為 MMORPG 的敵我感知帶來了新的體驗, 除了生命感知之外, 還有消形(視覺), 消聲(聽覺), 消味(嗅覺), 在遊戲中我們稱之為三消.

某些敵人還細分到某項能力特別的強, 如視覺看穿隱形, 或是靠聽覺聽腳步聲, 味覺嗅出玩家的蹤跡, 不過其骨子裡還是 EQ 的那一套, 只是換了不同的名詞而已, 這三種實質上的功能可以說是一模一樣, 而且在 FF 11當中, 並沒有把這套系統給發揚光大, 它有為 GamePlay帶來些許的變化, 但是它的影響遠遠不及 EQ 中的隱形術.

2010年末, RIFT: Planes of Telara開始 CB, RIFT 又為玩家帶來了新的敵我感知系統, 除了一般的生命感知之外, RIFT 也加入了視覺感知系統, 不過這個視覺感知和 EverQuest 是不一樣的, RIFT 因為有和 WOW 一樣的 PVP 系統, 所以為了公平起見, RIFT 應該也是沒有隱形術的, RIFT這套視覺感知系統不算是首創, 因為在單機遊戲中出現過很多例子, 比如說 魔鬼戰將(Commandos), 潛龍諜影(Metal Gear Solid)...等等.

如上圖, 扇形的綠色區域為敵方的視覺感知範圍, 若玩家不在感知範圍內的話則不會被發現, 不過 RIFT 的視覺感知的角度會比上圖來得大一點, 而且和單機遊戲不一樣的是扇形不會轉來轉去掃描, 而是敵人的前方在哪, 扇形就轉到哪, 所以遇到會巡邏走動的就要隔外小心敵人忽然轉向.

這視覺感知系統只有在人型或類人型的敵人才有, 而且根據研究好像只會出現在有職業屬性的敵人上, 一般的怪物還是以生命感知為主, 不過人型怪光有視覺感知是不夠的, 所以這類型的敵人是同時擁有兩套感知系統的.

如下圖, 藍色圓點代表敵人, 綠色區域為視覺感知範圍, 紅色區域為生命感知範圍.

會發現的原因是有一次為了閃避敵人, 卻沒有注意其它的敵人, 就這樣沿著如下圖的路線從敵人身旁走過, 而這隻敵人之前為了做任務有打過, 所以知道他的敵我感知範圍很大, 但是這次走這麼近居然沒有被發現, 後來整個 CB 6 就花了一些時間開始研究 RIFT 的敵我感知系統.

RIFT 的視覺感知還不止如此, 他的半徑範圍會隨著職業而有所不同, 近戰類的職業半徑較小, 遠程攻擊職業的半徑就很大, 這時才解開在 CB 4 時就一直很納悶的問題 (我是從 CB 4開始參與的), 問題就是 "為何 RIFT 的遠程攻擊的敵人敵我感知範圍會這麼的大, 這樣的設計很容易 Add, 難道開發小組不知道嗎?”. 相信以後其它的 End-User 應該也會發覺到才是.

即然有了這套獨特的敵我感知系統, RIFT 小組也沒浪費它的特性, 下面就舉個例子, 它在某些地方的敵人配置非常的巧妙.

在一般的 MMORPG 中, 遇到如下圖的敵人配置, 如果要從 A 走到 B 的話, 可以有幾種選擇, 清掉上排的怪, 或下排, 或全清, (一般的 MMORPG 因為只有生命感知, 所以通常範圍都有相當程度的大小).

但是在 RIFT 中你可以有另外一個選擇, 你可以把他當作匿蹤遊戲玩 XD (誤), 同一個地方為了解任務難免會路過或者就是任務區挑怪打而來很多次, 不過要小心, 通常也會有巡邏的敵人走來走去.

除此之外, RIFT 的敵我感知系統是會被障礙物所遮蔽的, 它的障礙物遮蔽比 WOW 更勝一籌, WOW的障礙物遮蔽以某方面來說可以說是假的, 即使是繞到樹後方(不論大中小樹), 只要敵人是遠程攻擊型的一樣會停留在樹的另一邊, 法術及弓箭照樣穿樹而過, 當然我們都知道是為了節省 Server 運算效能考量.

不過 RIFT的障礙物遮蔽可就不同了, 它做的非常的漂亮, 對於這個障礙物遮蔽當然也花了些時間研究了一下, 一度還以為是 Server 有計算多邊形或是有好的障礙物篩選演算法, 甚至是利用雲端運算 (User 的電腦是雲), 結果應該都不是(我猜的), 而且很容易就可以做到.

也許再過個幾年, 又會有更新潁的敵我感知系統出現在 MMORPG 吧.

Early-Z

介紹 Early-Z 之前先來回顧一下 Z-Buffer 的歷史. 並且會以 DirectX 為例.

最早還沒有 3D 加速卡之前, 為了解決深度排序的問題, 因此發展出了各式各樣的演算法, 但是對於太複雜的物件時, 深度排序依然無法完美的解決問題, 因此後來就發展出來了 Z-Buffer, 最早的 Z-Buffer 是屬於軟體 Z-Buffer, 後來才成為 3D 加速卡的標準規格.

Z-Buffer 解決了複雜的深度排序卻也帶來了另一個問題, 就是 3D 加速卡才有的問題-像素填充率, 簡單的說明像素填充率就是顯示卡每秒能畫在螢幕上的像素的數量是有限制的, 而每顆 不同等級GPU 所能承載的像素填充率也不相同.

但是隨著遊戲畫面越來越精細, 物件越來越多, 這個問題就越來越嚴重, 畫面上同一個像素的位置被重覆畫了太多次, 我們稱之為 Overdraw, 因此後來才會有建議在 Render 時儘量由前畫到後, 利用 Z-Buffer 來過濾 Overdraw 的問題, 這方法就和軟體 3D 為了解決深度排序的問題由後畫到前不同了.

只是演算法沒有完美的, 硬體也沒有完美的, 在硬體的限制下, DrawPrimitive 與 SetRenderState 呼叫越多次, 速度就會越慢, 所以在複雜的畫面之下該用什麼方式 Render 一直是被討論的話題. 由前畫到後, 可以解決 Overdraw 的問題, SetRenderState 卻有可能成了效能的瓶頸; 使用 Texture 優先 Render, 可以解決頻繁切換 SetRenderState 的問題, 但是又有 Overdraw 的問題, 哪個方法好是見人見智的問題, 每套不同的 3D Graphics Engine 的處理方式也不一樣.

幾年前 nVidia 發表了一項技術 – Early-Z, Early-Z 的做法就是先將畫面的物件(所有或部份物件)的 Z 值先寫入到 Z-Buffer 中, 如此一來就可以解決一些問題, 但是結果並非如此完美. 為了讓物件 Z 值先寫入 Z-Buffer 中, 物件必須渲染兩次, 第一次先將 Z 值寫入, 第二次才真的將物件繪製出來. 這個方法帶來了極大的代價, 而且並不是每種狀況都適用.

1. 渲染過程變得更複雜化, 因為第一次只寫入 Z 值不繪出物件, 遊戲中幾百甚至幾千個物件的 RenderState 都必須設過, 即使是在最優化的情況下, 一定數量的 RenderState 設定還是無法避免, 更不用說你還要使用什麼樣的 Render 順序, 以及將物件給提取出來...等等, 這些都是效能的消耗.

RenderState 就像一個個的開關, 在 DirectX 9 以前, 一次只能開關一個, 所以要設幾個就必須呼叫幾次, 到了 DirectX 10之後, 新的硬體架構允許一次設定多個 RenderState, 也就是一次就可以開關好幾個 RenderState.

那使用 Shader 呢? Engine 裡某些基本事情還是必須做的, 更不用提 SetShader Code還要再做一次的問題了.

2. 由於物件要繪製兩次, 因此呼叫 DrawPrimitive 的次數也會變成兩倍, 所有的 DirectX 教學都再三的警告我們要減少呼叫 DrawPrimitive 的次數, 因為 DrawPrimitive 是很非常耗效能的.

3. 物件的頂點全部都要計算兩次 (Vertex Shader).

4. Alpha 物件無法參與 Early-Z.

那麼難道 Early-Z 真的沒有用嗎? 當然是有用, 但是要看情況, 就以 MMORPG 來說應該是不適用的. 第一個使用 Early-Z 技術的就是 Doom3, 但是它使用是有原因的, 因為它的 Pixel Shader 使用量非常的吃重, 因此 Early-Z 可以來幫助它減輕 PS 的負擔.

隨著技術的演進, 硬體也跟著演進,

這是 DirectX 9 管線的一角, 圖中可以看出, Depth Test 是在 PS 之後, 因此 Early-Z 的卻是有幫助的.

下圖則是 DirectX 10 管線的一角, 圖中可以看出, Depth Test 是在 PS 之前, 是的, Early-Z 已和 Z-Buffer 一樣變成由硬體加速的標準規格了.

但是, DirectX 10已移除了 AlphaTest 由 texkill 來做, 因此如果有 Alpha 物件的話就會使得 Early-Z 失效.

感覺 DirectX 9 更應該使用軟體 Early-Z 不是嗎? 但是你願意付出上面那幾點中的 1 ~ 3點來換取小小的效能提升嗎? Nvidia 說可以提高 20% 以上的效能, 這是有限制的, 在 MMORPG 這麼複雜的畫面之下根本是不可能達到這個數字, 而且動態物件很多, Alpha 物件也不少, Early-Z 能做的其實非常的有限.

在公司新的 Terrain Engine 中做過實驗, 雖然Terrain Render 是純 Shader, 但是因為分割成一個個小塊, 因此 DrawPrimitive 和其它都無法避免多次的呼叫, 在效能上不但沒有提升反而變得更糟.

另外就是渲染過程變得更複雜化就覺得很不值得, 程式會變得更難維護, 更不用說當你的效能瓶頸不是在 像素填充率 或是 PS 上時, Early-Z 就更顯得沒有意義.

DirectX 10 之後 Early-Z 已由硬體支援加速, 因此軟體 Early-Z 也更沒有必要.

想要在 DirectX 9 上使用 Early-Z 最好先確定.

1. 效能瓶頸在像素填充率上.
2. 效能瓶頸在 PS 上.

當瓶頸在像素填充率上時, 先看看你的 Render 順序的演算法是否有弄好, 物件的裁剪是有否做好, View Frustum Culling 是否有做好.

當瓶頸在 PS 上時, 先看你的 PS 是否處理太多的事情, 某些運算是否能夠移到 VS 就先做好. 目前公司的要求的低標配備是不允許有大量的 PS 運算的.

然後, 最後再來考慮 Early-Z 的問題, 如果你效能瓶頸不再這兩項上, 使用 Early-Z 只會增加困擾而已.

什麼時候 DirectX 9 該用 Early-Z? 以目前來說是不需要.

1. 想要減少 RenderState 的呼叫必須使用 DirectX 10以上, 以目前公司要求的低標配備是不允許的.

2. 想要減少 DrawPrimitive 的呼叫必須使用就必須使用 Hardware Instance, 這功能要 DirectX 9.0c Shader 3.0 以上才有的功能, 以目前公司要求的低標配備也是不允許的.

那麼當公司的低標配備提高了的話是否就可以使用軟體 Early-Z? 那時候就不如直接上 DirectX 10 以上吧.

Ogre3D 與 wxWidgets

Ogre3D 與 wxWidgets 連結的基本元件已處理完畢, 接下來就是要正式開始製作工具的內容, 會先從地圖編輯器開始.

所謂工欲善其事必先利其器, 因此工具 UI 的 Layout 顯得格外的重要, 這部份可能要花一點時間來構思, 目前正在下載 UDK 當做參考, 雖然說是不可能寫成像它那樣, 不過拿來參考看看它的 Layout 及其它的功能應該還算不錯, 也順便想想是不是有哪些東西當初有漏掉了, 或是換另一個方法來做或許會更好.