一、MMO游戏优化经验同享沙龙拓展资料

昨天去上海参与了UWA企业的张鑫和张强进行了一场关于MMO游戏开发和性能优化的沙龙，活动主题链接为： UWA优化日上海站|传统MMO手机游戏性能该怎样突围？。虽然第二场场景分块加载部分的内容没有预期中对目前的项目那么有帮助，再加上最后由于赶火车没有听完Q&A的环节就离开了（然而还是没有赶上火车，此中悲苦就不提了。。。），有些疑问没有提出来讨论，略有遗憾，但对于我这样壹个刚刚接触Unity的新兵来说，收获颇丰。因此这里做壹个简单的记录和整理，只包含现场讨论我印象相对深的一些点，和讲座内容的顺序没有直接对应关系，更加详细、条目性的内容可以参考官方放出的正式文档。

张鑫博士说明了UWA成立这一年多时刻内做过的事务，我还是相对赞赏有组织在做这件事务的，可以说是Unity引擎和用户之间除了官网文档和官网技术支持之外的一座桥梁。虽然说他们目前的存在价格和盈利方法依赖于Unity引擎和这样壹个生态圈，然而对于程序员来说，它们比单纯的引擎部门接近游戏产品，和做产品的比又更纯粹，没那么功利，介于两者之间。如果有合适的机会我还是挺想做一做这样的事务的，哈哈~

目前来说，能有这样的一群人帮忙提供一些技术上的同享，一些坑可以拿出专门的时刻和精力去踩和解析，对于没有引擎组的小团队来说是特别好的事务。

张鑫博士提到他们提供热更新方法，会后单独问了一下还是只支持Android的版本，Lua方法的热更新还没有人力去做。希望后面可以有人力来做一些这方面的踩坑和性能优化职业……

在UI体系的优化中，着重提到了Mesh重建的经过，这通常一个消耗最大的部分，因此也是优化需要关注的重点。在NGUI中，这一经过发生在Panel的LateUpdate函数中——由于NGUI是插件的形式，因此这一经过是在C#中的，每次需要改变渲染网格时都会销毁内存中的mesh进行重建操作。而对于UGUI来说，这一经过是在Cavas的BuildBatch中进行的，已经被封装成了Native的实现，因此在UGUI中这部分没有额外的堆内存分配，这也是UWA官网把UGUI在运行时分配的堆内存大致标准定义为小于2M，而NGUI的提议标准是小于20M的核心缘故。

怎样降低UI体系中Mesh重建的次数呢？主要从下面内容两点出发：

上述两点分别对应两个优化思路：

针对第一点，除了不要进行不必要的ui修改操作之外，对于需要频繁切换的复杂界面，张鑫博士给出的提议是：

壹个运用案例是背包界面，有大量的item，创建经过消耗也会很大，如果内存允许的话，运用上述方式会有最小的性能开销。

而尽量减少Mesh重建影响的范围则对应壹个基本守则——动静分离，即把不需要动态改变和需要频繁地动态改变的组件分离出来。按照上述的第二点，可以运用canvas进行动静分离。就是说比如某个组件下面挂的物品一个会动态变化的部分，那就把它独立成壹个canvas。比如仍然以背包界面为例，滑动内容会导致界面的变化，在滑动经过中每帧都会有Mesh的重建操作。把滚动的部分做成单独的Canvas，这样背景图片和深入了解等部分就不会被每帧重建了。

这里需要着重注意的是一些会频繁改变的动态部分，相对容易遗忘，比如聊天中的动态表情，人物坐标信息的显示等部分，在开发经过中需要着重注意。

之前有讨论过动静分离的概念，然而进行分离的基本制度和原理并不是很清楚，张鑫博士的沙龙从性能解析的具体数据出发，结合具体函数的影响，讲解得清晰透彻。

另外有几点关于ui优化的笔记：

UWA做了壹个血条性能解析的Demo，也是和UI有关。

通常MMO游戏中血条会相对多，比如一些PVP或者PVE方法中，血条会有几十个甚至上百个，他们会随着怪物的死亡等消失，又会随着新的怪物产生而从头出现。这里需要注意的点有如下多少:

多线程渲染是我在网易的时候跟过的壹个大坑。。。当然不是我做的开发，而是大家项目相对早在运用引擎组做的这一功能，从集成经过到做兼容性测试遇到过很多难题，比如某些设备上莫名其妙的Crash。

张鑫博士说他们从他们的经验来看，Unity 5.3版本之后多线程渲染的功能已经一个相对稳定的版本了，现在已经有正在运营的项目在开始多线程渲染。因此整体上还是可以相对放心地开始的。多线程渲染对于PostEffect的提高效果很大，他们做了壹个测试可以让CPU消耗从平均20ms降低到平均2ms，也有项目开始之后出现顿卡。

和之前了解的一样，开始多线程渲染之后的性能提高效果根本上和是CPU瓶颈还是GPU瓶颈有关，不同设备效果不同，不同游戏的瓶颈也不同，因此要各个项目自己测试来看，因此UWA官方的说法是——

这部分提到如果在观察Profile面板时发现WaitingForJob很高，就说明CPU在等子线程，就已经有性能难题了，当出现PutGeometryJobFence的时候，性能难题就已经很严重了。

MMO开发中人物阴影已经成为了壹个标配，UWA经过测试，Unity官方的Build-in ShadowMap的性能还是最好的，主推运用，只是效果相对差，而且在Mobile设备上无法支持原生的软影（存疑，需要自己测试一下效果）。

而Projector的实现方法相对适合只有壹个人物需要阴影的情况，主推了两款插件：

阴影这块是大家项目目前要研究的重点内容其中一个，大家在思考全部动态阴影的方法来部分替代烘焙的LightMap。这部分市面上的产品只观察到韩国的两款Unreal的手机游戏这么来做，之前在网易内部运用Forward Lighting一直都是烘焙的方法。这块如果有兄弟了解啥子信息还希望不吝赐教~

这是相对有意思的一块内容，之前的思路一直都是大部分情况下统一运用异步加载，只有在明确了解资源特别小，而且不重要的模块运用同步加载的方法，比如壹个只有多少面的dummy model之类的。

UWA给出的提议是：在Loading界面中，如果不需要表现平滑的加载进度和加载界面的话，可以运用同步加载，其他的经过中运用异步加载。缘故是——

如果觉得加载时刻过长，而对于加载经过中的玩家尝试不需要过多关注的项目可以参考这一思路。这的确是我之前的经验所没有包含的部分。

在Unity中，对于异步加载来说，也也许会造成顿卡，由于不是全部的经过都是异步的。IO部分可以做到完全异步，然而内存中的初始化的部分经过也许仍然是同步的，比如一张1024 1024大致的贴图异步加载，通常设备上都会可以感受到卡顿，因此提议大于这个尺寸的贴图统一进行预加载*。

和此相关的还有壹个Unity的小姿势。Unity默认每帧给2ms的时刻让CPU拷贝内存物品到GPU中，比如贴图、网格顶点等，默认的Buffer是4M大致，因此这里也会影响资源加载到最终渲染到屏幕上的时刻。这两个参数是可以调整的，具体接口参考官方文档。另外默认4M正好是一张32位的1024 1024大致的贴图大致，如果运用了2048 2048或者更大的贴图格式，这个Buffer会增大为对应的大致，而且不会在缩小过来。因此提议资源中的最大尺寸可以给壹个定义，尽量不要出现只有偶尔几张贴图运用特别大的尺寸的情况。

除了常规的降低骨骼数量和动画曲线数量之外，Unity 5.2之后提供了壹个culling Group的功能，用在模型位置一直绑定壹个球的方法做碰撞体来优化判定，不在视锥范围的的物体不进行Animator的Update。这一功能主要针对脚本逻辑的Update，Animator没有提供单独的接口根据距离来控制Update频路，壹个可行的思路是自己重写其Update接口，接着传入更高的Delta Time来模拟降频的功能。不过以我之前用Havok的降频功能来做性能对比的话，除非人物数量特别高，否则这部分骨骼骨骼的更新的优化空间不是特别大，不过Unity这块具体的数据要进行测试才了解。

Animator中有壹个Optimize Game Objets的选项，可以降低Update的消耗，UWA提议运用。这是由于默认情况下每根骨骼都一个GameObject，每帧骨骼更新之后会需要修改它们的Transform。

对于Animator的Active和Deactive的操作有很大的性能消耗，这在之前斗鱼上的直播中已经提到过了，这里还是像ui一样，提议将人物移出视窗之外的方法来进行缓存，或者只把组件Active和Deactive，来提高性能。

除了上述的一些难题之外，还有一些相对了零碎的笔记，不进行赘述，只记录如下：

这一部分是张强同学做的讲座，基于地形的方法实现了的大全球动态加载功能。其实这部分本来是我期望去听和讨论的部分，以为大家项目正好在进行这块的技术预研，然而大家不是运用地形，而是基于静态Mesh，另外视角大家更倾给于平视而非2.5D，因此这部分对于大家的帮助没有想象中的大。

我个人觉得这部分的壹个难题是整个工程是基于壹个Demo性质的实现，而非正式的项目，由于时刻关系没有在后面进行深入的探讨，因此也不清楚目前的实现是否在正式的项目中应用了。一些应用方面的疑问其实讲座正文中没有讲到：

这部分可以直接参考官方给出的PPT，我做的笔记不太多，这里只放了一些没有来及提出的难题，幸好加了两位主持人的微信，回头整理好难题再一并请教，有答复了再修改这篇文章小编将。

这次上海之行，一天时刻往返上海杭州，只为了这两场讲座。从收获来说，虽然和预期稍有不同，然而还是很值得的。感谢张鑫博士和张强同学两位主持人的同享，你们辛苦啦也感谢UWA企业组织这样不收费的技术沙龙，祝愿贵企业越来越好~

2024年11月26日于杭州家中

三、网络游戏文案策略这个职业如何样

我是一名从业四年的游戏文案，故事了两三个漫长的游戏开发期。而在此之前，我的专业和游戏扯不上关系。

1、游戏文案是做啥子的？

我听过很多说法，文案就是编剧，写剧情的。又文案就是做全球观架构的。还有人说，文案是做道具包装的。

其实没那么复杂，我这里有个很简单的说法。你在游戏里看到的全部文字描述，都是咱们游戏文案来负责的。

像啥子加载画面的文字说明，应用商店里的描述和开发者有话说，剧情，台词……都需要文案来抠头想词儿。

2、入行有啥子标准？

最重要的事说三遍。

不看学历，不看学历，不看学历！

当然这个“不看”说得有点完全，校招的一些大厂从笔试阶段就拉高了门槛。只是从大范围来看，游戏企业比起你的“高学历”，更看你的“职业/创作经验”。

那么难题来了，创作经验是啥子？

已知：文案是做文字相关的活儿。

问：文案招聘到底看啥？

显而易见，企业需要招揽文字功底相对深厚的人。这是对文科生很友好的一条赛道，它的薪资比起其他行业还是不错的。

游戏文案需要的文字功底不是指写报告、写公众号（除非你写的是故事给）、写广告、乐影评、随笔、散文这方面的能力。

宽泛来说，项目组需要壹个会讲故事的人。

更实在一点，面试官基本会问：哎哎呀，亲爱的小兄弟，你有没有写过小说呀？或者类似的原创故事？

以我自己为例，是有百万字以上的创作经验，同时签约了网站写稿。我认识的一些兄弟，他们私下都会写物品，为爱发电写同人的，和同好创作密室逃脱和跑团剧本的，网站连载小说的……大家喜爱创作，也有一定经验，才会思考来干这一行。

而我的一些同学，学传媒编导的，虽然也写媒体锐评，但依旧不算是同一条赛道。

至少在面试的时候，面试官很高兴看到你能带着作品集。平时HR约人，也是希望入职者能先将作品发过来做壹个考量。因此作品是一道越不过去的坎儿，尽量整理好你到现在为止的输出，以防不时之需。

友谊小贴士：作品集还是可以有一些诗歌、随笔，这些是你本人的特色，然而最主要还一个有起承转合的故事，一些具体的人物设定。

3、入职之后你会做啥子？

往大了说，你要开始搭建全球观。

往小了说，你要死磕一句台词，反复修改，好让老板满意~

这个经过里，还有无数主线、支线的剧情撰写、包装游戏道具、方法、UI界面等等的活儿。以及，游戏文案还有一项相对重要的职业，就是提美术需求。你写出来的物品，要能描述出来让美术明白，他明白了才能画出你想要的物品。这个就是需求。

有时你还要去配合一些配音剧情的职业，这张就是我在录音棚和cv老师们接触时拍的现场。

文案或多或少还要和程序打交道，虽然不太复杂，然而小编认为是一个文科生，还是死了很多脑细胞。你写出来的剧情，要如何才能在手机里呈现呢？大家需要把一段段的文字配置进表格，接着再放进模拟器……听起来很复杂对吧？没关系，慢慢熟练就好了。

我认为不管任何行业，抱着壹个“这种职业谁都能干啊”的心态去求职肯定不会得到满意的结局。但如果把它想象得过于复杂也不可。放稳心态，确认自己的喜好，接着尽情去做就是了~

4、说说我的看法。

我觉得我还是挺幸运的，由于在大多数人干着不喜爱的职业时，我的职业还算和兴趣沾边，因此还能沉浸苦心钻研。

如果你喜爱写物品，那上班起码一大半的时刻，都是能够高兴的。

像这样出差连着一周还要半夜三四点坐飞机……都是高兴的。

有一种我，坐在体制内，枯燥地忍受着无休止的报告，和复杂的人际关系打交道。这样回家后抱头大哭的，是我。

也有一种我，面对word，沉浸构思壹个故事，加班到九十点也觉得值得。这样不知疲倦的，也是我。

你问游戏文案是啥子，其实就一个普通人结合兴趣和爱慕，在不断试错之后找到的一件还算喜爱的职业，仅此而已啦。