《大话西游》手游主程：失败了，我们能做什么？_游戏陀螺

本文由网易游戏学院授权发布

导读：我们很多人都会遇到瓶颈期，在工作一段时间之后进入这样一个状态：把日常工作做得很熟练，非常了解业务，但是觉得很难再有提高，总在做重复性的工作。这个时候我们会很焦躁，想要改变，寻求新的突破。但其实这并不容易。当我们遭遇瓶颈的时候该怎么办？大话西游手游又是如何获得成功的？本次，大话事业部资深软件设计专家波波，结合不同项目时期的经历，讲述对技术的理解。机会、挫折、迷局，为大家分享大话西游IP开发一路走来的历程。 以下是分享实录：

作为一个老司机，今天想跟大家聊个有关职业发展的话题。先跟大家分享一下职业经历：三个对我影响比较大的小故事。**1. 重来，一定能更好吗？**2004年我加入网易，一直到2006年我都在做大话西游2服务端的开发。2006年的时候我觉得我已经对大话2的服务端掌握得非常熟了，对于各个模块的实现细节、各个技术细节都很理解，而且对它有非常多的不满，觉得它有很多设计不够好的地方。比如代码结构很混乱、编程语言很不主流、脚本虚拟机跟游戏逻辑的耦合特别紧密。我一心想着，要是有机会做一个新的游戏服务器的话，我要把这些全部改掉，我要做一个比大话2的服务器更优秀的游戏服务器。 机会终于来了， 2006年下半年，公司决定开始做大话西游3。

一开始我们压根没有想过复用大话2的服务端，全部重新开始。大家的意见非常统一，我们用了新的编程语言、新的场景管理算法，实现了新的存盘系统、新的协议系统，所有这一切都是我们自己的意愿，想着一心要做好它。而且我们相信已经绕过了大话2的缺点。做这些技术的东西大家都非常兴奋。后来做了很多自己觉得很有意思的东西：比如当年做了一个场景分层。大话西游3是一个2D游戏，我们在2D游戏里面做了两层，同一个坐标可以有不同的阻挡，比如一个桥，你可以从桥下过，也可以从桥上过。当时做出来也是很多bug，但是当时确实觉得挺好玩的，还做了一个Lua调试器，修bug通常的做法就是加一点log加一个Print，然后把运行栈打印出来看，就分析好了。不过当时的我们觉得这样太low、太低级、太原始了。大家更想要像GDB一样给Lua做一个调试器，后来也确实做到了，我们在Lua里面设断点，单步执行，在运行的时候去动态地修改内存。做完觉得不过瘾，还做了一个远程调试的功能，在游戏服务器上开一个端口，可以随时远程去调试。做这些技术性的东西很有成就感。 一年之后大话西游3上线了，跟大话西游3同一天上线的还有一个游戏叫梦想世界。梦想世界是用Python做的服务器，我们是用Lua做的服务器脚本。大家肯定会觉得Lua脚本比Python运行效率更高，但实际上在开服的第一天，我们不停地crash，而且我们单服的最高在线只能去到3000多人。当时是32位的机器、4G的物理内存，根本经不住内存泄露。

而梦想世界做到了单服6000以上的在线，而且一天都很稳定。也就是说我们信心满满、殚精竭虑、加班加点做了一年的东西，既比不过同行的新产品，也比不过我们之前一直吐槽的大话2服务器（那个时候大话2的服务端单服在线达到六七千）。这件事情其实让我非常难受，我们为什么会做得比预期的差这么远？可能最开始的决定就有点急躁盲目。 重来就一定能做得更好吗？**我们很容易去发现身边的东西的缺点，但是很难去发现它的优点。**也许当年大话2服务端确实有很多不足的地方，但是我们没有注意到它优秀的地方，也没有去继承它的优点。

**做一个新的东西的时候，有很多细节会很容易让你陷进去，**就像之前说的Lua调试器，做完后上线后可能一次都没有用过，但是它花了我们一个核心程序员整整两个月的时间。作为一个全新的MMO，大话3的开发过程是非常紧张的，我们只有一年的时间，两个月可以做很多事情了。这是我今天讲的第一个故事。2. 失败了，我们能做什么？ 做完大话3之后，我们很快又开始做一款新的免费游戏：大话西游外传。在做大话西游外传的时候再也没有像以前做大话3那么冲动，把代码全部丢掉重新写。因为时间关系只是简单做了些优化。

开发过程很顺利，一年后大话外传上线了，上线之后最高在线的成绩，对于一个免费的端游来说不是特别好。所以运营了一年后游戏的在线人数急剧下降，整个产品的业绩下滑非常严重，团队人员开始流失。其实产品业绩不好的时候，程序员是很迷茫的。通过程序的技术创新、努力，让一个产品起死回生，我觉得是不大可能的。但是如果什么都不做，看着它慢慢地衰落，也很难受。 所以当产品失败、做得不够好的时候，我们在做什么呢？能做什么呢？总结下来就是两件事情：思考和试错。

当你开发一个新的产品，或者运营一个大产品的时候，可能基于进度压力、稳定性的需求，你不敢在技术上有特别大的动作。但是我们那时候可以，我们开始去反思，从大话3一直到大话外传的这段开发经历，想法、设计思路、每一个模块的实现细节，哪些地方是做得好的，哪些是做得不够好的，**思考应该怎么去优化。**我们做了很多尝试，比如游戏做了跨服组队系统，不同服务器的玩家可以跨服组成队伍去完成一个任务；为了让这些跨服的玩家能够交流，同时还做了跨服的好友系统，不同的服务器玩家可以加为好友，相当于把一个个独立的服务器连成整个游戏世界。此外还做了场景的优化等等。我们是网易游戏最早开始用MongoDB做玩法的团队，那个时候MongoDB才出到1.8或2.0。游戏服务器性能也是一个很大的痛点，于是团队开始深入地分析游戏的性能问题，去分析Lua的源码，去尝试优化Lua的GC策略，做了非常高精度的profile等等。其实做这些技术性的工作有时候并不是产品的驱动，比如说在线人数、在线压力。其实那个时候已经没什么在线压力了，**当时只是想去尝试把它做好，但是也会遇到很多压力，甚至有时候你会需要很强大的内心去面对这些问题。**比如就有同事问过我：你们产品这样子了，你这样折腾来折腾去，能让它好起来吗？确实无言以对，因为确实没有好起来。从2008年到2013年，一直在维护大话西游外传，整整六年时间，不停地去做优化，不停去做这些技术性工作，最终它于2015年彻底停服了。**但是在整个六年的过程中团队的技术能力、运营经验、开发能力都得到了很大的提高。**这是我今天讲的第二个故事。3. 成功，是注定的吗？ 到了2013年，我终于又有机会去做一款新的产品：大话西游手游。

那个时候手游的开发条件其实没有现在这么成熟，对于做一个MMO手游其实也并不是特别有把握，包括客户端的效率、移动网络的稳定性、服务器承载能力。服务器性能在大话外传的过程中虽然做了很多优化，但其实一直没有接受过真正的检验和挑战。但是最终大话手游的开发过程非常顺利，从确定要做成一个回合制的MMO开始到它最终上线，只用了大概半年时间。而且大话西游最终做到了单服1.5万以上的在线。我们做了一个实时的存盘系统，任何时候服务器故障了，你只需要换一个服务器把游戏开起来，不用做数据迁移，也没有数据损失，程序员都不需要参与。此外还把游戏里面一些负载比较高的逻辑，比如战斗和场景管理，还有存盘，做成多线程，你可以任意配置多个线程去跑这些逻辑。现在大话手游的服务器已经是一个非常成熟好用的2D游戏的服务器解决方案了。 也许很多人会觉得大话手游这样一个有IP的产品，有这样的成绩是理所当然的。但其实我觉得并不是这样子，如果是这样，那之前做大话西游外传为什么没有做得很好呢？正是因为有大话3的经验教训，我们做大话手游的时候没有陷到那些技术陷阱里面去，没有纠结于那些技术细节。

**从程序上讲，这个叫做过早优化。**因为有大话外传的技术积累，团队后来几乎没有遇到过技术障碍，所有遇到的问题都有很成熟的解决方案。这是我今天讲的第三个故事。4、总结回到最开始的那个问题：当我们遭遇瓶颈的时候该怎么办？ 我们总会有把技术做得很熟练，觉得在重复劳动的时候；也总会有能力到了一定的程度 觉得很难再有提升的时候，这时我们应该怎么办？

其实这是成长的必经之路。我之前也很纠结这个问题，而且纠结了非常长的时间。虽然我现在已经不纠结这个问题，但是我也没办法给大家一个特别普适性的方法。但是我觉得大家可以换个角度思考下我们今天提出来的三个问题：**第一个问题：重来一定能做得更好吗？**我们总是会忍不住地有种冲动想推倒重来，从成就感上说这是很有吸引力的事情。但是当你做这个决定的时候你一定要想清楚，你对现在的东西已经足够了解了吗？你除了看到它的缺点你还看到它的优点了吗？对于做一个新的东西，你是不是真的已经完整地评估过它的风险？你确定能做得更好吗？**第二个问题：失败了我们能做什么？**游戏行业也存在着失败风险，有时候一个产品不好，不是策划、程序、美术做得不好，整个团队都很协调，大家也很努力，但是最后产品就是没成功，你该怎么办？你怎么面对这种失败的情况？**第三个问题：成功是注定的吗？**总是会有很多人做得很成功，有很多产品非常成功，但是它们真的是从立项开始的时候就确定了这个产品是会成功的吗？他们背后会有什么样的坎坷经历？希望大家在度过这个时期时，能够去思考这三点。以上就是我本次要跟大家分享的内容。最后以今天的主题：平凡之路，行者无疆，跟大家共勉，谢谢~关注微信公众号：游戏陀螺（shouyoushouce）,定时推送，游戏行业干货分享、爆料揭秘、互动精彩多。