《大话西游》手游主程成长自述——”平凡之路,行者无疆“

波波

2022-11-183094次浏览

4评论

5收藏

6点赞

分享

导读:我们很多人都会遇到瓶颈期,在工作一段时间之后进入这样一个状态:把日常工作做得很熟练,非常了解业务,但是觉得很难再有提高,总在做重复性的工作。这个时候我们会很焦躁,想要改变,寻求新的突破。但其实这并不容易。

 

当我们遭遇瓶颈的时候该怎么办?大话西游手游又是如何获得成功的?本次,大话事业部资深软件设计专家波波,结合不同项目时期的经历,讲述对技术的理解。机会、挫折、迷局,为大家分享大话西游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那么冲动,把代码全部丢掉重新写。因为时间关系只是简单做了些优化。

 

开发过程很顺利,一年后大话外传上线了,上线之后最高在线有15万16万左右。对于一个免费的端游来说,这个成绩不是特别好。所以运营了一年后游戏的在线人数急剧下降,整个产品的业绩下滑非常严重,团队人员开始流失。

 

其实产品业绩不好的时候,程序员是很迷茫的。通过程序的技术创新、努力,让一个产品起死回生,我觉得是不大可能的。但是如果什么都不做,看着它慢慢地衰落,也很难受。 

 

所以当产品失败、做得不够好的时候,我们在做什么呢?能做什么呢?总结下来就是两件事情:思考和试错。

 

当你开发一个新的产品,或者运营一个大产品的时候,可能基于进度压力、稳定性的需求,你不敢在技术上有特别大的动作。但是我们那时候可以,我们开始去反思,从大话3一直到大话外传的这段开发经历,想法、设计思路、每一个模块的实现细节,哪些地方是做得好的,哪些是做得不够好的,思考应该怎么去优化。

 

我们做了很多尝试,比如游戏做了跨服组队系统,不同服务器的玩家可以跨服组成队伍去完成一个任务;为了让这些跨服的玩家能够交流,同时还做了跨服的好友系统,不同的服务器玩家可以加为好友,相当于把一个个独立的服务器连成整个游戏世界。此外还做了场景的优化等等。

 

我们是网易游戏最早开始用MongoDB做玩法的团队,那个时候MongoDB才出到1.8或2.0。游戏服务器性能也是一个很大的痛点,于是团队开始深入地分析游戏的性能问题,去分析Lua的源码,去尝试优化Lua的GC策略,做了非常高精度的profile等等。

 

其实做这些技术性的工作有时候并不是产品的驱动,比如说在线人数、在线压力。其实那个时候已经没什么在线压力了,整个游戏才两万左右人在线,十几个服务器,平均一个服务器才一两千个人。当时只是想去尝试把它做好,但是也会遇到很多压力,甚至有时候你会需要很强大的内心去面对这些问题。

 

比如就有同事问过我:你们产品这样子了,你这样折腾来折腾去,能让它好起来吗?确实无言以对,因为确实没有好起来。从2008年到2013年,一直在维护大话西游外传,整整六年时间,不停地去做优化,不停去做这些技术性工作,最终它于2015年彻底停服了。但是在整个六年的过程中团队的技术能力、运营经验、开发能力都得到了很大的提高。这是我今天讲的第二个故事。

 

3. 成功,是注定的吗?

 

到了2013年,我终于又有机会去做一款新的产品:大话西游手游。

 

那个时候手游的开发条件其实没有现在这么成熟,对于做一个MMO手游其实也并不是特别有把握,包括客户端的效率、移动网络的稳定性、服务器承载能力。

 

服务器性能在大话外传的过程中虽然做了很多优化,但其实一直没有接受过真正的检验和挑战。但是最终大话手游的开发过程非常顺利,从确定要做成一个回合制的MMO开始到它最终上线,只用了大概半年时间。 

 

 

而且大话西游最终做到了单服1.5万以上的在线。我们做了一个实时的存盘系统,任何时候服务器故障了,你只需要换一个服务器把游戏开起来,不用做数据迁移,也没有数据损失,程序员都不需要参与。

 

此外还把游戏里面一些负载比较高的逻辑,比如战斗和场景管理,还有存盘,做成多线程,你可以任意配置多个线程去跑这些逻辑。现在大话手游的服务器已经是一个非常成熟好用的2D游戏的服务器解决方案了。 

也许很多人会觉得大话手游这样一个有IP的产品,有这样的成绩是理所当然的。但其实我觉得并不是这样子,如果是这样,那之前做大话西游外传为什么没有做得很好呢?正是因为有大话3的经验教训,我们做大话手游的时候没有陷到那些技术陷阱里面去,没有纠结于那些技术细节。

 

从程序上讲,这个叫做过早优化。因为有大话外传的技术积累,团队后来几乎没有遇到过技术障碍,所有遇到的问题都有很成熟的解决方案。这是我今天讲的第三个故事。

 

4. 总结

 

回到最开始的那个问题:当我们遭遇瓶颈的时候该怎么办? 

 

 

我们总会有把技术做得很熟练,觉得在重复劳动的时候;也总会有能力到了一定的程度 觉得很难再有提升的时候,这时我们应该怎么办?

 

其实这是成长的必经之路。我之前也很纠结这个问题,而且纠结了非常长的时间。虽然我现在已经不纠结这个问题,但是我也没办法给大家一个特别普适性的方法。但是我觉得大家可以换个角度思考下我们今天提出来的三个问题:

 

第一个问题:重来一定能做得更好吗?我们总是会忍不住地有种冲动想推倒重来,从成就感上说这是很有吸引力的事情。但是当你做这个决定的时候你一定要想清楚,你对现在的东西已经足够了解了吗?你除了看到它的缺点你还看到它的优点了吗?对于做一个新的东西,你是不是真的已经完整地评估过它的风险?你确定能做得更好吗?

 

第二个问题:失败了我们能做什么?游戏行业也存在着失败风险,有时候一个产品不好,不是策划、程序、美术做得不好,整个团队都很优秀,大家也很努力,但是最后产品就是没成功,你该怎么办?你怎么面对这种失败的情况?

 

第三个问题:成功是注定的吗?总是会有很多人做得很成功,有很多产品非常成功,但是它们真的是从立项开始的时候就确定了这个产品是会成功的吗?他们背后会有什么样的坎坷经历?

 

希望大家在度过这个时期时,能够去思考这三点。以上就是我本次要跟大家分享的内容。最后以今天的主题:平凡之路,行者无疆,跟大家共勉,谢谢~

评论 (4)

0/1000
网易游学APP
为热爱赋能
扫描二维码下载APP