Parallel Futures of a Game Engine

http://publications.dice.se/attachments/BFH-Telemetry.ppt

Dice的ppt,dice的共享很赞很值得尊敬,而且的确提供了一些实践得来的数据和经验。

 

直接进入主题:

 

 

这组数据很不错:

 

一个续集游戏大约用2年,新品牌得3到5年。

引擎需要持续的开发和使用。

AAA游戏是70--90人:

 

40% artists

30% designers

20% programmers

10% audio

那coder大概是14--18人。

 

 

贵在团队素质和积累,当年dice放ps3上ppt的时候,感觉说的没什么亮点,很是普通么,唯一印象就是software rasterizer。

这么长时间积累下来,游戏牛,engine牛,做一个游戏是之前3--5年的积累的结果,其他2年蹦达出来的能比么?

 

 

 

这个说法比较喜欢:

Quick iterations Essential in order to be creative。

游戏是充满主观性的东西,很多本来想的挺好的东西做出来并不好玩,更多的点子也需要实践来检验。

项目组自己提出需求,自己实现,然后自己否定其中的一个部分,这就是游戏开发过程中追求高品质的必经之路。

灵感,尝试,沉淀与抛弃就是gamedev的一个属性。

所以quick iteration正是非常符合这一属性的方式。

 

觉得可以这样看,在第一版本prototype的时候,目的是验证需求(这个想法是正确的),那么就可以只考虑核心实现,以速度为最高优先级。

待验证了这个想法果然是好的,也就是需求定了,那么开始把代码质量提到更高的优先级,把想法高质量的完善好。

 

项目组也需要给developer空间去做好完整迭代,否则烂代码积累下来,杀伤力很可观的。

 

quick iteration需要

  • load快
  • build快
  • 热加载
  • coder也有意识的去做到尽可能敏捷

 

 

在应对多变的多核结构,360,ps3,pc(2hw thread--12 hw thread,很快会更多)的时候。

dice选择了job系统。

任务面向的是job,job由job manager来管理,负责将其根据彼此之间的关系(dependency等)在线程资源上管理和运行。

job虽然带来debug噩梦等等,但是也真是技术趋势了。

 

dice的job之间dependency也比较复杂,形成了job graph,很华丽。

profile result screen shot:

Parallel Futures of a Game Engine_第1张图片

 

 

 

gpp部分代码量上了1.5M行。

无script。

逻辑复杂,难以并行。

 

 

 

render 部分用了大量的job,

  • terrain geometry
  • vegetation
  • decal&particle
  • frustum culling
  • cmd buffer
  • occlusion culling
  • occlusion rasterization----这个存在比较长时间了,dice的标志性技术,很赞,软件渲染地resolution的occlusion场景,然后看不见的部分找出来,直接跳过相关的update和render。
  • edge的triangle culling

dice展望未来,

  • larabee能顺利成长就好了,这样就可以做精确无跳帧的occlusion culling,然后省掉大量的计算了
  • 或者gpu更牛一点,把这些culing什么工作自己搞定

material方面和unreal一样用shader tree----相信有一天shader tree会被他们自己干掉的。

 

 

 

 

editor&tools

editor也很不错了

  • 所见即所得的资源管理
  • c#的ui----interop到死

pipeline上,texture compresion有用到cuda。

debug的环境,对于vs2010和nv的nexus抱有很大期望。

 

 

 

然后是展望未来部分,提出了一些挑战:

  • gpp部分怎么来更便捷的开发维护和并行化gpp代码。
  • 在硬件继续在多核这条路上狂奔的情况下,engine部分的job graph怎么应对。

第一个挑战,抱怨贴:

  • shared concurrency不行
  • c++也不行
  • 没啥好工具(openpm也不行)
  • 但是ea job manager还比较行----该不是想卖授权引擎了吧。

第二个挑战,engine部分的feature未来发展空间广阔,各种高杆技术,简介光照,更高质量的特效(motion blur, DOF...),但是最需要提升的是动画部分(这个很赞同,现在的确图形部分走的比其他几个部分要快一些,站着不动很真,一动就感觉假了)

继续怨:

  • rasterizer pipeline不行
  • hlsl不行
  • 。。。

一堆展望,看得犯困。

 

 

 

 

 


原文链接: http://blog.csdn.net/ccanan/article/details/5637847

你可能感兴趣的:(Parallel Futures of a Game Engine)