前文回顾
The world at your fingertips—天涯明月刀幕后22（优化）
项目的开始都是令人记忆深刻的，而开发的过程却是平淡乏味的。好比高速上开车，周围的景色一成不变，就容易疲累瞌睡。
天刀开发几年后，逐渐和玩家见面，工作的重心，也从怎么让人眼前一亮，变成了怎么把这一大摊子的内容都整合到一起，如何确保性能和内存，如何满足策划和美术的需求。
项目早期什么都是新的，新的挑战，新的团队，新的游戏；项目的中后期什么都是旧的，旧的代码，旧的数据，旧的流程。倦怠不可避免，需要一些技术的理想主义，给团队寻找高光时刻，给大家找到远方的挑战。
几次测试后，工具大致可用，策划美术开始狂堆内容，逻辑和后台程序忙着做逻辑内容。引擎团队也需要找点目标。
海洋和航行进入了视野。
之前说过，程序员喜欢做水。天刀最初的demo有水，但还不够好。几次迭代后就不再使用了，这次又拿回来重做。
长时间的闭关开发是最有意思的事情。做水也许是很容易进入心流的吧，每天看paper，对着数学公式瞎想，没有什么人打扰，闭关一个月，努力搞一些说出去外行听完一脸懵逼的功能，搞定可以炫耀，失败了也很难有人指责。技术是最好的壁垒，隔绝世间的喧嚣。
我们安排小谢去搞这个功能。一方面他是资深渲染，之前也有类似的开发经验，另一方面也和公司内部的职级晋升体系有关。
在腾讯体系内，对一个技术人员，技术级别晋升是一个很重要的事情。没有做过好的技术，就不容易得到专业职级晋升，这个容易理解。但在一个项目里，总有人需要做一些相对不难的脏活累活，这个就很纠结。
我们团队，为了平衡项目利益和个人发展诉求，一般的做法是脏活累活轮流干，有难度的挑战也轮流做。有时冲刺，挑战技术难点，做有亮点的事情，以便升级，有时做助攻，分担点琐事，辅助其他同事晋级。
这次轮到渲染小谢挑战一下高科技了。
海水渲染一直是一个很有趣的领域，各个前沿项目不停做出各种高端效果，发布各种先进算法，眼花缭乱。大多数算法核心都是基于快速FFT变化来做，加上各种tricky的技巧，做出其他相关的效果，浪花、浪的形态、水的折射反射、水在海滩的波浪等，都是需要一一解决的，充分展现了工程上的复杂度，是可以持续做很久的一个技术。
海水这部分，我们大量参考了刺客信条的海水系统。刺客信条4-黑旗中的海水系统给我们留下了非常深刻的印象，海水的表现、和天气互动、以及海水和船的交互，是当时最顶尖的水准了，也只有神海3后期的海水能超越，但那个又是略有不同的技术体系。
水的这一块持续进步中，也加入了各种参数，可以在统一的天气框架下调整天气表现，表达出狂风暴雨天气下的惊涛骇浪。
另一边，有了观感良好的大海，总是希望有些不一样的gameplay。既然大家都是刺客信条海战系统的深度爱好者，我们的第一想法自然就是做一个海战系统，这个能展现技术实力，有非常大的挑战，而且用各种违反物理常识的轻功在大海上跳跃和战斗，想想也是非常有趣的，应该可以非常出彩。
但难题接蹱而至。
最初的网络战斗体系，在位移层面，并没有考虑platform。也就是说，所有的位移相关的事情，默认都是发生在整个世界坐标体系下，并没有考虑人可能站在一个会移动的物体上。技术上倒是不复杂，所有的位移计算，都应该要考虑站在什么平台上，在这个例子中就是船上，位移要加上船的速度。但在这个接近上线的关口，我们却不敢做如此激进的改动。这个改动意味着所有的前后台逻辑都需要重新梳理，所有战斗体系中的位移要另行计算，多层移动的逻辑也要改变算法，技能中和场景的碰撞也面临冲击。更可怕的是，即使程序员有勇气去改，我们又怎么面对策划的大量数据，他们是不是需要重新配置数据，我们怎么面对玩家测试，已经有无数人测试过，验证过我们的移动体系，重新写一个，会有多大的冲击呢？移动模块是一个最基础的模块，改变实在太大。
当年多层碰撞体系，也是考虑到冲击过大，所以没有做真实物理碰撞，而是用折中的多层碰撞结构，这次的platform移动，相比上次，更是动摇了根本，实在下不了决心推翻重做。
项目大了，独立出自己的意志，裹挟着你的喜好，去向你不想的地方。理想和现实，总要有选择，我们还是选择了面对现实，收起不必要的幻想，先做点基础工作，把复杂留给以后。
既然如此，就只能做一个非常简单的航海玩法了。玩法本身不展开，大家可以随意吐槽，只说一下船体互动。
船的互动，是有一些文章介绍过的，刺客信条和神海的文章都有讲过如何做船和水的交互。简单说，就是在船下绑定很多probe，可以想象成一个虚拟的船，绑定了很多浮筒。每帧判断浮筒和水面的位置差，来判断船应该受到多少浮力，然后相应调整船的姿态。
但这工作真不是一帆风顺的。我们先让一个小杨同学去开发这个模块，当时离上线只有3周不到，我判断这个功能并不好做，如果来不及做好，老于又要动刀砍特性了。
偏偏越着急，越容易出问题。小杨做啥都挺给力，但做船就是没找到感觉，半天没有好的效果。船体和水的互动，一直有奇怪的问题，都谈不上什么物理规律，最基础的观感就不对。
实在来不及了，又过了一周，再搞不定，就真没法上线用了。咬咬牙，又拉了个壮丁，叫何老师一起来搞。
何老师是一个骨骼清奇，身躯微胖，脑洞大开大合的程序员。早年和我初识，天天魔兽3单挑，连赢我几个月。然而办公室里面回荡的一直是他的惨叫，天天哭喊着不行了要打不过了，不明真相的群众以为我又虐他。好事者过来张望，何老师一边喊着救命救命，一边指挥部队在我基地中拆迁违章建筑，驱赶采矿农民。
合作多年，对何老师有足够的信任。岔开话题，稍微谈几句，从占用leader的管理精力的维度，我怎么分类程序员。我们把能不能独立工作作为一个维度，需不需指导作为另一个维度，就可以看到有四类程序员。大致分为：不能干活不需要指导，不能干活需要指导，能干活需要指导和能干活不需要指导。
最低级的类别，不能独立工作且不需要指导。这类同学只能给最简单的工作，也没什么潜力，指导的念头都没了。
稍好点的，不能独立工作但需要指导。这类同学已经有不错的能力，但由于时不时需要leader投入一定的关注，而在一个大团队里面，leader的精力永远是团队的瓶颈，所以这类同学有价值，但团队里面如果这类人手太多，项目规模是很难扩大的。
更好点的，是能独立工作但需要指导的。这类人需要有简单的方向指导，就可以交付很好的成果，定期汇报成果，不用太操心做不出来，就是进度上要操心一下。
最好的，就是能独立工作且不需要指导的。你发现团队有啥搞不定，扔过去让他搞定即可。也不用管太多，对他有充分的信心，可以近似认为，如果他也没有搞定，那很有可能这个特性换了谁都没有办法搞定的。
最后一类就是预研的技术终结者，他一出手，要么功能做成，要么彻底失败，再无回旋余地。
何老师就要担任这样一个技术终结者。他做完奇葩的多进程加载，又喊着：不行啊、太难了、搞不定、要被开除、老板饶命啊，勉勉强强接下了烫手的热山芋，一起来开发船和水的互动。
几天内就看见了明显的改善，挑剔的老于也觉得，有希望，这个特性可以有。何老师又继续努力了一周，差不多把这个特性做进了版本，船终于可以在海上航行，随着海浪，一起摇摆。
我也已经记不清具体他是怎么解决问题的，这不就是feature teminator的价值所在。项目中有太多细节需要leader操心，如果有人能让我减少关注，且依然能安全交付feature，我就可以把精力放在更危险的领域，更好的确保版本的安全。
BTW，知道大家又要吐槽航海玩法单调，枯燥乏味，没有好好利用功能。但从这一篇来看，策划也很不容易，航海不仅仅他们的问题，技术层面依然有很多不容易解决的问题，也许值得另外起一个项目单独解决。
知乎专栏 https://zhuanlan.zhihu.com/gu-yu
Steam 
App Store 
闽公网安备 35020302034348号