[六龍爭霸]制作人向楠:遊戲開發的取與舍

Gamelook報道/4月11日,由Unity公司舉辦的Unite 2016大會在上海正式舉行,在4月12日的案例分享專場會議上,祖龍娛樂《六龍爭霸》項目制作人向楠做瞭分享,其以《六龍爭霸》為例講述瞭遊戲開發過程中的技術取舍、優化方法、團隊管理相關問題。

20

以下是演講實錄:

向楠:今天我代表祖龍娛樂,我的演講題目叫取與舍,通常來說我們要做一款遊戲需要知道什麼該做什麼不該做,產品立項的時候就需要設定一個目標。

7

《六龍爭霸》立項目標是要做一款實時3D的MMORPG國戰遊戲,有這個目標就出現瞭一個最大的矛MMORPG面臨一個效率的選擇,作為國戰遊戲通常需要多人同屏,美術表現與多人同屏有點不可調和的矛盾,如何取舍,我們取的是同屏達到200+單位,舍掉的是部分美術表現力。



具體怎麼來實現呢?在遊戲開發中怎樣圍繞這點來做取舍,需要找到取舍的理由,玩傢通常會提出一定的需求,開發者需要對需求提出解決方案,但很難決定什麼該做什麼不該做,什麼先做什麼後做。

8

第一個取舍,是核心玩法的取舍,我們最在乎的是遊戲本身有沒有競爭力,第二個就是產品有沒有商業價值。

什麼叫競爭力,比如有兩款國戰遊戲、都是重度遊戲,如何比較誰更好呢?通常我們會從遊戲的世界觀、遊戲流程、體驗的全民性、多人同屏在線表現、遊戲的吸量能力,來看遊戲好不好、競爭力強不強,但是這些跟商業價值可能有一定的背離。

舉例來說,通常一個有宏大世界觀的產品在競爭力上會更強,但可能帶來一個壞的結果是一旦世界觀越大我們開發量就越多,而商業價值是考慮的是性價比,投入多少能帶來多少收益。

同理,遊戲有自由的遊戲分支,國戰遊戲的是否應該讓部分頂級玩傢有最好的體驗帶著一幫玩傢玩就夠瞭?同屏人數當然越多越好,但需要考慮到底有多少玩傢能得到好的遊戲體驗。很多遊戲希望導入所有的用戶,希望迎合所有人喜歡。

9

《六龍爭霸》希望達到200+人同屏,這個數字是如何定義的?其實六龍的服務端能收到協議其實能到1000人,1000人如何顯示?首先我們得做一個分析,多少人物模型被徹底隱藏瞭,多少人我們用簡化的通用模型,多少人要用實際的模型,然後針對遊戲來看,場景的面數需要很好的控制。

角色和裝備方面,通常來說同屏超過200個單位、Drawcall就會讓CPU變的非常艱難,這個時候需要對遊戲的裝備拆分做一個好的規范,我之前做過端遊,當時產品裝備切分的很細,頭盔、手腕、鞋、包括角色的頭發,都是用不同的貼圖來組合,這麼做的好處很明顯,遊戲的細節變的很豐富,但如果手遊中同時出現20個這樣的人物就不行瞭,因此需要對貼圖進行合理的合並,比如角色從皮膚到裝備就一張貼圖,但是角色不僅僅隻有角色模型,除瞭服裝還有武器要可以換,如果角色再戴上翅膀、坐騎,每次都會在drawcall上計算上去,因此必須對遊戲貼圖drawcall進行控制、才能從整體上控制住CPU的效率。

動作方面,動作需要進行壓縮,Unity提供瞭自帶的壓縮方案,但如果做的是MMO、且動作多的話,可以針對不同的動作做不同的壓縮,我們的簡單經驗是小的動作盡量不要壓縮,比如站立、行走的動作,實際上是持續不到1秒鐘的循環動作,如何壓縮會讓動作變的非常醜,怎樣的動作可以壓縮的比較大?動作幅度比較大的動作,比如角色跳起來砍,壓縮之後其實效果沒有太大的變化。動作壓縮會對遊戲的內存帶來比較大的變化。

特效,其實主要控制的是對整個屏幕的填充率,一個全屏特效會對讓遊戲性能大幅降低,而多個全屏特效會讓遊戲的幀數瞬間掉到不能玩,我們首先要讓特效盡量減少巨大“阿爾法片(阿爾法通道)”,要合理的控制鏡頭的距離,一個真3DMMO鏡頭是可以調的,如何調整玩傢的默認鏡頭、這對遊戲中大的阿爾法片有比較大的影響。

分級機制,當遊戲卡到一定程度的時候,可以對機型、以及當前幀率對不同的特效包括元素進行臨時的關閉,提升性能。

UI,UI通常會涉及到內存以及體驗,通常一個卡牌遊戲UI可以控制在10M之內,遊戲全部加載都可以。但一個MMO遊戲UI單位通常在200個左右,如果直接加載可能要用掉30M、40M內存,對於內存控制來說通常200M以下、最多不能超過300M,因此對UI要進行合理的預加載,比如非常常用的需要預加載,不常用的則要有一個卸載機制,這裡主要是程序在做,但美術做的時候必須知道這些才能更好的控制內存。

技術框架,技術框架的取舍,我們今天主要說客戶端,如何選擇引擎,一個叫設計思維、一個叫實用主義,選引擎方面,如果我們做引擎當然希望引擎高大上,我們在乎的是渲染效率、有很多易用的API、可以跨平臺發佈,且最好是開源引擎、這對程序來說意味著無限的可控性,但本著實用主義來說,5人以下的團隊不用考慮自己的工具鏈,但對於一個MMO遊戲、稍大的團隊,比如超過10個人、甚至MMO團隊可以達到50人-80人則必須要有工具鏈,以及編輯器怎麼去實現很重要,要有強大的編輯器、要有足夠的擴展性、可以開發自己的工具,可實時預覽,預覽在網絡遊戲開發中很重要,如果進行一個調試需要1、2個小時是不可接受的,要有足夠方便調試性能。

10

設計思維和實用思維也存在矛盾,如果說一個引擎做出來遊戲成功瞭一半的情況,那麼大傢完全可以自研引擎,如果項目時間很有限,要在有限的時間內開發完,那麼引擎的實用性就非常重要,我們項目在立項之初就選擇Unity,Unity在各方面都很出色,但相比自研引擎在可控性上相對差一點,當然我們希望Unity能夠給能力強的廠商提供更多開源的支持,這樣或許對Unity的開發生態會更好一些。

11

產品運營調優,我們是一個做瞭2年手遊的團隊,產品調優非常重要,產品能否長期去發展。

12

我見過一些遊戲找100玩傢來玩的時候是很好的遊戲、1000個玩傢來玩依然好,但遊戲在公測後進入10萬人服務器卻出現經常崩潰,遊戲好玩但在運營上缺陷太多,因此我們在遊戲的運營上也要進行取舍,今天我們主要說客戶端。

第一個是包體大小,這是一個很麻煩的事情,以目前中國的現狀來看,網絡條件沒法做到先下載一個遊戲再更新幾百M的可能性,在包體大小控制上需要謹慎,包體大小包括動作的壓縮、貼圖的合並、以及用多大的貼圖去做一個模型,我見過一些團隊做的demo,遊戲看上去沒問題、但仔細檢查一個石頭會用1024的貼圖,這樣等於在包體大小控制上完全沒有預見性。

13

當包體大小不可預見的時候,在遊戲更新機制上也會出現問題,比如修改一點東西就要更新上百M,Unity無論用C#、還是C++寫的都不支持熱更新,需要換包,因此用Lua來寫遊戲的部分邏輯、或者說大部分邏輯是非常現實的,關於Lua大傢上網搜都可以搜到,如果你做的是大項目,用Lua做熱更新會有很大的好處。

Crash監測,越小的團隊越難以把精力放在遊戲的crash上,但很多情況下遊戲崩潰玩傢就流失瞭。在產品運營方面,技術保障我們非常在乎。

14

關於項目管理,這個工作是管理人的事,但我們需要讓所有人認可,簡單說,我們需要所有人前置學習、約法三章,尤其對一個新引擎,要讓所有人先提前去學,如果是邊做邊學我認為項目就走進彎路瞭。

第二,要註重能力的提升,如果大傢用Unity,那麼策劃和美術遇到挑戰,因為要使用引擎策劃、美術也需要一些技術含量,這個時候程序需要給他們進行一些培訓、甚至寫一些插件。

第三個是版本管理,Unity涉及到所有文件關聯beta的設定,如果用SVN管理的時候可能經常產生很大的錯誤,比如下載到一個錯誤的文件導致遊戲半天恢復不過來,讓所有人習慣版本管理非常重要,並且還涉及到版本發佈的問題。

15

最後一個是敏捷開發,對於一個大項目,應該更好的進行分享,並進行更快速的決策,如果項目時間有限,決策過程舍棄團隊更多人參與也很重要。

Comments are closed.