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

一元

文/顾煜 专栏：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阶段。下一次，就是要对外见一下玩家了。