游戏研发细节总结

一、程序

1.务必删除脚本中为空或不需要的默认方法；
2.只在一个脚本中使用OnGUI方法；
3.避免在OnGUI中对变量、方法进行更新、赋值，输出变量建议在Update内；
4.同一脚本中频繁使用的变量建议声明其为全局变量，脚本之间频繁调用的变量或方法建议声明为全局静态变量或方法；
5.不要去频繁获取组件，将其声明为全局变量；
6.数组、集合类元素优先使用Array，其次是List；
7.脚本在不使用时脚本禁用之，需要时再启用；
8.可以使用Ray来代替OnMouseXXX类方法；
9.需要隐藏/显示或实例化来回切换的对象，尽量不要使用SetActiveRecursively或active，而使用将对象远远移出相机范围和移回原位的做法；
10.尽量少用模运算和除法运算，比如a/5f，一定要写成a*0.2f
11.对于不经常调用或更改的变量或方法建议使用Coroutines & Yield；
12.尽量直接声明脚本变量，而不使用GetComponent来获取脚本； iPhone
13.尽量使用整数数字，因为iPhone的浮点数计算能力很差；
14.不要使用原生的GUI方法；
15.不要实例化（Instantiate）对象，事先建好对象池，并使用Translate“生成”对象；

二、模型

1.合并使用同贴图的材质球，合并使用相同材质球的Mesh；
2.角色的贴图和材质球只要一个，若必须多个则将模型离分离为多个部分
3.骨骼系统不要使用太多；
4.当使用多角色时，将动画单独分离出来；
5.使用层距离来控制模型的显示距离；
6.阴影其实包含两方面阴暗和影子，建议使用实时影子时把阴暗效果烘焙出来，不要使用灯光来调节光线阴暗。
7.少用像素灯和使用像素灯的Shader；
8.如果硬阴影可以解决问题就不要用软阴影，并且使用不影响效果的低分辨率阴影；
9.实时阴影很耗性能，尽量减小产生阴影的距离；
10.允许的话在大场景中使用线性雾，这样可以使远距离对象或阴影不易察觉，因此可以通过减小相机和阴影距离来提高性能
11.使用圆滑组来尽量减少模型的面数；
12.项目中如果没有灯光或对象在移动那么就不要使用实时灯光；
13.水面、镜子等实时反射/折射的效果单独放在Water图层中，并且根据其实时反射/折射的范围来调整；
14.碰撞对效率的影响很小，但碰撞还是建议使用Box、Sphere碰撞体；
15.建材质球时尽量考虑使用Substance；
16.尽量将所有的实时反射/折射（如水面、镜子、地板等等）都集合成一个面；
17.假反射/折射没有必要使用过大分辨率，一般6464就可以，不建议超过256256；
18.需要更改的材质球，建议实例化一个，而不是使用公共的材质球；
19.将不须射线或碰撞事件的对象置于IgnoreRaycast图层；
20.将水面或类似效果置于Water图层
21.将透明通道的对象置于TransparentFX图层；
22.养成良好的标签（Tags）、层次（Hieratchy）和图层（Layer）的条理化习惯，将不同的对象置于不同的标签或图层，三者有效的结合将很方便的按名称、类别和属性来查找
23.通过Stats和Profile查看对效率影响最大的方面或对象，或者使用禁用部分模型的方式查看问题到底在哪儿；
24.使用遮挡剔除（Occlusion Culling）处理大场景，一种较原生的类LOD技术，并且能够“分割”作为整体的一个模型
25.场景中如果没有使用灯光和像素灯，就不要使用法线贴图，因为法线效果只有在有光源（Direct Light/Point Light/Angle Light/Pixel Light）的情况下才有效果。

三、渲染

1.不使用或少使用动态光照，使用light mapping和light probes（光照探头）
2.不使用法线贴图（或者只在主角身上使用），静态物体尽量将法线渲染到贴图
3.不适用稠密的粒子，尽量使用UV动画
4.不使用fog，使用渐变的面片（参考shadow gun）
5.不要使用alpha –test（如那些cutout shader），使用alpha-blend代替
6.使用尽量少的material，使用尽量少的pass和render次数，如反射、阴影这些操作
7.如有必要，使用Per-Layer Cull Distances，Camera.layerCullDistances
8.只使用mobile组里面的那些预置shader
9.使用occlusion culling
10.远处的物体绘制在skybox上
11.使用drawcall batching： 对于相邻动态物体：如果使用相同的shader，将texture合并 对于静态物体，batching要求很高，详见Unity Manual>Advanced>Optimizing Graphics Performance>Draw Call Batching 规格上限
12.每个mesh不要超过3个material
13.骨骼数量不要超过30
14.面数在1500以内将得到好的效率

四、物理

1.真实的物理（刚体）很消耗，不要轻易使用，尽量使用自己的代码模仿假的物理
2.对于投射物不要使用真实物理的碰撞和刚体，用自己的代码处理
3.不要使用mesh collider
4.在edit->project setting->time中调大FixedTimestep（真实物理的帧率）来减少cpu损耗

五、逻辑

1.尽量不要动态的instantiate和destroy object，使用object pool
2.尽量不要再update函数中做复杂计算，如有需要，可以隔N帧计算一次
3.不要动态的产生字符串，如Debug.Log(“boo” + “hoo”)，尽量预先创建好这些字符串资源
4.cache一些东西，在update里面尽量避免search，如GameObject.FindWithTag("")、GetComponent这样的调用，可以在start中预先存起来
5.尽量减少函数调用栈，用x = (x > 0 ? x : -x);代替x = Mathf.Abs(x)
6.String的相加操作，会频繁申请内存并释放，导致gc频繁，使用System.Text.StringBuilder代替
7.数据类与控制类应区分明显，数据类中只有数据和存取等操作，不应出现逻辑
8.每个函数应负责一个子功能，整个文件负责一个模块。
9.每个函数行数越少越好，不能超过50行。超出则表示你函数冗余
10.运算逻辑与执行逻辑不能在同一个函数。
11.函数尽量使用形参和return形式返回结果，而不是直接在该函数内部直接使用。
12.update等函数应避免大量运算。
13.运算量大的地方应分帧处理或简化运算。
14.尝试使用空间换时间的方法解决问题。
15.严禁log对象，上线项目必须去掉。
16.变量名应遵循驼峰命名法。
17.变量及函数名语义要明确。相同功能名字要统一。
18.为自己建立工具类及常量类。
19.减少类与类之间的耦合。
20.每个功能函数要增加注释，每个重要算法及模块要增加注释。
21.注释要写清楚该功能是要做什么，而不是单单把函数名字中文化了一遍。
22.变量与函数名 严禁使用1234数字进行增量表达。
23.每个功能模块制作前，应再三考虑是否有其他可能出现，以确保模块的利用率
24.功能模块实现完成后，应自测3遍再交给QA。
25.改动逻辑时应仔细观察该改动会引起的其他耦合模块是否正常工作。
26.遇到问题及报错应首先自行查询问题及对照刚才自己修改的内容，判定问题所在，再查找解决办法。
27.平台相关逻辑应避免散落到各个模块，应创建对接类处理。
28.做好各个平台的逻辑if判定，使各个平台运行项目可以正常运行。
29.禁止在战斗过程中使用LocalStorage进行硬盘的读写操作（重要）

六、资源

1.游戏场景应分为非战斗场景，loading场景，战斗场景
2.各个场景之间的资源尽量不耦合，以做到切换时释放内存
3.每个场景内，严谨所有UI都摆放到场景内。
4.每个界面应单独制作prefab，通过热加载进行展示
5.弹窗形式UI，应在加载期间应做到全屏loading遮盖，加载完成展示后去掉遮盖
6.各个按钮应做好短时间内多次点击导致的重复触发的问题。（重要）
7.界面背景UI应尽量使用九宫，包括中景层
8.界面文字应与按钮区分开，文字使用BMFont。
9.列表形式界面，列表的cell应注意DC的优化。（重要）
10.避免界面之间的耦合，应使用回调形式，或事件派发机制处理。
11.UI动画应尽量避免帧动画，如果程序可实现的程序自行实现。