引用来源:http://bbs.51testing.com/viewthread.php?tid=124864&page=1#pid1055013

暴雪总裁演讲总结游戏十条经验

由于性能测试与功能测试有很大的区别，所以讨论出的结果可能与预先的设想有一定的区别。　　

性能测试的目的：

　　为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。

　　性能测试指标的来源：

　　用户对各项指标提出的明确需求；

   如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验）

　　主要的性能指标：

　　服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间。

　　BUG观点：
　　1、性能测试就象人在无风情况下跑步（正常情况下的性能指标）；
　　2、压力测试就象人在微风中跑步（在正常的基础上加大多少百分比压力的性能指标）；
　　3、负载测试就象人在强风中跑步（不断加压，直到系统崩溃）。

　　HTTP观点：
　　1、 负载测试是正常情况下持续的加压；
　　2、 压力测试是直接加压达到一个极限值。

　　大家统一的观点：

　　性能测试、压力测试、负载测试密不可分，可统称为性能测试。

　　性能测试要点：

　　1、 性能测试是在功能测试完成之后进行。
　　2、 性能测试计划、方案一般与测试用例统一在一个文档里。
　　3、 测试环境应尽量与用户环境保持一致。 
　　4、 性能测试一般使用测试工具和测试人员编制测试脚本来完成，性能测试的环境应单独运行尽量避免与其他软件同时使用。 
　　5、 性能测试的重点在于前期数据的设计与后期数据的分析。 
　　6、性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。

（说明：当系统中出现的某个功能点需要修改，它一般只会影响到功能测试的设计用例，而对于性能测试，很少影响到性能测试的设计用例。但是如果某个功能有较大的修改，性能测试也应该进行重新测试。）

纵观整个互联网

无论是使用Google还是百度

搜索关键字“游戏测试”

可悲的是，我们竟然得不出一个有用的地址连接

看了看51的论坛，游戏测试板块也是惨淡的要命，无奈，只能站在前辈——云老大的脚背上继续跺两脚

我也来鼓捣鼓捣基础铺垫类的文章吧~

人们都说酝酿是一个长时间的体力活

其实需要更多的就是一个灵感~灵感来了就如果……：“……￥……%&！%@￥#%！￥#”(我要引用的话有点不合适，所以系统给屏蔽了……)

在我个人看来，游戏测试与软件测试的胡同之处只有他功能要点，而其他方面，需要更多的就是我们的YY思维

所以我从今日起的文章将要围绕这几个方面来写

 

第一：也是最重要的，任何想做游戏测试的人，不保证自己一定是一个常规软件测试工程师，但是必须保证自己是一个游戏达人，无论是什么类型，什么风格，什么机种的游戏，都要了解一下，对游戏做到一个知道分子。

第二：角度的定位，在我个人看待游戏，更多的是出于他的感性层面，我愿意去思考他的文化背景，思考他的设计初衷，思考他的价值取向，我们不要单纯的去评论游戏的好玩与否，而是要看他是怎么设计的，怎么实现的，为什么要这么做，他们的初衷是什么？说的在直白一些，我建议所有的游戏测试玩家都是各大小说阅读网站，自习的看看那些中国修真类作品，西方玄幻类作品，还有网游YY类作品，大家尽量的理性去分析他们小说所营造的世界观，他们对整体宏观的架构设计，国外论坛有一个高手曾经说过一句话：“一个优秀的小说作者其实就是半个游戏策划师。”

那么我们其实真的可以理解为：一个优秀的读者，也是半个游戏测试工程师。

第三：有一天，我在一个QQ群里跟人闲聊，聊了一会出现了意见的分歧，

然后他冒出来一句话：“你说的不对”

我就问他：“哪里不对”

他又说：“你肯定没去过51论坛，你自己上去看看吧，我刚才那些话都是云层说的原话”

我想要说的，请不要把我和云老大相提并论，他是我的老师，但是您不能奢求学生的观点一定要跟老师一致，多种角度不是坏事，至少目前中国的游戏行业来讲，一个系统化理论化的游戏测试方案还没有，每个游戏公司都是有他们自己的一套管理方法。我更多的是摸索……

所以以后我的东东里面可能有一些跟云老大不同又或者是冲突的地方，希望个别朋友不要去相互对比，就事论事就好。大家一起的理性分析一些事情

第四：有好多人PM说，写一些测试基础的东西，比如怎么做游戏测试，怎么设计游戏测试用例，怎么做游戏的XXXX测试………………

我不想对这方面过多的陈述

首先我们要明白，游戏测试归根结底还是软件测试，如果你连软件测试都不会，那么最基本也要去先学习一下软件测试的基础知识才行吧？

如果你是一个软件测试工程师了，那么以上的问题根本就不存在了，做游戏测试工程师切忌不要把自己定位成一个游戏玩家，因为那样的话，你只会渐渐的失去你那份对游戏的热情，那将是十分可怕的事情。

其次，我大概是上周，已经找到了一个工作，我只说一下当时三面的时候BOSS对我说的一些话，我转述出来给大家，

“小伙子，别去在意那些什么狗屁技术，这年月技术是最不值钱的，因为所有的技术都是慢慢被更多人学习，更多人去使用，使用人的人多了，也就不值钱了。

我选员工要的是思想，要的是思维，如果你没有一个很成熟的思维，没有一种发展的期望目标，甚至说你对于工作来说只是一个赚钱的方式，那么你的路会变得很窄，所以我建议你进来公司不要去过多的关注你手里的技术问题应该怎么解决，多去看看你们的经理，你们的同事，他们是如果做‘管理’的”

意思相信都能理解，我觉得这是一个不错的BOSS，我在那里更多的是吸收，学习，消化

其实我一直主张的观点，就是游戏测试工程师千万不要把自己当成一个普通玩家，也不要总是从发现缺陷这种层面去考虑问题

我的观点更倾向于“想做好游戏测试，先去学会游戏策划”

 

摘要：本文探讨了Visual Basic 6.0在测试自动化中应用的可能性，并列举了一些在实际工作中应用的例子

一 现有自动化测试工具的不足

当前，一个摆在软件测试自动化面前的一个很明显的事实是目前可用的工具并不能做一切我们想要它们做的事情；指望任何一种工具能够完全支持众多不同应用的测试自动化是不现实的。由于很难找到一个能完全满足测试自动化需要的测试工具，而且测试自动化工具都十分昂贵，所以常用的做法是使用一种主要的自动化测试工具，然后用传统的编程语言如Java, C++ 和 Visual Basic编写自动化测试脚本以弥补该工具的不足之处。

二 Visual Basic 应用于自动化测试的优点和局限性

利用Visual Basic之所以能实现一些比测试自动化工具更好的功能的原因在于它毕竟是针对实际的项目而编写测试脚本，而且，事实上Visual Basic确实存在比其他编程语言更明显的优点可应用于测试自动化项目。
众所周知，Visual Basic 不是一种测试工具，但它是一种非常流行的软件开发语言；使用Visual Basic最大的好处是它是一种非常流行的语言，它简单、易学易用和有非常广泛的懂得Basic语言的用户群基础，即使对不熟识Visual Basic 的测试工程师，要熟悉它也可以轻易找到大量有关的出版物和资料。
Visual Basic本身拥有一些能支持测试过程的特性，例如，它具有返回有关测试平台和被测应用程序的重要信息的功能。Visual Basic 的Shell函数和SendKeys函数可以启动一个应用程序和操作它的图形用户界面，用Visual Basic可以编写所需要的一些脚本程序，例如，装载一个测试应用程序。Visual Basic中集成的可视化数据管理器可以直接连接一个数据库并查看它的数据结构。此外，Visual Basic 还可以用来测试一些后台操作的应用程序，例如，可以编写一些脚本存取初始化文件（.ini文件）和Windows注册表。从Visual Basic 中访问Windows 的应用程序接口（API）对操纵受测应用程序和报告一些重要信息都是非常有效的，而且Visual Basic语言比当前其他的编程语言花更少的时间去掌握和有更高的编程效率，适合要求快速建立测试脚本的测试自动化工作需要。
由于Visual Basic不是一种专业的测试工具，因而有其局限型，首先它不包含目前已经成熟的自动化测试工具所具有的大部分的功能，例如，Visual Basic本身不提供缺陷报告、测试设计和文档管理等功能；它还缺乏录制功能和任何自动化测试设置，要在Visual Basic 测试代码中包含这些功能，需要手工编写这部份功能代码，而且目前大部分有关Visual Basic 的出版物和资料都是针对开发者而不是测试者。虽然如此，依然有一些不需要很多的投入而使Visual Basic应用于自动化测试项目的基本方法。

三 Visual Basic中支持测试自动化的工具集

Visual Basic 6.0 包含一套不需任何编码就能支持测试的工具集，包括丰富的向导，可视化数据工具和对象浏览器等。
1向导和模板
在Visual Basic 中有众多的向导可以使用。其中一个对测试人员非常有用的向导是数据窗体向导，它可以创建一个能连接Access或ODBC数据库的数据窗口，该数据窗口可以设置成单独地查看单个记录或者用表格形式批量浏览数据记录，因而可以实现一个能快速定制而又易于使用的用来检查数据库内容的测试工具。
窗体模板不但可以快速创建一个标准的窗口，而且能同时伴随着这些窗口产生源代码，这些自动产生的代码可以部分或全部应用到为测试而定制的窗口中，这对提高测试效率是非常有效的。
此外，一些其他的向导如数据对象向导，ActiveX 控件窗口向导都可以实现花费最少的编码工作量去创建和配置一些有用的测试对象。
2可视化数据管理器
可视化数据管理器可以快速地连接到ODBC或OLEDB数据源，去查看数据库结构，数据表，视图和其他基本的对象。通过它去检查后台数据库实现数据库应用程序测试。也就是说如果被测应用程序包含一个在SQL Server，Sybase ，Oracle和 Access的数据库，则可以通过可视化数据管理器去检查所有的这些数据库而不需要分别登录DBMS界面。通过Visual Basic作为一个通用的前台数据库管理器去管理一个用ODBC或OLEDB存取的后台数据库，可以节省测试工程师的测试时间和可能花在熟悉这些数据库产品而花的培训时间。
可视化数据管理器通过数据库输入和测试SQL语句支持白盒测试。利用它可以修改后台数据，甚至创建新数据对象如数据表，存储过程和数据视图。一些被用来测试数据的SQL语句（通常用来检索重复的数据行和暴露有关完整性的缺陷）甚至必要时可以在这里创建和执行。
3 Object Browser对象浏览器
对象浏览器是另一个非常有用的Visual Basic工具，通过它去检查对象输出的属性和方法以及各种必要的参数；测试人员可以利用这些信息创建这些对象的验证性和功能性的测试，特别是对面向对象测试，非常有用而且非常有效的。
对象浏览器可以显示一个定制COM对象的信息库，这个库列出了该对象的属性，方法和事件，而这个对象可以用任何支持COM对象模型的语言来开发。在对象浏览器里设置一个对象相关信息的捕获和查看对一个缺乏测试培训的测试人员而言只需很短的时间，当然，要建立Visual Basic测试脚本去测试对象的属性，方法，事件需要做一些编写代码工作。

四 Visual Basic在自动化测试工作的应用举例

下面列举了一些在实际测试工作中应用Visual Basic通过简单的编码实现测试自动化或相关工作的例子，如记录测试结果信息、简单的GUI测试等。

1 利用文本文件记录测试信息

　

例1 

Open "testlog.txt" For Input As #1               ‘打开记录文件

Print #1,FileDateTime(“c:\windows\calc.exe”) ‘记录被测试程序创建的日期和时间

Print #1,FileLen("c:\windows\calc.exe")     '记录被测试程序的长度

Print #1,CurDir                                        '记录当前目录路径

Print #1,Environ("Windir")                        '记录当前Windows 目录路径

Print #1,Now                                                  '记录测试开始日期和时间

…….                                                       ‘记录测试过程信息

Close #1                                                   ‘关闭记录文件

在测试过程中经常要做的一项工作是为了查找错误信息而检查应用程序的登录文件，这些登录文件通常是文本文件，而对任何编程语言来说利用本身基本的文件操作函数都很容易取打开和读取这些文件。而另一项工作是记录测试过程信息和测试结果，它实质上跟上面所说的是使用相同的函数功能：一个简单的记录方法是将测试结果写进一个文本文件。例1所示的代码就是实现了这些记录功能。

2 GUI功能测试

　

例2 
Shell("c:\windows\calc.exe") '启动计算器 
For i = 1 To 100 '设置计算循环
SendKeys I & "{+}", True '发送击键动作到计算器
Next I '累加每一次I的值 
SendKeys "=", True '计算总和 

在黑盒测试中，实现自动化测试要编写测试脚本去模拟用户日常的操作输入。使用Visual Basic的Shell函数和Sendkeys函数可以简单有效地实现一些GUI功能测试。
例子2的所示代码打开了一个Windows计算器，然后发送击键动作模拟用户输入，计算一系列数值（1到100）的总和；启动程序调用Visual Basic的Shell函数，SendKeys指令被用来发送击键动作到应用程序去模拟用户输入和计算结果。



3读取和设置注册表信息

　

例3 
Dim astrSettings() as string ‘定义变量
lstSettings.Clear ‘清除列表框内容
astrSettings = GetAllSettings(testAppname, txtSection) ‘调用专用函数返回VB
‘专用位置的注册表信息
For iCount = 0 To UBound(astrSettings) ‘通过循环将注册表信息
‘显示在列表框中
lstSettings.AddItem astrSettings(iCount, 0) & ": " _ 
& astrSettings(iCount, 1) 
Next iCount 
注：testAppname是被测试应用程序的名称

测试人员很多时候都要检查注册表，注册表是一个存储应用程序安装设置、选项等重要信息的地方。Visual Basic 6.0 包含了一些可以从预留给Visual Basic 应用软件专用的注册表键值位置返回信息的新的功能函数。这些功能函数简单地设置和返回这些注册表键值，这对测试用Visual Basic 开发的应用程序尤其有用。
例子3所示代码返回注册表中位置"HKEY_CURRENT_USER\VB and VBA Program Settings\"中的所有注册表信息并把这些信息显示在一个名为lstSettings的列表框中。如要存取其他位置的注册表信息，需要调用Windows API函数。

五 小结

由此可见，为弥补当前自动化测试工具的不足，选择用一些编程开发语言编写一些测试脚本或测试辅助工具在实际工作中证明是切实可行的，而Visual Basic 6.0由于其强大的功能，易学易用，有广泛用户群基础等优点而成为应用于测试自动化比较有应用前景的工具之一。
参考书目
1 《软件测试自动化技术》美 Mark Fewster & Dorothy Graham 著,电子工业出版社 2000年1月
3 《软件工程---实践者的研究方法》（美）Rgoer S.Press著，机械工业出版社，2000年9月
2 《Visual Bsaic 6 技术内幕》（美）Steven Holzner著,机械工业出版社，1999年4月

 首先，先来简单搞清楚一个网络游戏的策划需要做些什？
这是从BAIDU里搜索到的一个答案。
网游策划一般都要由7人左右完成
首先是主策.这是最高地位,主要起到一个协调全局的作用.合理的去用人分配工作.把握网游策划的主线路,负责分析策划的方方面面写出可行性的报告.
之后就是艺术创意主要牵扯到整个网游的艺术走向问题
还有最重要的数据平衡设定策划.这个是最重要的也是最难的.需要合理的去分析数据找出平衡点,让游戏的平衡性达到最佳状态负责各种公式的编写.最好的例子就是暴雪公司 10年磨1剑 不是为了别的就是为了不断的测试修改找出完美平衡的交接点
之后就是一个文学创作,每个网游都会有其一个完美的故事背景,而网游就是一部电影,从游戏的起因到游戏之后的更新资料片出炉这点,文学创作的时候都需要完全的考虑进去.
网游策划与很多策划不同,需要多方面的分析各种情况,网游从可行性报告到策划再到程序编写 最后进入运营
这些期间 策划都是在不停的发挥着最重要的作用.一个网游是否好策划是最至关重要的方面.
我们注意到红线的2句话。可以说正是老徐主策把梦幻带到了我们之中，把梦幻带上了轨道，建立了梦幻至今还在运行的游戏模式。最后一句，也说明了策划对于网络游戏的重要性。
那么，对于现在的梦幻西游的策划，我有那么几个小小的问题。
一，梦幻西游再推出活动的时候，是否有考虑到游戏服务器所能承载的MAX？
三重大奖贺盛会最新神兽领回家这是梦幻西游即将在8月3日推出的活动。玩家们并不需要感到陌生，早在不久之前，梦幻的策划们就推出过一个“英雄帖”的活动。内容大概类似。我不否决这个活动，我只是注意到这个活动推出的时间，恰恰是在星期天12门派的活动的时候。12门派，作为一个梦幻的玩家，不需要再废话什么，一个人人争先的活动，一个比较受到好评的活动（尽管现在的奖励正在被恶意减少，后续提到）。12门派是和三界比武齐名的活动，参与的人不计其数。在当今的梦幻西游，12门派当天卡机的情况绝对会发生，而且卡机的频繁率不敢让人恭维。那么，在原本就会卡机的活动中，推出这样一个活动，策划们是否衡量过自己游戏服务器的承受能力。是否能经受得住几百万的上线量（WY就是靠这个数据认定MH是国产第一网游）。梦幻的卡机现象，就像12门派一样被人所熟知了。当初，最简单的配置即可下载玩的梦幻西游，已经是现在最高配置的机器也避免不了卡机的情况。客服的解释是玩家自己的网络和机器问题。也许，大公司里的电脑的配置已经远远超过了我们玩家的电脑吧。
那么，策划们注重的是玩家的参与数量还是游戏的可行性。我不知道这样的活动安排是否进行过可行性分析，还是策划兴起随便随手一笔加上去的。至于这个类似“英雄帖”的活动的实际意义，我想除了个别玩家能享受到一些比较实惠的奖励来说，大多数玩家，一个人开了好几个号的玩家，收获的仅仅是连点卡都不够贴的经验和钱。
在游戏本身上，策划们的确成功地吸引了玩家，心甘情愿的浪费自己的点卡，挂在游戏里，没有怨言，却只在等待幸运降临自己。
你不觉的策划==吸血鬼吗。还是个高吸血的JN，从来不会因为玩家的干扰反抗抱怨而中毒。
二，策划们是不是经济学毕业的经济师，是否具有调控游戏市场的能力？
在商人们通过差价不断赚进利润的时候，是否有人想过，这个时候，更大的商人在后面隐藏，那就是梦幻西游的策划。我举个最简单的例子，当初法宝刚开的时候，法宝材料的获得有些时候是需要道具的。那个时候反应最大的两样东西---夜光珠和河豚。这两样物品的价格不断直线上升，而玩家为了做一个垃圾法宝的花费也在不断的上涨。但为什么后来这两样东西的价格又直线下降呢？很简单，那就是供大于求。而为什么突然会供多起来呢，更简单，就是梦幻策划悄然改了这2个产品的出场率。导致这2样东西越来越多，远远超过了需要的人，降价自然顺利成章。这只是个最简单的例子。
最近的更新里，我们注意到部分卡片的作用和等级发生了调整。在最初，变身卡的附带JN大都是依据于本身召唤兽所拥有的技能。注意，是大多数。而现在，这个大多数正在被刻意减少。大牛卡的JN从高招架（本身自带）变成了加气血。这个刻意的变化，用意很简单，就是为了提高大牛卡的价格和使用量。而野鬼卡的没落意味着玩家不得不去追求更高等级的蜈蚣卡或者吸血鬼卡和幽灵卡。另外，卡片合成的时候，合成7J卡片的召唤兽也需要是宝宝了。可以说，合成卡片的成品又微微的调高了。由于是刚刚推出，我不做评论。但是，这同样说明了梦幻西游策划们会有意去调控和平衡梦幻西游的市场。
这是不是类似于我们国家的经济体制呢，市场经济+国家宏观调控。那么，梦幻西游的策划们是不是经济学专业的博士生，还是个个都拥有经济师的资格呢。或者，我大胆的假设，他们只是凭直觉修改游戏呢！还记得丁老板对于SM要环率的解释吗，不小心调高了！-----我只是想说，国家都无法很好的控制住国家的经济发展，那么小小的策划们又有这样的本事吗？
现在梦幻币和RMB的比例是1：9.5。那么，这个比例几乎接近了当年RMB与美元的比例1：8。这可以说明梦幻币几乎是供不应求。对于一个游戏币能有这样高的比值，我们不能理解为什么WY现在腰这么粗的原因。现在是暑假，点卡的价格却高达120-130W：150点。我记得三年以前的点卡还是75W一张，后来到了90W，到了100W，直到现在。按常理来说，暑假里玩的人多了，游戏的点卡价格自然会下降，而现在不降反升，再次证明了梦幻币现在的高的市场价值。说实话，如果我是WY的人，我高兴。可惜，我不是，我难过。60点60W，1点1W，这是多么可怕的比例。
三，梦幻西游的策划为何随意的修改门派的JN，FB的奖励？
不说梦幻西游不断得出台资料片了，法宝的出现改变了整个比武的格局，也带来了不少的争议。如果说这些是策划们为了延续游戏苦心研究推出的结果，那么至于随意对门派JN的修改，是为了什么。
你可以说是为了平衡门派的竞争性，那么我说，这只是个幌子。什么叫平衡，所谓平衡就是对立的两方互相依靠，克制，在一种模式下达到了一种稳定的状态。那么，只要随意的打破一端的平衡就会引发另一端的不平衡。改了这个，改那个，再改这个……能达到原来的平衡吗！绝对不能。而梦幻西游的策划们却轻易打破了这个平衡，导致现在门派的盛衰依然未变，门派间的争斗和攻击四起。
每个人在游戏开始的时候选择了这个门派，看中了这个门派的特色。可是在玩到一半的时候，却被随意无情乃至毫无预知的情况修改了。原来欣赏的JN没了，原来倚重的法术MISS了。试问这样的修改是否在某种意义上侵犯了玩家的权利。在我国游戏法还在摇篮里的情况下，WY几乎反过来成为了玩家的衣食父母。哪天的更新里没有什么特殊的改动，估计玩家就要跪地大拜上天怜悯了。商店成了父母，顾客成了儿女，去消费还要受气，岂不是每个梦幻西游的玩家都有受虐的BT心理。花钱就是图个爽快，反而成了受气的原因。一个字----贱。门派的JN就像是玩家的生命，所依赖的生存手段，当这个受到了破坏和修改，那我们还靠什么立足于游戏。
至于FB的修改，请问修改也不必偷偷摸摸的吧！不止FB，包括其他活动，12门派等等都受到了暗地里的修改。策划们是小偷大学毕业的。也许自己也认为是亏心事吧。而这样的修改，又无意中回到了刚才说的第二问，间接的调整了整个游戏的市场。

ACT......(ACTION GAME )动作游戏

    STG......(SHOTING GAME )射击游戏

    RPG......(ROLE PLAYING GAME )角色扮演游戏

    A.RPG....(ACTION ROLE PLAYING GAME )动作角色扮演游戏

    S.RPG....(SIMULATION ROLE PLAYIG GAME)模拟角色扮演游戏

    FTG......(FIGHTING GAME )格斗游戏

    S.FTG....(SIMULATION FIGHTING GAME )模拟格斗游戏

    SLG......(SIMULATION GAME )模拟仿真游戏

    SPG......(SPORT GAME )运动游戏

    TAB......(TABLE GAME )桌上游戏

    PUZ......(PUZZLE GAME )益智游戏

    AVG......(ADVENTURE GAME )冒险游戏

    RAC......(RACE GAME )赛车游戏

    RTG......(REAL TIME GAME)实时战略游戏

    PET......(PET)养成类游戏及电子宠物

    MAG......(MANAGEMENT GAME)经营类游戏

    L.MUD....(LETTER MULTI-USER DUNGEONS)文字网络游戏

    F.MUD....(FIGURE MULTI-USER DUNGEONS)图形网络游戏

    ETC......(ETCTERA GAME )其他类游戏

有关位置同步的方案实际上已经比较成熟，网上也有比较多的资料可供参考。在《带宽限制下的视觉实体属性传播》一文中，作者也简单提到了位置同步方案的构造过程，但涉及到细节的地方没有深入，这里专门针对这一主题做些回顾。

　　最直接的同步方案就是客户端在每次发生位置改变时都向服务器报告 ，服务器再转发给周围的其他玩家，其他客户端将对应的游戏实体移动到新的位置上。

　　但是这样存在一个问题，每个玩家的位置都是自己先开始移动，一段时间之后才在其他玩家的客户端上表现出来。如果只是希望每个客户端上看到的游戏对象都同时开始移动，那可以让玩家的每一步操作都由服务器确认之后再执行，这样误差将缩减到不同客户端之间的网络延时差。但是显然的，这样的做法不可能真正被采用，因为这将使得玩家的游戏体验非常的糟糕。有谁能忍受连每走一步路都要卡一下的游戏呢？

　　既然一定存在先后时间差，那需要一种方法来让不同客户端上看到的玩家位置不至于有太大的误差，尤其是不能有影响到游戏公平性的误差存在。根据误差出现的直接原因：时间差，我们应该能够想到一个解决方案，那就是让其他客户端设法弥补掉这段时间差内少走的距离。这样的话也就要求我们的消息包中多带一个开始移动的时间数据，用于其他客户端在收到这个消息包时计算对应的玩家实体已经移动过的时间和距离。

　　我们以一个实际的例子来说明如何减少这种误差的影响。假设玩家A以速度V从P1点去到P2点，A的网络延时为T1，在A旁边有个玩家B，他的网络延时为T2。B收到服务器转发过来的移动包时，A在其自己的客户端上已经移动了T1+T2的时间，在这段时间内他自己已经走过了V*(T1+T2)的距离。如果这时在B的客户端上开始将实体A从P1移动到P2，那显然两个客户端上看到的A的位置始终存在V*(T1+T2)的误差。

　　为了使A在B客户端上显示的位置与其实际位置的误差尽可能的缩小，一个简单的做法是直接将A的位置向前拖V*(T1+T2)然后开始移动，这样两者之间的误差便消除了。但这样会使得客户端的显示太鲁莽，要让其看起来平滑一些，我们可以考虑使用一些算法，比如计算出A从当前位置走到P2点还需要的时间，然后加快其速度使其在规定的时间内到达P2点，这样A和B看到的最终时间是相同的，但中间过程还是存在较多误差。另一种较好的做法是先让A以一个可接受的较快速度移动到其当前应该所在的位置稍前一点的地方，然后以正常速度移动到P2点，这样后面的移动情况与其实际移动情况基本吻合了。

　　看起来这个方案很完美，但是这里却忽略了一个问题：我们假设的是每次移动时都知道玩家要去的确切位置。这在靠鼠标点击来移动的2D游戏中是正好合适的，但是在WOW一类的靠键盘来移动的3D游戏中却没有办法采用。WOW中的移动消息都只能向服务器报告当前的坐标及朝向信息。

　　这类移动的位置同步其实也可以采用类似方案，服务器将移动玩家的当前位置信息广播给周围的其他玩家，当然其中也包含了时间戳。当其他玩家收到这个移动包后，表示的是在过去的某个时间里该玩家移动到了这个位置。如果只是简单地将其对应的实体移动到这个位置，那同样的，也存在位置误差。

　　与上一种情况类似，如果我们知道该玩家的移动速度，再通过数据包中的时间戳，假设该玩家还在以相同的速度朝相同的方向移动，那我们也可以预测出该玩家从开始移动到现在这段时间内他走了多远了距离。我们也可以将其位置做适当的修正，并使其继续移动下去。

　　我们需要先停下来考虑一下这些算法的部分细节。其中出现了一些数据是否应该包含在我们的每个消息包中，也就是我们需要考虑的另外一个问题：移动同步的消息中应该包含哪些数据，以及这些数据到底应该向哪些玩家广播。

　　对于2D游戏的情况来说，我们的算法需要的数据有：玩家的速度V，玩家开始移动的时间T0，收到数据包的时间T1，玩家当前位置P1和玩家要去的位置P2。T1和P1从当前客户端上都可以取到，而速度V一般来说不会经常改变，至少不是每次移动时都不一样，所以我们可以为速度的改变设计单独的消息码，这样V值也是可以在客户端上取到的。最后，每个移动消息中包含的数据只需要有移动到的位置P2和开始移动的时间T0。

　　其他客户端在使用特定算法将玩家移动到P2后会将其停在此处，直到收到下一个移动包时再开始移动。而对于在移动过程中又收到了新的移动包的处理过程基本类似，不做过多描述。

　　对于3D游戏的情况，算法是基本相同的，但是没有目标点，替换为移动方向，比如是向正前方移动，还是向左或向右移动等。在这种情况下，只要没有收到玩家停止移动的消息，其他客户端上都会以最后一次收到的移动包的状态来继续模拟移动。

　　所以，在网络偶尔卡一下的时候也会出现一些奇怪的现象。比如WOW中，看到队友直冲冲地走下了悬崖，你刚喊了句“怎么掉下去了？”只见队友又从身后走出来，还冒出一句：“没啊，我就在你旁边!”

　　关于数据要向哪些人广播的问题，其实很简单，哪些人会看到这个玩家就需要向哪些人广播。不管是直接在主屏幕上看到还是在大地图上看到的代表其位置的一个点。但是，针对不同的人使用的广播策略还是存在差异。

　　在《带宽限制下的视觉实体属性传播》一文中提出了一个方案很值得参考。该方案提出的基础是因为3D空间透视的原因，离你很远的一个玩家移动了10米，最终在你的显示器上看到的位移可能只有一个象素；而离你不到一米的一个玩家虽然只移动了一米，但最终显示出来的位移可能会有几十个象素。所以，远处玩家的移动并不需要非常严格的关注，但近处玩家的移动同步需要非常高的优先级。

　　这个方案的实现还依赖于另一项技术要求，玩家的属性更新以一定的频率来进行，更新时比较一下当前属性值与上次更新时的属性值，如果存在差异则通知客户端更新，另外如果中间跳过了某次更新也不会对客户端表现及游戏公平性造成什么影响。比如这里要处理的玩家坐标，第一次移动到A点，第二次从A点又移动到B点，如果移动到A点的更新包没有发送，直接发送了移动到B点的更新包，这将不会对游戏逻辑产生大的影响。

　　这套方案基本上是为3D游戏的实体属性广播优化而设计的，在2D游戏中很难使用。一是斜45度视角的2D游戏中屏幕顶端、中间和底部任何一个位置上的玩家移动，其距离和象素比是完全相同的，因为画面不存在透视，所以也就没有远处对象更新频率低这一可能。另外2D游戏中的移动与3D游戏也存在差异，具体情况前面有详细描述，2D游戏中基本上每一次移动都需要广播，不能跳过哪一个，否则玩家看到的现象就是在乱跑，这也必将影响到技能的使用等游戏逻辑。

　　有关位置同步所涉及到的一些技术细节及优化方案上面描述了一部分，但是在实际的应用中是否会使用还是要看具体游戏的需求。比如大话类型的游戏，其本身对位置的精确同步就没有要求，两个客户端上出现一前一后的移动也不会影响任何的游戏逻辑，所以前面提到的同步方案可能都用不上。

　　而对于一些同步要求很高的游戏，如WOW中盗贼这类职业的需求，上面的方案可能还不够细致，还需要设计更加有效的同步方案。

　　另外，在位置同步过程中还有一个不容忽视的问题是外挂。我们不能像WOW那样完全依赖客户端，如果没有暴雪那样强硬的封号措施，游戏也就成为了外挂们的温床。所以，如何在服务器端模拟每个客户端的移动，如何检测出客户端是否存在作弊行为，也是需要重点关注的一个问题。