比如听朋友说某国产3D网游优化做的烂，即使是配置机器也无法全流畅运行。这里的优化指的具体是哪些方面？

　　（我看这题目的其他答主就已经快分门别类地把底层到前端，从技术开发到游戏内容等方面都说尽了）

　　，可以说任何在已经完成或初步完成的功能性开发基础上的调优，改善，修正，美化，填充，Debug，只要不是推翻重制或彻底的增添删除，都算优化（对应的反义词是劣化，一般来说我们不认为商业产品中会出现任何有意劣化的行为），其字面意思本身就是指使现有的东西变得更好，而整个产品开发的方向不就是这样吗。

　　而且这个优化的范围远不止游戏底层代码，整体架构；从数据储存，到外部接口；从游戏界面，到操作方式；从声画效果，到表现；甚至游戏体验，关卡难度，新手引导，任务设计。任何方面的调整改善都算作”优化“。

　　而且我们在开发中也确实会这么阐述——优化一下封包，优化一下前期，优化一下画面，优化一下，这些说法都是很泛泛的，往往只有在双方对实际需求非常清楚的情况下，这个说法会作为对一系列需求的统称：例如优化一下前期可能是指包含有从进入画面到login的方式，从角色建立到新手引导的一系列需求的统称而已。

　　的确，比如游戏的3d引擎效率低下、显存或渲染的资源占用过多、64位环境下Dx10支持不好、某个API存在Bug、特定显卡或驱动有兼容性问题。等等等问题都会造成画面fps大幅下降，进而造成不流畅，

　　但并不是说“没优化好”这个非常不确切的概念，就可以变成一个问题的原因。

　　还是得说，您朋友的描述本身就没什么道理，类比于这桌菜就是烹饪不行所以不好”，听起来好像没错，实则什么都没说。是原料不佳，还是加工不良，是火候不行，还是是搭配不当，是调味出了岔子，还是色香不够诱人？这些都可以算作“烹饪”的一个方面吧。

　　用可以涵盖全体的原因，描述一个具体的问题，其实是不那么合理的叙述方式。实际上也无助于解决问题。

　　一般概念中的优化，是随着开发者对于硬件特性和图形原理更深入的理解，使得游戏画面比原来更好，或者同样的画面有更高的帧数。

　　更新的技术往往需要更高级的硬件支持，尤其在某些历史阶段，硬件的灵活性非常低，留给你自由发挥的空间并不大。像当年的32位机，大量图形效果都是硬件设计时就锁死的，强行实现某种效果可能导致其他的效果狂跌。

　　这也是为什么近两代游戏机越到后期反而帧数和解析度越来越低。主机上市初期，只能用保守的方法做游戏，看上去机能很富裕，到了后期，能实现的新技术越来越多，算力不够了，只能从其他环节挪用，于是什么720P，什么20帧都冒出来了。

　　编程技巧提升更难，因为谁也不会故意把程序往烂了写，除非你之前太小白太蠢，犯了很多不可原谅的错误，否则水平不可能有本质性的提升。（日本游戏业这种段子挺多的，比如忘了做LOD，导致几公里外的山上有几十万个多边形）

　　硬件本身设计得不合理，某个部分形成了瓶颈，在大家都暂时没办法解决的情况下，只能做出取舍。

　　比如SS这台主机。在硬件T&L显卡出现前，3D游戏的多边形顶点与光照运算是由CPU完成的，而且运算量非常大，同期的PS有专门的芯片辅助CPU做矩阵运算，SS 很不幸全都要扔给CPU。所以从《VR战士完美版》开始，SS的3D游戏都直接删除了光照效果。直到后来《格斗之蛇》有了经验，能更平衡地分配CPU负载，才把光照加回来。

　　这就引出了一个很反常识的结论：很多游戏的所谓优化，从某些角度看其实是劣化。

　　假设我们有20点硬件资源，A和B两个必须的特性各耗费10点，给玩家带来20点的愉悦。后来制作者发现，如果放弃A，把20点全加到B上，会给玩家带来30点的愉悦，所以A就被咔嚓了。

　　早期的3D游戏，光和影的运算是分离的。所以游戏中往往有一个专门的模型用来生成影子，这个模型对玩家是透明的，只对阴影算法可见。模型非常简陋，胳膊腿就是长方体，降低运算量。省出的资源可以干别的用，这就叫合理分配资源。

　　其中用户体验很笼统，甚至包含了故事流程，交互操作，视觉效果（美术+技术），游戏性能等。

　　按你说的配置问题，那就是侧重于游戏性能的单机（纯客户端，基本不涉及网络）一侧。

　　程序运行效率，程序语言执行效率，模型优化程度，贴图/材质优化，数据解析优化，场景优化（灯光等），算法优化，以及其他暂时没想到或者想不起来的优化。

　　程序运行效率的优化大家都明白，不过很多程序员其实了解不深。这不光是一个算法，更是一个、架构设计/流程设计思路，和语言设计思路的问题。算法只局限于一个局部。而架构设计额和流程设计则影响了整个程序运行效率的全部。

　　纯客户端架构方面（这与服务器端的架构非常不一样），比如是否存在进程之间的协作、同步、数据传输，以及其效率如何；是否有不用语言之间的来回穿透，比如Java的游戏通过JNI频繁调取本地C/C++动态库处理数据，等等。

　　流程包括流程的合理性。比如，是否为了获取一个计算并不麻烦的整数，然后创建了一大堆中间临时对象等。比较贴切的例子（但也很无关）是数据库的多表联合查询。在网络，很多事为为了提高效率而故意的破坏范式，增加冗余数据或者表合并，就是为了尽量避免多表联合查询。

　　语言方面，你是否是存Java的？还是Python的？还是？Java有没有用JNI？有没有多次频繁穿透JNI？是否使用了C/C++？是否使用了顶点渲染？等等。以及是否为了OOP而OOP？（过多的抽象，过多的class。大部分的class极其简单和破碎，而且还是非静态的，需要来回创建。有必要么？）

　　不必要的细节是否都被删去？模型定点是否在不明显影响渲染质量的情况下，降到少？（每个顶点都需要被计算的。同一个人物模型，3000个顶点和100个定点，在同样的光照和材质下，哪个渲染更快？）

　　贴图是否尺寸恰好？不需要（或尽量避免）程序进行缩放？能不用透明材质的地方是否避免使用？能用贴图代替的镜面材质是否使用贴图代替？……

　　本地方面，数据存储的（对象）模型设计是否高效？使用JSON还是binaary存储数据？网络方面是否使用了xml这样体积膨大效率超级低下的格式进行传输？

　　能用float的地方是否还在使用double？能用int的地方是否还在使用float？三角函数/开方等的计算是否经量避免？用的矩阵函数库，或自己写的矩阵计算是否高效？

　　灯光/光源等是否优化，且尽量减少？每多一个光源，就得多计算一组光照，包含折射烦反射等等~~场景是否尽量切割，避免同时运算过多的模型和材质对象？是否使用了LOD？或者引擎自动生成，或自己自做的LOD模型效率如何？等等……

　　大致就这样吧，服务器端和非客户端性能相关方面有需要再问再答。吃饭先~~（马上该1点上班了）~~

　　总结下其他答案：中文优化对应了两个完全不同的英文词的含义：Optimization 性能优化、Improvement 宽泛地指提升的意思。

　　”优化“是游戏开发过程中的一个重要组成部分，同时也为了感谢@谢熊猫君的精彩食谱，我来答一答吧。

　　本质上，游戏是一种实时交互程序。两个关键字——“实时交互”和“程序”。所谓“实时交互”就是计算机要在很短时间内对用户的输入做出反应，由于现代游戏主要都是基于图像和声音，所以在这个短时间内游戏引擎需要对大量的数据进行更新并输出。一般游戏的更新频率是30fps，也就是每秒钟内要完成30个数据更新周期，才能达到交互的实时感。帧数可以说是游戏程序运行效率的直接体现。所以对于游戏程序，帧数至关重要；所谓“程序”就是游戏必定是运行在某种硬件之上，一定会受到硬件的制约。在诸多限制中，内存是重要的一环——内存溢出的直接后果就是程序异常中断，这在商业游戏中是不可接受的质量问题，问题的性质远比低帧数严重。同时现代游戏的海量内容又要求尽可能塞满内存。所以对于游戏程序，内存的管理至关重要。

　　从广义上来说，如何让计算机程序运行的更快，处理的数据更多，都算得上是“优化”；但是从游戏开发的角度看，对于已有的成型的项目而言，优化就是两大方面——帧数和内存。

　　在展开详细谈之前我先要提一下不同平台和不同渠道对于优化的影响。按照“优化”要求的严格程度排序，有高到低，大致上是审核严格的封闭平台——比如Console游戏；审核较松的封闭平台——比如苹果的App Store；有审核的开放平台——比如Steam；完全无审核的开放平台——比如PC和Mac的自由开发原野。

　　Console平台的游戏审核严——这是有任天堂从“雅达利大崩溃”以来首创的做法，Sony和微软也采取了同样的方法。目的就是为了保证自己平台上游戏的高质量。Console都是封闭平台，硬件规格延续数年不变，网站优化代理这创造了稳定的开发环境，网站优化代理让开发者可以通过数年累计出专门的优化经验和技巧。另外Console平台一般销量巨大，对质量和稳定性要求很高——当你的产品要呈现给几百万几千万人，创造几亿的销售额，“的体验”是很自然的事情，而优化正是用来保证这一点。

　　手机和平板其实也属于封闭平台——用户无法替换任何硬件部分，但是数代并存和家众多造成了相当数量的硬件规格同时存在。相对的iOS平台硬件比较整齐，分辨率相对统一，App Store的审核相比较Console宽松不少，但仍有一定要求。而Android阵营则比较混乱一些，硬件参差不齐，App销售平台纷繁芜杂，审批更加宽松。另外手机游戏的开发投入规模一般比较小，也不太会有过多的精力投入优化之中。总之优化的要求是ConsoleiOSAndroid。

　　开放平台一般指的都是桌面系统，特别是PC。各种硬件规格的排列组合可以几乎说是无限多，所以相对的每个特定性能区间的配置获得优化的注意力是很有限的，除非资金充裕如暴雪，否则很少有会做到面面俱到，给主流配置优化一些，过高或者过低很有可能就忽略了。有审核的游戏发布平台会好一些，比方说Steam，会有起码的要求，无审核的完全就靠开发者对产品质量的追求了。国产3D网游就是属于末一种（新闻出版署的审核是政治审核和内容审核），在时间和成本压力下，很有可能出现问题描述中的情况。

　　笼统的游戏优化一般都是指优化帧数, 也就是FPS, 用以衡量游戏的效率, 一般情况下影响FPS的有下面这些:

　　[ 迷之音: 为毛看上去像是PC上的主要部件都会有影响啊; 迷之音2: 废话, 土豪们的游戏PC所有部件都是顶配, 就是因为这~~ ] [纯joke]

　　基本上每一个部分都可以展开来说很久很久, 而且由于木桶原理的存在, 实际的效率取决于短的木桶那块. 我们先假设所有的部分性能都差不多好了.

　　贴图优化, 缩小texture的尺寸, 根据不同用途使用不同的压缩格式, 等等

　　pipeline优化, 尽量不用discard指令, 尽量在vs中计算, 等等

　　预渲染, 将某些光照计算bake出来, 避免pre-pixel light的时候, shader单元压力过大, 等等

　　渲染优化, 使用deferred rendering/lighting, 而不是forward rendering. 当然, 如果你一定要x格十足, 要用ray trace, 当我没说

　　避免使用阻塞的api call, 尽量使用api里面的异步调用方法, 等等

　　太多了, 没法细说, 粗想起来这些吧, 当然, 太多优化不是好事, 很容易搞得惨不忍睹, 所以, 千万记得, 还是要具体情况具体分析的~

　　在游戏中，你会发现某些地方会“比较”流畅，比如郊外，而有的地方会特别卡，比如汴京虹桥。

　　我们假设网易的程序不会出现低级错误，比如游戏占用显卡资源少的问题，优化好的游戏，会尽可能的去占用你的电脑资源。

　　难一点的呢，优化加载项、底层代码、架构、内存占用、算法、调用等等，总之，程序水平有多高，优化就能多好。

　　总之，大多数优化都是建立在砍画质上的，游戏都已经在正式运营了，优化的空间也就那几样了。

　　不知道是不是绝地求生给了雷火勇气，觉得玩家为了顺火暖舍得升级电脑配置，确实，得益于网易铺天盖地的宣传，没开服之前很多人买了电脑，等待着后一款端游的到来。

　　他的优化在我看来，制作人背大锅，立项的时候方向出了问题，后期修改都来不及。

　　评价一款游戏的性能好坏，我们通常会用到帧率（每秒钟的渲染帧数）作为主要参考指标。当然，手游这块功耗也是一个重要因素，但主要还是看帧率。像MOBA、FPS类的游戏，帧率肯定是越高越好，出于功耗与显示设的限制，一般跑满也就在60fps左右。而像其他的棋牌、放置类游戏，帧率只要有30fps就足够了。

　　性能优化要谨遵二八原则：20%的代码影响80%的性能瓶颈。因此要合理地找出性能瓶颈所在，避免负优化。下面就三个比较常见的方面：bandwidth、drawcall、overdraw来分别阐述渲染阶段是如何造成性能瓶颈以及对应的解决办法。

　　移动端的GPU设计之初，优先注重的肯定是功耗问题，然而在实际渲染一帧图像的时候，对功耗影响的因素就是带宽（bandwidth）。

　　这是因为出于空间的考虑，手机芯片的设计上采用了SoC架构，因此内存与显存实际上是共享在一块物理内存上的，在OpenGL ES规范中，内存与显存中的数据却不能共享。在有限带宽的前提下，我们不妨计算一下，一台分辨率为1920*1080的移动设，按60帧率来算，每秒钟1次overdraw产生的数据量为：

　　如此大量的数据存储在显存的FrameBuffer中，GPU要以高昂地代价频繁地去显存访问FrameBuffer里的数据，这显然是很难接受的。因此在移动端的显卡硬件上，想到了一种优化方式，就是将FrameBuffer拆分成不同的小块(tile)，每次可以先将这一小块的数据放到访问速度更快的On-Chip Memory中去，GPU会先从tile中一块块地去进行渲染，等整体渲染完成之后，再将数据搬回显存上。

　　然而在TBR模式下，可能存在着这样的一个问题，如果对于CPU每一次传来的绘制命令都进行渲染的话，那么GPU必定会频繁、大量地对tile数据进行搬迁操作，这显然是不可接受的。为了解决这个问题，TBR一般的策略是：对于CPU提交的Draw Call请求，先只做顶点处理，将Vertex Shader计算的结果暂存到一个叫FrameData的地方。等到执行Swap Buffer的时候，再对整个数据做光栅化，进行绘制。网站优化代理

　　既然是等所有的FrameData数据处理好后一次性进行绘制，GPU硬件上便进一步做了些延迟渲染相关的优化。例如iOS上的PowerVR，专门有一个叫 ISR 的硬件，会去处理FrameData中那些诸如深度测试、模板测试没有通过的数据，尽可能地只去渲染那些终影响FrameBuffer的物体。

　　基于移动端GPU特有的架构模式，需要我们做哪些优化方面的事情或是注意事项呢？

　　手机上CPU与GPU的关系，就好像客户端与服务端的CS架构。所谓Drawcall，可以理解为Client端的CPU向Server端的GPU发送的一次绘制命令，同时会传递需要被渲染的图元列表。现代GPU就为了高并发处理数据而生的，一般Drawcall的绘制数据计算起来应该还是绰绰有余。但由于CPU传递的渲染数据得通过PCI-E总线才能传到GPU显存中的全局存储区域，频繁且大量地提交绘制相对简单的绘制命令，会造成GPU端的“产能过剩”，CPU无法及时提供渲染数据而造成性能瓶颈。

　　与此同时，TBR架构下优化过的GPU，会先将顶点数据存储到FrameData队列，如果Drawcall数量过多，且顶点数量巨大，万一FrameData承装的内存放不下了，就得先将数据移动到别处，进而大大降低了访问速度。这也是我们需要控制DrawCall数量和顶点数的一个重要原因。

　　在每一帧都对需要的网格进行合批处理，这样的好处就是合批的物体仍然可以各自移动，但是必须使用同一个材质。当所需合批的顶点数过多时，其实会对CPU产生额外的计算开销。因此在做动态合批的时候，通常会有顶点数的限制，需要根据实际需要做好取舍。

　　只进行一次合批处理，生成一个大的网格，性能优于动态合批，但没有动态合批灵活（只能作用于静态物体），并且会有较高的内存占用。

　　根据机型或摄像机距离，使用不同的材质shader，尽可能地降低细节表现，去除不必要的渲染Pass以及计算开销。

　　常见于大世界场景的游戏中，对于摄像机可视范围之外的物体可以进行视锥体剔除，但是可视范围内的那些已经被遮挡住了的物体，可能仍然会去进行绘制，造成不必要的性能损耗。

　　对需要绘制的物体进行排序，是游戏引擎规避性能开销的一种常见手段。非透明物体相对摄像机由近及远地排序绘制，可以有效剔除那些深度测试不通过的片元。但对于那些未被遮挡（深度测试通过）的透明物体，由于需要开启混合计算，因此在Early-Z阶段也没法剔除掉那些背后的图元数据，这就造成了同一个像素的多次(过度)绘制，即我们常说的Overdraw。

　　GPU中跟Overdraw有关的指标可以参考像素填充率，即每秒所能渲染的像素数量。在确保带宽没有遇到性能瓶颈后（改用压缩纹理格式），如果降低设分辨率后，帧率一下子上去了，那么很可能就是像素填充率遇到了瓶颈。这时候就需要看看Overdraw是否在一个合理的范围内，是否有优化的空间。

　　实际的游戏开发中，常见的Overdraw大户莫过于粒子了。美术同学在制作粒子的时候，往往会为了追求细节效果而忽略掉Overdraw的问题。大量的透明粒子相叠加，造成的性能开销是十分可怖的。为此，我们在立项之初就设定好一些粒子的制作规范，或是一些建议要求来约束美术设计粒子效果。

　　为了照顾低端机型，我们可以对粒子采取分级的策略，等级越低，表现越简单，同时也可以从粒子数量、运算模块来进行精简。如果还是不能满足性能要求，也可以考虑改用帧动画来替代粒子。

　　本人作为玩家的理解，就是对游戏程序的编程优化，让游戏在同样的硬件下，优化前和优化后有performance上的提高。

　　你说的优化就是这个意思吧，例子就比如星际争霸2，常见的看法是此游戏在i5双核CPU和i7四核CPU下并没有显著的差别（即战斗单位一多，i5和i7下游戏画面都会卡，而战斗单位少的时候，都不卡），具体原因据说是因为没有对多线程处理器的支持（虽然sc2刚出那会儿好像也没听说有任何别的游戏是支持四核威力提升的---*好想这也是贴吧ZOL那些地方对玩家普遍推荐i5双核而不是i7四核的原因吧）

　　还有一种就是那种小游戏，只有几MB，却能带来一个相当不错的内容（但占用很高的内存）如「稿纸大战」。
以上信息由常州声谷信息科技有限公司整理编辑，了解更多网站优化,网站优化代理,单词优化,网站优化哪家好,单词优化代理,正规网站优化代理信息请访问http://www.shengguxinxi.com