一个unity游戏开发团队，需要掌握哪些知识？

David902 · 发表于 2021-1-8 18:03

我是来围观的逊 · 发表于 2021-1-8 18:06

陈嘉栋：Unity项目开发过程中常见的问题，你遇到过吗？Unity引擎是一个很灵活的引擎，根据团队开发游戏类型的不同，对人员的要求也有差异，所以不能一概而论。但是，一些在Unity项目开发过程中常常会遇到的问题还是可以总结一下的。
下面我就来聊聊实际工作中，一个项目组可能会遇到的问题吧。
0x01.项目前期规划时的问题

这里指的不是策划的需求或者游戏玩法的计划，而是作为一个Unity项目我们需要在一开始明确并制定好的规范和标准。作为一个Unity项目或软件项目，这部分是很重要的，因为项目早期的规划随着项目的开发时间越久，就越难以修改。

对支持的最低机型不明确
作为一个Unity项目，我们首先要明确我们所需要支持的最低设备标准。并且项目组要有这样的设备，以供开发和QA团队使用。
否则，对项目的优化将无从谈起。

资源标准不明确
开发过Unity项目的同学可能都有过类似的经历，即开发过程中的资源标准不明确。这常常也是早期在项目规划时没有重视资源标准导致的。
所以在项目的早期阶段，最好能够明确资源标准比如模型的vertex数量、纹理资源的尺寸格式等等。
也要对每帧开销中，脚本和渲染所花费的时间有一个目标和预期。

没有合理的Asset流水线
这里指的是资源应该按照一定的流程和标准从美术那里导入到Unity项目中。
很多项目最终出现性能问题，都是由于没有一个合理的Asset流水线。从而导致项目内的资源标准无法管理，很多冗余或不符合目标设备水平的资源构建进了最终的安装包里。
所以，作为项目组，大家一定要指定一套自动化的Asset流水线。为Asset的规格和标准制定明确的规范，在自动化脚本中进行设置。
例如texture是否开启read/write?texture的压缩格式？尺寸？非人形的model在导入时是否关闭了rigs？动画模型是否开启了Optimize Game Object选项？等等。

没有合理的构建和QA流程
也有很多项目的构建并非一番风顺，构建的版本也难以管理。策划或者QA常常是找负责某个功能的开发兵荒马乱的打一个包出来。
所以项目组可以思考一下下面的几个问题：
是否有专门的打包机？
一个新的功能是如何发布到最终的发布版本的？
是否有自动化的可持续集成设施（CI）？
QA要如何反馈Bug，Bug如何有效的管理？

正式项目直接在Demo原型上进行开发
这个也是一个常见的情况，有些项目组早期会有少数几个人开发一些玩法演示Demo，Demo被认可之后开始开发正式的项目。
此时会有一个问题，即在Demo的基础上直接开发正式项目。由于很多Demo只是为了演示玩法，所以代码中有很多为了尽快实现需求的特定Hack。
如果正式项目以此为基础，到后期维护会比较麻烦。

除了上面所提到的问题之外，还有一些别的需要重视的内容，例如制定统一的编码规范、确定采用的光照模式（RealTime？Mixed？Baked？）等等。

0x02.项目开发过程中的问题

经过了项目早期的规划阶段，来到项目的开发阶段时项目组有可能会犯哪些错误呢？一些不好的实践有可能会拖慢项目的开发进度以及让项目组成员的焦躁感上升。

不重视版本管理
很多团队对版本管理不重视，或者团队内部对版本管理例如git的操作不熟练。
当然，关于git的最佳实践的资料有很多，建议项目组在内部进行培训和普及，让大家（程序美术策划etc）对版本管理的操作符合规范。
针对Unity项目，serialization 的格式建议设置为text serialization。
设置commit hook：

3pjgames/unity-git-hooks

静态数据存储在Json或XML文件保存
不少团队喜欢或习惯于使用Json文件或XML文件来保存一些静态数据，在游戏运行的时候加载使用。但是使用Json或XML文件保存数据会有以下的问题：

所以数据最好使用二进制来保存，在Unity内部也提供了ScriptableObject来帮助保存数据。

项目中包含了没有用到的资源、插件或冗余的库
这也是很多团队中常见的一个问题。一些废弃的资源没有及时处理，仍然留在项目中甚至被构建进入了最后的发布版本，从而造成不必要的开销。
另一个问题是冗余或多份同样功能的库，比如项目中使用的插件中有多款插件都使用到了Json解析库，那么就会造成冗余。

只在Editor中测试性能
这是一个很不好的开发习惯。因为在Editor中测试的是Editor的性能开销，而不是在真正的目标平台上的性能开销。所以在做Profile的时候，一定要在目标平台的设备上进行。否则只能得到让人误会的数据，例如在Editor中，GetComponent这个API会产生堆内存的分配，但是在真机上并不会产生堆内存的开销。
详情可以查看：
陈嘉栋：再议Unity优化

当然，更可怕的是真正的性能瓶颈被隐藏了，这样只会让Profile变成一件浪费时间而又没有收益的事情。

开发者不了解Profiler工具
在开发Unity项目的过程中，常用的Profiler工具主要包括以下几种：
Unity提供的：

https://unity3d.com/cn/learn/tutorials/topics/performance-optimization

Unity-Technologies / MemoryProfiler - Bitbucket移动平台相关的：

在项目后期才进行性能分析和优化
在开发的过程中就应该关注项目的性能问题，在日常的工作中就应该重视性能分析，而不是等到了项目后期甚至是deadline前才进行。
一方面是能做到对项目的性能问题心中有数，不会在后期手忙脚乱。
另一方面能够及时发现问题，修正工作流程，不至于“开发债务”越积累越多。

0x03.写代码时的问题

开发者不了解Unity脚本的生命周期
有一些开发者由于不了解Unity脚本的生命周期，而出现一些程序上的错误和问题。
例如引擎什么时候会调用Awake、OnEnable、Update等等API？协程在什么时候会被更新？FixedUpdate又是怎么执行的？
可以参考Unity的文档：
Execution Order of Event FunctionsFixedUpdate的执行可以查看：
陈嘉栋：FixedUpdate真的是固定的时间间隔执行吗？聊聊游戏定时器

过于重度的使用MonoBehavior以及Update
有些开发者喜欢在制作Demo甚至时正式开发项目的时候大量的依赖MonoBehavior以及Update方法。在Unity中MonoBehavior脚本的Update方法会被引擎记录在一个List中，在运行时引擎会遍历这个List，并调用其中的Update方法以实现脚本逻辑的更新。但是，原生代码到托管代码的调用总是会有性能上的开销的，因此场景中的MonoBehavior以及Update过多会影响游戏的性能。
相关文档可以参考：
10000 Update() calls – Unity Blog

没有对需要频繁访问的数据进行缓存
这也是一个初学Unity的开发者有可能会犯的错误。要对需要频繁访问的数据进行缓存，以避免不必要的性能开销。
例如访问Camera.main，其背后的实现是FindObjectWithTag，因此如果没有对这个值进行缓存，那么每次都会调用
FindObjectWithTag，这是一个开销很大的操作。
另一个常见的情况就是GetComponent，对它的返回值也要进行缓存，以避免不必要的开销。

频繁实例化时不使用缓存池
这一点其实并不是什么新的观点，或者是什么高阶的知识。但是仍然有很多开发者可能忙于业务功能的实现，而没有对此给予相应的重视，造成了性能上的瓶颈。
实例化操作是一个比较耗时的操作，所以切记当需要频繁实例化时，创建一个池，并对其中的对象进行复用。

不了解会造成堆内存分配的API
C#的GC操作是造成游戏卡顿的一个常见原因。因此，对脚本堆内存分配的优化是很重要的。这里可以使用Unity的Profiler来检测堆内存分配，除了重视堆内存分配很多的帧之外，对数量不起眼但是每帧都会有堆内存分配的方法也要重视。
Unity开发中，常见的会带来堆内存分配的API主要有LINQ、String相关的操作以及返回Array的Unity的API。
例如Physics.RaycastAll，这个API每次调用都会返回一个Array的拷贝，因此更好的选择是使用RaycastNonAlloc来代替。
还例如很多开发者喜欢在检测用户输入时使用Input.touches，对这种property的访问也会带来一次Array的拷贝，所以更好的选择是Input.GetTouch。

0x04.图形以及UI开发中遇到的问题

项目的Overdraw太多了
这一点主要是开发移动平台项目的团队需要注意的问题，Overdraw是导致图形性能瓶颈的最常见的原因之一。所以要避免渲染不必要的半透明物体，也可以使用更复杂的mesh来勾出半透明的区域。

制作UI时遇到的种种问题
UI系统也是导致很多项目出现性能问题的原因，下面Unity官方公众号总结出的《Unity UI性能优化技巧》是十分有参考价值的。
Unity UI性能优化技巧

0x05.提醒

不基于数据来优化
今年Unite Berlin上，Ian做的一个Presentation的图片可以很好的说明这一点。
除了数据，不要相信任何人，更不要迷信自己的经验。通过之前提到过的各种性能测试工具来获取目标平台上的真正数据，根据数据分析真正的性能瓶颈。并进行调整、对比来确认问题真正的得到了修改。

-EOF-
最后打个广告，欢迎支持我的书

《Unity 3D脚本编程：使用C#语言开发跨平台游戏》(陈嘉栋)【摘要书评试读】- 京东图书

今早我梦醒了坎 · 发表于 2021-1-8 18:07

最最最最最需要的经验。
一款游戏的筹备并没有你们想象头脑风暴当中的那么简单，游戏的制造需要时间去磨出来的，从中有很多细节是先前难以想象，最重要的有一位有经验的指导。
对于你上述的问题，我希望你所提到的知识，都能够掌握，取决于你对设计这款游戏的理解深度，制造难道，在自己能力上的扬长避短，你一样能创造好玩的游戏！

什么大师特 · 发表于 2021-1-8 18:08

谢邀～

我也只是unity3d的初学者，但是我很明显地感觉到一点，就是unity这个玩意真的很简单，如果你是要完全倾向应用而非学术，Asset Store里有无数品质颇高的素材可以供你使用，度娘里CSDN里也有很多你想要实现功能的相应代码块。

可以说只需要一点编程基础你就可以拼凑出一个想要的游戏。U3D里自带的shader自带的资源包对于独立开发者来说已经是相当丰富又具有水准了。（U3D蒸汽时代教程包的特效可以说是极其惊艳）

在这种情况下，你要组建一个拥有图形学，程序逻辑，数据库设计。。。技能库的开发团队，所付出的代价和得到的回报完全不成比例。

但是如果你想要从头到尾自行开发，那么上述的技能里，网络通信的知识肯定是必要的，程序逻辑肯定是必要的，因为这两个组成了你的游戏的主体。数据库在网络游戏里也很重要，但是如果是局域网游戏，数据库就只是个添头了。

在开发一段时间后，你会发现游戏美术才是真正卡住你的东西。我们说体素游戏像素游戏很粗糙很复古，可是开发的时间却一点也不短（街霸早期为了制作出流畅的像素打击动画可以说是煞费苦心），TitanSouls等游戏虽然是像素画风可是在特效、构图和光照上下了大功夫，现在你在steam上看到的像素风游戏基本上没有几个是粗制滥造的吧？拟真的画风其实在开发周期和难度上很不适合独立团队的说。

随后就是文案，这个事情我就没什么好说的了，没个想法你还开发个球的游戏_(:з」∠)_对吧？

如上，有错请指出，毕竟我也是个菜鸡。但是如果题主想要组建一个真正的Team，技能库还是有多少要多少，可能一个shader一个Sql对你的游戏改观微乎其微，但是正是这些细节使一个独立游戏伟大。

宇宙无限 · 发表于 2021-1-8 18:18

虽然没有当过主程，但是抛砖还是会的。
写在最前面，要是打算做个商业游戏不用心的话还是省省吧，人大代表刚联名反对游戏呢，请别再给游戏抹黑了。

第一个问题

需要储备的知识根据你想要做的游戏来的。2D/3D？什么类型？什么题材？有没有物理或者模拟物理？强调不强调AI？玩家有多少的自由度？剧情有无？单线/分支/交互式？声音我没弄过，但是不能没有，等等。确定了这些才能知道需要那些储备的。
第二个问题

看题主的提问方式貌似并没有把数据结构&数据库&网络基础&高数这种科班必修课设置为默认掌握技能，所以建议筹划不如开始做，做的过程中会发现好些问题，哪里不会补哪里。框架问题的话……看看开源，不是说epic的moba游戏开源了么？参考一下总是可以的。
图形学的话，不是2018GDC正在开么？看看人家工作室公开的新技术。基础的话弄个rendermonkey玩玩吧。据说现在有H5的更好用，没研究过。。。
最后一个问题

建议了解下游戏发展史，你就会知道做什么东西需要什么样的技术，会产生什么质量的游戏。日本软伦时代的奇技淫巧，23333
可溜~

		自动登录	找回密码
密码			立即注册