GameRes游资网

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

The world at your fingertips — 天涯明月刀幕后11(首秀)

[复制链接]
发表于 2018-4-16 08:48:55 | 显示全部楼层 |阅读模式
01.jpg

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

前文回顾:The world at your fingertips — 天涯明月刀幕后(10)回收

新特性还在紧张开发中,每一个版本节点,都是好机会,往版本中塞入诚意和野心。

但时间毕竟是单行线,飞驰而去,太多特性错过了班车,太多挣扎无处安放。总该要抉择和决策,挣脱包袱,轻快上阵。看两个特性的例子,有些是无奈被放弃的,有些是退无可退终于搞定的。


光照

之前的版本,阴影暗部缺乏光照变化细节。

渲染程序员永远有几个怨念:想做一次引擎,想做一次高质量的水,想做全局光照。Tough哥当然也不例外,眼看光照变化不够理想,当然要祭出全局光照大旗。我们商量了一下,他开始做Irradiance Volume的系统。

整个系统工作量较大,而且更致命的是和Editor开发绑定在一起,当时小李也在拼死写编辑器中,烘焙相关的部分只能让Tough哥自己上了,由于各种前后依赖关系,导致进展比较慢。

为了在后续的汇报中能拿出一个可用版本,Tough哥天天加班到深夜,就为了早点能把功能实现,终于做得差不多了,美术开始把这个系统用在了刚开发不久地图上,于是发现,烘焙一遍的时间超长,达到了数个小时。常常是晚上下班回家,把电脑留在那里烘焙光照,第二天早上满心欢喜跑来看最新的结果,然后就发现电脑崩溃了,一波crash带走了editor,也带走了美术的脆弱的心。

Tough哥抓紧优化性能,提升稳定性,但离版本截止时间已经不多了。老于review了版本,觉得这个迭代速度实在无法接受,当时的地图还不大,只有512x512米,已经如此之慢了,以后如果要做大地图,时间完全无法接受。老于又用力看了效果,如果努力看,可以有肉眼可见的细微区别,但不留心看,也没什么不同。这个特性的边际效用递减了。在大场景的室外,新系统的确有优势,但不那么明显,而它的劣势,包括更大的复杂度,更低效率的迭代速度,实在无法让人接受。

团队还在努力优化版本,提升效率,改善工具。所有的特性发出了绝望的冲刺,和里程碑节点做最后的拼搏,想要挤上末班车。但努力不一定会有回报,老于做了一个决绝的决定,还是砍了这个特性吧,马上要封版本了,一切为大目标服务。

技术和产品理念的冲突又一次出现,从技术的角度,更好的技术是未来的趋势,但在没有优化好之前,对产品并不会有帮助。产品里程碑不等人,滚滚向前,碾压一切的不甘心和不情愿。不抓紧搞定下一个版本,今后是不是还有机会继续做下去都是问题。

本来觉得还是有机会在将来把这个特性弄回来,如同很多其他先装死的特性,我们终究能后会有期。但后续团队进一步做了时间变化等特性,发现要不要拿回这个特性,似乎也不太重要了,于是这个特性就安心的在P4的深处不甘心的闭上了双眼。

Streaming

之前的Demo,内存管理比较随意,虽然对象生命周期还是控制很好,但是整个地图我们是一次加载进内存的,并没有做大地图的按需加载和streaming系统。

在规模比较小的游戏中,一次加载所有关卡内容是可行的,但对于大型游戏,或者MMORPG,内存并不足以容纳所有的关卡数据,我们需要做的,是一个按需加载的系统,根据玩家的位置,把他周围的场景全部加载出来。同时,磁盘的IO是非常慢的,还需要合理的进行处理,使用多线程之类技术在后台加载,在合适的时候才使用加载完的数据创建对象。

这次demo做着做着就不行了,内存已经逼近32位程序的2G限制,我们用了OS的补丁,可以用到3G内存,但将来给玩家打补丁也是一个很麻烦的事情,而且这些功能本来也是引擎必须的。

程序员白白刚入职没多久,就把这一坨事情接过去了。对象生命系统比较复杂,也要考虑物件没有加载出来怎么办,如果有现有的场景物件需要引用那个对象要如何处理,如何减少加载和创建对象时候的卡顿,销毁已有物体如何确保安全等等琐事。

时间是非常紧张了,还有3周不到,我们才开始做这个功能,要把它做稳定,打磨优化好,时间是不太够的。

程序员的命运,就是和时间赛跑,项目机器已经开动,驾驶员老于已经踩下油门,每一个团队都像轰鸣的引擎,嘶吼和咆哮着,榨出最后一份能量。

技术团队大了以后,管理变得心累,很多时候不知道大家能不能搞定,心里没底,但又不能自己一起上,上了也是添乱。这个系统并不容易,如果是压力不大,慢慢做,肯定也能做好,但当时的情况,谁也没有把握能够准时搞定。每一个特性,每一份数据都在那时候被整合,所有人商量好了一样,同时提交着改动,让整个特性的开发变得更糟糕。

白白之前工作中的合作不多,能不能搞定呢?我手里捏了一把汗。如果搞不定,意味着我们可能要美术减内容,大量项目不就是这么做的么,程序搞不定,美术缩贴图,但凡搞不定,数据制作人员上去拼体力。美术的体能,永远是项目最好的Plan B。但我们不希望这样做,美术永远是我们最坚强的退路,在让他们拼死加班前,也许我们还可以做些什么的,这不就是程序员的价值所在么?

时间紧,老于催,对外CE的准备都在筹备,后悔药是没有了。硬着头皮打算自己也上去帮忙,好在白白不负众望,在最后一刻把整个系统跑通。美术们长出一口气,终于不用加班加点,重新制作更低品质的关卡。

整个关卡跑通了,没有内存泄漏,来回走了几轮,还算顺畅。

首秀

Demo逐渐成型,我们把各种片段拼在一起,用新的编辑器,做了新的地图,完善了关卡的流程,有一些简单的任务界面,部署了很多敌人,做了一个Boss,做了两个职业,加上了轻功。

玩了几轮,还是有一定乐趣的,一场杂兵战,一场精英怪战斗,一场boss出场前的杂兵战,最终进行决战,有点跌宕起伏、精彩纷呈的意思,画面也不错,首次Demo的动态水,技能与水的互动等等基本都保留了。

一定要给这个版本下一个定义的话,我认为是一个中间性的技术版本。当时还是一个单机版,后台技术并没有整合,技能等还是单机运行,即使我们有一定的架构,考虑到客户端服务器体系,但毕竟还是不完善的。开发的工具集开始摆脱原有引擎架构,使用我们新开发的编辑器,内部各种不顺手的内容被剥离,新的引擎核心确立,以全新对象结构组织起的引擎流程,外加全新的渲染流程,缺失的模块被一一补上,虽然打磨还不够完美。

产品的方向也不能一直尝试,我们打算做一次用户调研。腾讯内部有很完善的调研流程,请用户,玩产品,收集意见,改善产品,构成了一个完整的Loop。

终于要见一下用户了,我们在一个周末找来了一些用户,签署了NDA,安静的开始看他们玩。时不时也和用户交流一下感受,听听他们对游戏的理解,了解一下他们的抱怨。

用户整体还是好评居多,在那个年代,网游的战斗还是以你一刀我一刀为主,喊着招式名称,站桩互砍,播放着蔑视物理规则的夸张特效。我们的Demo简直就是一股清流,含蓄内敛,尽量弱化特效,用动作本身交代战斗,试图往更动作游戏的方向靠近。

少数用户不习惯玩3D游戏,也出现了操作不顺利的情况。擅长玩的同学打完了一遍,又愉快地开始刷另一个职业。

体验完demo,开始和用户交流,有一个问题非常有趣,用户提出,这个游戏画面、表现都挺好的,我想到一个特别适合你们的IP,我觉得笑傲江湖很适合这个产品。

一听笑傲江湖,我们就觉得用户暴露了自己的年龄,只有70后或者早80后才有可能知道这个名字啊,虽然这个名字是如此的如雷贯耳。

用户还沉浸在自己的遐想,不觉自己的言语已经把自己无情的出卖。

我们只好打断了用户:笑傲江湖IP早卖完了,在某公司手里啊。

用户好心的补刀:你们可以和他们商量商量嘛,让他们把IP让给你。

唉,感谢可爱的用户,但商业没那么简单啊。看王老吉和加多宝的风波,IP之争就在我们身边;看google改成谷歌,无数白领怒刷存在感,表示乡土气太重;看麦当劳改成金拱门,从音译改向形译,也是一大创举;看AirDrop改成隔空投送,浓浓的武侠风扑面而来。是时候给微信团队提个建议了,发个语音消息也应该改名传音入密。

圆满结束了CE,又是一针鸡血,看见了玩家的认同,大家都心满意足,再多的疲劳,再多的撕扯,相比玩家的反馈,那都不是个事。

评审

后续需要给老板们做新一次的工作汇报了。

在这个汇报前,还需要和策划、美术、程序等各个领域的专家做一次汇报,看各个领域的技术实现质量如何,做一次技术把关。

程序评审竟是出奇的艰难,在那个时间点,天刀的高技术成果还没有,都在搭框架阶段,从整体的画面和特性来说,很难解释为什么资源占用开销那么大。

评委们纷纷挑战,表示内存占用这么多,性能开销那么大,玩家机器跑不动啊。我再三表示,目前的确是很多,但这个只是Demo,我们并没有开始优化,整个团队在优化上非常有经验,我们后续会搞定的。

所有的承诺都是不靠谱的,除非你先做到点什么,评委们显然是久经风浪,他们并不信你。见多了那些在初次评审时候狂堆美术资源,在后续版本中暗暗缩水的项目,大家都懂得人世的艰难。但在那个时间点,我们确实也没有办法去优化。

我也是程序员中扯淡的一把好手,虽巧舌如簧却不敌世俗的偏见,很无奈,最后被评委们打了个黄灯,表示性能这里是有很大风险的。

但我们也不纠结,这一块真的不是大问题。团队中的成员曾经多次把高端主机的游戏,移植到性能更更孱弱的主机,只要有时间和精力,这都是可以做到的。

年底的时候,我们就拿着用户CE版本,外加少量Bug修复,走上了去总部的路。照例还是搬电脑,只是这次用上了新的Renderer,性能高了很多,只需要稍好点电脑就能运行。照样还是临时抱佛脚,在汇报前一天的晚上,还在深圳办公室遥控上海的同事们改Bug做版本。

关于发布版本,常年从事主机开发,团队还是养成了很多好习惯。比如我们发布重要版本之前一定会想办法做Content Freeze,封闭P4的权限,只有有限的改动才能上传,并且每一个上传都需要有专业人员的Review;再比如我们会规划几个Release Candidates,就是候补发布版本。每一个版本拿过来看一下,如果是一个质量还可以的版本,我们就会保存,定义成可发布版本候选,也有专门的版本号跟踪。当然每个版本都不会完美,我们还是会有很多意见,需要同学们进一步修改,但这个Release Candidate版本是我们的底线。任何时候都要留有底线,以备意外发生,我们随时可以知道,能拿出去的版本有什么问题。在开发人员修改版本的时候,测试同学继续测试最好的那个release candidate,尽量发现更多的问题。忙到最后一刻,我们手头就有一堆发布候选版本。我们再酌情选择一个对外的版本,公布出去。

虽然忙,但不乱,上海改一个bug,我们就相当于赚了,就算没改,也不是不能接受。

汇报,是工作的延伸,只要其他工作做到位,就没有太多的问题。我们很顺利通过了评审。进入了Production阶段。下一次,就是要对外见一下玩家了。

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

本版积分规则

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

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

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