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:
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不行
- 。。。
一堆展望,看得犯困。