大家好，我是一顆蝦丸。
這篇要和大家聊聊游戲加載進度條的故事。
電子游戲的發展日新月異，在過去的幾個月里發售/釋出了許多3A大作比如說《地平線：黎明時分》、《塞爾達傳說：荒野之息》和《不義聯盟2》（對我是認真的）。
但是盡管游戲在高速發展，但是有些東西還是逃不掉的，那就是加載時間，這么多年一點進步沒有。誰都知道那些沒耐心的玩家每次看到加載條都會瞬間爆炸但是還是必須要忍受。
大概只有密集的補丁攻勢才能和這這個惡魔之條相抗衡。為什么我們明明有更先進的主機和更高效的引擎卻還是逃不出加載條的魔爪？
一位游戲程序員告訴我，隨著時代的發展，游戲的加載內容在成指數增長，但是硬件卻沒有以同樣的速度進步。
威廉姆斯·阿姆斯特朗是一位有著豐富的游戲編程經驗，經手過大量類似《看火人》和《生化奇兵》這樣的大作的程序員，他說：“CPU和GPU的發展速度已經遠遠把硬盤的讀寫速度甩在身后”。
他解釋道：“硬盤是一種嚴格的受物理學定律約束的設備。硬盤的讀寫操作包含了大量宏觀微觀層面的操作，包括電子運動和機械運動。這和純電路的運行速度相比，慢的不知道到哪里去了。不如說，光速快過一切。”
“（硬盤的）操作比純電路操作慢太多。不如說光速快過一切?！?/p>
與硬盤們的前輩相比，現在的它們的容量確實提升了很多，但是次時代游戲的容量要求提升了更多，這兩者完全不成比例。
羅伯特·迪特里希是一位負責游戲環境和單位視覺效果處理的程序員了，他表示如果一名設計師要把紋理的分辨率從1024*1024提到2048*2048的話那么就意味著4倍的容量提升，如果提升到4096*4096的話那就意味著要乘16倍的容量。
同時，他也提到。如果將硬盤的轉速從多年前的5400轉/分鐘提升到7200轉/分鐘的話，你的讀寫速度提升只有33%。“
雖然固態硬盤在提高讀寫速度的效果立竿見影——盡管這樣往往意味著更高的成本——但是它們的讀寫速度還是在指數式增長的游戲容量面前相形見絀?！?/p>
這還不全是材質包的鍋。阿姆斯特朗在后續的回復中寫道：“游戲的視角越來越開闊，意味著同時的計算量更大。什么亂七八糟的東西都要往驅動盤上塞，包括AI、物理引擎還有其他巴拉巴拉的。視角增大的結果遠非你想象的那么簡單。”
如果能明白硬盤的容量和讀寫速度的增長到底用多慢之后你就會很容易理解為什么到現在加載條還是沒有變短了。那些可愛的程序員們已經竭盡所能去縮短加載時間了。
迪特里希補充道，加載畫面的開始并不是加載過程的開始，事實上它往往在最后一幕即將結束的時候就開始了。
比如說，大多數游戲會選擇在剛出現公司Logo的時候就開始加載內容，反正Logo是不能跳過的那就讓它變得有用一點好了。還有些在你點進去之前就開始加載下一幕內容，這就是加載條在游戲一開始看起來特別長的原因。
現代的游戲還會從程序機制上來減少所占內存，用更少的數據去描述更多的內容。比如，一個磚塊的紋理可能并非來自一個BMP文件而是來自一組數學計算式——也就是矢量圖形。
“玩家行動的不確定性越大，你就越難預判哪些數據是玩家接下來用的到的。”
一個常用的策略是將游戲的可能加載內容拆分，在加載時只加載要用的數據——還有可能用的到的數據。通常在開發者可以粗略地預測玩家的行動的時候會使用這個策略。
簡單來說，一般在每一幕的開頭用這個套路。
但是玩家的行為總是難以預料的，特別是在一個開放類游戲里?！巴婕业男袆釉诫y以預測，我們就越難判斷那些數據是玩家接下來用的到的”迪特里希說，“這就是為什么在你瞬移到一個很遠的地方需要加載，而走過去就不需要加載?！?/p>
大多數情況下，直到開發周期結束前開發者們都不知道該怎么去優化他們的游戲。游戲開發是個巨大的工程加載時候的進度條 js，包括了一系列數不清的調試和妥協，你有可能因為一個功能實現而延長整體加載時間、影響其他功能甚至搞出新的BUG。
游戲引擎也是優化的一個重頭戲，有些特別開發的引擎會進行針對性優化，而大部分通用引擎早在開發者使用之前就做好了，程序員們只能用預判的方式來猜測玩家的行為，至于能猜多準那就真的只有天知道了。
為了避免游戲進程被突然打斷，開發者們通常會在玩家解鎖一個有明確指向的內容之前鎖定其他的游戲內容。然而問題是直到開發周期結束前這個工作都很難進行，但是每到這時候就意味著開發者的時間已經所剩無幾了。
開發者們在這兩分鐘里能做的只有把重要的幾個問題解決到，顯而易見的是加載時間這個問題往往不是這個時候要解決的重點問題，為了趕發售的進度這一項優化往往要草草解決。
“發售一款游戲就像打開一扇泄洪閘，我們就像在這閘口上看洪流般的反饋涌來?！敝谱魅颂m德·米勒在他的2016年新作《仰沖異界》發售時如是說。
他在郵件里寫到，有很多硬件原因導致的問題是他們在優化時沒有預料到的，還有大量始料未及的反饋——他們當初根本沒想到那些地方會出問題。
“我們在這一次決定在游戲一開始加載非常多的內容”他在郵件結尾補充道，“所以我們不得不將游戲內容分塊并且緊急推送一個補丁來進行額外的優化。還有大量類似的工作，不得不陷入問題——推送的循環?！?/p>
但是這還是有些好處的，米勒和他的團隊這無盡的優化和更新的循環里找出了基本上所有有問題的和低效率的模塊。
“我們發現我們選擇在加載一個世界的同時加載所有的動畫影片，”米勒寫道，“看起來解決它只要重新下載就可以了，試試這涉及到整個人物交互系統的重寫。”動畫部門發現有些問題可以通過縮小材質包的標準實現加載時候的進度條 js，可是這么操作卻要對觸發器處理。諸如此類的問題都是要一鑿子一鑿子慢慢雕刻的問題，不是一錘子掄過去就能解決的。
我還就此詢問了其他兩個游戲——一個是開放式游戲《精靈鼠傳說》，另一個是奇幻類RPG《矮人》——的開發者。他們就縮短加載時間的問題上持相似的觀點，認為縮短加載時間的一個前提條件就是開發者要對他們的游戲了如指掌。
這一點對于《矮人》的開發團隊而言尤為重要因為他們近日決定將這一項優化貫穿在整個開發周期當中，這對于這個團隊來說將會是一個不小的挑戰。
正因為上述舉措，《矮人》在縮短加載時間上的工作卓有成效?！熬鞯臄祿虬?、最高效的內存分配、減少整體容量這些都是細致活，如果你選擇呢在開發完再去做這些就會變得極其麻煩?！弊尅さ偕卩]件里寫道，“我們在下個項目里引進的新系統保證會讓所有人再仔細想想游戲開始時的加載時間到底意味著什么?！?/p>
但是到目前為止只有一小部分人可以做到在游戲開發周期就完成這項優化。只要游戲加載的速度沒有和硬盤讀寫的速度一樣快，對它的優化就不會停止。
對于威廉姆斯·阿姆斯特朗而言，加載條就和游戲里的BUG一樣，只不過這個BUG不會使你的游戲崩潰，只會拖慢它的運行速度。這些BUG只會在游戲開發進程的最后出現。對他而言，在這個BUG解決之前，開發過程就不算結束。
ref