遊戲中的優化指的是什麼？

01-05

經常聽到有人說xx遊戲優化特別好 xx遊戲優化特別渣什麼是優化它是怎麼實現的

遊戲軟體的優化和一般軟體是有一些區別。

遊戲通常是軟實時（soft real-time），就是說運行上有時間限制，但沒有硬實時般嚴格。

先談固定硬體的遊戲平台，如遊戲機和街機。在這些平台上，通常會設置固定的幀率目標，例如30 FPS（即每幀33.3毫秒）。遊戲開發者希望在這個時間限制下，盡量提升遊戲的品質，例如更精細的角色和場境、加入更多效果、提升人工智慧水平等。優化的目的除了令遊戲順暢，也是提升遊戲品質的必要條件之一。

對於PC或手機平台，因為硬體的性能有很大差異，優化就沒有一個具體的目標，而是希望儘可能在大部分平台上都能做得最好（雖然PC遊戲有幾百FPS的情況，但實質上幾乎不能增加流暢性）。

從玩家角度，我認為遊戲的性能指標大概有這幾方面：

平均幀率
流暢性（不要「卡」，專業地說就是少spikes）
互動延遲（輸入後至看到反應的時長）
等待時間（讀盤、寫檔、網路連接等）
內存用量
遊戲體積
網路流量（主要是移動平台）
耗電量（主要是移動平台）

而在開發的角度來說，我認為優化方法可以分為無損和有損的。無損是指不影響品質，純粹通過技術上的優化去提升整體性能。而有損是指通過簡化、近似化去改善性能，例如簡化著色器（shader）、要求美術降低某角色的三角形數目、要求關卡設計師減少一些NPC等。

優化前我們要先進行性能剖析（profiling），找出性能問題的核心，然後再看看有什麼方法可以嘗試。主要可分為演算法上的和底層的優化方法。不詳細說明，就舉個例子吧。

例如，在二維彈幕射擊遊戲中，需把大量子彈與飛機做碰撞測試（相交測試）。如果有n顆子彈，m個可被擊中的目標，蠻力法需要mn次測試。我們可以看情況，使用一些空間分割的演算法，把子彈和目標分配到不同的空間範圍里，只需對每個範圍里的物體做測試。而在底層方面，我們可以考慮使用多線性、SIMD指令，並考慮到緩存一致性等方面去優化。

上述例子主要是在CPU上進行的遊戲邏輯方面的優化，而許多遊戲中也需要在CPU/GPU上對圖形方面進行優化。在PC/手機平台上，因為瓶頸不固定，遊戲開發者通常會儘力優化每一個部分。

----------

@孟德爾和 @Thinkraft提到了Quake的平方根倒數，我引用一篇以前寫的文章，測試SSE指令和Quake的實現：

在1999年，id software公司發布了《雷神之錘III競技場(Quake III Arena)》巨作，此第一身射擊遊戲有別於前作，以多人連綫遊戲為主軸，得到空前的成功。
在2002、2003年間，網上出現一段關於該遊戲中的源代碼討論，那段代碼是這樣的：
float Q_rsqrt( float number ) { long i; float x2, y; const float threehalfs = 1.5F;
x2 = number * 0.5F; y = number; i = *(long*)y; // evil floating point bit level hacking i = 0x5f3759df - (i &>&> 1); // what the fuck? y = *(float*) i; y = y * (threehalfs - (x2 * y * y)); // 1st iteration // y = y * (threehalfs - (x2 * y * y)); // 2nd iteration, this can be removed
return y; }
它是用於計算一個單精度浮點數的平方根倒數（reciprocal square root, 即1/sqrt(x)）。平方根倒數在遊戲中經常用到，例如把矢量歸一化（normalize）時，就要計算n = v / sqrt(v ? v)。

此段代碼使用了牛頓法（Newton』s method）去提升精確度，但令人漬漬稱奇的是它計算初始估值的這一句：
i = 0x5f3759df - ( i &>&> 1 );
它利用了IEEE754浮點數的二進位表示來計算第一個近似值。此方法是誰發明的，魔術數字（magic number） 0x5f3759df 從何而來，暫時也沒有確切的證據。但現在已找到比這更優的魔術數字[1]。
然而，本文想帶出的是，雖然此方法如此神奇，在現今的機器上通常不是最理想的。在PC上，自1999年Intel推出的Pentium III，就已經加入了SSE指令集，當中的rsqrtss指令就是能夠計算一個單精度浮點數的平方根倒數。此外，rsqrtps則能同時計算四個單精度浮點數的平方根倒數。
測試
我們可以寫一個程序簡單測試一下:
（略……）

結果及分析
使用VS2008 (預設release配置)，在i7 920 2.67Ghz上的結果：
dummy 363.8ms error= 83.70051795% standard 1997.4ms error= 0.00000871% quake 586.1ms error= 0.17520049% quake2nd 970.1ms error= 0.00046543%
dummy_ss 109.4ms error= 83.70051795% vsqrt_ss 1160.3ms error= 0.00000871% rsqrt_ss 108.3ms error= 0.03087627% rt2nd_ss 180.6ms error= 0.00002188%
dummy_ps 26.8ms error= 83.70051795% vsqrt_ps 288.4ms error= 0.00000871% rsqrt_ps 27.0ms error= 0.03087627% rt2nd_ps 53.4ms error= 0.00002188%
standard用了標準庫的sqrt()函數，編譯器使用傳統FPU的運算計算開方和倒數。
quake和quake2nd的確比standard快，但quake的相對誤差峰值約是千分之2，誤差較大。quake2nd則用接近一倍的運算時間來改善精確度，相對誤差峰值降至約百萬分之5。
divsqrt_ss使用了SSE運算，準確程度與standard相同，而耗時僅比quake2nd慢一點點。實際上，如果在編譯器開啟/arch:SSE，standard也會使用SSE運算，產生的代碼和divsqrt_ss相約，性能也差不多。

重點來了，rsqrt_ss的耗時只有quake的18%，而相對誤差峰值也更好，約萬分之3。仔細一看，發現它的耗時與dummy_ss相若。換句話說，因為使用了流水綫的潛伏時間，其數據吞吐量和至dummy_ss相若。
那麼，再比較使用多一次牛頓迭代的版本。rsqrt2nd_ss的耗時也只有quake2nd的18%。而相對誤差值也更好，去到千萬分之2的水平。
最後，若真正運用了SIMD的並行運算能力，使用ps後綴的指令又會如何？在此測試中，可以看到性能比ss版本的提升了3至4倍。而rsqrt_ps也因流水綫達至dummy_ps的吞吐量。rsqrt_ps比quake版本快20倍以上，比standard版本快70倍以上。
總結
雖然quake里的平方根倒數演算法是令人津津樂道的話題，但從應用來說，它並不一定是最好的選擇。

……
參考
[1] Lomont, Chris. "Fast inverse square root." Technical Report, 2003.http://www.lomont.org/Math/Papers/2003/InvSqrt.pdf

更新完成。

@Milo Yip milo老師說了整個優化的大框架，那我來補充一點實踐方面的知識好了，聊一下天涯明月刀OL的優化，下文把這個遊戲簡稱天刀。這是一個大型mmorpg，pc平台，客戶端程序員數量在25人以上，其中引擎程序員大約在10人不到。

天刀是我從業以來優化最久，投入最大的項目，沒有之一。以前的AAA遊戲，我們通常會有一個兩個senior的程序員，進行數個月的優化，而天刀的優化，斷斷續續做了接近3年，長期來看平均有兩個以上的senior程序員投入，整個引擎和遊戲方方面面都做了好幾輪優化。

優化的流程始於profiling，我們用過各種各樣的工具，cpu性能方面包括比較大路一點的vtune，自製profiling工具，已經數個小眾一點的基於sampler的cpu監測工具。為了監測各種卡頓，windows performance toolkit是最常用的利器，雖然相對難學點，但這是最好的查找卡頓的工具了，是windows平台上性能優化必須要掌握的工具。gpu性能方面gpa，perfhud用的比較多，中後期gpuview也很常用。至於為什麼要用這麼多不同的工具，主要是每個工具各有擅長，往往能看見其他工具不容易發現的盲區。

來幾個有趣的優化例子，看看天刀這裡的優化幅度:

1，milo老師的tag math+visibility組件，理念在2015年已經不算先進，但令人驚訝的是組件的效率。參考的dice公司同樣的技術，運行在ps3的spu，這樣的計算密集型特性，經過milo的優化，運行在普通cpu上，毫無壓力，在i3的入門級cpu上，依然只消耗低於2ms的cpu時間。這個技術甚至顛覆了傳統場景管理技術。天刀這個大場景遠視距的遊戲，玩過的朋友可能知道，場景複雜度和可視距離，都是國內少見的，即使和國外遊戲相比，也只有遜色於just cause，farcry等不多的遊戲，但是天刀裡面的場景管理，沒有用4叉樹或者8叉樹，直接扔進底層visibility組件。。。當然visibility組件裡面還是有一些簡單的類似管理，把這一層管理放到底層之後，場景管理和移動物體變得無比方便，對引擎層完全透明了。visibilty組件如此高效，以致陰影、樹木、反射，全部可以由它來裁剪，簡潔優雅。

在天刀早期做完大地形後，粗粗用visibility裁剪一下，幀數直接翻倍。後期主城場景密密麻麻，用到了其中的遮擋裁剪，看不見的就不畫，又沒有gpu的oclussion culling的延遲。

2，植被系統的優化。嚴格來說這不算優化，是一個特性。天刀植被用了speedtree，相當出色的中間件，基本一個美術就能把整個遊戲需要的樹全部建模出來了。於是我們就在考慮是不是可以在場景裡面種滿樹，因為這個中間件也有類似的demo。但是結果並不令人滿意，原生的技術在效率和質量上都不夠好。

開發同事在speedtree的基礎上做了很多嘗試和優化，效果被製作人幾次拍死，最後終於達到了滿意的質量，也就有了大家看見的漫山遍野得植被。遠處樹木本質上使用speedtree的billboard，但是在normal生成、樹木根部和地形的融合等多方面做了很多嘗試，對於樹木建模，是多一些polygon，好降低fillrate（因為pre z可以裁剪掉後面的像素），還是用大一點的面，可以減少polygon，也做了細緻的美術微調，找到了平衡。前後整個特性應該做了超過半年，初始效果做出來以後，在場景序列化、裁剪等方面又要做深度整合，而不能簡單充用原先speedtree的整合方式。在遠處使用billboard的樹木，同事很創新的想出密度倍增的技巧，一下子就出現了震撼的全景植被效果。

天刀的植被目前來說，效果和效率應該是是頂尖的。我們在2014年給unreal引擎創始人tim sweeney展示的時候，他也表示這是他見過的最好的植被表現，能得到偶像君的肯定，團隊也非常受鼓舞。更多細節我們今年下半年會有一個gdcc session，同事應該會介紹更多。

這個工作有一點值得注意，真正好的優化，是程序、美術等多團隊共同努力的結果。在效果和效率上很多團隊說起優化，就是程序定個指標，扔給美術去做，程序就不管了。這樣做下去，很容易出現美術用力縮貼圖減模型，效果一塌糊塗，幀數倒是沒提高多少。真正好的優化，必須是多方一起坐下來，共同分析問題，一起解決，即使是純美術的改動，也需要程序幫助定位問題，這樣才更有針對性，才能把優化帶來的質量損失降到最低。

3，卡頓優化，shader cache收集系統

天刀一測二測得到了較好的性能方面反饋，一方面的確優化的還可以，另一方面由於我們花了非常多的精力在防卡頓上面，導致遊戲裡面的卡頓相對較少，有玩家反映幀數只有20左右，但也能順利玩下來。由此可見，片面追求高幀數意義不大，去掉性能上的spike，會給玩家更好的體驗。

卡頓原因多種多樣，單獨就可以是一個很大的話題。我分幾個單獨案例來說。

一個情況是shader cache，天刀使用了uber shader的機制，根據場景和人物材質不同，可以組合出多種多樣的shader，開發早期會在構建版本的時候窮舉所有參數組合把shader全部編譯出來，存在版本裡面。很快這個方式就沒法用了，shader參數組合爆炸了，於是就用動態生成機制，根據參數組合去取shader，如果之前沒有編譯過就同步編譯，然後把編譯後的shader保存到cache文件，以後要用就可以直接load。之所以這裡沒有在後台用別的線程編譯，主要原因還是不希望編譯的過程中模型不顯示造成顯示上的瑕疵。但是這樣做的話，如果遇到缺失shader，就會有幾百ms的卡頓了。

開發過程中這個同步編譯當然無妨，但是見玩家的時候可不能這樣，事實上三測一開始就因為bug，cache沒處理好導致卡頓亂七八糟，被玩家噴死了。我們需要做的就是給玩家的版本裡面需要把所有的shader組合都編譯出來。

07年做xbox360遊戲的時候也遇到過一樣的問題，當時的團隊有足夠的測試資源，我們的方案是把所有用到過的shader參數存在文本文件，每天測試人員會把所有的參數發給我，我運行一個腳本去掉重複，整合所有的shader參數，然後第二天構建版本的時候就可以用收集的參數來預先生成所有的shader了。

但這次天刀項目組規模比較大，用類似的方法收集比較累。

我寫了個簡單的小server，測試版本都會上傳所有的shader參數組合到這個小server，這個server會定期合併參數，輸出後就可以上傳到版本裡面，下一個版本就可以構建這些shader了。

通過這個方法，我們在整個團隊不受到干擾的情況下，收集了所有的shader參數組合。同時如果一個shader太久沒有被用掉，也會被server去掉，這樣如果因為更新程序導致shader改變，那些廢舊的shader會在一段時間以後被慢慢淘汰，避免了shader的無止境增加。

4，卡頓優化，跨進程卡頓

有一陣子上線以後玩家表示卡得很，但只要刪除cross組件（騰訊內部的一個通用組件），就會流暢很多。聽到這個迷信的說法，大家都不以為然，自己測試一下，發現也沒有重現。

可是過了一陣子，發現坊間這個傳說越傳越廣，進一步測試，發現在主程或者群戰的時候，的確有可能會有很多沒發現的卡頓，這些都是我們開發版裡面不能重現的。

開發同學用Windows performance toolkit查了很久，結論非常令人崩潰。

起源是Cross組件使用了內部的另一個登錄組件，這個組件也被很多其他騰訊產品使用。每一幀cross更新的時候，這個登錄組件都會去讀一個系統的鎖。如果在遊戲內存佔用量非常高的時候，這個系統鎖的變數有可能被page out，於是引起了一個page fault，所以系統就會卡頓一下。我們內部的電腦都是SSD，所以page in也一般不是很慢，理論上也不應該卡啊。繼續追查，發現出問題的機器上往往裝了微雲，微雲經常讀寫硬碟，在多台電腦件同步數據。如果正好page in發生在讀寫數據的時候，就會卡了。換句話說，我們內部觀察到的現象，是騰訊的微雲讀寫一個文件，正好和遊戲中那個系統級鎖的page in過程重疊了，所以會卡。外部玩家如果用了其他騰訊服務，或者硬碟比較慢，也可能引起一樣的問題。

解決方案就比較簡單，把這塊東西的update全扔到另一個線程就好了。

就先講四個案例吧。可以看見在這幾個案例裡面，查找問題、解決思路都各不相同，但共同特點都是在程序端做了非常多細緻的工作，也有一些非常有創意的解決方法。在我看來，優化絕不僅僅是設一個budget，對美術資源的大小、polygon數量等等設好限制，然後push他們去減貼圖簡化模型。程序作為性能的主導者，有非常大的主動性，如果能有很多更有創意的實現方式，可以大大簡化美術的工作，也把性能和效果推到更極限。

只答前半部分「什麼是優化」。

我個人的看法：廣義上，優化是「為了達成相同目標，尋求並採用消耗更少資源的辦法」的過程，或其結果。

不知道題主小時候讀沒讀過高斯那個很流行的傳說，老師讓計算1+2+3+...+99+100，比起全部一個個相加，他發現1+100=2+99=3+98=...=50+51=101，然後直接101*50得出了答案5050。利用等差數列的求和公式使計算更加簡便快捷，這就是一種演算法優化。

那麼把上面斜體部分代入到遊戲這個話題中，不難理解優化是怎麼一回事了：

通過特別的軟體編程技巧……

實現相同的畫面表現效果、流暢度，對硬體機能的需求更低、更平民化

或者

在相同機能的平台上，實現更好的畫面表現效果、流暢度

如今玩家們口頭說的優化，一般是針對移植作品，也就是至少有兩個平台對比。人們會將遊戲在原平台的畫面表現和平台機能作為基線，去衡量移植版，有時也會以同平台的不同遊戲作對比進一步論證。總之，一個遊戲在一個平台上的優化好壞，大體可以用「表現效果/環境需求」的比值來衡量，或者說白了就是畫面好不好看、跑起來卡不卡。

@孟德爾提到的卡馬克平方根倒數演算法是一個細節優化的例子，就是採用了特殊處理而非標準庫函數來提升運行速度，無數個這樣的細節堆砌起來，造成的效果可能甚至不是不太卡和有點卡的區別，而是有的玩和沒的玩的區別——那個時候你甚至想不到「優化」這個詞。卡馬克之所以神，就是因為他屢次化不可能為可能。他在PC機上先後實現了捲軸遊戲、帶貼圖的偽3DFPS、真3DFPS、真實光源……這每一個進步背後都隱藏著優化，只是那個時代ID的光芒掩蓋了一切，其領先業界的幅度之大讓大家只能看到質變而已，可以說，在20世紀時，玩家們還沒意識到優化一說。

——————————

下面不說怎麼實現優化（可以參見 @Milo Yip 的回答），而是談談大家是怎麼意識到需要優化的，題主為何產生這樣的問題——其實那些嘴上說著優化好優化渣的人未必比題主更懂。

回過頭來，我們什麼時候開始感到「優化」的概念呢？我想，應該是PS2時代。

PS和SS時代，主機陣營相當分明，即使跨平台遊戲的表現有差異，多半也被歸功於SS的擴展卡。同期主機遊戲和PC遊戲的互相移植相當有限，也就是一些大作，例如PC版FF8、PC版MGS、SS版仙劍之類。

進入PS2時代後，微軟參戰，加之卡社、科社為代表的公司進一步婊化，遊戲跨平台化變得越來越流行。由於電視遊戲主機的硬體相對固定，為了最大限度發揮機能，提高3D畫面表現，開發過程中需要針對主機特性進行大量特殊處理，也就是所謂優化。而移植時限於成本，往往無法做到這麼徹底，因此即使硬體性能相當，原平台版的表現通常還是會比移植版要強一些，這個差距可能體現在解析度、抗鋸齒、貼圖精度、多邊形數量、運行幀率等各個方面。

到了PS3/X360時代，PC移植興旺後，「優化不足」的問題更加明顯，抱怨也更多，其實主要是國內玩家對移植版抱有不應有的期待，原因大概有以下幾點：

主機的特點是更新周期長，性能至少要照顧未來5年內的需求，硬體上必須採用推出當時中高端PC的配置；而價格上，為了迅速推廣搶佔市場，都是賠著本賣的——反正主要利潤模式是軟體抽稅。一來一去，也就是說次世代主機推出的一兩年之內，性能上是比同等價位的PC強不少的。買一台3000塊的主機可以爽最新的遊戲，但3000塊的PC也就是歡樂鬥地主水平。
PC顯示器解析度碾壓同時代電視，主機的設計輸出解析度其實是低於流行的PC遊戲的。例如PS2的標準解析度是480i（640*480），當時主流的17寸彩顯怎麼也是1024*768的。PS3的大部分遊戲都是720p輸出，每秒30幀；而兩年之後的08年，1080p顯示器已成主流。同一款遊戲若需要達到1080p點對點每秒60幀的PC玩家習慣需求，解析度上就扛了2.25倍的像素數量，幀率又翻了一倍，相當於需要的性能是主機版的4.5倍，這還沒算抗鋸齒的消耗。平民機玩移植遊戲卡頓也是正常的。
由於PC並沒有主機難以擴展升級性能的問題，廠商在將主機遊戲移植到PC時也不會太介意硬體需求——反正你現在跑不起來過兩年新顯卡出來了內存便宜了就能跑起來了嘛。所以很多移植遊戲的推薦配置都是變態級的。比如以「優化差」臭名昭著的GTA4，不光吃顯卡吃的厲害（1G以下顯存基本無法遊戲），對CPU的要求也極其苛刻。
（*本條慎讀）PC玩家和主機玩家的群體重合度並不高，想想和主機原版發售日期比起來，PC移植往往晚幾個月，有愛的早通關全成就了。其實等PC移植版的人有相當一部分是沒錢買主機專等盜版的lamer（這邏輯很奇怪吧？明明差不多性能的PC買一台主機加十幾個正版遊戲都夠了），素質也比較有限。你可以想像一下摳腳猥瑣男們，盼盼盼，盼來個傳說中的大作終於出了windows版，掛上迅雷拖兩天裝上一跑卡得像幻燈，上網發帖嗷嗷簡直是本能啊~

補一下，還是拿被罵優化爛最凶的GTA4說，這遊戲大陸根本買不到合法正版。你上amazon、steam去買下載版，沒有美國信用卡賬單地址人家根本都不讓你支付的。所以，吐槽歸吐槽，但有幾人真有資格抱怨優化問題？

說起遊戲的優化，在遊戲開發中經常分為這幾步：

首先要確定遊戲中經常會出現哪些問題 - Profile
然後確定在哪些方向進行性能優化 - Analyze
最後再儘可能將問題逐個解決 - Solve

遊戲開發中一定是先做工具，進行Profile，再進行優化，所以，說優化就不得不再扯一下Profile

常見的工具有一些是引擎和IDE自帶的，比如Unity自帶的Profiler，就包含了CPU，GPU，Memory等等各式各樣的性能分析工具，其他的比如GPA，Xcode Instrument和Visual Studio，Intel自帶的內存管理工具在必要的時候也使需要去學習和使用的。

另外一些工具，就需要根據遊戲的需求去編寫了，比如一鍵關閉所有特效，一鍵更改解析度等等，一鍵設置場上NPC數量，簡單的遊戲如啪啪三國是做成快捷鍵開啟Profile功能的，更為複雜的遊戲如神秘海域則是通過遊戲內控制台來進行更為細緻的Profie。

接著，我們再來說說遊戲優化中主要的四個考慮方向：

1、CPU

引發的問題：

由於短時間內的計算量太大，導致畫面流暢性降低，俗稱跳幀
發熱嚴重，耗電量高

常見的優化手段：

將計算分到多個邏輯幀中進行計算，避免短時間內的性能超過負荷，俗稱「分幀」（time-slice）。
將可以緩存的數據儘可能的緩存起來，避免重複計算和重複分配內存，常見的示例為「內存池」。
使用合理的演算法和數據結構，比如：冒泡排序和直接插入排序在整體數組比較有序的情況下效率大大好於快速排序。把快排替換成是優化程序排序效率的一個常見的思路。

2、GPU

引發的問題：

發熱嚴重，耗電量高
FPS降低

常見的優化手段：

優化美術資源，比如合理規劃圖集，約定好模型的最大三角形面數，制定合理的粒子效果規範。這個可以說是遊戲優化中最重要的一個，因此，技術美術在遊戲開發中作用巨大。
簡化或者優化著色器（shader）
使用Batching，盡量減少DrawCall
使用平台推薦的壓縮格式，比如安卓平台的ETC1和IOS平台的PVRTC

3、IO和網路

引發的問題：

網路延遲甚至掉線
載入資源導致的跳幀
載入時間過長

常見的優化手段：

使用獨立的線程進行載入，有些引擎如Unity中還能利用協程
減少網路包裡面的冗餘數據
合併小包，減少請求數據的次數
分幀對回包進行處理
限制一定時間內的發包頻率

4、內存

引發的問題：

閃退和卡死，比如安卓的Low Memory Killer會在低內存情況下殺掉內存佔用過大的程序。

常見的優化手段

動態載入和卸載資源，比如在遊戲內的時候，我們可以把遊戲外的一些UI圖集卸載掉。
降低資源質量或屏幕解析度，這是有損優化，一般作為最後的手段

其實這四個方面的優化總是相互制衡的，你把一個方面的優化做好了，另一個方面的問題又會出現了，比如，我們如果使用動態載入和卸載資源，這就雖然減少了內存佔用量，會在IO上造成載入時間延長的問題。

所以，我們在做遊戲優化的時候，不能太追求完美，剛剛好就是真的好（Good Enough Is Fine）。最終使得以上這四個方面能達到均衡即可，切忌在某一方面優化過頭，又引發其他方面的問題，此消彼長的情況下，有時反而不如不做優化。

程序方面：

內存優化

渲染效率優化（包含綜合幀率）

機型適配優化

CPU利用率優化

網路流量優化

資源大小優化

耗電量優化

I/O效率優化

美術方面：

配合渲染（面數，材質球，特效製作效率...）

配合適配（UI的適配性，字體的適配....）

配合內存及CPU(貼圖的UV排布，材質大小及通道復用)

策劃方面：

不產生新開發需求的各個模塊調優

既然說遊戲優化，那麼聊聊某些容易被人忽視的因素吧。

程序角度的優化：

1、項目開發周期的分析及預估（版本計劃）

第一個提是因為所有的優化方案都是基於整個項目基礎上的，所有的突發情況都應該是可以被預估的。所有的冗餘都是由於計劃不完整造成的。

2、模塊整合優化

項目肯定有重要功能以及輔助功能，將幾個重要功能整合作為核心功能優先處理是相當有必要的。如賬號登錄以及商城充值。

3、各個功能模塊功能點的梳理以及後續拓展的分析

如果模塊優化是粗放式的，那麼這個就屬於細節了。分析各個模塊的功能點有利於程序邏輯的實現以及項目的預估，並且使後續功能的拓展變得更加方便。

用戶方面的優化：

1、用戶行為分析需求整合——分析後提交給程序以安排時間設置埋點。

2、後台配置優化整合——添加各種查詢功能，並設置許可權。為策劃、運營、QA、客服提供支持。

3、基於用戶體驗的交互設計優化——主要利用策劃的主觀感性設計、以及用戶行為分析等客觀手段作為參考。

美術源源方面的優化：

1、美術資源的有效利用——盡量不使用整張圖片、重複利用小塊拼接方式拼圖、使用程序實現動態特效等等。手機遊戲怎樣壓縮美術資源？

2、美術資源的有效管理——保證每個版本的資源都是明確不冗餘的、不同版本的資源是可區分的、查詢修改是方便的。

QA方面的優化：

1、測試流程的規範化管理。——能夠隨時掌握項目當前的所有功能點的測試內容、測試方法、測試通過標準。

2、用戶體驗的分析報告。——有利於策劃在新版本開發時的功能模塊優化。

還有很多其他方面的優化、比如用戶可見的（節奏感、流暢度、動態特效表現）以及不可見的（遊戲底層、資料庫存儲過程、表結構的優化、機器人AI優化）等等。

雖然回復經常沒有人點贊，但是我還是會堅持每一條認真回復，只要能給予各位以些許啟發就滿足了。

優化在計算機中覆蓋的面太廣了，這種沒有具體指向的問題，只會引來越來越多的民科答案。

順便，題主聽到的這些話肯定都是門外漢說出來的。

ps，圖形方面的優化期待 @Milo Yip 前輩的答案。

我認為題主這裡說的優化更多是渲染層面的概念，它是兼顧設備、內存大小、運行效率、遊戲容量等諸多因素讓遊戲表現更好、運行更流暢且開銷更小的方法。一般優化方法都是有代價的，提升某方面，其他方面可能都會有所犧牲，需要考慮需求進行整合。

優化得好與壞都需要通過一種標準來驗證。比如我朋友製作的ARPG網遊，實時戰鬥，光影效果，精細動畫，在iPhone4S上可以同屏50個不同人物打鬥，穩定30FPS。那麼這可能就是ARPG手游的一個優化標準，如果你能超越它，那麼你就優化得更好！

最後明確一點，優化這個事一定是一開始就要打好基礎的！

不僅限於遊戲吧，我不是做遊戲開發的，了解一點，可以舉點（可能不合適的）例子

有高大上的優化，各種先進的數據結構和演算法等等，比如 @孟德爾提到的快速平方根演算法。

也有策略結合技術的優化，比如 @ArtS所言對於遠距離對象降低貼圖和模型質量。

也有「民科」的山炮技巧優化，這個例子我舉不出來，因為太貼合生產了。我能舉一個JS的例子，JS里用`~~x`做取整比`Math.floor`快很多……這種我看來就算民科了吧

可能有些跑偏吧，口頭上說「遊戲優化好不好」，主要是指它跟同期遊戲在相同機器上比能否顯得「它運行的效果與速度，對得起這台機器」

典型例子

卡馬克快速開方

卡馬克快速平方根---平方根倒數演算法 [轉]

電腦遊戲受限制，但是過去遊戲機上所有底層驅動都是軟體商自己寫的，所以優化就指的是整個軟體而不單單是某個方面了。

　　高票答案已經解答得非常專業了，這裡就從玩家的角度出發，舉幾個普通人就能觀察的到的遊戲優化手段吧。

　　不渲染大地圖遠處/遮擋的事物

　　現在開放世界式的遊戲越來越多，連在線性敘事遊戲耕耘多年的日本廠商，都開始嘗試製作開放世界遊戲，例如最終幻想15就硬生生把前幾關做成了開放世界。開放世界遊戲中，大地圖是必不可少的元素，但大地圖就意味著模型數量暴增，如何將大地圖流暢地呈現到玩家面前？於是就得在視野外的模型做手腳了。

大地圖對硬體負荷很大，要流暢的畫面，遠景和遮擋事物會被縮掉

　　儘管開放世界的地圖很大、視野開闊，但玩家總有看不見的地方，或者看得不太清晰的地方，例如背後，例如被遮擋住的建築，例如遠處等等。於是，遊戲就會不渲染或者只用低畫質來渲染這些模型，待到玩家移動到這些地方的時候，才使用高畫質來進行渲染。

　　玩家在很多遊戲中，其實都可以觀察到這些現象：放眼望去遠處明明是沒有草的，跑過去後草突然就從身前冒了出來；某座山剛剛看到的時候就像一個圓滑的土堆，但向它靠近的話不一會兒就變成了稜角分明的石頭。這些現象被部分玩家稱作「炸山」，帶有大地圖的遊戲想要流暢運行，這種優化技巧基本是必不可少的。為什麼《絕地求生：大逃殺》會卡？為了競技的公平性，這遊戲不能大幅減少遠處的草木、房子渲染，所以需要渲染的地圖大、事物多，對配置的要求自然也就水漲船高了。

　　利用崩落場景刪地圖

　　除了開放世界式遊戲，線性敘事的遊戲地圖也比之前進化了不少。地圖不僅更大，而且更加精細，像頑皮狗最新出品的《神秘海域4》，一些場景已經接近照片級，令人難分真假。一般來說，如此精細的畫面是很耗資源的，但偏偏這遊戲是PS4獨佔，PS4的機能遠不及現在的頂級PC，而《神秘海域4》還非常流暢，這是怎麼做到的呢？

《神秘海域4》的畫面令人很難相信是在PS4這樣的機能下實現的

　　這遊戲的一大優化手段，就在於不斷利用崩落場景刪地圖。例如，當玩家爬山爬了一段後，背後會發生懸崖崩落之類的情節，緊張刺激的同時，隨著崩落，舊的地圖也被刪掉了，遊戲自然也不再需要渲染太大的場景，硬體壓力大大減少。

《神海4》的遊戲流程伴隨著很多場景崩落，崩落的同時刪掉了無用地圖，減輕硬體負擔

　　其實這種手段在頑皮狗出品的遊戲中很常見，例如《The Last of Us》當中，也經常走一段路，後面的建築就崩塌掉，玩家沒法再走回頭路。這種和關卡設計緊密結合的優化手段，還是非常行之有效的。不過這種優化方式僅適用於線性遊戲，開放世界式的遊戲很難使用。

　　採用動態解析度

　　更高的解析度帶來了更細膩的畫面，同時也帶來了更大的運算壓力。現在越來越多的遊戲把解析度做到了4K乃至8K，這對於機器來說，可就很難吃得消了。但玩家偏偏又喜歡享受高解析度帶來的快感，怎麼辦？動態解析度應運而生。

　　顧名思義，動態解析度就是會變動的解析度，當遊戲遇到複雜場景、特效而壓力山大的時候，就會自動降低解析度，以犧牲解析度為代價，換取流暢度。動態解析度的使用是有技巧的，你總不能讓玩家跑一會兒人突然變成了馬賽克，再走兩步突然又高清得連毛都看得一清二楚。通常來說，只有在動態、特效複雜等場面下，玩家不太留神建模的時候，動態解析度才會發揮作用，帶給玩家更流暢的遊戲體驗。

像放無雙這種特效比較多的場景，某些遊戲機就會動態降低解析度，PSV的玩家應該深有體會

　　實際上，在PC中動態解析度這手段使用得並不算頻繁，在遊戲機平台上倒比較常見。在PC上遊戲卡了廠商可以賴你配置不夠高；但在遊戲機上遊戲都變成幻燈片，這遊戲「渣優化」的帽子可就脫不掉了。同時，遊戲機一般也不能設置遊戲渲染的解析度，遊戲用什麼解析度，全憑廠商的策略，於是動態解析度就成為了常見的優化手段。

　　利用過場時間讀圖

　　現在的遊戲體積越來越多，讀圖的時間也越來越長，如何讓玩家減少讀圖的等待，也很考驗遊戲優化的功力。現在最常見的手段，或許就是在過場時讀圖，等過場播完了，遊戲也就已經載入完畢，玩家並不會覺得等讀圖等了很久。

《女神異聞錄5》帶有大量非常炫酷的過場動畫，其實過場時就已經在讀圖，很巧妙的設計

　　什麼是遊戲的過場？例如遊戲過程中播放的CG、戰鬥結算動畫等等，就是典型的過場。現在很多遊戲都是用了電影式敘事，打一段遊戲播一段片，在播片時讀圖，的確可以提升遊戲體驗。

　　總結

　　上文提到的只是一些玩家留心就可以觀察得到的優化手段，希望遊戲廠商都能夠更加註重玩家的實際體驗，在用「顯卡殺手」來奠定畫質領頭羊地位的同時，也不要忘記並非所有玩家都會配備四路泰坦，多做優化，為最廣大的玩家提供流暢而精美的畫質，才能贏得真正的好口碑。

優化分很多：

內存優化

圖形渲染優化

CPU利用優化等很多的內容。

一部分是靠遊戲引擎，一部分是靠開發者。

如你要查找一萬個數字，遍歷的效率往往比二分低下，利用二分，就是優化。

占樓待詳細更新。&>_&<

優化這個東西涉及遊戲的方方面面，從程序到美術甚至策劃。。。不過一般玩家所說的優化是指畫面和配置要求跟同等級遊戲比起來要差一些，比方說同是x360的沙盒遊戲，gta5畫面比黑道聖徒好（打個比方）幀數也更穩定就說gta比黑道優化好

我本能的聯想到優化是調整各個系統、新手流程的體驗細節，消費設計，增加留存

這個優化要看是從哪方面下手

從程序上，可以是客戶端性能（比如提高最低幀率），可以是服務端穩定性（比如降低崩潰和維護次數），可以是玩法（比如增加了一個PVP系統），可以是美術的（換了套模型好看多了），可以是運營層面的（比如某個開服活動增加了xx留存）

依寡人愚見，遊戲優化是個複雜的跨工種過程，會涉及到各方面人員. 人多了，有些事情就複雜了. 公說公有理婆說婆有理的事情就發生概率大增，不確定因素就多. 搞砸了的概率也會提升，所以優化有好有壞羅

cpu是很快的，但不是無限快，內存是大的但不是無限大，所以要把有限的資源用在對體驗重要的地方。而對體驗沒那麼重要地方可以少用點資源。比如iPhone瀏覽器滑動時會使網頁暫停，早期極品飛車後視鏡里圖像刷新有點慢，Minecraft里不是所有方塊都同時顯示等等。

優化差就例如有的遊戲。是不打包的。

然後遊戲目錄下面幾萬到十多萬的文件。

然後也是沒緩存的。用到再讀取的。於是會有瘋狂的硬碟操作。

可能開發人員認為每個人的硬碟都很快吧。

於是過圖卡一下。然後走兩卡一步~

優化好。就例如。把十多萬的文件打包起來。加快讀取速度。

再把常用到的物件。先讀取到內存里放著。省掉頻繁的硬碟讀寫？

---普通玩家,可能不專業.

說點策劃面的找點存在感吧。

網遊是在持續運營的，所以其中的優化行為更加明顯。

以lol為例，每次賽季的規則修改，都是在上賽季大量數據的基礎上做出的系統優化，已使賽事系統和排位賽系統有更高的使用率。

每次版本的調整，都是對核心玩法的優化，優化玩家的對局體驗，提高數據，平衡英雄使用率，引導玩家行為。比如全tank時代啊，一代版本一代神啊，都是核心玩法優化的過程產物。螃蟹做的調整，也是改變了玩家行為的優化。

大廳界面的調整，聊天欄布局等UI交互優化，很多時候也是由策劃主導的。

優化無止境，優化不一定是好的，策劃優化尤其如此。WOW的版本迭代尤其能說明這個問題。

其實更多的優化點不是同一個遊戲中的，而是一個類型的遊戲不同世代不同作品前赴後繼的積累而成的，這樣看更有意思更有啟示。

嘛，好像跑題了~