[分享] 我的Uncharted 4開發雜記

[cjcat2266 (CJ Cat)]

之答應過要寫的，剛出爐熱騰騰的Uncharted 4開發雜記~

網誌版本 http://wp.me/p4mzke-WC
英文原文 http://wp.me/p4mzke-VD
系列清單 http://allenchou.net/my-career/

(強烈建議看網誌版本，有精美除錯截圖唷)

Uncharted 4已經發售，終於可以分享我負責開發的部分了
我主要是負責單人模式的夥伴AI、多人模式的戰友AI、還有一些遊戲邏輯
沒有收錄到最終遊戲的部分和一些瑣碎的細工我就略過不提


= 崗位系統 =

在本文開始前，我想要先談談我們用來指派NPC移動位置的崗位系統
這個系統的核心邏輯不是我負責的，我寫的是使用這個系統的客戶端程式

崗位是可行走空間中的離散位置
大部分是用工具自動生成的，也有一些是設計師手動擺置的

基於不同需求，我們設計不同的崗位平分系統
(e.g. 潛行崗位、戰鬥崗位)
然後我們選擇評分最高的崗位，指派NPC移動過去


= 夥伴跟隨 =

夥伴跟隨系統是繼承自The Last of Us

基本概念就是，夥伴在玩家周為找個跟隨點
這些可能的跟隨點從玩家位置扇狀分開
並且要滿足以下的路徑線段淨空條件:
– 玩家到跟隨點
– 跟隨點到前方投射點
– 前方投設點到玩家

攀爬是Uncharted 4的新功能，這是The Last of Us 沒有的
為了與現有的跟隨系統整合，我利用攀爬崗位讓夥伴可以跟著玩家一起攀爬

這個功能比我想像中的還要難搞
單純根據玩家的攀爬狀態來切換夥伴的攀爬狀態，結果不甚理想
只要玩家快速在攀爬與非攀爬的狀態之間切換，夥伴就會在兩個狀態間快速跳換
於是我加入了遲滯現象(hysteresis)
只有在玩家切換了攀爬狀態，並且保持此狀態移動一定距離之後，夥伴才跟進
廣泛來說，遲滯現象是個解決行為跳換的好方法


= 夥伴帶領 =

遊戲中的某些特定場景，我們要讓夥伴帶領玩家前進
我把The Last of Us的帶領系統移植過來
設計師使用spline曲線在關卡中標記他們想讓夥伴帶領玩家的大致路線

如果有多個帶領路線，設計師則會用腳本語言切換主要的帶領路線

玩家的位置投射到spline曲線上，再往前延伸設定為帶領參考點
當帶領參考點超越被標記為等待點的spline曲線控制點，夥伴會前往下個等待點
如果玩家走回頭路
夥伴只有在帶領參考點離此次推進至最遠的等待點一段距離，才會回頭
這也是利用遲滯現象來避免行為跳換

我也把動態移動速度調整的功能整合進帶領系統
根據夥伴和玩家之間的距離，一些”速度平面”沿著spline曲線放置
夥伴有三種移動模式: 走路、跑步、衝刺
根據玩家撞到的速度平面，夥伴會選擇不同的移動模式
另外，夥伴的行進動畫速度也會基於玩家距離做微調
目的是避免切換移動模式的時後，有太突然的移動速度變化


= 夥伴掩體共用 =

在The Last of Us中，玩家和夥伴可以在各不離開掩體的狀況下重疊
我們稱這個為掩體共用

The Last of Us中的Joel伸手跨過Ellie和Tess按在掩體上
看起來很自然，因為夥伴的身型都比玩家嬌小
但是同樣的動作就不適合身型差不多的Nate、Sam、Sully、和Elena
而且Uncharted 4的遊戲節奏較快
讓Nate伸手去按掩體只會讓動作流暢性打折扣
所以我們決定就單純讓夥伴靠緊掩體，玩家稍微繞彎避開伙伴

我用的邏輯很簡單
如果玩家位置往移動方向投射的點，落在夥伴掩體周圍的一個方框內
夥伴就會取消目前的掩體行為，並且快速靠緊掩體


= 救星戰友 =

我負責多人模式的戰友(sidekicks)，而救星戰友是其中最特別的
單人模式中的NPC，沒有一個人的行為跟救星戰友一樣
他們會復甦被擊倒的同伴，也會複製玩家的掩蔽行為

救星戰友會嘗試複製玩家的掩蔽行為，並且盡量待在離玩家很近的地方
所以當玩家被擊倒的時後，他們就可以迅速跑過來復甦
如果玩家有裝備救星戰友的復甦包額外功能
他們會在採取復甦行動之前，朝被擊倒的復甦目標丟復甦包
復甦包丟擲基本上就是延用手榴彈的拋物線淨空測試和擲彈動作
只是我把手榴彈換成復甦包而已


= 隱蔽草叢 =

在隱蔽草叢中蹲行也是Uncharted 4才有的新功能
要實作這個功能，我們需要某種能夠標記場景的手段
遊戲邏輯才可以判斷玩家是否身處隱蔽草叢中
我們一開始是讓美術人員在Maya中標記背景模型的表面
但美術人員和設計師之間的溝通時間太長，很難頻繁改進關卡
於是我們決定用另外一種方法標記隱蔽草叢
我在場景編輯器中的nav mesh增加了隱密草叢的額外tag
讓設計師可以直接在編輯器中精準標記隱蔽草叢

有了這個額外的標記
我們也可以用這個資訊來為隱蔽崗位評分


= 感知 =

Uncharted 4沒有像The Last of Us有聆聽模式
所以我們必須要找另外一種方法，讓玩家有辦法得知附近的敵人威脅
好讓玩家不會在未知的敵對環境中產生迷失感

我利用敵人的感知資料，加入了威脅標示
當敵人開始注意(白色)、起疑(黃色)、和發現(橘色)玩家
這些標示會適時地提醒玩家
另外，我在威脅標示開始累積的同時播放背景雜音，以製造張力
當玩家被發現的時候，則播放大聲的提示音效
這些音效的安排和做用跟The Last of Us類似


= 調查 =

這是在我們送廠壓片前，我負責的最後一個功能
我平常在Naughty Dog是不參加正式會議的
不過在送廠壓片的前幾個月，我們每週至少開一次會
由Bruce Straley或Neil Druckmann主持，專注在遊戲的AI部分
幾乎每次開完會之後，調查系統都有需要更動的地方
前前後後總共經歷了好幾次大改

會讓敵人起疑的因素有兩種: 玩家和屍體
當敵人起疑了(起疑者)，他會抓最近的同伴來一起調查
離起疑點較近的人會成為調查者，另外一個人則是看守者
起疑者可能會視調查者，也有可能是看守者
我們總共有兩組不同的對話，適用於兩種不同的情況
(“那邊有異狀，我去看看” vs “那邊有異狀，你去看看”)

為了讓雙人調查看起來更自然
我使用了時域錯位的技巧，讓兩人的行動和威脅標示時間點錯開
否則兩個人的行為完全同步，看起來非常機械式、很不自然

如果調查者發現了屍體，他會通知全部的同伴開始搜索玩家
屍體也會被暫時標示，以讓玩家知道敵人為什麼進入警戒

在某些難度下，短時間內連續觸發調查，會讓敵人的感應力變敏銳
他們會更容易發現玩家，即使玩家躲在隱蔽草叢中也一樣
慘烈模式下，敵人永遠處於敏銳狀態


= 對話動作 =

這也是我負責的最後幾個功能之一

對話動作系統負責操控角色，在對話的時候做出一些小動作
像是轉頭看其他人和肢體動作

之前在The Last of Us
開發人員花好幾個月的時間，把整個遊戲所有的對話腳本手動加註上對話動作
我們可不想再做一次這種苦工
在這個開發階段，已經有部分對話腳本被手動加註好對化動作了
我們需要一個泛用型系統，可以幫沒有加註對化動作的腳本自動產生對話動作
而我就是負責制做這個對話動作系統
動畫師可以調整參數，改變轉頭速度、轉頭角度、注視時間、反覆時間等


= 維持吉普車動量 =

開發初期遇到的問題之一，就是馬達加斯加的吉普車駕駛關卡
當玩家開車撞到牆或者敵人的載具，玩家的車就會旋轉失速以致脫離車隊而關卡失敗

我使用的解決方法是，當玩家的車撞到牆或者敵方載具的時候
短暫地限制吉普車的最高角速度和線性速度的方向變量
這個簡單的方法相當有效，從此玩家就比較不容易旋轉失速而導致關卡失敗了


= 載具死亡 =

可駕駛的載具是首次在Uncharted 4登場
在這之前，所有的載具都是NPC駕駛、沿著固定軌道行進
我負責載具死亡的部分

摧毀載具有幾種方式:
解決駕駛、開槍射車、開車撞飛敵方機車、開車撞敵方吉普車導致旋轉失速

基於不同的死法，載具死亡系統會選擇載具和乘客的死亡動畫來播放
死亡動畫會漸漸混入物理引擎控制的ragdoll系統
所以死亡動畫會不著痕跡地轉換成物理模擬的翻車

當玩家開吉普車撞飛敵方機車的時候
我使用機車在XZ平面上投影的bounding box和碰撞點
來判斷要使用四個撞飛死亡動畫中的哪一個

至於衝撞使得敵方吉普車旋轉失速
我是拿敵方吉普車與預設行進方向之間的旋轉量差來比較旋轉失速判定閾值

載具播放死亡動畫的時候，有機會穿透牆壁
我使用球體投射，從預設位置投射向載具實際位置
如果投射結果是與牆壁碰撞，則把載具稍微往牆壁的法向量移動
不一次完全修正誤差，是為了避免太過劇烈的位移

我另外實作了一種特別的載具死亡類型，叫做載具死亡提示
這些死亡提示是動畫師和設計師在場景中擺置好的客製化死亡動畫
每個死亡提示在載具行進軌道上都有個進入範圍
當一個載具在死亡提示進入範圍中死亡，則會開始播放死亡提示的特殊死亡動畫
之所以開發這功能，一開始是為了2015年E3展的超帥氣吉普車死亡動畫

https://www.youtube.com/embed/sB0xy74Zrj8?start=475


= 混色用的貝爾矩陣 =

我們想要消除攝影機切入看穿物體的瑕疵，特別是遊戲中的各種植物
於是我們決定要讓靠近攝影機的像素淡出
使用半透明像素並不是個好主意，因為非常消耗效能
我們使用的技巧，是所謂的混色(dithering)
https://en.wikipedia.org/wiki/Dither

使用混色技巧搭配貝爾矩陣(Bayer matrix)
利用一個預先決定的點陣模板來決定哪些像素可以捨棄而不渲染
https://en.wikipedia.org/wiki/Ordered_dithering

結果就是產生半透明的錯覺

一開始使用的貝爾矩陣是個8×8矩陣，取自上述的Wikipedia頁面
我認為這個矩陣太小，會造成不美觀的帶狀瑕疵
我想要使用16×16的貝爾矩陣，但是網路上都找不到相關資料
於是我試著用逆向工程找出8×8貝爾矩陣的遞迴特性
光用目測法，我想我應該可以直接解出16×16貝爾矩陣
但是我想要讓過程更有趣一點
我寫了一個工具，可以生成二的任何次方大小的貝爾矩陣

換到16×16貝爾具陣之後，可以明顯看到帶狀瑕疵的改善


= 爆炸聲延遲 =

這個部份我其實沒有什麼大貢獻，但是我還是覺得值得一提

在2015年E3展示中，Nate和Sully同時接收到高塔傳過來的爆炸聲和爆炸畫面
這是不合理的，因為高塔距離非常遠，爆炸聲應該會晚一點才被接收到
我在開展前幾週指出這點，美術團隊後來就在爆炸聲之前加上一小段延遲了

https://www.youtube.com/embed/sB0xy74Zrj8?start=50


= 繁體中文在地化 =

直到送廠壓片前幾週我才開始在遊戲中改用繁體中文字幕，而我找到了許多錯誤
大部分的錯誤都是英文直譯中文，而變成四不像的用語
我認為我沒有足夠的時間可以單槍匹馬全破一次遊戲又同時抓出翻譯錯誤
於是我請幾個QA部門的人分章節、用繁體中文模式遊玩
然後我陸續瀏覽他們的遊玩錄製影片
結果這個方法相當有效率
我成功地把我找到的翻譯錯誤建檔，而在地化小組也有足夠的時間修正翻譯


= 結束 =

以上就是我對Uncharted 4開發上值得一提的貢獻
希望大家讀得愉快 :)

--

Web       http://AllenChou.net
Twitter   http://twitter.com/TheAllenChou
LinkedIn  http://linkedin.com/in/MingLunChou

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 75.82.92.98
※ 文章網址: https://www.ptt.cc/bbs/GameDesign/M.1462940679.A.BE9.html
推 chris38c28: 推
推 BSpowerx: 你還要負責翻譯除錯喔XD
推 dreamnook:
推 rhox: 推，我猜抓錯只是因為身為開發者不忍看到有錯而已
→ cjcat2266: 沒錯，有些錯誤離譜到我覺得賣出去會丟臉
推 dklassic: SIET 沒有對這款做中文化測試嗎@@？
推 youtien: 很多廠對這種不必花大錢就可以做好的地方都很忽略。
→ youtien: 要不是團隊裡有本地人，翻譯錯誤就難免了。
推 LayerZ: 推
推 RobinpeterH: 太厲害了!!
推 zseineo: 推
※ 編輯: cjcat2266 (75.82.92.98), 05/11/2016 14:21:57
推 aiiueo: 昨天看了別人破關　你那搜索AI讓他痛苦萬分　哈哈哈
推 abucat: 感謝提供自身開發經驗
推 Kendai: 推
推 CiC: 推！ 另外文中有小typo「起疑者可能會視調查者」
推 eye5002003: 你救了一款大作!
推 windzon: 推阿阿阿阿
推 laikyo: 推推
推 Frostx: 推!!
推 leograss: 推推
推 ahsdf0910: 推！我很喜歡這款作品啊！我家櫃子上有一到三，但是最
→ ahsdf0910: 近趕專案還沒買四orz
推 holymars: 那些看起來是不必花大錢就能作好的部份，對大型組織來說
→ holymars: 有時侯是有很多潛在成本的...
推 damody: 有分享有推
推 seedamen: 繼續推~相當立志
→ lemmii: push!!
推 Ekmund: 深深覺得你超萬用...雖說是夢想工作 但從老闆角度來說 真
→ Ekmund: 的撿到個好員工
→ cjcat2266: 還好啦，在ND的每個人都是什麼都做的，沒有固定職責
推 madeinheaven: 推~!!!!
推 w60241: 推推
推 v86861062: :D
推 snowmilkchen: 推!