當前位置: 華文問答 > 遊戲

是不是自從遊戲能夠上架steam之後,遊戲體積變得越來越大了?

2024-03-25遊戲

和steam有一些關系,但沒有這麽簡單

在很早時期,遊戲的資原始檔都是零碎放置的,一個遊戲可以有成千上萬個資原始檔

因為早期遊戲體積不大,資原始檔數量也不算多,所以沒啥問題這麽做

後來隨著資源越來越大越來越多,但當時主流媒介是機械硬碟和光碟,就出現了一個問題:零碎讀取跟不上

旋轉媒介每讀取一個檔就需要進行一次尋道,甚至可能用時比讀取本身更長

這導致如果遊戲需要讀取大量零碎檔,讀取速度就跟不上

所以就出現了資源封包的概念,把零碎資源封在一個檔以內,遊戲讀取單個檔並自己處理內部對映邏輯

這樣的封包解決了零碎讀取尋道太慢的問題,還引入了壓縮演算法節約空間

到這一步其實發展的都沒啥問題

但是,封包一定程度上增加了遊戲差分更新的難度

以前資源全部零碎放置的時代,差分更新很簡單,哪些檔變化了就更新哪些,簡單粗暴而且高效

封包之後,顯然一次性直接更新整個巨大的封包是不可能的,那就必須引入差分演算法尋找每個封包的二進制差異

那麽steam的差分演算法是如何推動遊戲體積膨脹的呢?我們來看看steam的差分演算法是怎麽樣的

簡單來說有幾個特點,第一個是steam永遠會為需要更新的檔同步建立新副本最後再覆蓋回去,所以需要2倍待更新檔的硬碟空間,第二個是steam按1m大小劃分塊,所以如果整個檔長度發生了很多變化,盡管只是內容整體偏移,也可能產生很大的更新體積

所以理論上來說,針對steam的更新機制開發的時候,應該引入一些padding策略來盡可能減少大範圍的檔更新

但問題就在於,很多遊戲開發階段根本沒有註意steam更新的策略,就引入了一些與steam更新策略八字不合的設計,比如不定長還帶時間戳的toc遍布整個封包,更新封包內1kb檔就導致整個封包都被diff演算法算進去了

而且這個問題往往是在第一次推播更新的時候才被發現,也就是此時往往第一個釋出版本已經被很多使用者下載了,調整封包格式已經來不及了

玩家往往會抱怨要很長時間更新才能玩上,對於多人線上遊戲尤其,所以很多開發商就采取了一個騷操作:直接把產生變化的檔打入一個patch封包,並修改引擎使其優先從patch封包載入資源

這種做法確實對於steam的更新機制非常友好,可以把更新體積控制在真的只有實際差異左右的大小,玩家每次更新只需要下載數m的小檔並且不用磨半天硬碟

但這種做法有什麽問題呢,就是一個資原始檔的舊版本和新版本實際上同時存在,多消耗了一倍空間,同時遊戲啟動時需要遍歷的封包多了之後載入也會變慢

於是隨著遊戲不斷更新,產生越來越多的patch封包,越來越多檔實際上雙倍消耗空間了,最後的結果就是體積膨脹,比如GTA5的patch depot大小已經比釋出時本體的大小還大了,這也是GTA5載入越來越慢的原因之一(不僅僅是糟糕的json解析演算法導致的)

這就是很多持續營運型遊戲體積越來越膨脹的原因,所以堡壘之夜才會弄過一次性推倒膨脹更新(代價是下載幾十g的更新幾乎是把遊戲重下一遍,才能把100g壓縮到30多g,而且又隨著更新再次膨脹了)

對於一些單機遊戲,如果已經有封包和解包工具,自己把更新包與主包合並後不會影響遊戲執行並且能節約很多空間,代價則是下次更新需要全量下載

當然,也不是所有開發商都會這麽做

像是unity之類的引擎本身封包就有為steam差分更新最佳化,開發者正常打包也不會產生過大的差分大小

又比如育碧就是一家很有個性的開發商,一個60g的遊戲更新一次更新要下載40g對於育碧來說是可接受的,所以育碧的遊戲就沒有那麽離譜的空間膨脹

近些年也有一些開發商發現反正現在ssd普及了零碎讀取不是問題了,倒車回古早一個遊戲成千上萬檔的時代倒也沒啥問題了,開始搞零碎封包,每個封包只有數m,也變相的解決了這個問題

那麽在這個過程中,遊戲設計本身是否起到了推波助瀾呢?答案是正確的

這種封包更新機制在更新只是修bug小打小鬧的情況下其實膨脹量非常有限,但在大更新時就會嚴重膨脹,而現代遊戲逐漸轉向持續營運策略,導致遊戲的大更新越來越多,讓這種不適合大更新的更新機制顯露出了問題

在遊戲轉入封包趨勢初期,大多數玩家還沒有穩定的互聯網連線,遊戲大多是一次性賣的時候啥樣就是啥樣,最多有一些數m的修正修補程式。這時候遊戲以單次買斷收費為主,不存在所謂營運的概念,遊戲釋出完之後官網幾年不動都是常態

但後來有一款國服到現在都沒打贏復活賽的服務型遊戲魔獸世界出現了,讓廣大遊戲廠商看到了持續營運遊戲的盈利可能,從那時候開始很多遊戲就開始向著服務型遊戲的方向發展,一個遊戲釋出之後可以陸續推出多個資料片,每個資料片都單獨銷售,於是遊戲需要越來越多的大更新

而隨著服務型遊戲的發展,又有一些廠商發現可以遊戲半成品就拿出來賣,後面再慢慢更新,甚至是直接把遊戲本體原本的一部份內容拆成資料片賣,又或是分割商法

所以總的來說,是steam的差分更新機制與現代持續營運型遊戲的經營思路共同助推了遊戲的體積膨脹,而steam差分更新機制導致空間膨脹的原因又是遊戲資源封包化,而遊戲資源封包化的原因又是機械硬碟和光碟拙劣的尋道速度

機械硬碟你罪大惡極(劃去

那麽那些不依賴steam分發的遊戲是否有一些技巧來解決問題呢?答案是有的

我又要提逆水寒了,逆水寒自己的更新機制其實很有意思,更新器會直接把需要更新的資源寫入舊封包後面,所以硬碟寫入量就不大,啟動器單獨實作了一個資源整理功能,更新完成後預設不整理資源,手動整理的時候才會把封包中的舊資源刪除

但這種實作要求更新器知道遊戲封包原理,只適用於遊戲自己獨立分發的情況,對於steam這樣的遊戲平台顯然是不行的