注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

红楼&游戏

一位红楼爱好者&游戏策划的blog

 
 
 

日志

 
 
关于我

我们身处在一个悲哀的国家, 我们同胞的血脉中流动着短视的劣根性, 我所从事的行业正处于黑暗的时代, 我没有热血,但一息尚存。

网易考拉推荐

Postmortem的总结  

2007-09-12 11:18:26|  分类: 游戏发表 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

7月份,在网络上有一场关于postmortem(项目总结)的讨论,殊有趣味,故以此为引,展开一些相关的话题。

 

在介绍这场讨论之前,首先简要介绍一下postmortem的含义。原意为尸检的这个单词,通常指的是总结式的项目回顾,发现问题、剖析问题,为了以后做得更好。引用《游戏是这样炼成的——游戏制作案例精选》一书中的说法,postmortem“直接的解释为验尸、事后剖析,事后检讨对已结束事件的分析和回顾,第一个解释形象生动,第二个解释清晰的说明了这类文章的目的”。在国外,撰写postmortem已成惯例,“很多国际水准的游戏制作团队都会在项目结束后把开发过程中的酸甜苦辣如实地写下来,把开发过程总结写成postmortem发表。而正在参与游戏项目开发的制作人员往往也会通过阅读同行撰写的postmortem来获取经验,得到提高。”而这次讨论的起因,是Coding Horror站点的主人Jeff Atwod写了一篇关于游戏开发总结的日志,地址为

http://www.codinghorror.com/blog/archives/000901.html

 

在日志中,Jeff叙述了postmortem的价值,引用了Game Developer杂志对postmortem目标的定义:

————

给出五项完成良好或者超出计划的项目目标、功能或其他内容。

你认为开发中是否有某一阶段比你当初计划的情况更加困难?是否有新加入团队的程序员给项目加入好的想法或带来精良的编程能力?是否一种新技术得到广泛应用后解决了棘手的开发难题?是否有新的开发工具带来效果更好的图像和声音?是否用一些实现未能预料的手段节约了资金?是否通过不曾想过的方式解决了项目开发的时间?市场或PR部门是否在相关杂志上做出了非常棒的预览图?……

给出五项产生问题或完全失败的项目目标、功能或其他内容。

是否主程序在项目中途离开了公司?新技术的采用是否给开发者带来了未预料的问题?开发工具是否在某些方面让你很头痛或者达不到理想效果?项目开发中是否产生了隐蔽的开销增长,如果有,它们怎么产生的?开发日程是否因为某些原因被打乱?测试周期是否因为某些原因产生问题?是否因为项目工期的压力导致功能缩减?是否市场或PR人员未能将游戏正确推广从而导致玩家错误的期望?……

 

同时,日志中列举了作者所推荐的部分Gamasutrapostmortem

Trespasser

http://www.gamasutra.com/features/19990514/trespasser_01.htm

Myth: The Fallen Lords

http://www.gamasutra.com/features/19980731/regier_01.htm

Thief: The Dark Project

http://www.gamasutra.com/features/19990709/thief_01.htm

SWAT3 Close Quarters Battle

http://www.gamasutra.com/features/20000609/reinhart_01.htm

Deus Ex

http://www.gamasutra.com/features/20001206/spector_01.htm

Black & White

http://www.gamasutra.com/features/20010613/molyneux_01.htm

Operation Flashpoint

http://www.gamasutra.com/features/20011219/spanel_01.htm

Galactic Civilizations

http://www.gamasutra.com/features/20030507/wardell_01.shtml

Armadillo Run:

http://gamasutra.com/features/20060619/stock_01.shtml

————

 

的确,就像对于程序员而言,有经验的优秀开发者和普通开发者最大的区别不在于掌握新的语言或会某项独特的技术,而在于是否会不断地重复犯相同的错误。游戏开发也是如此,对比软件行业而言,阅读和分析游戏开发的开发总结更为重要。作为一种特殊的软件项目(需求不明确,玩家的乐趣?技术不明确,可能在开发中更新技术;规格不明确,可能在推出后进行修改等),过去的成败经验都是异常宝贵的亲身教训。Postmortem的目的就在于帮助我们更好地从以往的项目中学习并改进自身的开发实践。

 

 

不过,一石激起千层浪,MMO游戏《Pirates of the Burning Sea》的开发总监Joe ludwig在其博客上发了一篇回应上文的日志,地址为

http://programmerjoe.com/2007/07/07/game-developer-postmortems/

 

在文中,作者提到其阅读了大量游戏开发postmortem之后,发现内容抽象之后大同小异,无非类似于:

————

正确的:

l  大量迭代

l  有经验的团队

l  较早重视工具的开发

l  围绕功能范围(scope)的大量控制

l  从玩家反馈中获益

l  与公司喜欢的伙伴方合作

错误的:

l  迭代不充分

l  非常糟糕的开发日程规划

l  功能范围失去控制

l  工具不佳

l  缺乏经验

l  雇用优秀人才方面出现问题

l  与公司不喜欢的伙伴方合作

————

作者认为,与阅读这些空洞重复的报告相比,和一些开发者在GDC会议上的交谈或者和其中的程序员在酒吧中喝酒聊天得到的收获要大得多。

 

接下来,CMP集团(Game Developer杂志和Gamasutra网站所有者)的博客上也做出了回应,地址为

http://www.gamesetwatch.com/2007/07/gamesetq_game_developer_postmo.php

 

文中谈及由于着眼点在于整体项目,GD杂志上的一些postmortem会有一些共通之处,如《Stubbs The Zombie》的postmortem

http://gamasutra.com/features/20060811/seropian_01.shtm)集中于开发中较为独特的部分展开,不同于其他“大路货”的报告。同时提出大家更需要哪一种postmortem这一问题并希望获得反馈。

 

那么对于国内游戏开发的现状而言,总结报告应该如何写才最符合实际需要,这是我所关心的话题。下面就简单的说一下自己的想法,也希望得到更多人的回应。

 

国内的游戏项目以网游为主,项目的开发过程通常会持续很长时间,6个月、一年以至于三年四年,在漫长的开发过程中团队往往会碰到非常多的困难,整个项目的进展也不免遇到曲折;就算制作人有着丰富的开发经验,过程中会发生的困难也是他无法预计的,因此对每一个经历过的项目开发过程进行总结,对于游戏开发人员,尤其是国内的开发人员而言是一件应该做也必须做的事。

 

1、巧妇难为无米之炊——积累开发日志

要进行总结,至少要熟悉整个项目的开发过程,但是很可惜这需要非常好的记忆力。再困难的问题一旦得到解决,经过很长一段时间后就容易被遗忘;所以我们必须有一个很好的记录习惯,记录下开发过程中的点点滴滴——开发日志的书写。也许很多人有这个习惯,但是这件事在很大程度上被非常多的开发团队记成了流水帐,而且由于强迫行为,额外增加了开发团队的工作量。所以开发日志的写作并不需要真正做到每天都写,我的建议是间断性的写作,困难式的写作。怎么讲呢?就是每隔一个月记录一次开发过程,并且主要记录开发过程中的如下事件:

l  开发过程中的困难

l  产生争执的设计

l  技术实现和设计工作的冲突

l  时间管理和工作效率

l  设计思路的重大改变

……

有了清晰明确的开发日志,我们才能留住整个开发过程中的思路变化,才能对整个项目进行总结,所以这是整个总结工作的开始。

2、打破砂锅璺到底——分析原因

漫长的开发结束了,游戏也上市了;整个团队辛苦后的成绩也出来,结果也许有好有坏。因为网游产品的特殊性,游戏的成败尚未定案,对于开发团队来说真正要做的工作才刚刚开始。一个项目的上市并不意味着开发工作的结束,而是整体开发工作的新环节开始,待完成的工作很多,要改进游戏设置、继续开发新的游戏内容、增加修改游戏的系统等等;而这些工作有一个共同的前提,我们需要对项目进行总结和分析。那么可以从哪些方面入手呢?就设计方面而言,首要的问题是目前呈现出的游戏是否符合最初的原型?玩家是否满意?

这是第一件要分析的事,在开发游戏之初我们肯定已经构建了对游戏的整体设想,所要呈现出的游戏世界是怎样的世界、目标用户群是哪类人、游戏吸引玩家之处在哪里、游戏有什么特色、这些特色是否受人欢迎等等。这些在项目开发之初仅仅是作为猜测或者期望的命题,已有活生生的结果摆在眼前,玩家是否对于我们设想的世界予以接受很容易观察或询问。

首先要判断是否符合原型?如果符合,说明开发过程中管理得当,如果不符合,那么是什么原因?这一部分稍后再谈,先说符合原型的情况。开发成品符合原型的情况下,如果游戏表现的很好,那么证明最初的原型是符合玩家需求的,然而如果表现的不好,玩家并不接受呢?那只能说明我们并没有做出被玩家所认可的游戏,那么要分析的是设计理念的偏差、玩家心理把握失控抑、创新尺度缺乏检验,亦或是市场运气欠佳。

回到刚才的话题,如果游戏最终的展现与最初的原型相差甚远,那么问题出现在开发的过程当中。这说明开发过程中整个设计思路经历了巨大的变革,才造就了最终的游戏世界,在这种情况下这款游戏是否能接受玩家检验,接受市场检验,就已经类同赌博,无论输赢都无法全盘掌握。

就以此为例,如果设计思路发生大的变化,那么我们需要总结的便是:

l  为何作出这一决定?

l  为何要对游戏设计进行改动?

l  为何要进行这样这样的改动?

l  改动的时期是项目前期/中期/后期?

l  在改动之前的设计思路是什么?

l  改动后的思路是什么?

l  新的思路表现好不好?

l  这样的改动增加/减少了多少工作量?

l  这样的改动增加/减少了多少成本?

l  造成改动的原因是个人意见还是团队的意见?

l  改动是否值得,对项目的成败的影响有几分?

通过类似的分析,可以对未来的项目开发中遇到类似情形时的判断和选择提供宝贵的参考。

3、行百里者半九十——常见错误

在博得之门2的开发总结中有一句话:“那些不能从历史中吸取教训的人只会重蹈覆辙。”就个人经验而言,国内一些公司对项目总结亦非常重视,拥有详尽的记录和回顾,但根据观察,往往会犯以下的一些错误:

1)总是等项目结束了再进行回顾

项目开发完结进行总结,只是让我们去分析项目成功或失败的原因,以便让以后的开发不再范同样的错误,但这对当前项目鲜有益处。真正的总结应该在开发过程中就开始,发现问题总结问题,这对于国内的开发现状而言,比在完成后再分析得失更有价值。现在流行的Scrum开发方式中,每个scrum结束的总结都很重要,定期反馈也是敏捷方法的核心之一。事实证明,在游戏开发这所学校中,我们做出的选择以及一些随之产生的问题就是我们的良师益友。

2)反馈做不到足够的开放和坦诚

我们往往会发现很多总结报告显得空洞贫乏,食之无味,并非我们预期的效果;很多时候分析出了结果但却无法分析造成这种结果的原因,原因何在?导致项目产生问题的因素有非常多的可能,真实的原因很多时候被各种各样的理由所掩盖,我们往往不愿意去正视。项目总结的过程是自我剖析的过程,需要每个成员足够的开放和诚实,分清责任,寻找原因,这并不意味着要找出谁的过失,而是为了获取项目开发中极为宝贵的经验。

3)未能参照全局开发的流程和规划来看待反馈

游戏是多元化的产品,开发过程中也会考虑各方面的因素。在总结回顾的时候,往往容易将焦点集中于某一段工作进度,分析其中利弊,但这种视角放入产品的整体布局当中,也许“正确的事”反成了“错误的事”,反之亦可能。如果不能甄别出真正的经验,带来的效果不免捉摸难测。

4)未能真正按照反馈的内容去改进

也许很多人会不同意,但这样的错误的确每天都在发生。的确很多项目组都在分析之后进行了相关改进,但往往在一段时间之后又出现了由同一原因导致的其他问题。这是由于项目总结到最后,往往会提炼出比较精髓的实质内容,而对这些内容不同的项目成员很可能产生不同的理解,这也是不同人在阅读了同样一份gamasutraGD杂志的postmortem之后会得到不同的信息和结论的缘故。而在让成员统一认识之后,真正的执行也是至关重要的

5)没有把吸取的教训放到前台和中心的位置

项目总结报告的目的,是为了减少犯重复错误的可能,既然有了诸多项目的总结报告,开发过程应该相当成熟才对,但为何现实并非如此?道理很简单,因为在大多数项目中,这些经验和教训总是放在知识库或者资源库当中,总结、归档、讨论,然后结束。书读千遍,其意自现,没有对这些经验教训的反复记忆和理解,它便是未打磨的璞玉,难现光彩。想像一下,如果我们各个角落书写他们,鼓励项目成员贴在自己墙上、放在自己博客里、写入自己的签名档,他们必然会成为项目文化一部分。否则再多的项目总结也是徒然,只会积累出越来越多自相矛盾的教条。当项目总结所包含的整体意义和准则成为个人和团队的思维体系组成部分之后,这个团队才算没有白白开棺(见前文postmortem含义)。一个拥有这样文化的团队无论成功失败相信都会一路走好。

 

最后,列举一下我所总结的上一项目的postmortem,由于难以展开具体的开发内容,很不幸的属于前文提及的“大路货”,兹以抛砖引玉:

 

正确的:

 

l  程序、策划、美术在项目前期的充分协商

在项目制作前期,程序、策划与美术就开发目标、开发细节、开发难点进行统一协商,能够较大程度地减少开发过程中面临的未知风险,同时对产品大致情形有充分理解。在此之后,持续性的定期集体商讨亦不可少。

l  列举功能清单

将游戏内容按重要性、开发难度、开发次序进行编排,并注明哪些功能在必要时可被删去,同时根据功能的排布指定里程碑计划。与此同时,功能的列举与排布不做轻易改变——只有在绝对必要时才能对开发决策做出改变,而且需要经过深思熟虑。 

l  程序提出需要策划、美术完成的前置任务

这对于保障开发进度至为重要,程序的工作通常模块化且比较集中,在前置任务完成的情况下,程序的进度可以得到准确的规划,从而保证开发日程的顺利进行。

l  提供充分的设计与运营工具支持

这属于前文所引的“老生常谈”,大多数项目也能做到对工具开发的支持,但只有当这部分支持充分到一定程度时,才能见到可观的效果。当策划或美术在完全独立的情况下操作易用性良好的工具进行设计工作时,提高的效率是双倍的。

l  与玩家深入接触

自始至终在开发各个环节与玩家保持“亲密”的接触,带来的益处是不可估量的。游戏的最终目的就在于让玩家觉得好玩且易上手,也就是满意度,这也是网游的商业价值所在。因此,我们要和玩家交谈,观察他们的行为,以及理解他们的心理。从市场调查、系统评估到可用性测试,都离不开玩家的存在。

l  团队透明化

无论程序、策划、美术、市场、运营,都是团队的支柱,每一部分都直接关系项目的成败。只有真正的坦诚的沟通才是有效的沟通,也才是维系团队、建设团队乃至团队文化的关键,没有沟通也就没有真正的团队。在团队中,有不同的意见不说,有好的建议也宁愿它烂在肚子里,这样做的结果极其不利于团队的成长和项目的质量。各部门对项目进度、项目质量的了解和重视,可以很大程度上避免走弯路。

 

错误的:

 

l  计划变化

计划变得越多,需要的开发时间便越多。如果要推出一款精品游戏,为了保证游戏品质、玩法出新,可能必须牺牲一些开发时间,严重的甚至需要推倒重做。但游戏需求频繁变动必然会导致实际开发与预期进度出现偏差。因此,立项时最好应明确项目的规模和进度时间,然后建立起完善的“需求评估”的机制,才能更好的控制游戏项目的频繁改动,保障项目开发的进度。对游戏的全局规划、功能范围和目标等等需求需要详细合理的描述。如果存在致命性的漏洞,很可能导致细部设计时不完善、达不到预期目标或工作量大量增加。

l  项目成员选取不当

项目开始时需要明确团队能力,如果一开始的定位就存在问题,错误估计能力与目标之间的差距,很可能导致整个项目推倒重来。游戏项目启动时,如果没有或者没能力去对项目人员的经验能力和技术开发存在的问题进行评估,因为人员能力的问题或者技术障碍往往会导致项目无法顺利进行。另外,开发过程中项目成员频繁变动也会给开发带来不少障碍。

l  讨论过多

在项目开发中,对于功能设计与实现纠缠于讨论,一方面浪费大量开发时间,分散成员注意力。讨论应该在以需要为基础的前提下即刻点明问题所在。冗长的、无休止的、没有明确议程、明确结果的讨论只是浪费时间。此外,过多争论容易产生内耗,因为争论的目的往往会转变为证明自己比对方技术好、能力强。长时间内耗,极容易降低成员的开发热情。

l  为设计而设计

这一条在EA的游戏制作人Paul Barnett(Warhammer 3KWarhammer OL)的“游戏设计中的七个致命”这一日志中亦有谈及。在那篇日志中Paul调侃道:“策划不停的增加、删改、重建无数的东西来增加团队的工作量。我认为这是他们的天性。他们希望革新,并且沉迷于给每一样东西增加特性,如中病魔。”在现实中亦遇到了这一情况,有很多设计看起来更像是设计者的喜好,“因为这样很好,很酷”,于是就增加了这样的设计,这样做可能导致的风险几乎不用说明也能体会一二。

l  缺乏功能完成度的评估。

如果成员过高的估算了自己的能力和工作热情,进度估算得过于理想化,到项目中期时多半会遇到完成质量不高或项目延期的问题。游戏项目的一个系统功能的全部完成,多数情况下需要美术、程序、策划来共同完成,对于各部分完成情况一定要有一个统一的标准,并且需要专门的评估人员来对游戏功能完成度做评估,这样才能确保避免项目人员产生一些盲目自信。而且完成度评估的另一个目的在于明确掌控项目计划的完成情况。假如项目成员把项目计划安排当成儿戏,项目必然会走向失控。

l  缺乏资源

资源的含义包括资金、时间、人员等。工期安排不充分,必要人员的缺少等都容易导致需求渐变问题。按期成功完成一个项目的关键在于积极的计划和合理的资源管理。举例而言,在未实际分析项目可行性的情况下,对于所给定的时限,项目显得过于庞大,这便导致时间资源的缺乏。 同样,必要人员的不能到位、对于项目开发必不可少的基础设备(如硬件、软件、工具、文档等)无法得到或不能正常运行之类的资源问题也会对项目开发产生较大影响。

l  上报问题不及时

开发时需要密切保持项目成员之间的沟通,及时了解并发现过程中产生的问题,分析主要矛盾和次要矛盾,并采取具体和适当的措施来解决。对于各种问题及时做出反应和处理,必要时修订和更新进度计划。当问题出现时,应该第一时间报告管理层,并尽可能多地制定解决方案。在事态严重到无法补救以前,尝试各种弥补办法便是最后需要做的一件事。上报不及时,可能会使本可解决的问题变得愈发严重。

 

最后,鲍威尔将军有句名言——“成功没有秘诀。它是仔细准备,努力工作,从失败中吸取教训的结果。”

 

  评论这张
 
阅读(550)| 评论(1)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017