GameRes游资网

 找回密码
 立即注册
查看: 1504|回复: 0

The world at your fingertips — 天涯明月刀幕后18(冲刺)

[复制链接]
发表于 2018-5-31 10:07:59 | 显示全部楼层 |阅读模式
011.jpg

文/顾煜 专栏:https://zhuanlan.zhihu.com/gu-yu

前文回顾:The world at your fingertips — 天涯明月刀幕后17(资源管理2)

冲刺

伴随开发,天刀的IP问题也渐渐明朗。在商务这条线,老于和市场部拿下了天涯明月刀的IP。这个IP在年轻人这里知名度并不高,读过古龙的人,年纪都开始奔40而去。但这个IP也有几个优点,一是读来朗朗上口,便于传播,二是此前正有钟汉良的同名电视剧热播,热度犹存,三是古龙的武侠世界观较为松散,便于改编和发挥。

有了IP,老于和市场部又顺势签下了专家顾问,陈可辛、袁和平领衔的几位金牌电影人,由他们对我们产品的后期进行最终的指导建议。这也是电影人首次比较正式的参与网游项目指导。说也奇怪,随后1、2年,突然冒出来一堆游戏,都想到一起去了,每次也是请几个著名电影人给游戏指导。同质化的行业,同质化的游戏,同质化的竞争。

2012年底的腾讯游戏嘉年华,我们就需要对外正式宣布了。整个项目组欢欣雀跃,但又忧虑重重,喜的是终于多年媳妇要熬成婆,忧的是貌似手头的东西还没法拿出去见人。还好老于也没有过多压榨,表示一切以明年5月上线测试为最大目标,这次暂时先拿评审用的视频做点润色吧。

年底发布产品,我们还是稍微花钱做了段CG。天刀早期的历史中,花钱做CG的事情只此一次,绝大多数的宣传视频,都还是用in game内录为主,成本低,效率高,而且真实度高,不容易后期被玩家吐槽。在制作in game视频的过程中,顺手可以把特效补完整,也是一举多得的事。

天刀的第一次亮相,并没有公布太多的具体内容,比较商业向,只是宣布了和导演、武指等电影人的合作,大屏幕放一段CG,并没有什么游戏画面内容的展出。虽然离天刀正式上线只有5个月了,但那时候的天刀,还是一个和其他网游差别并不大的游戏,只有战斗系统还算动作性较强,其他系统不上手也看不出太多的不同。

确定的测试时间是13年5月,后续如何在几个月里让游戏能有巨大的变化,能有好的卖点,对开发团队来说是巨大的挑战。这个时间点谁也没有把握,但既然提出,自然要努力做到。大地形,引擎改组,渲染优化,加载优化,稳定性,每个团队都被逼到极限。

简单来说,我觉得后续有几个事情值得说一下:

先说一下优化和Debug,这是一个版本质量的基础部分。优化一直是天刀的擅长,但第一个版本其实还没有做到那么好。当然我们也尽力做了一些优化,把主要的问题都解决了一下。值得一说的是Debug,第一个天刀的测试版本,质量方面把控的非常严格,即使我们是一个新的项目,测试等各方面资源并不多,但我们依然在最后大半个月进行了大量打磨。整个项目的开发人员都停下所有手中的工作,一起测试版本。一遍遍的通关已有的内容。大家一起疯狂的报bug,手头有bug的同学则忙碌在Bug的汪洋大海,修改、调整和优化。间或,他们清理干净了手边的Bug,便又大呼小叫的加入大部队,测试起版本。

第二个值得说一下的特性是天气系统。引擎团队当时的工作模式,把主力开发力量放在了发布版本,但我们一直保留少量力量探索新的可能性。团队新来了一个做渲染的女孩子,也就是后来被大家称为天气姐姐的小马,她一人游离在版本外,做着Research。Tough哥安排她看了天气系统。

天气姐姐做了很久预研,已经离上线时间只有一个月不到,但还是有所产出的,我们看了效果,觉得相当不错,很希望能加入上线版本。老于谨慎小心,认为版本已经快要扑街,任务和Bug熙熙攘攘,如大江东去,冲破层层心理防线。能不加大特性,还是不要加了吧。他谨慎的推脱,目光游移且身形蠕动,慢慢陷入终日不见阳光的工位深处,和黑暗融为一体。

口说无凭,我们还是拉着老于去天气姐姐那里看看预研成果。天气姐姐在编辑器里面变换天气,只需美术做少量工作,就可以让已有的场景更多样化。晴空万里的场景,转眼竟是细雨如烟,老于眨眨眼,不敢相信,再定睛一看,却是一阵瓢泼大雨。

很多时候工作成果不能打动别人,还是因为做的东西不够好,不要相信什么进度来不及了、预算不够了的鬼话。老于虽担心进度,但心向往之,表态说现在整合这些特性有点晚,但我们还是努力试试看加进版本?

大家当然很受鼓舞,欢欣雀跃,预研团队是一个奇怪的物种,信奉少一事不如多一事,能用上成果当然是最好的。但随之而来的就是巨大的工作量。单独看每一个技术点,其实很多团队都能做,但整合到产品,依然是一件非常复杂的事情。

天气效果需要调好,并不是很容易,一个新的系统,一堆陌生的参数,一个开发中的环境,种种难题摆在了美术团队面前。好在美术团队是经历了种种考研的,每次都能超出预期。参数多不怕,多凑凑来找感觉,加班自然也是免不了的。

另一个麻烦的地方在于,下雨的场景,我们肯定希望场景也有相关的变化,这个不是很有把握,我们也不可能针对整个场景做批量的调整。幸好天刀的材质系统用了PBR。

Tough哥在天刀开发伊始就坚持要用PBR材质,美术开发们不干,人总是喜欢熟悉的系统,不想迁移到新的系统。他们和Tough哥大战了几百回合,但架不住Tough哥死缠烂打,软磨硬泡。战力,是战意乘上体力,Tough哥意志坚定,体力充沛,天天劝说,积极引导,到处争取支持,终于还是搞定了美术。迁移到PBR是大势所趋,只是美术开发肯定会有阵痛,材质调整方式都不一样了,外包公司也要重新熟悉系统。

让人惊喜的是,下雨天导致了场景变湿润,可以简单通过PBR中的参数调整来实现,只要动态改变PBR系统中的参数,物件就会呈现湿润的油光感觉,我们基本无需重做大量物件。

天刀很多高端特效的开发过程,是美术和技术相辅相成的开发过程。程序有一些进展,和美术一起做出简单的demo,后续就扔给美术调效果,过几天跑到关卡美术那里一看,总是大吃一惊,原来这个技术还能这样用,效果经常好到让程序也不敢相信。有了好的技术,还需要有足够好的美术团队能发挥出来,这点上天刀的美术团队表现一直稳定和出色。

这个最后一刻加入的大特性,推出以后大受欢迎,让开发团队非常受到鼓舞。


测试

说到上线,还想探讨的话题是测试。

主机和网游相比,对于品质的要求非常不同。主机对于品质、稳定性有很高的要求。Sony、微软、任天堂等主机厂商,对于每一个产品的审核,是有着非常详细的规范的。小到一个文本或者图标,大到一个Crash或者卡顿,只要在审核期间出现,必然记录在案,视乎审核人员心情,轻则建议修改,重则打回版本,要求修改后重新提交。

原因在于如果游戏容易crash,那么玩家会责怪的主机厂商,表示这个机器上的游戏很容易闪退,而早期的主机游戏没有硬盘,并没有太好的手段来做发售后的Patch,真有大问题是没办法弥补的。长此以往,大家养成了对质量的高要求。

而国内网游的内测公测,正如字面含义,所有的测试,真的是测试。Bug满天飞,有Bug不奇怪,如果没有Bug,玩家还要觉得奇怪。主机上一次都不能有的Crash,在网游和手游上往往是以Crash率来计算,低于3%就算优秀了。

天刀第一次小规模测试,尽可能往主机测试的水准靠拢,服务器运行一周没有回档和崩溃,玩家在群里面表示不科学,这个游戏可能已经做完了,否则怎么那么稳定呢…对于客户端,倒是没有那么稳定,但依然是可以超过平均水准的,而性能方面则是远超当时的平均水准。

我们不禁要问,造成两者巨大差异的根本原因又是什么呢?开发还是那些开发人员,测试也是那些测试人员,为什么两者的质量差距如此之大?

第一个原因是网游规模太大,Scope是单机游戏很难想象的,对这么大的游戏进行完整测试,成本非常难Cover住,而且完整测试一轮的时间周期也极长,回归测试Bug让人头痛。加上很多Bug需要多人来重现,更让成本上升很多,

第二个原因是理念和监管。开发主机游戏是在人家平台上做游戏,人家有规矩,你不做到,上线也不可能,逼着开发者去提升质量。而PC上的游戏是一个开放的平台,并没有人监管你的产品质量,长此以往,大家也就不那么上心了。

第三个原因是投入问题。天刀最初的测试团队不过3-4个人,上线前的测试团队也就10个左右。这点人根本不可能完整cover整个游戏的测试,只能通过自动化手段,大致对关键功能、协议做一下扫描,跑一下最基本的流程,就算测试通过了。而我们之前做的主机游戏,即使是雷曼疯兔这样的party小游戏合集,3个小时的游戏长度,也有20个以上的测试人员,三个月内每天通关无数次来测试产品。

第四个原因是和开发人员的协作问题。由于测试人员如此的少,自然很难和开发人员一起定位和解决问题,能发现问题就不错了。而我之前参与的主机游戏测试流程,测试同学可以针对非常低概率的Crash bug,反复帮助开发人员找规律重现,这个过程甚至会持续好几天,就为了找这样一个Bug。我很喜欢说的一个例子,就是有一个很低概率的crash,我摆开一排xbox360的开发kit,每天下班前把新的版本上传到开发机,测试人员每天有人留下,在那排kit上一一重现crash bug,把所有机器都玩crash了就下班,我第二天一早来,连到每一台机器进行调试。所有的问题现场都在那里,我的工作效率就非常高。

黑盒测试和白盒测试都很重要,无法相互取代。但我们的测试人员数量极少,只能把大家逼向白盒或者灰盒测试。

然而这并不合理,开发人员的成本相对是比较高的,测试可以通过外包等方式来降低成本。如果测试不帮助重现更多的Bug,自然需要开发人员自己来重现,甚至会有10多个开发人员约好一起进游戏去重现某些复杂bug的情况。而且开发人员重现Bug的效率不高,作为开发人员,我有能力修复复杂Bug,但我并不擅长重现那些Bug。这是对开发资源的极大浪费。

有人会说,不配或者少配测试,是为了让开发者更负责,更多做好自测。这有一定的道理,但自测是个人素养问题,流程是项目管理问题,不可混为一谈。可以想象,在配足测试资源的情况下,我们依然可以要求开发者做好自测,提高初次提交功能的质量,这样在足够测试团队的支持下,一定可以有更高的工作效率。

比较合理的运作方式,还是拥有固定的测试团队的,高质量的人才,使用白盒或者黑盒的自动化测试手段,然后在产品需要的时候,招聘大量短期测试人员进行黑盒覆盖测试,并给予开发团队足够的查错辅助测试,帮助开发人员能更好的定位Bug。

开发资源永远是不够的,测试少也有测试少的做法,大家只能找各种变通的方法,实践下来也还能将就。

一是充分发动内部开发团队做更多的自测,以降低生产效率为代价。天刀在首次小规模对外测试中,让整个开发组测试自己的游戏,反复玩了大约3周的时间,修正了无数的Bug,成本可想而知。手机游戏上线前也会发动整个开发团队来玩自己的游戏,不仅仅是为了体验版本,还为了寻找Bug,确保基本玩的流程中没有低级错误。

二是珍惜每一次的Bug现场,有足够的在线离线系统收集每一次问题,尽量确保各种问题出现一次就能给程序员提供更多的信息。在崩溃、卡顿、逻辑等方面,我们有很多自动化系统运作,收集开发机上的信息,不浪费每一次的Bug重现。

三是做好外网版本数据收集,提醒玩家上报Crash,关注外网论坛,第一时刻发现重要bug话题并定位修复,这个也算是弥补了,毕竟不好的体验到了玩家侧,我们能做的只是尽快响应。

谁都是一面挣扎一面前行。很多时候我们能看到问题,测试质量不够高,测试资源不够多。解决方案似乎很直观,更重视质量,加上更多的测试人力即可。但解决方案却又因为种种其他因素无法实施,每个团队有每个团队的现状,每个公司有每个公司的组织运作形式,每个社群有每个社群的习惯,改变不了大环境,团队也只能从自身入手,尽可能缓解问题。

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|稿件投递|广告合作|关于本站|GameRes游资网 ( 闽ICP备05005107-1 )

GMT+8, 2018-6-18 19:55

快速回复 返回顶部 返回列表