王者榮耀成功的背后,看騰訊是如何針對自家產(chǎn)品做底層支持的
騰訊作為游戲界的巨頭,旗下游戲項目眾多,涉及品類也十分廣泛,在騰訊游戲取得的矚目成績之下,離不雄厚的開底層技術積累所提供的支持。在騰訊體系下,已經(jīng)可以實現(xiàn)依靠一套通用的底層技術實現(xiàn)多品類游戲開發(fā),并解決多品類游戲研發(fā)和運營中出現(xiàn)的各種問題。
技術人員作為騰訊這個巨擘的幕后英雄鮮少走到臺前被人們所熟知,但在今年ChinaJoy期間的中國游戲開發(fā)者大會上,來自騰訊的資深技術人員吳嘉偉為大家分享了騰訊底層技術這么多年來積累下來的經(jīng)驗。
龍虎豹將他的演講內(nèi)容進行了整理,由于并非專業(yè)技術人員,在聽寫過程中可能會出現(xiàn)錯誤,歡迎讀者朋友指正。
以下為吳嘉偉的分享。
我今天分享的題目是“談騰訊精品游戲的基礎技術體系”,有一個問題是,到底什么是基礎技術?基礎技術這里我做一個簡單的定義,我認為它說的是圍繞游戲新玩法這樣一些底層技術的集合。那么,底層技術它也分了很多,怎么去做一個分類呢?我這里大概就簡單分了有六個,第一類大概就是引擎技術,引擎技術其實也有很多這種細分的品類,比如像2D的引擎,它可能更強調(diào)打擊感,像3D引擎可能它更強調(diào)是用戶上手的程度,像Hero引擎就更加強調(diào)游戲畫面的寫實性。下一個比較重要的技術,就是整個游戲的基礎框架,基礎框架實際上它是決定著游戲在上線之后的過程中,整體運行的一個效果,那么同時它也是決定游戲在研發(fā)初期,去快速完成代換的這樣一個可行性。 第三個,就是網(wǎng)絡通訊部門,其實一直都是網(wǎng)絡游戲開發(fā)以來比較基礎的模塊,但是現(xiàn)在談的更多是在弱網(wǎng)的條件下,技術模塊的效果,以及在全球發(fā)行化的過程中,整個的網(wǎng)絡通訊的方案。
音視頻技術,其實很早以來都是整個游戲里面比較基礎的模塊。好像它和一個游戲整體的玩法沒有太大的聯(lián)系,隨著現(xiàn)在游戲整體品類不斷的發(fā)展,其實我們看到現(xiàn)在有越來越多的項目,像狼人殺、MOBA、FPS游戲里面的這種組隊開黑的玩法,其實也逐漸碰到這樣一些核心的玩法。關于測試這方面,其實它主要是保證整體測試,保證游戲在整體發(fā)布之后的整體質(zhì)量。游戲安全這一部分其實很簡單,主要是保證整個游戲的一個公平性,以及個人財產(chǎn)的安全性。我今天主要是圍繞技術框架,網(wǎng)絡通訊以及音視頻相關的給大家做一個簡單的分享。
我們來看一下騰訊基礎的底層框架,實際上它經(jīng)過了十多年的發(fā)展,從最開始端游的時候發(fā)展而來,不管是從網(wǎng)絡介入,還是從數(shù)據(jù)存儲,從數(shù)據(jù)的描述和表達到底層的小型中間件;從與游戲邏輯相關的一些特性,包括到整體的逐漸的管理,運營用戶的與數(shù)據(jù)相關的附件,都有相應的一些設計。在整體的組件里面有幾個比較關鍵的技術,第一個是Debussy技術,它其實主要是負責基層間通訊或者是跨界通訊的這樣一個技術。另外一個,是一個叫做T/R的組件,這個組件主要是負責數(shù)據(jù)的序列化以及轉序列化相關的這樣一些工作。同時它還有各種數(shù)據(jù)表達的這樣一些能力,比如說像內(nèi)存、文件或者是excel等等,只要有基于TGR數(shù)據(jù)的描述,都可以相互地轉告或者是打通。另外一個,實際上重要的是Torm組件,其實是一個數(shù)據(jù)關系對象的組件,它能夠將mqsql表的管理縮減為整個對象管理。
在端游時代,實際上分區(qū)分服這種架構設計,整體對數(shù)據(jù)庫的壓力其實不是太大,隨著手游玩法的變更,全區(qū)全服這種結構似乎越來越盛行,那么我們也發(fā)現(xiàn)到,qver存儲效似乎護會更高一點。在此基礎上,我們開發(fā)一個叫做techbus的組件,這個組件主要是能夠在海量的用戶中,從一個比較好的性能,成本之間達到一個比較好的效果。其實隨著整個底層框架時間的發(fā)展,我們其實發(fā)現(xiàn)整個組件規(guī)模越來越大,參數(shù)也越來越多,編程也越來越復雜,整體升級以后的難度也越來越高。在此基礎上,我們將這些離散的組件把它集合起來,然后統(tǒng)一優(yōu)化,形成優(yōu)化的這樣一個服務,這個也大大加速了整體游戲接入的一個效果。剛剛講的大概是基礎組件以及整個在服務化引進的相關的一些事情,實際上后臺的這樣一些框架組件,其實他們扮演的是幕后英雄這樣一個角色,很難被前端用戶或者大部分玩家感知到。而我們能感受到的,包括比如說像游戲下載速度是不是夠快,或者是不是很好地能夠去體驗到副本的一些玩法。那么我在整個接入的過程中,是會出現(xiàn)這種卡頓的這樣一些情況,包括說我在與人副本會在溝通的過程中,或者說在開黑的過程中,整體語音的這種交互是否是足夠地清晰,實際上這些是能夠被用戶所感知到的。
接下來,我將從技術基礎它如何去改善用戶體驗的這樣一些角度去做一些簡單的分享。我們首先看一下整體的一個游戲中心;第二我會介紹網(wǎng)絡相關這樣一些模型,包括像對戰(zhàn),像MMO這些接入的問題;第三個主要是會介紹一下整體的語音在游戲中應用的這樣一些情況,第四個就是講一下我們整個游戲一個對外服務或者對外推廣的情況。
我們首先看一下游戲更新這一塊主要挑戰(zhàn)大概是什么。其實這里它們會存在兩個矛盾。第一個矛盾,就是說游戲安裝越大,然后推廣成本越高,簡單來講,一個100兆的包想把它推廣下去,或者一個150兆的包想推廣下去,其實這整個成本是不太一樣的。第二個就是說對于整體的分發(fā)類的用戶問題,其實在整個一個分布的環(huán)節(jié)下都會存在這樣一個問題,那就是劫持問題。這些問題到了最關鍵的因素,就是整個游戲業(yè)務在推廣或者說在活躍回復的情況下,可能是說沒有達到你的預期,因此整個的一個下載更新或者整個推廣的一個方案,需要在整體的唯獨去考慮一些事情,怎么去解決這樣一些問題。
騰訊的游戲更新的方案,實際上它是一個以底層為基礎,然后在上面逐漸去擴展的方案。首先,本身必須有這樣一個海量的支撐,有tv級別帶寬輸出的這樣一個穩(wěn)定,在全國的范圍內(nèi),都有相應的機房的分布,實際上也就是能夠讓用戶就近訪問,能夠起到這樣一個效應,同時也能應對突發(fā)的帶寬的一些情況。這個是在最底層的這樣一個硬件支撐層面,在整個引擎層面,它本身具備TYP的下載能力,同時它也具備一些抗劫持的能力。它本身交驗這樣一些方式,所以能夠經(jīng)常地去發(fā)現(xiàn)環(huán)境或者發(fā)現(xiàn)被劫持的這樣一個情況,整個分析策略上,實際上可以分為差異分析、簡單分析,同時也可以在多個電子市場,也會存在多渠道發(fā)布的這樣一些問題。那在整個更新的方案上,可以簡單地把它劃分為程序的資源更新以及熱更新和動態(tài)下載這樣的情況。
我們首先來看一下程序資源的申請戰(zhàn)略情況,其實相對于整體的安卓或者是iOS這塊的升級來說,其實相對于端游——端游本身它是一個比較開放式的環(huán)境,其實不太需要去區(qū)分程序升級或者是資源升級。但是由于iOS或者是安卓的特性,它們本身是有一些沙箱的切換。所以,每次更新的時候,相當于可能你只需要更新很少的一些資源,但實際上缺乏完整的包,實際上這兩種更新的方式效益不是太高。那么,為了解決這樣一些問題,我們實際上采取的是仿效在PC上的這種模式,把2進制的程序的升級或者是說把資源的升級拆分得更細,這樣通過這種更細的拆分來達到整體一個提高效率的目標。那么舉個簡單的例子,比如說是兩個ATK之間的兩個之間的差異更新,可能整體算下來,它們的差異大小可能只能減少10%左右的樣子,如果我們現(xiàn)在采用了純粹的程序,以及資源分離的這種方式,那么整體減少大小可以到15%或者到20%的樣子。這個是程序和資源更新的矛盾的問題。
另外一個是,對于通用的多版本發(fā)布的問題,實際上在端游的時候,我一直是采用逐版本發(fā)布的這種方式,那么這種方式的特點就是一個用戶如果他一周不去訪問這個游戲,那么他可以下載大量的這樣一些資源,在手游的時代,實際上大家更看重流量,是怎么樣能夠更好地幫助用戶去節(jié)省資源?那么我們采用的方法是將唯一的資源,將更新的資源,將它放置在服務器上,通過客戶端動態(tài)服務器去計算商業(yè)對比的這種方式,來投到每個用戶不同需要下載的這樣一個最小的集合。那么,通過這種方式,實際上你會發(fā)現(xiàn)不管你是在玩《王者榮耀》也好,還是在玩其他游戲也好,不管你多長時間都沒有去更新,都只需要更新一次。另外一個問題是如何去防止劫持。實際上這種方式其實也是一些比較常規(guī)的,或者說大家在業(yè)界比較通用的一些做法。簡單來說,就是一個 URL。然后, https,也會有一些資源或者在類似的時間上的這種方式去繞過時間劫持的情況。但同時,也需要去做好相應監(jiān)控的工作,因為在一些大規(guī)模發(fā)布或者在更新的過程中,經(jīng)常會發(fā)現(xiàn)某一個省或者市出現(xiàn)大面積劫持的情況。那么我們整體系統(tǒng)要好好地去反饋出這一點,公司也有相應的這樣一個機制幫我們?nèi)プ鲆幌拢@個事情現(xiàn)在大概就介紹到這里。
我們看下一部分,從整各游戲資源質(zhì)量保證的方式來看,實際上會經(jīng)過很多輪外網(wǎng)恢復測試??赡艿谝惠?0萬用戶通過這樣一些規(guī)模,第二個就是其他的一些用戶。但是最終發(fā)現(xiàn)了一個問題是什么?就是不管你去經(jīng)過多少外網(wǎng)用戶測試的情況,最終你都會發(fā)現(xiàn)整個程序一定會存在大量問題。為了去解決這樣一些問題,實際上整個熱更新的環(huán)節(jié),在整各游戲里面是比較剛需的問題。熱更新從方案上來看,其實可以分為安卓的方案,因為本身安卓它是可以去加載SO的,簡單來說由于一個函數(shù)問題,函數(shù)地址的這種替換跳轉的這種方式,再去加載一個新的SO,這個新的SO肯定是對以前的SO有個小的規(guī)模,這種方式實際上就是一個比較傳統(tǒng)的APP的更新的方式。另外一種方式,就是說是在iOS里面,iOS它本身因為cocos在游戲里面應用不并不多,在整個游戲實際上還是unity引擎會更多一點。在這種情況下,實際上是需要一個游戲的APP去起承一些類似于解釋器的環(huán)境,再通過腳本運行的方式來打造替換。
業(yè)界一般的做法,是插入了Lua,我們是采用XLua的方式, XLua它本身具有三個特點:第一個特點,是說XLua它的系統(tǒng)會非常高,主要是通過數(shù)據(jù)在序列化和反序列化 的過程當中,將C# 把它下載到native。那么這樣的話,就可以做到這個項目完全沒有這些,因為這個也是與其他的XLua。第二個,整體來說, XLua現(xiàn)在來說還是非常方便的。它主要是通過空間層代碼的這種方式,它可以將一個C#類對象這樣一些簡單數(shù)據(jù)類型標記出來,在Lua之間形成這種無縫穿插,這樣的話其實也就方便了一些開發(fā)者和用戶針對這種數(shù)據(jù)類型一個一個去展開。第三個是關于hotfix熱更新的操作,其實它是可以自動地去申請埋點的代碼,可以做到在危急時刻,能夠對整體的這種方法,操作類服務,屬性事件或者是函數(shù)能夠無縫做到從私下切換成Xlua的實現(xiàn)。
另外一個,是關于動態(tài)下載。其實現(xiàn)在大家在用因特網(wǎng)之后,其實也可能會感覺到,如果你是一個500兆的安卓包或者是100兆的安卓包你的承接重要成本是不太一樣的,我們一直在這塊做了相應的裝接工具。簡單來說是一個動態(tài)下載的方式,對于業(yè)務這一層來說,需要做的事情就是說需要提供一個資源分析的這種過程,能夠把必要資源和非必要資源給分離出來,再通過我們的工具可以做成一個相對比較經(jīng)典的包。對于玩家這一部分來說,主要一個問題是,玩家在使用游戲體驗的安裝包的情況下,通過怎么樣的策略和方式,能夠去達到比較無損的體驗。
在這里其實我們的動態(tài)下載系統(tǒng)大概做了兩件事情,第一件事情就是通過按需下載這種方式,對有些資源去做一些區(qū)別管理,那么這個管理實際上是對必要資源和非必要能夠做一個統(tǒng)一的管理,不僅是從升級的這個流程上,還是說從讀取的這種方式上,都能夠做到在邏輯審批上一致。這樣的話,使用起來才會非常得方便。第二部分是安全下載的一個過程,我們實現(xiàn)了一個比較好的優(yōu)先級的通道機制。簡單來說,比如在一張地圖里面,在我視野范圍內(nèi)的這樣一些NPC也好,或者是說玩家也好,它是一個二位進制 的是也去做一個,而在我們視野之外的這樣一些物部件,是以自衛(wèi)的這種方式。那么可能在一些特殊的場景地圖里面,也會采用一些預判或者AI的方式,能夠提前知道用戶它可能會要發(fā)生什么劇情,那么通過這種方式的話,我們可以盡量讓有損的體驗變得無損。
我們先看一下網(wǎng)絡接入的情況,首先看一下整體的一個大盤還是這樣一個數(shù)據(jù)。實際上,我們可以從上面這張圖可以看到,目前的話大概是占65%的情況,實際的這樣一種用戶,看完以后馬上也要進入到5G時代,但是從我們整個海量的數(shù)據(jù)分析來對比,我們對比2013年的時候手游最開始的一個情況,以及2017年這樣一個情況,我們可以發(fā)現(xiàn)隨著基礎設施的建設,整體的物理面度的質(zhì)量相對于手游初期的時候越來越好,但是因為wifi這樣一種上網(wǎng)其實本身它會導致網(wǎng)絡閃斷,切換以及流動這樣一些問題,可能會影響用戶體驗。有了這樣一些基礎的數(shù)據(jù),其實我們可以對于游戲業(yè)務來說,他們需要關注的是在現(xiàn)有的網(wǎng)絡質(zhì)量一個情況下,游戲的玩法怎么樣能夠做到比較好的匹配。首先,看一下對于基本通用的這種方式,那么這種方式其實也是目前大部分手游應用到,或者端游頁游應用,這種方式主要是想去解決兩個問題。
第一個問題,是本身騰訊的賬戶體系它非常多,既有手游基于ONI的方式,那么同時也有基于端游的方式。在頁游的時候,可能還會存在一些三方打通的方式,比如說我想是基于微信的方式,實際上都是以云端為核心的賬號體系。如果這么多的接入方式把它放在整個的電路設備來看,實際上這個跟game sever就會非常得多,那它整個邏輯就顯得不夠純粹。因此在整體的game sever之前,我們加入了一個叫做中間件這樣一個組件。這個組件程主要一個功能就是說我可以再建立一個TCP或者UVP基礎之上,能夠建立一個抽象安全的通道,同時能夠把平臺的健全或者是說賬號體系能夠把它給分離出來,那么對最終的gamesolo來說,它需要做的一件事情就是知道我進去過,還是沒有通過。那么我們到底是在哪個平臺去做的健全,最終的一個賬號體系是什么樣子的。那么,為了屏蔽這種賬號體系的差異性,我們甚至做了一些賬號縮小的事情,這樣對業(yè)務現(xiàn)在看起來,整個的賬號能夠形成一個統(tǒng)一的完整的系統(tǒng)。
這個是在前端我們?nèi)プ龅倪@樣一些工作,那么在后端,我們是將與游戲玩法之外這種可以相互提煉的這樣一些邏輯,我們是把它給集中起來,就是像這些排行或者支付這樣一些游戲的邏輯關系的這樣一些服務集中起來。其中的這種模塊化的方式提供給game server,其實也是它整個的一個開發(fā)的效果。這種方式是比較常規(guī)的一種,因為對于剛剛看到那種統(tǒng)一進入的方式,實際上它是一個單點切入的模型。單點切入的模型其實比較適合于早期的手游或者端游。簡單來講,就是客戶端去計算一個分數(shù),計算完分數(shù)之后,再把它上報到服務器,服務器最終再對接到數(shù)據(jù)庫里面。實際上這種方式的話,存在一些管理上面一些弊端,如果是去承載MMO或者RPG這樣一些玩法,我們會經(jīng)常發(fā)現(xiàn)一些跳線的問題。所謂跳線就是說,我從一個地圖跳到另外一個地圖,或者從技術上來講,就是說我從一個服務器斷開然后我要去連接到另外一個服務器。那么,在端游的時候,這種體驗在物網(wǎng)這種環(huán)境下,其實相對來說會顯得比較平滑,到手游的時候,實際上這種方式我們越來越覺得它會覺得這種給用戶帶來體驗會非常得差,特別是說在一個地圖結合的部分,如果反復地這種切,實際上效果會非常不好。那么,另外一個問題就是對于整體后臺系統(tǒng),其實有比較大的挑戰(zhàn),因為你會不斷地去跟登錄然后再去數(shù)據(jù)庫拉取相應的信息,然后會導致邏輯問題。我們提出了一種新的通訊的方式,它是一個叫做網(wǎng)上的通訊,這種通訊方式它有一個特點,就是你從任何一個切入點去切入,實際上你都可以將消息投接其他的邏輯結點上去。那么這種方式在整個MMO或者RPG模型里面,能夠比較好地去解決就是用戶跳線的問題。
然后第三個,是最近比較火的關于PVP對戰(zhàn)這樣一個模型。實際上,對于PVP對戰(zhàn)來說會有兩種方式,第一種就是C/S模型,C/S模型它簡單來說就是客戶端里服務器去做免測,最終是以服務器計算的這樣一個效果為主。但是C/S這種方式,它有一個比較好的特點,就是客戶端可以去表現(xiàn)。因為你最終以服務器的機構為準的話,我們服務器告訴我需要怎么去做就好。實際上,我們可以看到,這種方式它對于網(wǎng)絡要求的其實沒有那么得敏感,因為對于C/S模型來說,他們有很多的這種差幀或者表現(xiàn)的這樣一些操作方。其實我們可以看到LOL就是一個簡單的C/S模型,那么在150-200毫秒這種情況之下,我們可以看到它這里的表現(xiàn)還是相當?shù)钠椒€(wěn)。
另外一種PVP的模型,是幀同步模型,這種模型它起源于早期的類似于《星際爭霸》這種游戲,因為一些條件上的限制,導致了它必須采用很少的數(shù)據(jù)捕獲方式來達到自己這種比較大規(guī)模的數(shù)據(jù)同步。幀同步的模型來說,實際上我覺得它比較適合早期的這種原型的開發(fā)。簡單來說,就是客戶端將一些簡單的工作序列把它發(fā)給服務器,讓服務器去做組成或打包相應的工作,然后再去做一個廣播。因此對服務器來講,它的整體的承載相對來說會比較高,它的并發(fā)性也會比較高,但是不好的地方是,它將的邏輯都集中在客戶端,那么在這里對于客戶端來講,會有兩點非常關鍵,第一點就是本身客戶端的性能,如果很難去達到性能要求的話,其實這種方式就很難適用在這個游戲里面,舉個簡單例子,比如說我們在《星際》里面可以看到16位數(shù)的快放的這樣一些情況。假如說在整體的某一個游戲里面,如果是不能夠再渲染或者在其他的邏輯跟上這樣的目的,其實就很難適應這個模型。另外一點,幀同步這種模式實際上它對整體網(wǎng)絡的抖動影響是非常得敏感,因為它所有的表現(xiàn),包括計算都集中在客戶端。這樣來說,實際上我們可以看到整體上幀同步實際上它是一個能夠簡單去開發(fā),但是你想把它做好卻很難。
我們接下來講針對這兩個模型的網(wǎng)絡優(yōu)化的問題,實際上不管是這個模型還是狀態(tài)同步 模型也好,實際上他們都很難再用以前TCP的方式來做基礎的傳輸模式,tcp本身其實因為它是具備這種超時規(guī)避這樣一些機制,它不再適合作為弱網(wǎng)這種網(wǎng)絡環(huán)境下的通訊方式,本身APP它又是一種不可靠的這種實驗方式,游戲的業(yè)務特性又要求某些消息確實是更優(yōu)的,因此在這個基礎上面,需要在UDP的這種方式上,去實現(xiàn)這種可靠的通訊方式。簡單來說,這種可靠的通訊方式,無非是兩個,一般都會采用消息重傳來實現(xiàn)其可靠性,采用消息重傳的時候有兩種方式,一種是發(fā)送者發(fā)起,另一種是接收者發(fā)起。對于發(fā)送者發(fā)起的方式的這種傳輸,實際上有一個比較關鍵的點,就是基于一個RTT的平臺測量,在這個測量基礎之上,你能夠去做到快速的傳導,RTT的這個實際上它只是一個測量,它其實是很難預測到下一秒到底會發(fā)生什么樣的問題。我們之前做過很多的這樣一些測試,比如說在PC的端游上,我們發(fā)現(xiàn)做出來的這種效果,會比TCP那種效果會好非常多,但是實際在wifi模擬的這種情況下,在外網(wǎng)運行的情況下,確實發(fā)現(xiàn)有時候效果是不是比TCP還要差,那怎么樣去解決這樣一些問題?最簡單的辦法就是看整體游戲的特性,實際上可以說是通過多位冗余,或者是通過動態(tài)冗余的方式。這樣的話,通過流量去換延遲的這種做法,能夠在一定程度上去改善這種網(wǎng)絡擁塞的一些問題。
再看一下我們整個的一個解決方案,說一下為什么我們要去做這樣一件事情。本身騰訊整個的游戲的成分它會非常非常多,如果都采用不同的解決辦法,實際上在這里的效益,在整體的應用上都很難地去形成一個比較快速的demo模型這樣一個過程。那么我們在整個構建統(tǒng)一方案的問題上,其實也是希望說我們能夠將底層做得非常簡單,非??煽浚敲丛趹眠@一層其實是可以留給用戶調(diào)優(yōu)的空間。
那么,整各的這樣一個統(tǒng)一方案,簡單來看,大概它分成三層,最下面的是一個傳輸層,在傳輸層首先我們可以分為用戶是一個UTP,在用戶基礎之上,它需要去實現(xiàn)一些可靠消息的類型,那么也需要去實現(xiàn)一些非可靠消息的類型。這里其實還有很多這樣一些細分,比如說快速可靠的消息,或者非快速可靠的這種消息,實際說我們在整個UDP的業(yè)務管理基礎之上,是做了非常多的這種測試和模擬這樣一些工作,也參考了其他的這樣一些像國外的一些游戲已經(jīng)適用網(wǎng)絡層的解決方案。實際上他們通常的一種做法,就是我需要對整個通道做一種分級的處理,這個就好比是說一條高速公路通道。你可以把它分為一個可以開到120的這種快車道,也可以分為可以開到100的慢車道,當然也有80的這種比較慢的車道,但同時又限制你必須開到60以上,那么你才能夠在這條高速公路上比較正常地進行。就是說對整體的流量的或者說對通訊通道的管理方式是需要有比較好的策略,才能夠保證你整體不會發(fā)生堵車,比如說你的整個的吞吐,還有包括你的延時都能夠在一定的合理范圍之內(nèi)去得到控制。
這個傳輸層,它實際上是一個最底層的這種通訊方式模型的選擇,那么在它的基礎之上,是相應的邏輯層的功能,剛才我講的健全的功能,要排隊的功能,還有數(shù)據(jù)包合并、緩存這個問題,或者是加密、壓縮,防止沖擊這樣一些功能,或者作為相應邏輯上的一些功能,他們在審核的方案里面,那么在整個的一個監(jiān)控模型上又會分為單點的模型,以及網(wǎng)上的模型。它也是一個不同游戲模型的選擇。那么對于業(yè)務來說,他們可以分為一個公共層的這種邏輯,比如健全排隊,還有強壓縮等等,那么也有分為它私有的一些邏輯,比如說它的移動包,它的攻擊包,這些是可以看成一個可丟失的輸入。對于說像買一個裝備或者是說去換槍,最終的數(shù)據(jù)結算上報到系統(tǒng),這個也是后來作為一個比較單面的數(shù)據(jù),這個是整體的一個解決方案。
前兩天大家還看到一個新聞,就是說我們現(xiàn)在到底是音頻時代還是視頻時代。實際上關于語音這一部分,我們正好是在2015這個點,正好是在行業(yè)里面視頻還是在發(fā)展,然后大家相互去競爭的這種情況下,其實沒有對語音的這個細分的市場去做一個比較全面的這樣一個分析。然后,可能我們看到的這樣一些機會,推出的一個叫GVoice的產(chǎn)品,它目前也是放在騰訊這樣一個有游戲服務的團隊。它的一個主要方式是想說全面提升整體游戲的交互的體驗,從目前運行的這個情況來看,實際上從某些維度上,它的整體的一個話務量也是超過了某些運營商。它主要提供3個功能,第一個功能是一個實時語音功能,第二個是類似于組隊語音,或者是類似于一個電話本溝通的這種方式,是一個語音電臺的這種模式,實際上它就有點像說是一個喜馬拉雅或者說像有主播在講,然后大量聽眾在收聽的方式,還有就是說是類似于基于微信消息的方式。
(圖5)
那么作為一個內(nèi)在SDK,它必須有幾個比較重要的特性,首先這點它會非常的低功耗,因為你不可能去跟有些邏輯去搶內(nèi)存,那么同時它作為是一個輔助的功能,不能占用太多資源,同時它需要很多平臺的這種監(jiān)管,包括多種引擎的適配,在接入上能夠做到非常簡單。接下來看一下語音這一塊目前兩個典型的使用場景,第一種場景就是類似于在《王者榮耀》里面,這種小的語音的模式。那么這種模式它的一個特點是從技術上來講,它需要用戶能夠在較短的時間內(nèi),能夠聽得清其他用戶的發(fā)言,但是它對整體一致的要求,其實不是要求那么嚴格。第二個模式,是類似于這種國戰(zhàn)語音的方式,它的要求是,因為在這種模式下面,一般是一個主播開著比較勁爆的背景音樂,然后對大家的指揮或者種行為會有一定的煽動效果。所以,在這種情況下,需要對整體一致要控制得非常得好,然后用戶要定得非常得清晰,但是在這種情況下,確實不再去考慮流量這樣一個問題。
我們看一下語音的這樣一個整體的流程,包括它整個處理結構的情況,我們簡單地分為前處理和后處理,中間是通過網(wǎng)絡來進行的。在前處理的過程中,首先第一個要做的就是降噪。第二個是做VAD,這里是一個比較關鍵的點,它會語音之外信息能夠把它給過濾掉。為了達到節(jié)省帶寬的目的,因為我們現(xiàn)在在這邊開的策略相對都會比較得嚴格。那么VAD把整個聲音給過濾之后的話,需要去做一個ATC爭議這樣一件事情,它實際上是說把整個的人聲,能夠相對來說提高到一個比較高的水平。第四塊是LTC,它其實是一個嘯叫音質(zhì)的功能,因為在以前,其實我們更多的是考慮用戶在使用過程中,他們不會坐在一起,我們最近發(fā)現(xiàn)其實很多的人,比如說在網(wǎng)吧,大家坐在一起。那么在這里的話,兩個音源相近,就容易出現(xiàn)嘯叫情況。所以,在這個地方也需要去做相應處理去優(yōu)化近距離嘯叫問題。最難的一個問題就是回聲消除問題,實際上從整個業(yè)界來看,大家都在去想辦法去解決這個問題。那么對于這里其實在總體的這樣一個環(huán)境下面會存在一些挑戰(zhàn),比如說像在有背景的這種情況下,如果我們每個人都去說話,甚至某些背景里面,還有一些人的聲音,那么在這種情況下,想把這樣的聲音消掉或者說聽得非常舒服還是非常有挑戰(zhàn)。
在整體的這樣一個前處理過程中,我們會將整個語序進行編碼,然后再把發(fā)送給服務器,在服務器這邊目前這邊是采用一個整理集群這種模式,那么它在接入上會有三個特點,第一個特點就是它是一個就近接入的方式,我們也收集了海量的 Jrpl,并且在QS上做相應的測試,它能夠保證這個用戶的接入點是一個最好的接入點。那么,另外一點,整個的這種網(wǎng)絡它實際上是4G網(wǎng)絡體系,通過內(nèi)網(wǎng)去進行傳輸。因為在深圳,還有在其他地方都有相應的布點,可以打造整個語音傳輸?shù)淖顑?yōu)化的效果。我們再看第三個梳理邏輯,相對來說會比較簡單,它主要是去處理整個數(shù)據(jù)包在網(wǎng)絡都懂得情況下,可能會產(chǎn)生這種跳音或者變音的情況,那么現(xiàn)在的話,我們在整個服務器端其實也做的一些類似于混音的處理,其實也是想去減少整體用戶的這么一個帶寬或者占用的問題。我們看一下實時語音,剛才我們有簡單地介紹,比如說在《王者》的時候,我們場景下面,其實我們更多的是去考慮一個平衡型的效果,比如說我們希望用戶能夠聽得見用的好,然后像在國戰(zhàn)的場景下,其實我們希望整體這樣一個音質(zhì)的效果會非常得優(yōu),我們看到帶寬的這個一個情況。所以,整體來說它是一個多維度的這樣一個需要去考慮的問題。簡單來講,第一個就是帶寬,或者怎么樣能盡量地去減少帶寬延遲。第二塊就是對于有些音效的影響,到底是是以語音的這塊為主,還是背景音樂這塊為主,還是以游戲音效為主,其實也是需要在不同語音場景里面去做權衡與選擇。
第三個是關于監(jiān)督系統(tǒng)。目前其實監(jiān)督系統(tǒng),我們是整個實際用戶處理里面非常困難的一部分,相對來說iOS的體系這種系統(tǒng)還更加容易去調(diào)優(yōu),但是對于安卓的整個系統(tǒng)來說,其實是做了300機型的這樣一個團隊,它甚至有更多的這樣一些機型,包括更多的這樣一些安卓團隊等等。
第四個,就是關于網(wǎng)絡丟包的這種情況。對于網(wǎng)絡丟包這種情況,目前其實也有類似于像FEC或者說強行編碼這種情況,可能在這個場景里面,需要有其他的這種某一次會造成雙方卡頓,尤其核心網(wǎng)的發(fā)生,有些數(shù)據(jù)這樣一些情況。那對于整體的一個新聞化的這樣設計,你需要對所有的算法去做相應的一些采集,來包括對整體的這種音頻需要去做相應的這種優(yōu)化,來保證整體的SDK系統(tǒng)的比較輕量化。最終一個請大家看到的是一個音質(zhì)上的問題。目前來說其實好的辦法就是說我提高編碼,然后我提高我們的冗余,但是這是一個比較常規(guī)的做法。
我們看到一下在《王者榮耀》的語音里,我們主要是優(yōu)化了一些思路和方式,第一個是怎么去做一個的過程,那傳統(tǒng)的這種語音儲備或者語音的方式它是每秒鐘不間斷地向服務器發(fā)送,但是在一些電話的場景下面,還會出現(xiàn)需要去制造一些環(huán)境音,或者是說一些制造一些數(shù)據(jù)音的方式,讓用戶覺得我沒有掉線。在游戲的這種場景下面講,其實不太適合。那我們的做法就是只要你說的話,我們才去發(fā)報,你不說話,我們是不去發(fā)報的。因此,延伸監(jiān)測這個模塊就顯得非常非常得重要。那么,目前常規(guī)的做法就是說在延伸整個聲音頻段的范圍,但是其實也還是有其他方式,比如說你可以采用一些類似于音階的手段盡可能地來識別,到底哪些是人聲,哪些是背景音。
第二個要解決的是嘯叫問題,我們剛才也講過,就是在某些場景下,大家可能坐在一起,說白了,就是去做一些移向移位的操作?;蛘呤前颜麄€的一個征信能夠盡量地放低,相應的這種模型錯開。
第三個,主要是合并消除,合并消除現(xiàn)在可以去優(yōu)化的大概有兩點,第一點是怎么樣能夠更好地去擦除回聲,然后還有一個點就是對于播麥交替的距離探測,也會有一些好的效果,但目前還是在一個嘗試的狀態(tài)。對于我們丟包的這種情況,目前其實能做的事情也還是挺多的,就你剛才說的這種可靠的冗余這種方式。但是到底選擇哪一種方式,是需要取決于在當前的這種網(wǎng)絡環(huán)境下,能夠支持你去辨別,不會對游戲整體造成過多的影響。
再看一下,我在這種優(yōu)化的情況下,實際上剛才也提過,它其實更多的是說,它既有背景音又有MP3的這種音樂,然后又能聽清楚人的聲音。那在這種情況下,怎么做?簡單來說,就是去提高均衡,通過提升人聲的這種聲音能量的方式,同時對整個的一個伴奏,去做高頻處理,對音樂部分進行相應壓制,通過這種方式去達到均衡,讓整體的效果聽起來,既能夠聽得清楚人講話,同時也能夠聽得清楚MP3或者是說背景音樂給人的這種比較亢奮的效果。那在音質(zhì)的這個提升上,其實主要是針對人聲的飽和度,簡單來說就是對你的音色或者對于一個平面變換的方位,讓這個聲音顯得更加得好聽。
那么現(xiàn)在前面也講了挺多,我們在不同的場景下面,不僅是在網(wǎng)絡應用的場景,還是說是在語音的這種場景,都會針對不同游戲去做相應的適配。其實做了這么多,也是想能夠把它給開放出發(fā),我們更好地能夠服務到其他一些游戲上,所以我們又要有一個叫做,騰訊游戲服務的平臺,它是基于在整個騰訊語音的基礎之上,它游戲服務子板塊的平臺。
目前開放的服務,有語音存儲下載,然后還有一些游戲相關導航問路的玩法,還有包括我們針對數(shù)據(jù)分析的這樣一些特性的功能。有些語音計劃,剛才簡單介紹過,這里就不再重復了。然后,數(shù)據(jù)存儲之前在提過一個叫做techbas的系統(tǒng),這個系統(tǒng)實際上目前是大規(guī)模地運用于整體的數(shù)據(jù)存儲。那么這個系統(tǒng)剛才講了,它其實有一個最大的特點,就是它能夠在海量的用戶之間,能夠在性能與成本之間找到一個比較好的平衡,那么同時它也可以比較好地去適應業(yè)務的這樣一些特性,比如說第一個就是活動的特性,能在短時間內(nèi),不會有海量的并發(fā),但是也能夠保證在高并發(fā)條件下,整個的一QBS效率也好,還有包括QS的質(zhì)量,還有包括我的查詢的量,都能夠達到比較好的標準。
第二點,是整體本身游戲的數(shù)據(jù)存儲,它有個特點,就是它經(jīng)常會存在一些荷負,或者是說一些擴容的問題。那么(英文)這個系統(tǒng),它可以保證做到不管你是對數(shù)據(jù)的分類也好,還是對數(shù)據(jù)的合并也好,實際上可以做到在線無損的擴容。
游戲下載更新服務,這個之前也簡單地講過,我們把整體的服務,把它分裝在一起,其實也是想去解決游戲在發(fā)行過程中,可能會遇到的這種局域化發(fā)行的問題,那么目前與騰訊在合作,在全球大概10到20多個國家都有相應的這種布點),那么依賴于當?shù)乇旧淼腃DN建設,我們可以將整體的內(nèi)容分發(fā),可以擴充到全世界大概20多個地區(qū)。目前這個地區(qū)的數(shù)量其實還是在不斷地增長當中,我們可以看到最近比較火的印度市場,還有包括像南美華西市場,實際上都有相應的布點。
我今天分享大概就到這里,謝謝大家收聽!
掃描二維碼推送至手機訪問。
版權聲明:本文由財神資訊-領先的體育資訊互動媒體轉載發(fā)布,如需刪除請聯(lián)系。