|
|
文/顾煜 专栏：https://zhuanlan.zhihu.com/gu-yu
前文回顾：The world at your fingertips — 天涯明月刀幕后18（冲刺）
首测
全项目的内部测试大致做了三周左右，我们觉得有把握了，于是逐渐把开发人力调整到后续开发上，只留下少数人继续修Bug和测试版本。
这次准备的测试内容可圈可点，诚意十足。有当时并不多见的天气变化，有流畅的战斗，有诚意十足的优化，还有高端的关卡设计。在夜探郡王府的副本，我们加入了类似单机游戏分裂细胞一样的潜入玩法。玩家需要在尽量不惊动敌人的情况下潜入，如果惊动敌人，则会面临苦战。整个关卡难到丧心病狂，是第一次测试的高端副本，但大家前仆后继乐此不疲。
13年4月左右，腾讯在北京举办了Up+的发布会，公布了整个腾讯游戏的产品规划。开完Up+会议，我们邀请了很多媒体记者直奔北京怀柔，做了一次天刀的专项发布和小规模的媒体体验会。这也是第一次稍大规模的外部玩家见面，天刀终于从一个单机向的Demo，变成了完整的网游架构，迎接挑剔的目光。那几天非常紧张，之前版本出问题，都是内部问题，从今以后，再有问题，就是外部问题了。当然这个版本已经被测试了无数多次，内部员工都已经玩到吐了，自然不会有太多的问题。
规模尚小，一切可在掌握。
结束了媒体发布会，两周后，我们的正式测试顺利开始，从每天下午的14点，到晚上的12点。这是一次限时、限量、删档的技术测试，仅开服一周。所谓限时，就是每天只开10小时服务器，我们的服务器还没有准备好24小时运作，这样的开服时间给我们留下足够的时间查错和维护。首批玩家数量也非常有限，1000多人，仅仅是一次稍大规模的CE。
开服总是伴随着忙乱。
一样的游戏，在不同规模的玩家下，我们发现了无数的新问题。不管你做了多充分的准备，总有想不到的问题。首当其冲的问题，还是玩家同时并发数量过大，造成前几关任务，怪物刷新不够。大家随着游戏进度一路往前冲，每到一地，就看见无数玩家纷纷在旷野中徘徊，一波波争抢着收割新刷出来的怪。所有依赖杀够足够数量敌人才能过的关卡，都会卡住玩家。
这类问题在前期测试中被忽略了，没有足够的并发玩家测试，是不可能暴露出这样的问题的。内部测试中开发团队成员数量不够多，且是三三两两，错开时间进入游戏，所以这个问题不明显。我们紧急修改怪物刷新时间，增加投放来帮助玩家过关。
另一个问题是网游PVE的常见问题，内容量不够。测试之前我们估算过，如果按照一个玩家每天玩4个小时，差不多5-6天是够玩的，然后玩家在游戏中到处探索一下，测试就差不多过去了。但玩家在多人游戏中随时可以组队，过关效率极大提升，而且玩家天天从开服玩到关服，快速消耗内容。第一批头部玩家，差不多两天就把内容消耗完了。
这就没法搞了，大家进游戏前不都见过健康游戏忠告的么，说什么适度游戏益脑沉迷游戏伤身，合理安排时间享受健康生活…大家怎么说话不算话，玩家不用上班吗，不用上课吗？
PVE的内容是万万来不及增加开发的，第一版测试的PVP也不够成熟，无法吸引玩家持续投入，我们眼睁睁看着玩家们开始慢下来，游戏变成了聊天室。好在游戏基础素质还可以，两个副本各有特色，可以多次反复刷。这次测试规模不大，参与玩家都是核心粉丝，比较喜欢武侠，也比较兴奋，就靠尬聊撑过了那一周的时间。
作为开发者，最大的乐趣就是潜伏在贴吧等几个玩家讨论的论坛中，收集用户反馈了。测试那几天大家都愉快地在贴吧里面潜水。用户表扬的很多，好多人表示这个完成度，应该都快做完了吧，很快就能上线了。但也有不少用户吐槽内容不够，玩法太少。这都是正常的，谦虚接受即可。
比较有趣的是有一些玩家开始做专业状，评论游戏的技术。有猜是CryEngine的，也有猜是UE4的。也有考据党，翻出几个月前和Nvidia合作的新闻稿，表示这个是腾讯和Nvidia合作的引擎，然后被用户一通喷，表示绝不可能。
我决定匿名写一篇分析文章，以正视听。引擎是我们写的，并非外部采购，Nvidia等公司提供了很大的价值，也支持我们做了部分优化。
为了写这篇文章，我引经据典，但又不想暴露出专业的知识，所以很多角度颇为斟酌了一番，尽量用一个泛周边从业人员的口吻，似懂非懂的样子，来做出各种似是而非的说法，竭力做到专业人士一看有那么点意思但似乎还不精确，普通用户一看大神好厉害我一个字也看不懂但要跪拜。
我得意洋洋的把千字分析雄文发到了贴吧上，期待引起玩家关注。没想到发出后帖子石沉大海，并无音讯。空气中的躁动在积累，隐隐感觉会有什么大事件发生。第二天，果然看见有玩家回复：就凭你，也懂引擎开发？
这…感觉进一步的辩驳会变得很苍白，我懂引擎么？如果我懂引擎，为什么我竟哑口无言，如果我不懂引擎，眼前这个版本的到底又是怎么做出来的呢？我陷入了深深的沉思。
下一步
结束了首次测试，玩家留存情况良好，口碑也不错，团队又是一针鸡血，一不小心被玩家的热情和自己的努力感动了。当然，自嗨要不得，还是要抓紧走出下一步。
我们分析了一下测试的方方面面，在技术侧，有几点值得进一步提升：
首先是地图太大。当地图扩大4x4km以后，地图边缘空空荡荡，远景不好做。而且美术的产能无法填满这满满当当的16平方公里地盘，导致登高一望，大好河山竟是满目疮痍，地图上一片片空地，无声控诉着美术的凄凉和谋生的艰难，都加班到这个份上还是没法填满。
然后天气系统得到了玩家的极大好评，还可以进一步增强。我们打算把时间变化也融入游戏，后续把天空盒也做进一步的强化。
最后是碰撞系统还是不够好，我们采用了MMO中最简单的uniform grid的系统，考虑到原来的server代码复用以及cpu开销，在碰撞上也并没有改用客户端常用的碰撞计算系统，而是继续用grid，标注一下哪个位置有碰撞，哪个位置可以走，稍稍提升了精度而已。这个方案造成了很多问题，特别是多层地形碰撞没法做，只能在高度方面有一层碰撞。比如有一个凉亭，我们的碰撞要么是在地表，这样玩家就可以走进凉亭，但亭子顶部就不能站立。要么在顶部有碰撞，那么玩家就走不进凉亭，可以想象成实心的亭子。为了这个事情，不知道有过多少次争论，都21世纪了，还在用这么古老的系统，我们咬咬牙换了吧。但依赖关系一层叠一层，已有的服务器代码不舍得废弃，进度跟不上节奏，服务器承载会成为问题，到最后还是将就着就用了。
考虑到下次测试时间很近，留给我们的时间并不多。分头来看几个事情都是如何做的。
Paint the world with trees
填满场景光靠美术摆放物件肯定是不行的，地图太大。地形等都是预先生成的，能想到的办法，就是尽可能快的用树木来填充这个场景。笔刷等Editor工具都不细说，关键是树从哪里来。依靠外包肯定是不行的，太慢了。
以往做项目的时候，有项目用过Speedtree，还有些项目自己开发过树的组件，带有更好的物理交互。考虑到这个项目的时间周期，自己从头开发树木组件也不太适合，而且speedtree已经是一个完成度相当高的组建了，我们就从这个入手吧。
和speedtree授权方一通沟通，评估组件，发现真心好用，软件提供商也是真牛，一副爱用不用的气势，除非你付钱，否则不做技术支持。***的道理，speedtree价格便宜量又足，整个天刀的树木，就是一个美术同学制作的，产能效率很高，团队非常满意。
树木好了以后就往场景里面放，植物放少了，远处看上去稀稀拉拉，放多了，也并不好看。大家就很纠结，看看speedtree的demo，其实是有非常多的树木的，密度很高，但是游戏中放进这么多树，总觉得效果不够好。
老于表示就这样吧，广告和实物不一样的事情见多了，习惯就好。
开发树木的程序同学和美术同学觉得还有很大的空间可以提升，就一直研究其他同类游戏是怎么做到这么多植被的。他们做了两次尝试，在植被上试验不同做法，找老于来看过，都还是觉得效果不够好。眼看时间要不够了，老于说还是别试了吧，做正事要紧。这个特性就被压下来了。
大家还是心有不甘，在过了下一次测试后，这两个同学找了点空闲时间，又开始最后一轮尝试。重点解决效果问题。突破口在动态密度和边缘融合上。这次的尝试终于得到了良好的反馈，动态密度让远处的植被呈现出漫山遍野的效果，边缘融合让植被和地面的过渡效果更自然，得到了老于的认可。
后续还要解决很多问题，大量植被渲染的性能问题，由植被带来的阴影问题等，Streaming的问题等等，有些可以通过更好的美术实现解决，比如树木的叶片形状用polygon而不是quad标识出来，有些可以通过更复杂的系统来解决，比如阴影shadow map用分帧的方式来生成，有些通过更复杂的技术、美术结合来实现，比如streaming树木，既需要底层引擎针对树木做特殊streaming，也需要在美术层面指定每个关卡有几种最主要的树木，这些树木常驻内存。好在这些都是技术细节，并不太难解决。
每一个特性，加入的时候，都面临着和其他所有特性协同工作的挑战，需要体系化梳理一遍，工程化的难度也在于此，单独看都不复杂，完整起来看，还是有很多的挑战。
树木这个解决方案经历了两次测试才成型，我们起了个名字叫全景植被，视觉效果能和世面的一线产品相比，但物理交互等还是远远不如，留待以后解决吧。有了这个技术，美术同学可以用相对较低的工作量，在空旷的世界中画满绿色。场景的丰富度问题基本得到了解决，更好的是，植被密度提高后，这个特性本身就给整个场景赋予了不一样的价值，这也是技术能做到的最有价值的工作了。
|
|
发表于 2018-6-22 09:45:22
