12评论

【GDC分享】文富俊:梦幻西游手游研发周迭代的秘密

Gad-VR 2017-08-23 2.8k浏览

嘉宾介绍

文富俊

网易项目管理与培训发展中心总裁/网易游戏学院院长

文富俊是网易游戏的项目管理专家,主要负责网易游戏的项目管理和培训发展的推进和管理工作。文富俊具有丰富的游戏行业项目管理经验,特别擅长端游研发大团队精细化项目管理和手游研发敏捷项目管理,并建立其适合游戏研发的项目管理体系。

正文:

一款游戏,没有迭代,是很难生存下去的,尤其是手游,很大程度上,手游的成功与迭代有着密切的关系。有的手游是一个月迭代一次,有的是半个月迭代一次,基本上维持在这样一个时间间隔,迭代也就是版本的更新,迭代的时间周期过短,对团队的要求也就更高。

我们梦幻西游手游之所以如此的成功,可以说与迭代至关重要,因为我们的迭代是周迭代,也就是我们的产品一周就会有以此的更新,一周一迭代,对团队的工作量要求肯定是很大的,那么一款游戏如何实现周迭代,怎样在每周都能够有内容进行更新,下面我就来给大家分享一下我们梦幻西游手游研发周迭代的秘密。

首先说下我们的研发历程

我们的梦幻西游手游研发历程总共14个月,看看我们在这14个月里做了什么事情,这段时间我们至少完成了4000个独立的研发任务,修复了2000bug,而我们的这个团队人员接近30人,其中7位策划,12位程序,7QA以及4UI

再来看看我们具体做了些什么

首先是我们的玩法系统方面梦幻西游手游在上线的时候,内容、玩法其实是非常丰富的,大大小小总共超过50个系统在研发过程中我们针对每一个系统都经了多次迭代。

其次是产品美术方面,大家可能觉得梦幻西游这个IP因为有端游方面的经验和技术,美术比较简单,照着端游来做就行了,然而事实上我们所有的美术资源都是重新设计重新制作的整个过程我们美术的工作量都是非常大的,基本上超过了12000个人/,在行业中,这对于一款2D产品来讲,这样的工作量是十分庞大,如果细分的话,我们产品中的角色超过130多个,制作这么多的角色共花去了美术4000个人/场景超过30个大场景,总共超过180个场景。

再就是UI界面方面,我们产品的所有界面超过250个,我们因此迭代了很多个版本比如说紧紧助战系统这个界面我们迭代了差不多40个版本,还有队伍系统,我们迭代了25个版本宠物系统,我们迭代了30个版本。

我们这个产品历时14个月,差不多60周,所有的这些迭代我们都是在一段时间内完成的,那么大家肯定就有这样一个问题:这样一个手游,又有这么大的工作量,有这么多美术内容、版本迭代,你们是怎样在有限的周期里来持续迭代、打磨?怎么控制研发进度的呢

我们先看看传统实现大概是什么样的我用Scrum来举例,比如1个月1个版本,那么14个月,就会有14个版本来迭代,这是一个常规的做法但这样的做法,对《梦幻西游手游》团队来说是有问题的,存在几个挑战:

第一,大家都知道游戏研发分前、中、后三个时期,以4周为例,前3周都在研发进行中,等到第4周的时候,就会突然发现无数的bug,这一周就算紧急修复bug,也难免会因为匆忙而出现一些致命的问题,那么在1个月的时间里我们出的内容就是一个品质有缺陷的内容,那么这样也就出现一个问题:我们能不能迭代?有无数bug等着修复,体验有很多问题存在将这样的内容拿去迭代,无疑是自寻死路,我们只能继续修复bug放弃这个月的迭代。

第二,游戏研发是瀑布模型,是一个串行的过程,我们梦幻西游手游觉得这样传统的做法不够迅捷,存在许多的问题,所以我们采用的是周版本的迭代。

我们是如何进行迭代的

首先,我们在团队完成demo之后,我们每一周都会拿出一个可以通过验证、可以体验的游戏版本,然后我们在迭代过程中,就通过上一周的游戏版本来做迭代。在整个游戏研发过程中,对核心的研发人员来讲,他的核心任务就是把当周的游戏版本搞定,这就足够了。那么我们在这一周里,就要完成这一周的所有内容,完成所有的分支管理,同时还要做完测试,要把bug修复完。

另外,我们的策划最后还要验收,为了保证周版本的稳定和安全,我们还会邀请外部玩家来先进行体验,并收集他的反馈,然后进行优化。所以我们把系统、功能需求、UI需求、美术需求等都分散到每一周里面,这是思路。

我们为什么要做么做?

举个例子,比如梦幻西游手游中的助战这个功能,我们总共迭代了40多个版本。第1版其实已经满足了基本功能,目前市场上大多数产品所实现的也就是这第1版呈现出来的功能根据我们设计的思路,我们团队认为这样的效果对我们来说是不足够的,我们要通过周版本把更好的效果做出来每一个版本出来之后,我们的策划会首先验证是不是需要再做迭代,然后我们会邀请外部玩家来体验,体验完了再做下一个版本,直到最后一个。

从这里边我们看到,周版本可以让我更快地看到我的东西,并且可以更快速地做迭代,以保证玩家的体验度,我们思考的一切都是从玩家的体验度着手

做迭代,需要相应的支撑,要足够便捷。我们通过看板来管理每周的任务,我们有三个看板。第一个是需求看板,我们整个团队就根据这个看板来做工作,看板的内容一周一更换,我们所有人只需要当周把看板上的任务搞定就OK第二个看板是缺陷看板除了这两个,我们还有另外一个目的看板。通过这三个看板,我们一起来完成这样的事情。

当然这个只是基于系统玩法功能,还不够。我们会有一个专门给美术的看板,我们把所有的角色等内容都分散到了每一周里面,就需要对每一周的美术计划和周版本做一个可视化的匹配。另外,前面所说的12000个人/天的工作量,除了我们网易内部的美术在做之外我们还有大量的外包资源。

这样看上去,按周来搞定版本,我们比原本一个月出一个版本甚至两周一个版本的效率提升了30%以上。

但是,大家可能又有一个问题,一个周版本所花时间是5天,那么,这个版本不会有问题吗

在一个周期里,有多少人会在第一天提交人物?如果不加以管理,绝大多数同学会在最后一天提交他的任务可以想象一下,如果大家都在最后一天才提交,我们能在这一周出一个很好的版本吗?我们可以拿出一个体验完好,没有bug版本吗

所以这需要规划,我们可以看到上图中的纵轴是数量,横轴是时间。最开始在一周里面,大概第三天的时候我们只完成了1/4的任务,那最后两天一定是加班、熬夜。这不是一种好的状态。所以我们作了规划我们把工作负荷分到每一天里面,每一天的工作强度都是差不多的,到最后不至于赶工通过这样一种调整思路,我们的效率和品质能够比前面的方法提升了20%

那这样的迭代需要什么条件?

首先,要有一个有经验的产品制作人。

其次,这个产品团队要是一个成熟的团队包括前面有谈到周版本中的计划,所以更需要一个专注的美术team和产品team来参与。

然后,需要一个配套的项目管理和协作平台,这样才能精细化到每一天每一个任务每一个bug

从这些来看,周版本已经够敏捷了,但是,它是不是完全满足了产品的需求

我们提出了日版本和双日版本。在产品进入冲刺阶段的时候,我们需要每天或者每两天就出一个版本,这样的话我们每天或者两天就能看到产品效果。也就是说,在周版本的基础上,我们还会有一个日版本或者双日版本来看产品效果。具体执行方面就是早上会有任务的发布,到晚上的时候就必须要有一个可以体验、可以进行游戏的版本进行提交。

我们的这个版本,是团队30多人所有任务全部提交之后的一个版本。当然,这个版本对游戏品质的要求不一定有那么高,但一定要能看到变化。

不过这样的日版本和双日版本对工作强度要求非常高,不可能长期执行,于是我们做了一个考虑也就是双日版本,通过调整之后,我们整个团队30多人,大概的工作时间在13~14小时;如果采用日版本的话工作时间还会更高所以这样的模式是不能每天都进行的,我们只在冲刺阶段的时候,才拿来采用

最后,两个疑问

第一个问题,你这样的方法可不可信,能不能推广?

这个问题其实比较简单,举个例子。网易另外一款游戏,我们也是采用了周版本迭代的一种方式,从经验和教训的角度,我们把一个月或者4~6周的一次迭代化成以周为单位进行迭代。以月为单位的传统方式,常常会有前面松懈,然后冲刺,再休整,再冲刺的阶段,这样的做法团队的疲劳度会非常高。而我们以周为单位更多地强调每周的版本,效率实际上提高了超过30%

第二个问题,是不是说迭代周期越短越好?

并不是说未来的产品一定要以周或者35天为单位来做迭代。事实上采用周版本的迭代方式会产生更高的代价。另一方面,迭代周期越短会带来越高的工作强度。从另一个角度来说,游戏研发是创意工作,很多岗位是需要思考时间的,比如策划,我们要求就没那么高,他需要思考。但总的来讲,这样一个迭代是比传统方法要敏捷很多的,能够帮助小团队持续高效地做出精品产品。