|
|
文/顾煜 专栏：https://zhuanlan.zhihu.com/gu-yu
前言
离上次更新已经半年了。先是有个人工作方向调整，比较忙，想歇一阵子，当时并没没想过会要停更；歇着歇着，就没了力气，夜更长，事更多，人更丧，再不想更新。人世间的意外和惊喜，莫过于此。好在我迷途知返，熵增不由人，但总有当下，可以把握。
拖着不更新还有很大的一个原因，就是从这一篇开始，会写到更多的技术内容，这些东西不容易写得轻松有趣，这也是我迟迟无法落笔的重要原因。整个系列的方向，可能会从恶搞叙事，转向技术流水账，时间线也记不清了，可能有错乱现象。不纠结了，后面几篇，会更偏向程序员一些，聊一些技术上的判断和我们做过的取舍。
上回说到难得的一段修整时间，调整方向，招聘、重构等等。这篇会涉及到更多技术相关内容。
这次我们打算做一个完整一点的Demo，有稍大的场景，也要探索一下后续游戏发展的方向，无论是技术上，还是产品层面。
我们打算在半年不到的时间里面，做一个单人副本，有一个小规模的场景，有很多敌人，有数个boss，有两个角色，不同的技能。 相当于大规模Production之前的最后准备，完善内容生产线，增加新的特性，找到合适的需求。
对于更完善的生产线，有很多因素需要考虑，无外乎就是特性开发效率，内容制作效率，多团队协作效率，质量和品质控制等。
更快
要想富先修路，古老的道理指导着我们前进的方向。要想码得快，编译不能慢。程序团队在大规模开工前，先做了一件提升效率的事情：团购了一批SSD硬盘。
国内公司的理念，和国外公司非常不同。也许国外人力成本贵，也许国外竞争更激烈，也许国外电脑成本更低，我所见的几个游戏公司，都用着非常高端的电脑。比如在2000年进入UBI的时候，先领了一台PIII 700的电脑，512M内存，20’高端显示器，Voodoo 2 SLI的显卡。而我们当时的主流机器，也只是PII 400的水准，内存128M，17寸显示器。公司的工作电脑远超当时主流机器，这让我的工作和下班后的娱乐变成一种享受。
但换了公司以后，领完电脑大吃一惊，居然比自己家的电脑配置还要低，无法想象。大家对这一现象有很多解释，典型的解释就是用低配置电脑，就更接近用户电脑，程序员就容易注意到性能问题，保证开发出用户体验良好的程序。但这个对于游戏开发，其实是说不过去的。游戏开发有更多的工具，动不动就要用满内存跑编辑器和游戏，说不定还要多开，美术人员开个3DSMAX或者Photoshop又是大量的内存占用。性能总是不够用的，低配电脑浪费生产力，大把的时间都用在了等待编译和工具启动上。至于说配发低端电脑以便贴近用户电脑，确保性能不出问题，也只是自欺欺人，完全可以对有优化工作需求的同事，单独配发低端电脑，供他们调试使用。
于是公司在制度上打了一个补丁，表示低配电脑是办公用机，提供了额外的渠道，可以申请高配电脑。高配电脑性能高了不少，但还是消费级PC中还过得去的配置，算不上发烧级的电脑。
我们无奈的接受了公司的规则，但日常工作中，低配置电脑对编译、工具等带来的影响也是切实存在的。
在这个里程碑开始前，项目的规模已经慢慢变大了，第三方组件、工具集、sdk等源代码和开发库，拖家带口，住到了我们产品的Perforce，编译时间也慢慢增加，提高开发效率成为刻不容缓的事。
天刀开发的早期，tough哥满怀革命理想，表示做技术决策什么的最方便了，如果有两个不同的选择，我们吃不准，那就都做出来比较一下嘛。
早期的确有不少技术是这样做的，tough哥是工作狂人，他的生活中只有上班和睡觉，老婆和孩子应该都是充话费送的。大量特性是可以依靠拼死加班搞出来的，tough哥是一个永不疲倦的发动机，大喊着Charge，冲向无尽的Bug大军。当时项目规模小，迭代速度也非常快，客观上也助长了tough哥的霸气。
但做了一年半后，代码规模也在慢慢扩大，大家也不知不觉远离了大跃进的口号。开发效率逐渐降低成为一个头痛的问题。项目规模变大了以后，每次开发新特性，如何和旧有特性和平相处，成了一个新的课题，反复的迭代，编译需要的时间，也无法被忽略。
工作状况还是不容乐观的，没有额外精力去优化底层逻辑。因为要逐渐向量产转型，所以更多的资源都会被投入到开发特性上，没有办法做细致的提升。
SSD硬盘在那时候进入了大家的视线，据说可以极大降低寻道时间，进而影响编译、程序启动等方方面面，让电脑焕然一新。有感于内部流程繁琐，大家就自费团购了一堆SSD，我的项目我作主。当时SSD相当昂贵，64G就要1k左右，但提速效果极其显著，完整编译在传统HDD上需要38分钟，SSD编译只需要12分钟。Link时间和软件启动时间都有非常大的提升。换上电脑，生产力确实有了巨大的提高，心情也更好了。
更强
搞完硬件，开始抓软件，两手都要硬。这里聊聊动画和技术决策的问题。
在前两次的版本中，小方一直在朴素的动画系统上工作，管理起来各种不便，也缺乏足够的灵活度，一切动画逻辑都需要程序来写。而且早期的核心战斗迭代多，变化快，每次规划新版本，就是小方重写战斗框架的开始。这次他又面临进一步推翻的可能性，实在是吃不消了。
我们就开始讨论，有没有比较好的动画解决方案。
在第六篇中我们聊过天刀引擎的一些原则，其中一条是能用中间件，绝不自己写。具体到动画系统上来说，非不为也，实不能也，大家对怎么做一个高端的动画系统并没有太多的了解，于是我们就把目光放到外部，寻找可用的技术。
我们评估了一些技术，Natural Motion的Morpheme技术进入了视野。整套方案非常出色，考虑了美术制作和逻辑制作分离，两方面可以分开开发，充分解耦合，也有详实的案例，在动画制作上给了我们很多的启发。但不足也有，小方又要把自己做过的动画系统全部推翻重做了，而且整套方案非常昂贵，有一定的学习曲线，我们不确定动画同学能否掌握。
天刀开发过程中，好多次面对这样两难的选择，需要在信息不完备的情况下做出技术选择。我们能做的非常有限，先尽其所能，收集更多的信息，做更多的评估，权衡更多的利弊得失，降低整个技术方案的不确定性。然后总会有那么一个时间点，需要做出决定。往后看，是不堪回首的往事，小方的血泪，老于的挑剔，历历在目；向前看，新技术似乎做出了承诺，能解决所有的问题，天蓝了花开了，可以提早下班了。隐藏在迷雾深处的，是更多的不确定性。
信息不完备情况下的决策，非常依赖决策人的经验，有很大的风险，相当于一次赌博。如果人力资源充分，我们可以有fallback方案，一部分人尝试新方案，另一部分人继续做原来的方案，这样发现情况不妙还来得及退回原点。可惜当时并没有这么奢侈的团队配置，我们面临着二选一的问题。
没有必然正确的决定，项目的进度，已经没有办法进一步拖延了，我还是决定切换到新技术。好在这一次我们运气不错，morpheme引入后，很好的解耦合了动画和程序技术，管理起复杂的动画节点，降低了开发难度，也让动画表现更丰富。评估一阵子后，再三延迟评估周期后，我们终于开始走采购流程。
有了morpheme系统后，动画美术对整个流程有了一定的控制能力，拥有了自由度，只需要在前期和策划程序约定好动画的转换，就可以在后期独立微调动画表现，对动画间的transition也有一定的控制力度。程序层面也有了更多的自由度，可以把大量精力放在更高层的管理，而不用关心底层的具体动画实现。一定要说缺点的话，内存占用、性能等会比原来略差，在后期带来了一定的优化成本，加载系统也不够理想，数据零散杂乱，效率较低。好在runtime的全部源码都交付，有什么不满意，自己改就是了。没有什么是免费的，出来混总要还，把问题分化，从一个制作流程问题变成一个性能优化问题，并不是什么坏事，至少后者我们会更有把握，有资深程序员就能做好。
这是一次非常成功的尝试，虽然阵痛也不小。小方再一次重构所有的动画体系。这个级别的重构，和软件工程中讲得重构还不太一样。软件工程中说的重构，往往有完善单元测试保驾护航，做点代码调整，让结构更合理，以便提升质量以及未来维护效率。我们这个重构，其实是重做，只是为了照顾小方的情绪，我们勉强说是重构。
所有的巨大调整，都会伴随着流程重新梳理。美术开发突然发现自己光给出动画不够了，还要去图形化逻辑界面调整节点和参数，程序突然发现不能硬编码了，什么动画在做之前都要和策划、美术有完整的约定，策划突然发现有时候也要去看看动画，配置点动画参数了。新的工作，意味着新的分工，新的疆域，模糊了以往的界限。开发者们努力重新适应流程，能完整使用起来整套流程，已经是很久以后的事情了。但即使如此，在开发的当时，切换动画系统依然给我们带来了巨大的好处。
题外话：数年后，惊闻mopheme不再对外授权，也是一声叹息。好的技术，并不足以支撑一家小企业活得滋润。我们看见了太多中间件和引擎的陨落，比如scaleform，比如simplgon。新一代的中间件崛起，发展，然后没落，生生不息。残酷的生态，诅咒着开发者，凡你会的，必会消亡，终身学习是躲不开的宿命。
|
|
发表于 2018-3-9 14:49:59
