【转】AGE引擎沉思录 by 腾讯创新

原文链接：http://djt.qq.com/bbs/thread-28760-1-1.html

项目背景：AGE引擎是腾讯公司第一款自主研发3D游戏引擎，06年引擎研发工作开始，08年底基本完成引擎开发工作，09年AGE引擎开发的一个项目斗战神项目正式立项，10年斗战神项目正式发布，12年斗战神开始内测，整个开发时间持续了六年，这六年里，我们也积累了很多的成功经验当然也有失败教训,下面就分享一下在AGE引擎里的一些感悟。

1. 技术方案的选择

　　在解决游戏开发中的问题时，通常会面临一个技术方案选择的问题，怎样选择最合适当前项目组的技术方案呢？

　　以AGE引擎最早的渲染技术方案选型为例，在06年开始引擎渲染模块开发的时候，项目组就面临一个选择，是选择以可编程管线为基础的技术方案，还是选择以固定管线为基础的技术方案，虽然说当时可编程管线已经成为了一个大的趋势，但是国内很多出来的游戏还都是以固定管线为主，因为当时国内的机器配置也参差不齐，很多二三线城市的网吧还在使用配置比较低的电脑。但是考虑到以下因素，我们还是决定选用了以可编程管线为基础的渲染方案：

1) 引擎开发周期可能会比较长，可以选用一个稍微有前瞻性的技术方案.

2) 基于可编程渲染管线具有更大的灵活型，对于艺术家来说可以制作出更加出色的画面效果，对于图形程序员来说可以设计出更加结构简洁清晰的渲染器。

3) 基于可编程渲染管线的技术方案做技术升级方面也更加的容易。

　　最后在后面几年的项目开发中也证明，我们这个方案的选择是非常明智的，我们考虑的因素也都得到了验证，现在可编程管线也成了绝大部分3D游戏引擎的选择。

　　另外一个例子是光照方案的选择，在Doom3和half life2时代，已经有了两个主要的技术流派，实时光照，静态光照（Light map），最早在研发的开始，我们采用了实时光照技术，这样的好处就是不需要额外的去烘焙静态光照，可以所见即所得的调试光照效果，艺术家也不会为了烘焙Light map而大费周折，另外也可以实现天气昼夜变化的这样的全动态的效果。但是缺点就是我们在当时的条件下只能实现实时的局部光照效果，因此整体的光照效果不如静态全局光照效果生动。

　　到了斗战神项目的开发阶段，项目有大量的人力资源的投入，对光照效果的品质的追求也要求更高，局部光照模型在光照表现方面的生硬就成了一个比较大的问题，另外项目也对昼夜天气变化没有需求。在这种情况下，渲染小组只能回过头去选择Light map的方案，这其中也是费了不少周折。

　　总结，选择开发技术方案从项目实际需求（项目的目标、项目组的开发能力水平等等）出发，可以有适当的前瞻性，不要被技术华丽的外表所迷惑，虽然这个结论很简单，但是在游戏开发中，经常看到即使是有经验的开发团队也会在技术方案选型上面做出不明智的选择。

2. 处理运行效率和画面效果的矛盾

　　我们经常会看到游戏画面和运行效率的两种极端的情况，一种是画面做得很华丽，但在中底端机器上面跑得像幻灯片一样，另外一种是画面非常粗糙（达不到当前品质游戏的要求），但是还是能流畅运行。

　　这个矛盾早期一直是困扰着项目组，程序希望运行效率能够更高一点，对美术规格要求过于苛刻，而美术希望能够有更多的发挥空间，美术规格能够放宽松一点，双方甚至有过非常激励的争执。解决这个矛盾的时候，我们并没有采取程序或者美术单方面主导，而是大家都做了改进，程序这边则进一步提升引擎的运行效果，最早的情况，我们的引擎对渲染批次（DP）是会比较敏感的，大概每帧到了400,500个批次，效率会有明显的下降，但是经过对照一些市面的游戏的DP数，我们发现引擎在DP上面的优化还做得不够，所以我们在这里还是要做一些优化，后来我们做了一次彻底的分析，发现引擎中间DP调用存在又大量的冗余，额外的效率开销很大，我们在材质系统使用了D3D辅助库的Effect系统，这个系统虽然能帮助材质系统的设计，但是不必要的开销确实很大，经过优化之后，这块的效率有了200％的提升，另外美术也改进制作技术，大幅度消减了场景的渲染批次，这样就节省出来很多的运算资源，而我们可以把这些的运算资源用于到其他一些效果的制作上面。对于解决这个矛盾我们最大的收获就是，美术和程序一定要坐到一起解决这个问题，单方面的程序主导和美术主导很容易打击到另一方面的积极性，而且对于我们国内现阶段的情况来说，美术制作方面的经验相对来说积累起来时间要比较久（国外那些先进工作室美术都几乎成精了），而相对来说，程序在这方面可以多付出一点，程序优化有更多的资料可以去参考。

3. 重视调试和分析工具：

　　常见的情况：在游戏开发进入后期阶段、大量的游戏内容制作，这时大量的问题涌现出来，程序中出现奇怪的内存泄漏、新完成的关卡慢的令人无法忍受、以前运行正常的渲染模块也突然碰到各种黑屏、每日构建的版本效率越来越低，占用的内存越来越大、版本也越来越大、游戏内容中出现各种奇怪的bug、游戏程序出现莫名其妙的崩溃，更令人头疼的是有些bug很崩溃很难重现，可怜的开发人员每日加班到很晚，但是解决的问题的速度依然赶不上新出现的问题的速度。

　　这一幕难道不令开发者熟悉嘛，在游戏开发的人员，都或多活多少碰到类似的场面，现在的问题是怎么解决这个糟糕的局面呢？

　　解决问题的方法稍微有经验的开发人员都能回答上来，在项目的前期就准备好调试和分析工具，做好内存分析工具，就很容易检查出内存泄漏，并且很容易就定为出找出消耗的内存的罪魁，做好日志系统，就很容易调试一些奇怪的bug，做好性能分析工具，每日构建生成性能分析报告就能很好的定位出效率问题，做好dump分析系统，解决一些崩溃问题就能事半功倍。

　　但是在项目实际执行情况时，有时候很难的按照这个设想来执行，制作人、项目经理出于对进度的压力，很少会给开发人员留给这么充足的时间来开发这些调试分析工具，或者项目组在早期根本就没有这么充足的人力来开发这些工具，为了项目早期的发展，必须在游戏内容进度上面开足马力。

　　在AGE项目开发中有这样一个例子，我们在项目进入中后期阶段之前，曾经想开发一个分析引擎渲染帧的工具，这个开发工具类似与PIX、GPA、或者是NV的Perfhub，所不同的是它是引擎自带的工具，当游戏画面出现问题的时候，可以使用这个功能把当前渲染的帧捕获下来，然后又另外一个预览工具分析这一帧的问题，可以预见的是，当游戏进入大规模测试阶段，必然会碰到奇奇怪怪的渲染问题，我们不能让用户去安装PIX、GPA或者Perfhub，另外就是有时候出现画面问题不容易重现，无法在出现问题之后再把程序拖到GPA里面去分析，再有有些时候我们如果能把出问题的这一帧抓下来，我们也可以通过Direct3D参考模式来确定，渲染的问题是引擎本身的问题，还是底层显示驱动的问题。

　　这样分析下来这个工具对项目后续的画面兼容性问题会有很大的帮助，令人遗憾的是，因为人力不足和项目需求方面的压力，这个工具的开发被搁置了。前一个月，项目开始进入小范围放号测试阶段，为了解决一些画面的错误，我们有同事全力的投入在其中，并且还协调显卡厂商的外部资源，渲染分析工具开发的时间和解决画面问题花去的成本，谁轻谁重，一目了然。

最后的建议是，在进入项目大规模生产阶段，一定是带着准备充分的工具，一幅成竹在胸的姿态了。

4. 做好持续集成

　　常见的情况：在项目进入到开发后期，早上，美术师打开从版本管理工具更新下来的编辑器，发现一个编辑功能不正常了，他今天还有很多的内容需要完成，他只能去找到开发功能的程序来修复这个问题，这期间他只能干点别的。前台程序更新了代码，又发现后台服务器的修改，导致客户端的一个功能出现异常，诸如此类的事情，还会有很多。

　　问题的关键在于，如何保持一个大型团队高效、协调的工作，每个人尽可能少的被其他人的bug所干扰到。

　　续集成是一个不错的办法，大型的游戏开发团队都会做持续集成，持续集成都解决上面说到的一些问题，持续集成可以是每日构建，甚至是每一次提交代码和提交资源都做一次构建，当每日的版本出现问题之后，通过提交记录可以很快的定位出“罪魁祸首”，制造这次缺陷的同事，必须放下手头一切的工作，修正这个缺陷，确保其他同事能够少的受到缺陷的影响。

做到这一步之后，能避免一些效率的问题，但这还是远远不够的，实际的情况要复杂更多，更多的时候每日构建的版本中存在的问题还是没有被发现，举上面的例子来说，每日构建出来的编辑器仅仅是经过了开发人员和美术使用人员的简单测试，很有可能有一些潜在的缺陷还没有被发现，知道问题被发现的时候，可能是很多天的事情，再去回溯版本检查问题，可能就比较困难了。

　　开发测试在这个时候就变得非常重要，开发测试通过对每日版本进行大量的测试，尽最大的可能去发掘出问题，保障了每日构建版本是一个高质量的状态，是团队可以信任的版本。另外，自动化测试案例也是非常重要，虽然它经常会被开发人员给忽视，但如果开发人员在被有缺陷的版本折磨一段时间之后，肯定会改变这样的看法，在积累了大量的自动化测试案例之后，这些案例会在持续构建中执行，这样版本的质量会进一步提高了。

5. 一些小的惊喜开发

　　游戏开发并没有大家想的那么的有趣，甚至是非常枯燥和郁闷的，特别在开发团队在进度上面遇到了大的困难。这时候如果有一些小惊喜的开发，就能很好的改善局面了。

　　早期在AGE项目进展遇到了困难时，一些有经验的同事总是会适时的开发出一些小惊喜的功能和效果，记得有一次是做了一个效果很好的水面，项目组的同事都过来围观，同事们都觉得开心，团队能开发出这样出色的效果，每个人对团队的信心，对项目的信心都是一个积极的提升。