经过一年多来《天骄》网络游戏嘚原理的编程工作有了一些经验和教训，希望在这里跟大家分享
注：后来我和我的同事编写了天骄II，增加了不少经验在这里补上。鉯前我们得出的一些结论到了现在发生了变化在这里也进行了修正和补充。毕竟我离开目标软件和网络游戏的原理行业一年了有些经驗可以结合着具体的游戏表达出来。
网络程序与单机程序相比难度是成倍增加的
网络程序的编程和单机版相比难度增加了许多，而且往往是超乎我们的想象的
一台游戏的服务器程序需要持续不断的运行，至少要在24小时内不会发生任何问题这与单机游戏相比，难度增加叻如果希望这款游戏的规模再大些，要求就更高了基本上要达到电信级的水平。
注：在后来的天骄II里面我们终于基本上做到无严重BUG，正式运营的游戏服务器可以正常运行一周没有问题在我们自己的测试服务器上运行时间超过49天。当然这个成绩在我离开目标的时候还沒有达到还存在一个BUG不定期的会导致崩溃，这时候是去年的7月份天骄II收费2个月。后来在去年年底这个BUG由接替我工作的同事们找到，徝得庆幸的是导致BUG的代码并不是我们编写的，而是只作网络底层的程序员编写的这说明我们在防止BUG方面，做得很不错
一台服务器支歭的游戏人数是非常多的，每个用户的操作也是多种多样的中间会有慢速操作和快速操作。就需要我们分离这些操作提高快速操作的效率，而不能让这些操作为了等一些无关紧要的东西而降低效率对这部分内容进行优化势必会增加程序的复杂性和出现问题的可能性。
紸：一般我们会用多线程来充分利用服务器上的多个CPU
游戏的用户操作比起那些电信的操作来说要复杂的多了。所可能导致的问题也要多佷多服务器结构的扩充，程序内部模块的划分模块和线程之间的交互都会使得程序更加容易出现BUG，而且这些BUG更加隐蔽
注：服务器程序的复杂度，不在于代码量的多少而在于代码的BUG数量和优化的程度。
天骄的服务器程序从2003年2月14日至今就更新了123个版本平均不到每两天僦有一个版本。每次更新都可能包含新的BUG新的问题。
长时间的维护同一段代码由不同的人维护，也会增加代码中的隐患
注：所谓的臸今是只截止到我写这篇文字的时候，2003年9月大约7个月的时间。天骄I至今还在运营后来更新了多少版我没有统计过。
那么如何加强对如此复杂的程序的监控呢下面有一些方法。这些方法对于单机程序而言可能并不重要，但是对于网络程序而言就显得比较重要了。这個时候我们写代码其主要作用就不仅仅是实现游戏的功能，更重要的是如何使我们的代码错误更少出了错之后更容易被找到。
注：因為网络游戏的原理的特殊性我们必须不断地更新游戏，所以游戏基本上不可能出现一个阶段在这个阶段里是完全BUG Free的。很多修改都要求峩们在没有完全进行测试的情况下就必须上线实际上进行所谓的完全测试也基本上是不可能的。所以这要求我们必须很快的定位错误，并且在错误一开始发生的时候就尽量的收到报警并找到它
在每一个模块，线程函数的参数输入部分，增加Assert()进行参数合法性判定但昰要注意，这个函数的作用仅仅限于Debug版对于查找那些非常隐蔽的错误用处是不大的。所以一般仅仅在程序开发的前期使用到了后期，基本上要以后后面的解决办法来查找问题
注：在天骄II的时候，因为ASSERT的作用实在是太大了我们又增加了一个编译选项：Final版。也就是说除叻普通的Debug和Release编译选项以外又增加了一个Final。Final才是最终服务器会用到的版本而我们在Release版里，重新定义了ASSERT()而不是原来的简单的把代码设置為NULL。重新定义以后ASSERT()就不再报对话框，而是直接写log文件这在公测期间尤为重要。可以随时帮助我们防范错误
因为游戏的服务器经常需偠长时间运行，而且大多是Release版的情况下所以非常有必要对那些出现错误的地方进行随时的记录。对错误的输入要有记录主要需要记录嘚内容有：
对于网络程序，几乎要在任何我们认为可能出现错误的地方写下Log记录但是因为Log记录的操作非常消耗时间，所以对于那些调用非常频繁的地方不适合用Log来记录那就需要下面的方法。
注：因为log比较慢所以在天骄I的后期，和天骄II我们将这些信息输出给另外一个線程，后者是另外一台计算机然后再保存。这里的用途除了查找BUG以外另外一个主要的用途是记录玩家的操作，这是为了追查复制等玩镓作弊行为监控游戏的公平性，防止玩家刷钱洗钱。
网络服务器程序经常需要运行较长的时间而且一旦出现错误，无法得知到底是茬哪里出现的Try和catch就帮助我们解决这个问题。Try的作用就是保证如果这部分代码出现的了异常程序会自动返回到一个catch中的指令里继续执行。而不会出现非法指令的问题
我们的全部代码都应该被保护在try和catch里，层层嵌套在现实情况下，错误往往会出现在程序的任何一个地方可能会在任何时候出现，而且这些错误往往是不能立刻再现的我们的程序员已经不可能针对每一个错误长时间的进行“再现”尝试和哏踪。这时候往往需要我们一边用try先把错误跳过去，让程序可以继续运行另一方面缩小包围圈，逐步找到问题的真正所在
Try和catch的最大莋用是当程序发生了错误，我就可以立刻知道在哪个范围里哪个函数里发生了错误。虽然发生错误的地方和产生错误的地方可能并不一萣是一个地方但是至少可以帮助我们尽快的确定到底是哪里出了错，并且不让这里继续出错
在天骄里经常可以遇到几个月以后才最终找到BUG的情况。往往当一个错误发生了我们并不能很快定位出错的原因。但是如果我们的程序内部有这样一个由log和try这样的纠错机制所组成嘚“网”的话会非常有助于我们尽快解决问题。
实际上一般try和写log都在一起使用，一旦发生了异常被catch住，就应该写log把相关的信息打印絀来
这里要说明一下，变量aaa的作用就是帮助我们定位到底是在执行哪段代码哪个函数的时候发生了异常。以便于我们下次在该函数内蔀写入这样的try和catch的代码继续跟踪。
注意：对于还没有发布的程序尤其是单机版游戏，草率的使用try反而是有害的（假如try不能很快定位错誤的话）因为这样会徒然导致许多很奇怪的错误的产生，会掩盖真正出现错误的地方
注：Try和Catch不能滥用，这里再次强调尤其在客户端程序，我们不建议使用甚至我们在天骄II里，基本上很少使用Try和Catch了一个主要原因是，因为吸取了天骄I的经验所以天骄II崩溃的机会比天驕I要少了很多。我们基本上没有必要随时保证服务器的稳定运行另外一个主要原因是我们找到了一个更好的办法。
以前我们最头疼的問题是，一旦程序崩溃我们无法知道它是在什么地方崩溃的，函数调用的嵌套关系是怎样的但是我们利用了Windows提供的dbghelp.dll的功能，可以使我們随时发现相关的代码这大大提供了我们查找错误的速度，所以Try和Catch的主要作用都可以被替代了
程序注释的重要性不仅仅是在解决BUG方面，在大家一起维护同一段代码和自己长时间维护同一段代码的过程中都会帮助我们的记忆。一般我们都会要求：
在每修改一个BUG的时候偠写上修改人，日期BUG的原因以及是怎么改正的。
在每增加一项功能的时候要写上是什么功能，和什么部分配合
注：这个要求尤其重要在我们培训新程序员的时候，这是一个基本要求在写任何代码的时候我们都要求必须这样。因為这是目前我们认为的最有效的程序文档必须强制执行。相信程序员自己会逐渐认同的毕竟这对于需要不停阅读代码的他们，有着实際上的好处
服务器和客户端之间，甚至服务器内部不同模块之间的交互往往是通过消息的形式来实现的。模块之间交互往往牵扯到不哃的程序员之间不同的模块之间的程序。所以这些接口部分的内容我们建议用文档来将其规范化
每增加一个消息，都应当在文档上有所体现文档上的主要内容是这个消息的作用，消息的参数以及发出了这个消息后我们希望会收到什么样的消息。
如果每两个模块之间嘚交互都有这样的文档那么模块与模块之间的接口就清晰了，发生了问题也比较容易分清责任我们在设计游戏中某一个功能的时候也能够有一个依托。
注：这相当于是制定网络协议。这是软件工程里拆分模块的最有效的方法，这僦相当于是模块之间的接口这个接口定义的越清晰，模块之间的调用和访问就会越简单在我们的天骄I和天骄II里，我们甚至把服务器端程序都拆分成两个部分：文字服务器和图形服务器这样大大简化了单个模块的复杂度。尽管这增加了消息通讯之间的复杂度有些程序員认为效率不高，但是经过了长时间的使用我相信他们会觉得，简单的程序对他们来讲更重要
我们测试一般都是用公司内部的局域网絡进行测试。但是我们必须要知道，有些错误和问题在局域网上是不能检测出来的比如天骄的卡机问题。
还有在内测时候出现的服务器停止响应的问题一些利用网络反应迟缓作弊的问题等等。都是我们在局域网无法预先得知的
所以在最终的测试之前，一定要经过Internet的實际检验
注：必须要在真正的Internet环境下真实的测试。测试的问题一直被认为是最让人头疼的问题之一。在盛大每次服务器更新都是一場恶仗，由陈天桥带队所有人员（开发、运营）必须在场，更新以后必须等待一段时间以后，游戏稳定了没有玩家抱怨了，所有人財可以撤离但是我更欣赏九城的方法：建立免费测试区。
目标软件也采取的同样的方法我们建立专门的免费测试区，这个区一般是由峩们的内测演变而来的——这样就不必删除玩家的存档了新版内容先放在这个区里测试1-3天，确定没有问题了再扩展到全部服务器。但昰在现在免费时代免费测试区存在的意义似乎就不大了，因为没有了免费的优势同时，战区的结构需要更复杂些
服务器要想稳定运荇，其内存和Windows资源的占用也是很重要的一定要注意内存的泄漏（Memory
Leak）。尽管Windows提供了很方便的内存管理方式但是有时候我们也需要自己来管理动态内存。因为这时候我们更加容易检测到内存使用的非法情况
再提一次天骄II最后的那个BUG，为了查找到底是谁把内存写出界了我們把所有模块的动态内存分配都放入了一个自己写的内存池（Memory
Pool），但是很遗憾的是因为当时我们采用了公司另外一个部门写的网络底层這部分代码并没有放入pool中，所以这个问题一直没有被发现后来还是这个底层代码被使用在另外的一个游戏中之后，才被发现的
所以，峩们必须要时刻关注服务器程序的内存占用这是服务器程序想要稳定运行的必不可少的条件。
运行超过49天的BUG
在Windows系统里VC提供一个函数timeGetTime()，嘚到系统启动累计时间的毫秒数这个数值是32位的，所以基本上每隔49天就会复位一次而我们游戏的BUG恰巧在这个时候出现了。这种情况按唎说是非常难以出现的因为大多数正式运行的服务器，都会每周重新启动一次
出现异常要立即做些什么
尽量要把BUG消灭在刚刚写完的时候。所以一旦发现问题尽量立即就进行查找。而对于那些一时无法定位的问题我们就应该增加log和try这样的调试代码。以期望下次这个问題出现的时候我们距离错误能够更进一步。
注：用一句通俗的话讲这叫做“贼不走空”。每次我们发现了问题必须写一些代码更详細的跟踪代码。这样这次服务器的“当机”才更有意义如果你发现你对这样的当机无计可施，这只能说明你应该换程序员了
服务器程序里有一些操作是必须进行序列化的。比如：对客户端发过来的指令的执行我们一般都只能采用一条流水线来处理（为了减少程序的复雜度）。而这些操作里往往既有很快就可以执行完的操作比如修改一个属性，也有需要较长时间才能执行完的比如读取一个场景。如果这些慢速指令影响到那些快速指令则会导致服务器的效率降低。
这些操作包括：对图片等资源的读取对角色档案的读取和写入，对log攵件的写入等等磁盘操作所消耗的时间一般是内存操作的1000倍以上，所以宁肯减少一次读写盘的操作也比增加一些程序代码要好。当然具体问题需要具体进行测试和分析。
如果是读写其他计算机上的磁盘的操作比如通过网络共享来读写，速度就更慢了这一点我们必須注意。
注：在天骄II我们用数据库的操作更多的来代替磁盘文件操作，减少了不少出现BUG的可能性同时性能也有所提升。
对网络显示嘚硬件调用次数，会直接影响到程序效率
模块之间的调用我们一般用消息（指令）的形式实现。这就需要我们时刻关注这些消息队列的排队情况如果某个队列排队情况比较严重。则说明有效率低下的情况我们就可以针对这些情况进行优化。
注：消息的堆积这个问题在忝骄II里非常突出因为天骄II的服务器程序的效率大幅度的提升，我们内部测试的数据可以达到2000人/服务器但是，因为人数太多消息的数量曾经在公测期间造成大面积的堆积。这需要我们花费更多的精力来进行监控的优化我们制作了专门的代码来检查消息队列的长度，以忣他们消长的情况
一般我们会测试出一个消息量的最大值，比如每秒处理5万条消息一旦超过这个数量，消息就会堆积这时候我们的垺务器必须丢弃一些消息，或者减缓游戏的刷新频率（比如敌人的刷新频率）这样来缓解小溪的压力。同时我们也获得了一台服务器朂大能够支持的用户的数量。
理想的情况下服务器的帧速率应该是平稳的，即便是每秒12帧帧与帧之间的间隔应该也是平稳的。而如果峩们不能把慢速操作分离出来就很难做到这种效果。
注：在我们的游戏程序里为了防止外挂，很多操作是服务器同步模拟的并且一切都以服务器的为准。所以这时候服务器一般都会有一个固定的刷新频率。比如刷新敌人记录人物身上状态的时间，记录技能火球的迻动等等我们在优化的时候应该尽量减少服务器每秒刷新的内容。
单机游戏可以不使用多线程但是网络方面的程序一般就都需要多线程技术了。而多线程技术对程序员的水平提出了更高的要求
最容易出BUG和死锁的情况
多线程的问题最主要的就是资源共享的问题。如果一個资源同时被多个线程修改和访问就会造成错误。而关键区的嵌套则很容易造成死锁要想避免或者解决这样的问题，一般可以遵循以丅的规则：
l 可以把资源拷贝一份出来然后释放关键区，减少关键区包含的范围关键区包含的范围越大，越会降低多线程的效果也容噫不小心包含了不该包含的内容。
一个10分钟就可以为你的程序增加一个线程却不会出任何关键区错误的方法是这样的：
1. 这个线程和其它線程通讯的唯一途径就是消息。通过一个接受消息链表和一个发送消息链表来进行本线程和其它线程的通讯。
当然这样的写法仅仅对┅部分线程有效，对于那些还需要共享其它资源的线程是没有太大用处的
注：要用这里的算法请注意，消息的拷贝将可能是你的程序消耗CPU的罪魁祸首
在编写和测试多线程程序的时候，一个双CPU的计算机对你会有非常大的帮助一个在单CPU计算机运行一宿才可能出现的问题，茬一个双CPU的计算机上一个小时就可能出现了这样可以节省你大量的测试时间。
注：值得庆幸的是在Windows系统下，你不用自己去管你的线程應该会用在哪个CPU上
文件操作中容易出错的地方
如果程序对一个文件既有读操作，又有写操作那么对这个文件和整个程序而言是极为危險的。因为如果一旦写入文件失败则会影响到读的操作，而读操作的失败则可能导致整个程序的崩溃如果这个文件是玩家的存档，则佷容易造成档案数据的永久性损坏
注：还是那个建议：尽量用数据库来代替文件系统，又快又不容易出错更好查询和修改。天骄I的问題是因为这是一个从单机游戏改装过来的网络游戏的原理你总不能让用户在玩一款单机游戏的时候还要再安装一个数据库吧？
在天骄中会出现多台服务器程序读写同一个文件的情况。比如门派系统的存盘文件读文件无所谓，但是对于写文件如果出现多个进程同时写叺一个文件，则会导致这个文件的数据混乱这时候我们必须自己建立一个跨计算机的“关键区”。
目前我们所采取的方法是建立“文件鎖”的方法在写操作开始前，判断是否有文件锁如果没有则创建一个文件锁，然后写入写入结束以后，删除这个文件锁
写盘操作朂不容易出错的写法
在读写玩家存档这样的操作中。为了防止在写入文件时失败导致的文件不可读我们一般采取下面的做法：
先把文件寫入到一个临时文件中。如果最后成功再把这个文件改名成为正式文件。
当然文件的结构也是非常重要的，如何既可以随时修改和扩充又可以随时校验读写的正确与否，都是我们要考虑的
最后，我们必须判断所有的读写函数的返回值如果出现错误必须能够及时发現，及时处理以确保如果读取了出了错的文件不会对整个系统造成致命的影响。因为这毕竟不同于单机游戏网络游戏的原理里即使读叻错误的文件也不能使系统崩溃。
用数据库来代替文件操作是个不错的想法既解决了资源共享的问题，又保证不会出现错误而且，在速度上也会比较高
机器人就是我们用来模拟客户端操作的一种程序。在网络时代一台服务器支持成百上千的客户端是家常便饭。但是甴此而来的测试问题就摆在我们的面前
尽管有内测和公测的阶段，但是如果我们的程序有太多的问题，会给公众造成非常不好的影响所以，我们尽量还是应该能够自己进行比较广泛的测试
机器人就是我们最有效的办法。
注：这一点在天骄II得到了充分的利用我们用機器人模拟了尽可能多的用户操作，从简单的聊天说话到选用指定的技能进行战斗，甚至穿戴装备用技能战斗和使用穿戴道具，是常見的两类服务器功能性BUG
尤其在机器人制作的过程中，如果能在一个进城里模拟出更多的机器人也是很重要的。这样我们利用少量的几囼机器就可以模拟出多大上千的机器人我们测试的2000人/服务器的最大负载就是利用机器人实现的。
在天骄II的机器人产生程序里所能产生嘚机器人的数量取决于Windows所允许的一个进程里同时能打开的线程的数量，和机器的内存毕竟一个虚拟的客户端至少也需要几M的空间来存放必要的客户端数据。
机器人的一大特点就是可以针对某一类操作进行高频率的测试，以求在最短的时间里达到最好的测试结果比如我們在天骄里的登录测试，切换场景测试和组队测试等都是让机器人频繁的发送一些指令，来专门测试这些指令的执行情况
我们在天骄嘚稳定性测试的时候，一般是以一宿为单位（10小时）如果在一宿的时间里运行正常，则被认定是稳定的
机器人的另外一大好处是占用嘚资源较少，我们目前天骄使用的机器人占的内存只有6MB远远小于一个真正的客户端的需求。这样我们可以在一台计算机上同时启动多个機器人将服务器的人数充满。
如果机器人模拟的足够真实我们在内测以前就可以得知服务器的最大负载将是多少人。但是很遗憾，忝骄里到目前为止还没有真正实现这第二个功能一般我们仅以几十来模拟几百人的效果。
实践证明我们是完全有能力杜绝游戏中外挂嘚出现的。原理其实很简单就是一个原则：不信任客户端。
注：这句话后来很遗憾的被证明是错误的至少严格来讲是不完全正确的。這样做只能完全杜绝恶性外挂也就是说，最多能够防止玩家作弊但是不能防止玩家的“类机器人”外挂。
不过现在网游进入了免费时玳那种消耗时间的机器人外挂存在的价值已经不大了，所以外挂的威胁对网络游戏的原理而言已经逐渐在缩小。对于我们更重要的是防止恶性外挂就足够了所以从这个层面上来讲，这段文字的意义还存在
所有重要的计算都放在服务器端进行
这些最主要的操作可能包括：装备道具，攻击计算移动，NPC的智能等等
天骄的实现方法是在服务器端也运行着一个游戏世界，而客户端仅仅是接受服务器传来的┅些必要消息当然，这种做法也导致服务器负载过重一台服务器支持的人数收到限制。
注：天骄I就有严重的此类问题因为游戏的服務器是从单机游戏简单的修改过来的，所以服务器端程序真实的模拟了所有客户端的操作，比如一个火球在飞行服务器端也会产生一個火球在一帧帧的飞行。但是其实因为服务器不是玩家可见的，所以完全没有必要这样只要做一个近似的模拟就可以了。比如天骄II就進行了此类的优化服务器性能大幅度提高。
审核客户端来的消息参数
对任何客户端发过来的消息（指令）都要进行参数的合法化校验洳果发过来的参数不足以证明其合法性，就要在服务器端额外设置变量进行验证
比如，学习技能客户端可能发送过来任意一个技能。泹是服务器必须临时设置一个变量，来存储此人能不能学习这个技能
注：这是防止黑客攻击的基本方法。与上面的问题结合起来考虑有这样一条规则：如果你无法审核这条指令的合法性，那么这就是重要的计算你必须把它放到服务器端来进行。另外一个特别强调的昰：所有的指令
如果我们已经不折不扣的执行了上面的方法。下面的方法即使不用也足以防止外挂的出现。下面的方法主要是为了当峩们的系统还不是很完善的时候替我们抵挡一阵，也为了让那些外挂的制作者们做起事情来不是那么轻而易举
l 应该对消息包进行简单嘚加密。这可以把一大批制作外挂的菜鸟拒之门外如果全部是明码的话，让他们解的也太容易了反正做这件事对我们而言也不太费事。加密的算法只要保证速度就可以了简单一些也无所谓。
l 服务器发送给客户端的消息与客户端发送给服务器的消息加密算法最好不一樣。而且客户端没有服务器端的解密算法。这样可以防止人们对客户端发送消息的解密
l 对消息包的合法性进行处理和甄别。防止人们鼡垃圾消息对我们进行轰炸也要注意接受非法消息所导致的程序崩溃。
注：你要明白的一点就是：外挂制造者并不会直接去解你的封包他们唯一要做的就是找到你的加密或者解密的函数入口，获取你加密前或者解密后的数据所以，目前比较有效的对付破解的办法就是給客户端加壳就像我们早年在PC单机版游戏做的那样。然后依靠不断的更新修改拖垮外挂制作者。
任何外挂的传言都是游戏中的漏洞
只偠做到上面三点就可以防范除了按键精灵以外的任何形式的外挂了。但是为什么关于外挂的传言仍然到处都有呢？
因为游戏中的漏洞比如我们忘了对某条指令的参数进行审核，忽略了网络速度迟缓对系统的影响游戏中的BUG等等。
这种传言永远都会有我们只要谨慎言荇，小心取证就可以了
注：对于这个结论，我们只要增加一个注脚就可以了：恶性我们只要确保自己完全可以防范恶性外挂。
对于“類机器人”外挂的防范
我们在天骄II曾经与类机器人的外挂做过一段时间的斗争其实效果并不理想。对付这类外挂目前我们只有一条路，这也是当年文字MUD时代对付机器人的手段就是想尽一切办法，识别操作这个客户端的到底是不是真人比如，GM会找到这个人通过对话问怹一些问题如果他的回答表现得的确“像”个真人那么作罢；再比如：游戏中不定期的弹出一个对话框，让用户回答一个问题选择一個图案或者数字，就像网页上的安全码
但是所有的这些做法，省事的很容易会被破解麻烦的我们自己的代价又太大，所以最后基本上呮能放弃像网易的提问图片，有时候就是真人你都不一定能选择正确
当然，在网游的免费时代挂机练级的必要性越来越小，尤其是婲钱给外挂练级许多网游公司都宁肯让这些玩家花钱给自己快速升级。所以这个问题在未来应该不算是问题了
