天朝GDC 2009归来（三）：经验，展望

天朝GDC 2009归来（三）：经验，展望

文：六水 2009年7月26日

精益开发：高效率低成本的开发
Danny Isaac，EA，资深制作人

这主题讲的比较深奥，许多术语没听懂。大概听到，按Danny的说法，精益开发最关键的是Optimize the creation and delivery of the value。他对value的理解也是让我最难忘的：value就是能为客户增值的东西，相反，waste就是不能为客户增值的东西。接下来他详细分析了关于waste的方方面面，影响最深刻的是Overproduction：extra feature。
做了多余的设计，是头条浪费,据统计，office系列软件的各项功能模块被用户使用的概率如下：
频繁使用 7%
经常使用 13%
有时使用 16%
很少使用 19%
从来不用 45%
也就是说，只有20%的功能是被经常使用的，45%的功能模块是从来不会被使用的。这一点就很值得我们深思了。

下一个次时代： 2012~2020实时渲染技术的前进方向

他提到，2010~2020的潜在目标是达到电影级别的实时渲染结果，而且在人工智能等方面比现在有标志性的提升。他提到以下几个技术将代表着未来十年内渲染技术的前进方向：

1.  回到“软件”渲染，跳过OpenGL或D3D。这里的软件渲染，是指不使用显卡（GPU）进行渲染，所有渲染都是基于CPU，因此就回到了上个世纪的渲染方式。尽管显卡现在很快，但是它的缺点也越来越明显了。它固有的架构让开发者无法使用最优的算法，这在很大程度上限制了渲染速度。随着cpu多核技术的发展，软件渲染将逐渐变得可以胜任实时渲染。
2.  Raytracing，使用光线跟踪。光线跟踪比目前的最流行的渲染方式（光栅化）要优秀很多，它的算法本身可以完美地解决许多光栅化无法完美解决的问题，譬如反射。然而算法本身时间复杂度比较高，目前只能在高端机上运行准实时的渲染程序的例子。随着多核技术的发展，光线跟踪将越来越能大展拳脚了。
3.  Reyes。
4.  Volumetric Rendering（体渲染）。目前流行的渲染方式都是基于面的，也就是以面的方式去描述一个模型。而这种体渲染着是用体素来表示一个物体，直接以Voxel来渲染。
5.  Hybrid Graphic。这一点我没搞明白。

他还提到需要开发商注意的以下几点：
1.Productivity is vital
在欧美国家，一款单机游戏的预算大概在1000W$~2000W$，成本其实已经太高，许多游戏开发商都处于亏损状态。
2.Today’s hardware is too hard
以下是使用了某项技术的开发周期（跟一般使用技术相比）
多线程技术 2X
PS3平台 5X
GPGPU 20X
1.  Next Generation
下一代游戏开发周期你，引擎的前导开发周期会长达5年。

完美时空：提升3D引擎效率以适应大型3D MMORPG需求
李毅 完美时空3D引擎总监

1． 设计统计分析函数对自己的渲染进行全方位的观察

从分析的方法来讲，有计数分析和计时分析。
从分析的粒度来讲，有宏观分析和微观分析。
组合起来就有四个分析项目。
宏观来讲，需要观察的就有

（不详，大概是一下这些）
-渲染的批次
-shadowmap渲染的批次
-skinmesh的个数
-树木植被渲染的批次
-地形的三角形个数
-特效渲染的批次
……

微观来讲：
-渲染的三角形的个数
-渲染的顶点的个数
-shader切换的次数
-渲染切换的次数
-填充率
-设置shader常量的个数
…….

而对于计时统计，也是对应地把上面的个数变成时间。

2.  关于场景管理的策略
完美使用九格方块的方法，也就是永远只加载9格，以限制内存显存的占用率，理论上实现无限大场景加载。

3.  关于渲染状态的管理
使用二维表格来管理渲染状态，这张表记录了每种状态之间的互相对应关系，表里每个元素保存着两种渲染状态之间切换所需要做的状态改变。使用这种方法将有利于减少渲染状态切换的个数。

4.  lod方面的经验
mesh方面lod的管理，总共分5级别。
下一级的三角形个数大概为上一级的75%，这样出来的视觉效果会比较好，如果太小，突变就比较严重。不过最后一级经常使用公告板。

案例：动态概念设计
主讲的是辛鑫，资深概念艺术家

他就展示了一下动态概念设计的过程。他提出，原画设计师不应该只懂画2D艺术图了，为了能适应动态概念设计的要求，还需要自己亲手做做3D。由于是动态概念，因此需要借助动画来向别人表达。在3DSMAX里做些示意性的模型，做做示意性的动画，然后在After Effect里合成一下简单的动画，已达到表达自己的设计的目的。

时间太短了，辛鑫其实还没讲完了，就匆匆结束了。讲完了，就有人上去大呼“佩服”，或呼“全才”，要赶快交换名片的说。辛鑫给我的印象是，好像在CGER的期刊上见过。我在业内认识的艺术人士不多，也希望认识一下辛鑫，交换名片后，说以后会和你在email上交流交流。

案例：大型MMORPG游戏开发流程

郑锺必（NDOORS公司，游戏设计总监）讲述了他公司里一个游戏项目死里逃生的过程。
NDOORS早期是开发2d游戏的，随着3D的越来越受玩家欢迎，NDOORS也转向制作3D游戏了，面临的问题是：目前公司里的团队都是做2D的，以后是否能做3D？当时他们正考虑一个方案：裁了老团队，建立新的3D团队。然而，他们最后并没有这么做。他们坚信，每个员工，只要经过培训学习，都是可以胜任3D游戏开发的相关工作的。
很快他们就开始新的3D游戏项目了，因为大家都边学边做，没有相关经验，出来的结果确实是不堪入目的，游戏画面太糟糕，完全没有效果。他们做出结论，这样的游戏是没有玩家能接受的。接下来就是公司气候的一片混乱，还有就是团队之间的互相指责，程序骂美术，美术骂策划，策划骂程序，大家变得越来越不信任自己的同事了，很多成员都放弃了该项目了，还有很多人想干脆离开团队。
大家都在怀疑当初的抉择是个错误，然而郑锺必在做的是分析问题所在。他首先分析出来的第一点就是策划，策划把设计做的太具体了，没有留给美工足够的艺术空间。譬如角色设计，策划把角色的衣服，发型，各种小挂件，等等都详细地列出来了，交给美工去制作。问题就在于，策划通常都不具备比较好的审美观念，因此美工根据他们的设计稿而制作出来的效果就很难看。除了考虑到角色的性格职业以外，美工还需要考虑到美感而做出具体的设计，如果这些设计都被策划过分地限制死了， 那后果就可想而知了。因此在后来的修改方案里，他就提出了，策划只负责设计角色的性格，职业，精神面貌等，不适宜做过于具体的设计。
另外，他还分析出来，美工本身的设计和制作也是存在问题的。这些美工后来都被拉去培训了。事实证明了他当初的信念，培训后的美工确实做出了比以前好很多的作品。
程序方面也被证明是有问题的。从2d转过来的3D程序员，并没有为游戏添加足够的效果。包括灯光，特效等。
有那么多问题，那么多东西需要改，而游戏离发布时间已经很近了，因此如何制定修改方案，也是一个大难题。做最少的修改，达到最大程度上的视觉提升，这是他的目标。最后出来的计划，第一步，不是马上就开始去修改，而是恢复团队凝聚力，提高团队效率。他建立了内部论坛，用于内部交流。他要求每个美工都必须以图片方式把自己的每项工作放到论坛上，自己先做好注释，然后让大家来评论。他同时要求该项工作的组长或经理必须进行阅读并回复（他提到这点很重要，否则每个人发现自己写的东西没有回复，以后就不想去发表了，也不愿意去看了）。另外他还规定了一点，在论坛的公开场合尽量多做赞扬或有益的建议，而批评就尽量在私底下进行。他要求成员对自己做的设计进行并负责到底，在论坛上可以自由讨论，但要避免无休止的争论。对于策划团队，他给大家灌输了这样的理念：美工和程序员都是策划的客户。目前公司游戏已经开发到这种程度了，游戏系统和玩法本身已经不需要太多调整，这意味着不需要太多新的策划方案，而画面倒是个大问题，策划应努力配合美术和程序。
接下来他制定了具体的修改方案。考虑到时间已经不多了，不能让美工大规模的修改或重新制作，他确定在一下几个方面进行修改：
1.  主要角色的艺术数据，包括模型和贴图。
2.  光照的建立。为场景添加光照，提高立体感，丰富色彩。这一点同时需要程序开发以及美工编辑。
3.  修改Map Editor，编辑器的设计者和开发者必须要考虑到美工操作的方便性及其心理习惯等。他们发现美工的情绪对于编辑出来的效果（包括建模）有着很大的影响。他们觉得编辑器不好用的话，他们情绪就低落，就发挥不出他们的水平。

还有一个细节可能需要留意一下，他建议的修改周期是三个月，但开发团队说两个月就做完。而实际上却花了四个月。最后他们还是成功了，效果跟之前相比有着天渊之别。

这是最后一场了，我们都听的很认真很轻松，他也讲得比较有意思，韩国人在我心中的印象有了一点点好转（滴汗）。从始至终他好像只说过一句中文吧，还有一句英文。全场他都用的韩文，同事有个翻译帮大家一句翻译，因此讲座进展的很缓慢。我忽然产生了挑战一下他的英文水平的念头，哈哈。他讲完后，我鼓起勇气走上去，跟他说，your speech is very wonderful。然后他好像只说了一个单词，好像是thanks，还是wonderful?忘记了。然后我接着说“shall we exchange our cards？”，边拿出名片，他也陶出个名片，也没说一句话，就给我了。我就没办法了，只能说，thank you，see you。。。呵呵，很滑稽吧。

 

 

天朝GDC 2009归来（二）：http://www.cnblogs.com/sixwater/archive/2010/06/02/1747064.html