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