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需要
在应对多变的多核结构,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,
dice展望未来,
material方面和unreal一样用shader tree----相信有一天shader tree会被他们自己干掉的。
editor&tools
editor也很不错了
pipeline上,texture compresion有用到cuda。
debug的环境,对于vs2010和nv的nexus抱有很大期望。
然后是展望未来部分,提出了一些挑战:
第一个挑战,抱怨贴:
第二个挑战,engine部分的feature未来发展空间广阔,各种高杆技术,简介光照,更高质量的特效(motion blur, DOF...),但是最需要提升的是动画部分(这个很赞同,现在的确图形部分走的比其他几个部分要快一些,站着不动很真,一动就感觉假了)
继续怨:
一堆展望,看得犯困。