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

一元

文/顾煜 专栏：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话题并定位修复，这个也算是弥补了，毕竟不好的体验到了玩家侧，我们能做的只是尽快响应。

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