TGDC | 騰訊互娛天美楊拓:如何打造動態遊戲世界?

語言: CN / TW / HK

GameLook報道/8月14日至8月17日,由騰訊遊戲學堂舉辦的2022騰訊遊戲開發者大會(Tencent Game Developers Conference,以下簡稱TGDC)將正式舉行。

大會以Inspire Six Senses為主題,匯聚國內外頂尖遊戲從業者以及學界專家學者,以激發遊戲的創意力、想象力、洞察力、科技力、影響力和凝聚力,共同拓寬遊戲產業的邊界與可能性。

在8月15日的藝術專場論壇上,騰訊互娛天美L2工作室技術美術專家楊拓,進行了題為《打造動態遊戲世界》的分享。

以下是分享實錄

楊拓: 各位聽眾好,我帶來的分享議題是《打造動態遊戲世界》。我是來自騰訊互娛天美工作室群的專家技術美術師,我的名字叫楊拓。我大概是在2017年加入了天美工作室群,首先是參與了天美L1的《王者榮耀》的專案,接下來參加了天美J3《使命召喚(手遊)》的BR玩法的攻堅,最近幾年回到了天美L2工作室,主要是負責天美L2工作室幾款新專案技術(預研)的工作。

2019年,如果大家有印象的話,當時我是作為天美技術中心的技術美術師,分享的基於程式化生成技術,開發開放世界遊戲場景製作的經驗。幾年過去了,我也是想基於這幾年的工作總結和推進,把自己一些工作狀態和工作經驗做一個分享。

打造動態遊戲世界的分享,大概分為三個部分。第一部分,是打造動態遊戲世界的動機和想法;第二部分,講的是如何打造動態世界,所需要做的一些技術準備;第三部分,我們在執行時支援動態遊戲世界做的技術儲備和實現方法。

下面分享正式開始。首先介紹一下我們為什麼要做動態遊戲世界的支援,以及在實現想法和設計的一些思路。

打造動態遊戲世界的目的是什麼呢?大家也清楚我們的核心目標,其實還是希望能夠實現一個有沉浸感、可重複遊戲的遊戲場景,為什麼要這麼做呢?也是因為當前的大環境下,首先玩家對遊戲的品質要求越來越高,而玩家的胃口和眼界放開以後,對每一款遊戲保持的耐心其實是很有限的。同時也需要我們提供的遊戲有一定的尖叫度,有豐富或經常更新的內容來吸引玩家的關注,這對遊戲內容的開發質量和更新頻率有一個很高的要求。

在現在降本增效的大環境下,這對於不少天美工作室來說不是現實的。我們的想法是在有限的AAA資源和玩法的基礎上,通過一些動態的變化,來實現重複的可玩性。

所謂的動態,我們分為三個特性。首先是支援遊戲品質與沉浸感的真實性,其次是重複可玩、有一定隨機性,也就是可變形,最後需要有遊戲的互動性。

接下來我也基於這三點,簡單展開一下我們到底要做哪些事情。從真實性角度講,作為一個真實的遊戲世界,需要有一定的品質和沉浸。這裡的“真實”並不是照片真實,而是要符合世界觀的真實。

一個真實的世界,從頂到底的大概定義,比如有真實的時間和天氣。如果它是一個城市,應該有一套符合世界觀的城市搭建的結構,在城市裡,有一個真實運作的交通網路和行人系統,這叫一個完整的系統。

而可變性,是這套動態世界的核心,所謂的可變也就是遊戲世界的結構是可以變化的。因為大家也清楚一個遊戲的可玩點,在於它的遊戲體驗和基於遊戲體驗的敘事和任務系統。

敘事和任務最基礎的點就是時間、地點、人物,也就是所謂的動態的三個核心。首先在一個可變的時間框架內,不管是場景的結構和表現,還是人類之間的關係和屬性,都是可變的。在這些可變的基礎上,來實現一個可以重複、可以變化的敘事體驗和任務體驗。

第三部分也就是遊戲性的互動。遊戲的互動,我們把它從最直觀、最即時反應的一些動作反饋,到和場景物件的互動,以及一些任務系統的觸發。

這些任務系統的觸發,通常是被動的,而且是延遲反饋的。意思也就是說,平時的移動是所見即所得,當我們的一些移動或行為影響到世界的變化時,更多是隱性的,或者很長一段時間你才會發現自己的行為對整個世界線產生了一定的影響。

定義完動態以後,如何實現動態的方案呢?

我們知道很多遊戲都是基於EPIC的UE5引擎開發。包括去年Unreal把它們一款開放城市的Demo,也就是《黑客帝國》的資源完整地開源了。它實現了大量的靜態解決方案,從一個城市的搭建到它的車輛、它的行人整套系統都是實現了。

我們如何去實現動態的世界呢?以《黑客帝國》的資源作為例項來講解一下我們的動態有哪些。

首先整個場景結構,大到建築的輪廓或街區的變化,小到一個磚塊和材質都是可變的。因為整個場景的動態結構可變,連帶街道、車輛的行為、走向和交通系統也是可變的。隨著車輛的變化,以及場景的變化,街道上的行人規則也會變化。

場景的動態也會使它產生一定的應激反應。我們的動態實際上就是大型場景從表象到結構的動態操作,以及在這種動態操作的基礎上,我們車輛和行人的行為,以及他們的反饋是否能隨著場景的變化,一直保持邏輯的一致性,其次我們也會從策劃和美術角度來規劃,我們的動態要解決的問題。

大家知道策劃更多的是確保一個遊戲的好玩或遊戲性,而美術決定了這個場景是否好看,也就是它的表現效果。從策劃角度我們總結下來,就是它在動態下的邏輯一致性,而美術表現就是在動態下面表現的一致性,當然這個前提都是在一個高效率,而且邏輯或者表現正確為前提。

基於這些需求,我們知道UE5原生提供了很多基礎支援,大家也清楚一個開放世界肯定有一定的LOD或一些分層的渲染,以及邏輯優化的邏輯。

比如UE5原生的World Partition技術,還有AI相關的技術,以及ECS的優化技術。那麼在這些優化策略的基礎上,它還提供了大量的GI渲染的特性。

有了這些特性,我們的動態是不是完全實現了呢?我們感覺在這個基礎上,還要做很多的事情。接下來簡單介紹一下我們如何在天美工作室群積累的技術棧下,在UE5基礎上對動態遊戲世界的支援進行了改造。

我們引入了數字場景的概念,它和之前理解的數字城市是比較近似的。或者元宇宙大家瞭解的數字孿生技術,這張圖從資產的生產、邏輯的維護、玩家體驗的反饋,這是一個塔形結構,一級級實現數字場景的表現效果和邏輯效果。

通過這個概念,我們也是基於例項,把《黑客帝國》進行了拆解,它也是分為三層。比如組成場景的建築資源、車輛資源和行為資源,這些我們會把它叫做資產層。作為一個數字場景,這些資產層都是在數字場景的邏輯和表現層之下進行排程的。

而我們真正要實現的,更傾向於上面的兩層,也就是我們的邏輯層和渲染表現層,特別是邏輯層部分,因為它才是數字場景最核心的地方,當我們把邏輯層進行完整實現,並把邏輯解釋成表現的時候,最終的動態世界距離我們就越來越近了。

也是因為這點,我們要解答兩個核心的技術。我們理解在不同的粒度下,如何保證世界邏輯和功能,以及效果的一致性。這點確定了整個遊戲在動的時候,它要能夠隨時確保它的動態效果是正確和統一的。另外一點,就是讓場景更快捷地運作和操作,而且在操作後,可以很快反饋操作結果。

在這兩個基礎上,我們以一套做遊戲的方式,必然是它的編輯狀態和執行狀態。在編輯狀態下,就是要把它的表現、邏輯和優化策略準備好,同時要確定一套編輯狀態下,這些技術的管理和呈現的能力。接下來把這些能力平移到執行狀態下,確保在執行狀態下這些屬性也可以很流暢,完整一致性地執行。

上面講完以後,我們首先要做的是什麼呢?是一個動態世界可改變的一個最小單元。為了定義這個最小單元,我們引進了兩個概念,和海外的AAA公司,特別是和育碧這些大廠合作中引進了一個叫T.D.G規則,它就是場景資產在設計和擺放上的規則。

核心目的無論什麼樣的資產,一旦按照T.D.G的規則進行設計以後,它怎麼進行組合、怎麼進行拆解或移動和擺放,都能滿足它的要求,這點就和我們的數字場景裡面所講到的原子化模組功能非常接近。

設計的想法解釋清楚以後,就是工程上的想法。工程上我們引入了原子化的設計這個概念,這在網頁設計和很多專案設計裡都有應用,我們也是把T.D.G規則基於原子化設計做了一個整合,得到的就是最小粒度的原子化模組概念。

這裡做一個簡單介紹,場景裡的每一個磚塊和模型資產,它以前只有美術資產。而我們把它賦予原子化的設計以後,它除了美術表現,還賦予了它技術和設計上各方面的規則。特別是在T.D.G規則的加持上,確保了這個資產無論是渲染效果、渲染優化、美術效果,不管這個模組放在哪,都能維持它的功能完整。而且當這些模組進行組合和擺放以後,也能確定一個更大規模、資產功能的完整,和效能、渲染效果的正確。

按照剛剛所說的,我們對整個遊戲的動態從區域性到整體進行了設計,剛剛講到了遊戲世界以建築為例,從單個的牆面到一個更大規模的建築,甚至一個街區都有不同的變化方式。在不同的變化方式下具體怎麼變、怎麼反饋變化,其實不管在技術上還是表現上都是不一樣的。

我們也是基於原子化模組來實現了,不管它是以單個建築,我們把它叫做站位器或者Place Holder,或者是以建築為單元、叫Prefab,或者更大的單元叫Zone,無論怎麼操作,都能滿足整個功能的完整性。

就像在這個空間裡,無論是移動一個街道也好,還是一個區域性小的範圍也好,它的功能無論怎麼變,應該都是保證功能和渲染效果的支援。在這個基礎上,通過一些更簡便的方法把功能進行組合,就得到了一個動態的場景。

如何更簡化地修改和改變這個世界呢?大家應該也許比較熟悉。其實,就是我們後面所要講的程式化生成技術,而我們的程式化生成跟傳統程式化生成不同的地方在於,我們可以叫做動態或執行時的程式化生成,它和傳統的基於Houdini的程式化生成的差異在哪呢?我覺得有以下幾點。

首先,傳統程式化生成生成的是美術資產,而我們生成的實際上是滿足T.D.G規則的一個帶有玩法、帶有技術優化,以及美術資產的遊戲內容,這是第一點。

第二點,傳統的遊戲化生成,可能是一個瀑布式從0到1的生成過程,而我們的程式化技術除了生成以外,還要起到管理跟整合的作用,就好像下面的影片,它需要的是把一個、幾個簡單的Box變化組合成的場景,通過提取它的輪廓線和一些特徵屬性的方式,最終組合成一個整體的建築,然後再在這個整體的建築裡面由區域性或整體進行改變。當左側的建築輪廓屬性發生變化,右邊的場景效果也會在執行時發生變化。

這樣基於程式化生成技術,我們就得到了一個完整的動態遊戲系統的設計的思路,這也是我們一個動態遊戲系統的設計導圖。從下面可以看到我們的頂層,對整個數字場景結構管理,通過一個執行時的程式化生成技術來進行操作的,它根據不同的資源型別,可以是一個掛在伺服器上的Houdini,也可以是一個UE4伺服器上跑的一個邏輯。

通過數字場景系統的結構,來管理每一個原子化模組,最終確保我們的遊戲場景不管如何動態變化,遊戲的內容、玩法、特性都能持續保持不變。

第一章的內容大概就是這樣,裡面介紹了我們想做的一些想法和思路,接下來的兩個章節,我會針對性介紹一下,我們是如何準備和搭建這些資產,也就是在編輯狀態下,如何設計我們的資源模式,設計我們的原子化模組,以及T.D.G規則。第二部分則是簡單介紹了目前的幾個做得比較好的例子裡面,它是如何在執行時去支援動態效果的。

第二部分,做動態遊戲世界所必須的資源與技術儲備。

之前介紹了數字場景的概念、動態的概念,資產和技術要怎麼準備,才能更好地讓他們在執行時支援動態,這裡面根據前面的章節,就兩個核心問題展開介紹。

首先需要在不同的場景粒度下,都能確保動態的功能一致性;第二,整個場景的動態如何高效地排程、管理和維護。

先講第一個點,也就是如何確保一致性,如何去設計原子化的模組設計,來展開我們的分享。

左側是原子化模組的截圖效果,它也是基於藍圖的概念,把大量的美術資產按照元件的方式封裝成了各種最小的原子項。而右側是從事程式化生成的方法,把左側的這些原子化模組進行整體的展示組合和管理的流程。

先介紹一下我們的原子化模組。這裡面是我們嘗試的一個場景搭建的流程,上面就是一個大型樓房裡的資源,每一個資源我們定義為一個最小的原子化模組。它和整個建築的關係,其實就是一個程式化生成的組合關係,每一個場景,例如這個門有它渲染或技術上的特性。

如果它是一個門,有它遠處的剔除方式;而從玩法上講,有它的物理互動,有它開門的標籤設定,以及可攀爬的資訊;在美術效果上,有材質、有貼圖。根據不同的資產,它所處的場景位置和結構的不同,這些屬性肯定有很大的變化,如果是建築內的場景,它的剔除策略肯定是不一樣的。

但是我們現在也有一個問題,就是如果大家用過UE4會發現,剛才講到所有的設定處於整個場景的各個部分,有些是在它的材質編輯器裡面,有的是網格編輯器,有些是優化的設定面板裡。這樣的話,我們不可能把大量的設定儲存於各個地方,所以我們需要有一個載體,它就是藍圖的BP,通過這個藍圖BP裡不同的元件,來儲存這些設定。

最後得到的構造這一個物件它在整個場景資產上,或者渲染優化上的特性,它在互動、在玩法上的特性,以及它在渲染優化上的特性。

一個牆磚或建築的牆面有這種特性。我們會把它進一步拓展,例如在上面的圖裡面,建築的結構就是一個牆面的效果,還有場景裡面的樹木,它的邏輯和互動肯定不一樣。像天空、河流、地形的T.D.G規則,必然跟建築的規則也是有差異的。

我們也是根據整個場景結構,在建築系統的設計基礎上,把整個T.D.G做了一定的擴充套件,來確保整個場景數字的原子化模組都能支援我們程式化的管理,以及這些數字化功能的一致性。

單個模組有了以後,就是怎麼對場景大量的模組進行大規模的組織與管理。

首先,我們的原子化模組它的組合,並不像一些遊戲裡面是隨機搭建的。首先還是以建築為例,建築的模組它其實有一定的搭建規則,哪些建築做基底,哪些建築怎麼搭,或者是橫向的組合關係還是豎向的組合關係。

就像圖裡的神殿也好,或者是現代建築也好,不同的資產有它的組合關係。這些概念也是程式化生成裡面很重要的一點,除了組織外,就是空間結構的概念。

利用有些資產,比如室內的建築,比如我們的燈、椅子依賴於地板、牆面或房頂,它有了這些關係,它跟其他的資源就是一個附加的關係。有了這樣大量的關係以後,我們的程式化才能更好地對場景進行一個變化。同時在變化以後能進行快速地解析,確保我們的變化和呈現都是滿足效能要求最輕量的方法。

基於這些概念,以下面的例子為例,如果要對一個村莊進行修改的話,通常有以下幾個維度,我們改的是一個建築的結構,也可能改的是一個牆面的材質,甚至因為物理破壞,影響的是某幾塊磚的材質,我們的改變應該從最低的粒度向最高的粒做轉化,應該都能支援才可以。

為了達到這個目的,我們就是要實現一個更高維度、或更全能的場景調控能力。基於這個,我們還是把程式化生成技術進行了一定的優化,以及跟引擎進行了一個內建的管理來進行開發。

大家也知道,整個遊戲場景的製作和管理,從傳統的手搭到Houdini的PCG ,到最新GPU的PCG,每一種方式有它的優勢。手工搭建美術更好搭建,會更靈活,而基於Houdini的程式化,通常由TA或美術主導開發,而基於物聯網的CPU和GPU的PCG是由技術人員來搭建,它基於CPU、GPU內建的程式化生成的優化在於剛剛所講的程式化生成,它生成的不僅僅是美術的資產,它生成的是玩法邏輯,生成的是各種優化的特性,以及各種引擎的底層特性。

考慮到這些因素,我們也是決定後續執行時的動態程式化生成,還是應該由技術人員主導進行開發。

第二點是程式化生成更適合生成哪些。因為Houdini的優勢相對來講更傾向於叫資產的生成,比如用Houdini生成一個完整的場景,而不需要任何美術的參與或者一個開放世界的地形,這些生成的都是一個資產,是把一個場景從0到1的生成過程。

而基於CPU的程式化生成我們叫一個點雲方式,點雲的方式最大的體現也是在《黑客帝國》的demo裡面,特別是在建築類。因為每一個建築的資產都是美術預先做好的單元模組,或者在我們的例子裡叫模組化的單位。這樣真正要生成的是每一個單位它所代表的點,也就是程式化生成裡面的點雲。

這個點雲的資訊,比如它的位置資訊、屬性資訊,修改這些點的成本和更新頻率,肯定是要比地形低很多。所以我們現在的動態,更多是以點雲的方式為基礎來進行的。

接下來用一個示例介紹,我們怎麼把UE5《黑客帝國》demo裡面Houdini的生成,往UE4使用了一些市場資源的CPU城市的點雲生成來進行遷移。

這張圖是我們之前跟天美某個專案組合作的,試做的一套內建的基於CPU的建築系統,時間關係,不做很詳細地介紹。

首先可以看到,左邊這張圖裡面綠色的點,就是建築的輪廓,而右邊就是整個建築的搭建規則和拼接方法,整套流程也是從Houdini的方式進行了平移。

除此之外,我們還實現了資產之間的替換規則。首先可以看到,左側就是我們的數字場景系統,裡面的數字場景結構就是一些點線的組合。“點”大家很清楚,它是場景裡面每一個資產的屬性,不管是它的優化屬性,還是可玩的屬性以及表現的屬性,其實都是存在於這個點裡面的。

而“線”則是代表了這些原子畫像在場景裡面的組織方式,首先屬於一條線上的時候,有一個比較強的關聯結構。當場景發生變化時,優先以線的方式進行變化,這些和Houdini的程式化生成非常近似,這裡不做過多的敘述。

像現在的影片裡面,在UE4實現了各種線框的繪製模式,跟Houdini比較類似,通過這些線框把一個建築的外輪廓確定下來,而一個複雜的建築是非常多的線框組合,我們的程式化生成可以把一個建築拆成多個線框的格式,這樣就能實現更為複雜的建築系統。

而且每條線可以單獨進行編輯,在編輯以後,場景也可以反饋整個線框裡面屬性的變化。除此之外,一個建築的結構,像《黑客帝國》整個樓會分成非常多的層。我們相對簡單,只是分了三層,比如底下這一層,中間的樓層裡面是兩層,中間要加更多層,只需要在節點裡面配置更多的節點屬性,把它拼接起來也可以實現更多層次的疊加。

剩下的像房頂,除了房周圍的邊以外,房頂的自動生成也有一定的策略,整體來說我們把《黑馬帝國》的這套Houdini的程式化生成轉移到了UE4的C++的這套方案裡面去。

上面的,就是一個用市場的資源,把整個城市的結構進行一個線框或簡模化,再把這些簡模化替換成不同主題的建築。

除了生成以後,我們還有管理的功能,管理是對它的資產和主題進行一定的替換,包括對單個和整體資產的替換都能實現。通過這些能力我們支援了建築在動態時候的一個程式化的管理替換,還有全域性維護和改變的功能。

除了剛剛講的建築系統外,我們也做了大量其他的從Houdini往GPU轉化的流程。例如上面的圖裡面,把傳統的Houdini地形系統轉移到了基於GPU的系統裡面去。

但是因為整個計算速度還很難達到實時化,而且除了地形外,河流、植被這些對GPU的依賴很高,會影響到很多遊戲的體驗。所以也是剛剛提到了,除了點雲外,其他的程式化生成方式我們還是儲存在了編輯狀態下,並沒有把它往執行時的實時進行遷移。

第三部分,因為時間關係,我簡單挑了幾個我們已經實現的點,或者大家比較關注的技術點進行講解。

這裡面最核心的是動態世界如何確保它優化或效能的,其次也是剛剛講到了很多次的如何在原子化模組基礎上,確保角色跟場景的互動的一致性,還有是《黑客帝國》裡面的AI,不管是車輛還是行人,是如何動態支援場景,實現它邏輯的一致性的。

在上一章講到了,我們對整個場景做了大量的準備,或者我們把場景的引擎裡面的特性,基於T.D.G和數字場景的概念進行了組合。實際我們基於整個場景的分類,搭建了一套完整的藍圖加元件的模式,這裡面每一個藍圖元件除了它的表現以外,更多是它的一些邏輯性、迭代性以及優化策略。

簡單來講,一棵樹的渲染策略和一個建築模組的渲染策略肯定不一樣,樹和草更多是基於例項化渲染,而建築會用到一些GPU專用的方式,從做法、規格和剔除策略上,肯定是完全不同的。我們也是在這些元件裡面,進行一個設定區別,支援不同的動態效果下如何進行效能的優化。

之前也講到,其實UE有大量的原生和優化的支援。除了這些原生的技術以外,在IEG也好,在天美工作室群也好,也有大量的優化方法。時間關係,這裡不做過多的敘述,我們也是根據上面的原子化的設定,能夠通過配置來確定它在動態的時候,組合也好、單個物體也好,都會選擇一個最適合它的優化策略來進行。

就像上面這張截圖一樣,建築用的是batch的方式,因為它的建築和整體的輪廓要一直保持,所以它肯定不能被Culling掉。而是稍微遠一點以後,通過一些Mesh Merge的方式,類似叫HLOD的方法。

而植被跟樹木則不一樣,稍微遠一點以後,有一些草體可以被剔除掉,來減少Draw call,而小的物件也會根據場景的組織關係,例如建築內的物件稍微遠一點以後,建築立的東西肯定看不到就可以剔除掉。

建築外的物件還要更遠時,才會根據物件之間的組合關係來決定,它到底應該在什麼情況下被剔除,什麼情況下被合併。我們的優化就是在一個動態的時候,要有程式化的管理策略,來決定哪些物件用哪些優化的策略。

另外一點也是我們推進方法時遇到的問題,如果這些元件給策劃和美術用,學習成本和使用難度很高。我們跟引擎團隊配合,實現了一個後置基於藍盾的程式化生成方法,會把整個場景自動化通過配置轉化成一套原子化模組。

當前期策劃和美術需要快速驗證時,不需要了解和學習這些東西,而只需要我們把它進行轉化以後,他們在後期拿到的是一個完整的原子化轉化後的資產,樣就解耦了兩邊的開發的矛盾,也能順利讓這個技術進一步進行落地。

除了優化以外,另外一點就是剛剛講到了場景的互動,這裡面我們也是引入了之前跟育碧合作的一個攀爬線的概念。

攀爬線像左圖裡面,隸屬於每一個原子化模組裡面的線,我們的玩家也好、AI也好,會根據這些線的屬性來確定,當它進行操作時,應用哪些動畫反饋它的操作。

這些攀爬線具體如何組合而成,也是用程式化生成的方式,類似這張圖,每一個模組有自己的攀爬線,當我把這個模組的攀爬線生成或調整以後,可以通過程式化的技術,把這些攀爬線反饋到整個遊戲場景,而不需要每次調整攀爬的規則。

這個是早期的一個例項,可以看到樓裡面的每一個模組,它的攀爬線可以通過Houdini生成或人工的方式來配置,這個原子化模組有了攀爬線以後,當程式化生成的整個建築自然也帶有攀爬線的屬性。一個模組的攀爬功能實現了,基於T.D.G規則整個建築的攀爬也就實現了。

除此之外,我們在程式化生成裡面,也執行了一些優化的策略。例如T.D.G規則裡面,有一些線處於不對的位置,當兩個模組在一起時,這條線是不能攀爬的,我們也是根據一些空間演算法,把這些多餘的攀爬線在執行時或編輯態下進行一定的剔除。

比如圖裡左側的紅線,說明攀爬線起作用,右側變成黃線時,也是經過程式化的演算法,它是一個不可爬的線,就會剔除掉。

整個場景像左側可以看到,是有大量的無用的線。當這個場景用程式化生成組合拼接或人工改變以後,我們的演算法也會自動把這些錯誤的線給變灰掉,這樣也就確保了整個場景如何動態拼接、動態組合,它的攀爬邏輯都是一致的。

最後講一下我們怎麼讓AI更好地支援動態。以道路為例,每個道路車輛是怎麼應用道路、行人怎麼應用道路,我們都是在道路的原子化模組裡面,預先把它的一些功能元件進行設定,這樣的話在執行時,只要把這些資產拼接起來,這些道路的資訊也會動態進行合併,確保了行人和車輛的完整地適配。

這裡沒介紹的核心的點,可能還是我的動態場景怎麼去適配光照,因為現階段美術表現是所有遊戲最關注的點,而光照的效果就是這個重點裡的重點,這也是我之前所講的資產的管理、世界的邏輯和渲染優化裡面唯一沒有提到的,因為這塊確實有很大的難度,這裡面我也會在總結的部分進行一定的闡述。

這次分享並不是一個非常完整的思路或者完整的demo,按介紹的完成度只有50%,或者只完成了資產準備和部分執行時的功能,但為什麼還是要把這個東西分享出來呢?有以下兩個點。

以前我們聽到的各種對外的技術分享,通常是一套完整的方案,例如前些年的各種Houdini的介紹,其實給了大家一種非常美好的印象。實際我這些年應用Houdini,包括把各種程式化技術、工業化技術往專案推進時,還是遇到了大量的問題跟難點。而且裡面也有很多的經驗教訓,我也是感覺從技術分享來講,不應該只告訴結果,而裡面所踩的坑、所遇到的問題和研發過程,其實也是需要為大家分享的。

例如你要推一套完整的工業化方法,我們所面對的問題是先有雞還是先有蛋的問題,就是先做專案,還是先推工具、先推技術。這裡面最大的難點還是在渲染的光照和表現上,如果你沒有資產,根本沒有機會去驗證或研發新的光照技術。所以也是因為這些原因,還是要把這些東西做出來,當做到只差光照時,老闆或團隊會傾斜更多的資源來支援他。

未來我們的想法,整個的程式化技術應該是在整個動態世界,在一個動態場景、動態角色,甚至動態敘事的基礎上,就一個更上層的管理系統。

不管這個更上層的管理系統是玩家的操作,是基於規則的AI,還是更高緯度、深度學習的AI,也就是大家常說的meta-ai技術外,都應該有一個更高階的技術進行一個管理。

所以我們現在做的所有的事情,都是為了能夠把底層的基礎知識,把它的驗證環境搭建好,這樣我們的天美工作室群才有機會去引入更多的AI技術,引入更多的外部團隊,真正地把這套動態世界解決好。

也正是因為這些原因,我在騰訊內部基於IEG所有工作室群的大家業餘的合作或共建的專案裡,立項了一個UGC的工程,基於UGC的專案,它就是為了支援和運作一個動態世界需要的所有基礎的概念,以及所有的資源。

基於UGC的Take a future,我們會在剛剛所講的基礎,引入更多的技術實驗和例項,來說服專案組和IEG,讓大家跟家關注這些技術點。

我的分享就到這裡,謝謝大家!

如若轉載,請註明出處:http://www.gamelook.com.cn/2022/08/493822

「其他文章」