开发宝典基于分布式对象的网游程序结构设计

1、 开发宝典：基于分布式对象的网游程序结构设计【编者按】目前，网游市场日趋激烈，每年新增的网游都有几十款之多。对于一个玩家来说，每款都下载，都去体验一下；不管游戏是否好玩，是否符合自己的品味，先花几个小时下载安装，不喜欢的话再卸载，其间还可能遇到各种各样的问题，耗费时间和精力，是不会有玩家这样做的。提高游戏的可体验性，易安装性，乃至于不需要安装。直接在游戏中体验游戏的优劣，比之宣传广告，能够给玩家更加直观的感受，是最佳的游戏推广方式。这应该是游戏开发的一个趋势。易安装，不安装，类网页游戏应该成为游戏发展的一个方向。基于分布式对象的网游程序结构设计(1) - 开篇Web浏览器和游戏毕竟不是一个事物

2、。Html超文本协议(虽有VB，javascript等脚本语言作为补充)也不完全适用于网游。之所以类比，是进一 步强调免安装，易于体验性的重要性。当然，Web技术也在不断发展，不仅出现很多Web浏览器上运行的网游，其图形和图像方面的功能也在不断丰富，本文将 在第二部分，对Web相关技术的发展进行一个探讨。基于分布式对象的网游程序结构设计(2) -Web技术的发展和网页游戏Web技术之所以能够如此快速发展，究其根源，在于基于BS结构的分布式应用，客户端不再需要部署其它软件，降低了发布成本和维护成本。并且使用浏览器， 能够浏览各种网页，且与平台无关，不管网页服务器运行在Windows，Unix，还

3、是其它操作系统上面。如果不是这个特性，Web技术和浏览器应用不会 发展如此之快，这点谁都不能够否认。也正是由于这点特性，带动了整个Internet的发展，促进了Web相关的各种技术的研究。基于分布式对象的网游程序结构设计(3) - 分布式组件模型DCOM/COBRA 分布式组件技术是一种CS结构，其出现，是为了简化网络编程，开发者不再需要关心具体如何进行底层通信。目前比较有代表性的有两种：DCOM和 COBRA。DCOM使用ORPC机制，COM服务器创建对象类的实例，一个COM对象可以具有多个接口，分别代表不同的观察角度和不同的对象行为。客户 端获取对象接口的指针，通过指针调用相关的方法。基于

4、分布式对象的网游程序结构设计(4)-SRP分布式对象的概念作为游戏中的一个角色。在服务器端和客户端同时存在，服务器端负责角色对象的逻辑，以及各种属性的更新；客户端负责角色对象的显示，与玩家进行交互。这应 该是一种非常典型的分布式对象模式。但是目前的分布式对象技术，能够支持这种模式吗；答案是不支持，没有使用Web Service或者 Cobra/DCom开发的游戏。因此可以说目前的分布式对象的 概念，还存在不完善的地方。=基于分布式对象的网游程序结构设计(1) Web技术之所以能够如此快速发展，究其根源，在于基于BS结构的分布式应用，客户端不再需要部署其它软件，降低了发布成本和维护成本。并且使用

5、浏 览器，能够浏览各种网页，且与平台无关，不管网页服务器运行在Windows，Unix，还是其它操作系统上面。如果不是这个特性，Web技术和浏览器应 用不会发展如此之快，这点谁都不能够否认。也正是由于这点特性，带动了整个Internet的发展，促进了Web相关的各种技术的研究。提到Web，我们都会联想到各种名词和概念，Http，Java，ASP，SOAP等等，一方面反映了技术发展蓬勃向上，欣欣向荣的趋势，也在另一 个侧面，说明了Web技术发展本身缺乏系统性和完整性。也就是说，在各种Web应用过程中，发现缺少什么，还有什么不方便，那么就补充什么，继而引入新的 概念和技术。最早超文本描述语言HTM

6、L是静态的，在客户端表现力不丰富。服务器端存储的网页，只能够下载到客户端进行显示浏览，客户端的操作需要提交到服务器 进行处理，即便类似于简单的输入参数的验证，在客户点击确认之后，也由服务器进行校验；如果输入错误，客户端需要等到几秒甚至几十秒的时间，才能够得到反 馈。改变这一现状的是1995年，Netscape引入的Javascript，使得在客户端能够执行脚本。解决了这一问题，程序员可以使用脚本语言，创 建内容和表现力更加丰富的HTML页面。AJAX进一步提高了页面的表现力和客户的体验。AjAX不是一个新的技术，1999年，微软的IE5就支持这种特性，只不过当时并没有得到认可。 AJAX的核心

7、思想是异步操作，可以通过JAVAScript和VBScript调用。客户端在提交请求之后，不再需要等待响应。当收到服务器响应之后， 使用JavaScript和CSS更新页面相应的部分，而不需要更新整个页面。在服务器端，最早的Web服务器只是简单的接收Http请求，并将存储在服务器上的Html页面，传送给浏览器。CGI技术的出现，使动态页面生成 成为可能。允许服务器端的应用程序，根据客户端的请求，动态生成HTML页面。使客户端和服务器端能够进行动态信息交换，可以根据客户端请求，当前服务状 态，以及数据库的内容，为客户订制页面。随着CGI技术的发展，聊天室，论坛，电子商务等各种各样的Web应用程序

8、也蓬勃兴起。早期的CGI是可执行程序，用C/C+等语言开发。为了简化CGI程序的修改，发布和编译。逐渐采用脚本语言编写CGI程序。最早出现的是Perl语言编写的CGI程序，后来出现了多种脚本语言，PHP，ASP，Servelet等。 Web技术的发展，也促进了基于Web的各种分布式应用的技术的提出和发展，最具代表性的是Web Service技术。简单的说，Web Service就是一种应用程序，可以使用标准互联网协议进行远程调用。其核心的内容是简单对象访问协议SOAP，和Web Service描述语言(WSDL)。SOAP定义了消息格式，以及如何通过Http协议传输SOAP。WSDl用于描述W

9、eb Service及其函数，参数，以及返回值。WSDL是文本格式，可以通过工具，生成对应的调用的桩函数代码。 基于浏览器Web应用和服务可以用下面的图形象的描述：HTML描述了Web Server和浏览器之间的数据格式。WSDL描述了Web Service的特性，但是它不描述Web Service和浏览器之间的数据包格式。 从概念上讲，Web Server及其上的各种应用，诸如：各种网站，论坛，博克等，都可以看作是Web Service，它们提供的是一种信息服务。目前对Web Service的概念诠释为一种可以通过Web远程访问的者一组函数库。根据词义来说，服务和函数不是一个概念，正如函数不

10、是应用程序一样。一组函数放在 一起，绝不能够说是一个应用程序，应用程序具有整体上的完整性，能够对外提供某些功能。从这一点上说，对于稍微复杂一些的Web服务，都不是简简单单的远 程调用。因此说，目前Web Sevice的发展还处于初级阶段，就好像90年代初的静态网页一样，随其发展和需求的不断增加和明确，肯定会不断出现新的概念和技术。在Web Service中，比较重要的两个名词是SOAP和WSDL。SOAP描述了调用接口的传输格式，WSDL描述了提供的服务的内容，参数，返回数值等。在 Web技术的发展过程中，形成了一种既定的概念或者结论，那就是服务器端和客户端是独立的应用，两者之间只在底层传输接

11、口上进行交互。虽然也出现了一些浏 览器的插件，将某些功能由服务器端下载到客户端执行，但是并没有打破这种概念。这就要求客户端，特别是客户端的开发者，从接口上去观察和理解Web服务。 虽然WSDL可以描述服务的内容参数，但是随着服务变得越来越大，功能越来越多，各式各样，不同类型的服务，势必导致WSDL越来越复杂。即便简单的Web服务，用WSDL描述起来也不简单；其文本格式，与其说是为了方便进行开发人员参考，还不如说主要为避免了通信上的问题（不同操作 系统，不同模式的计算机都能够解析）。作为开发者，直接使用底层的Web Service接口，难度比较大。相当于将通信处理，接口的编解码全部由开发者承担，

12、而且不同的Web服务，这些是不同的，可以想象是多么大的一个工作 量；因此，一般是利用一些工具，根据WSDL生成客户端调用的桩，自动生成的代码有时不能够完全满足要求，此时还需要进行一些直接面对底层的开发工作。客户端使用桩函数进行开发，上图略为做些修正：Web Service Stub虽然是自动生成的，但是其代表了Web Service定义的功能在浏览器或者客户端的映射。开发者直接了解Stub提供的功能和如何调用即可，不再需要关心如何编码，如何传输，也不用关系如何 在Stub和Web Service之间传递消息的。这不仅仅简化了开发工作，而且在概念和Web Service整体架构上，前进了很大的一

13、步。不再通过传输接口调用服务器提供的Web服务，而是在本地，直接调用Web服务的桩，是一个概念和思路的转 变。 试想一下，如果我们将Web Service对上的接口标准化，将会是什么结果呢？明显一点，在Web Service Stub与Web Service服务器之间的过程，对使用者来说变成透明的，不再需要关心。Web Service可以采用任何语言实现，可以用Javascript，VBScript，还可以是效率高的C/C+，两者之间的通信是Web服务的内部事 务，可以使用SOAP，也可以使用任何自定义的或者任何熟知的协议。这将对Web技术的发展产生深远的意义。在这种思想下，上图修正如下： W

14、eb Service Stub对上的标准接口，需要体现Web Service提供的各种服务，需要能够描述任何Web服务。最适合的方法是采用对象的概念，描述一个Web服务。一个Web服务，由多个对象组成，每个 对象有属性和方法。客户端可以通过对象的方法，完成对服务的调用。比如，Web Service中包含有一个当前天气的对象，有温度，风速等属性，在客户端，直接读取对象的属性，即可完成对Web Service的调用。 基于这种概念提出的模型，就是本文重点研究的分布式对象模型，如下图：其中，蓝色的部分构成了分布式对象平台。 基于BS的各种Web应用，其优点是不需要部署和安装。但是，HTML,HTTP

15、最初都是针对文本信息的，虽然扩充了很多内容，诸如：动态网页，客户端插 件等，力求丰富客户端的功能。但是其本身存在一些固有的缺憾，这对某些方面的应用，如网页游戏的应用，将是一个很大的限制。1数据和资源文件反复下载在BS应用中，通过URL定位资源或者数据文件，在打开网页时，虽然图像等文件已经下载到本地了，但是在刷新时，还需要下载。虽然浏览器都提供了本 地的Cache，针对相同的URL可以减少一些重复下载。但是，基于URL的缓存并不能够说明数据的内容是否发生变化了，是否应该下载，这在有些应用的时 候会产生一些问题，以致于对于同一资源，需要使用不同的URL才能够在客户端正确刷新。数据本身的变化（例如图

16、片发生变化），需要通过更新URL才能够正 确下载，这本身就不是一种合理的处理方式。2不方便维护客户端状态维护服务器端不维护客户的状态，客户端重新打开网页，与第一次打开网页，对于服务器来说，没有什么不同。虽然使用Cookie能够在一定程度上解决这个 问题，但是不是一种很好的方式，Cookie每次在客户端和服务器端的传输，都增加了通信的开销，再者Cookie在数量和大小上是有限制的。3服务器端不能够主动发起数据的传输。由于服务器端与客户端是无连接的，在某些应用场合，如果服务器端需要主动给客户端发消息，比如实现聊天室的功能，一个用户的发言，需要广播给其他客户端，实现就存在一些困难，需要用其它途径解决

17、。这点恰巧是网友中必须实现的重要功能。4编码简单，通信传输的开销大在服务器和客户端传输使用文本方式编码，对于需要大量信息交互和频繁交互的应用场景下，通信传输占据的开销很大。 目前网页游戏的特点都是偏向于休闲，交互性不是很强，画面表现力也不丰富。网页游戏只能够在游戏内容上，力求新颖，吸引玩家。其进一步，特别是在表现力和交互性上的发展，将受到BS结构上述问题的限制。=基于分布式对象的网游程序结构设计(3) - 分布式组件模型DCOM/COBRA 虽然在游戏开发中，很少使用DCOM/COBRA分布式组件技术。但是作为一种分布式技术，这里也分析一下存在的问题。分布式组件技术是一种CS结构，其出现，是为

18、了简化网络编程，开发者不再需要关心具体如何进行底层通信。目前比较有代表性的有两种：DCOM和 COBRA。DCOM使用ORPC机制，COM服务器创建对象类的实例，一个COM对象可以具有多个接口，分别代表不同的观察角度和不同的对象行为。客户 端获取对象接口的指针，通过指针调用相关的方法。COBRA是由OMG（Object Manage Group）提出的，其核心是ORB（Object Request Broker）。作为一个透明的总线式模型，可以与本地或者远程的对象进行交互。COBRA对象对外呈现一组接口，客户端获取对象的引用，通过引用进行方 法的调用。ORB负责查找对象的实现，发送请求并处理返

19、回结果。两种组件模型都采用CS模式的通信。为了调用一个服务，客户端需要调用远程对象实现的方法。服务器端提供的服务，封装成为一个对象，对象的接口使用 IDL（Interface Definition Language）描述。客户端通过调用IDL中定义的方法与服务器端进行交互，不用关心实际对象的实现。支持面向对象的一些特性，例如：数据封装，多 态，继承。COBRA支持多重继承，DCOM不支持，但是一个对象可以有多个接口。 为了调用一个远程的方法，客户端调用本地的桩函数，桩函数将参数封装成为请求，将请求发送给服务器端。服务器端将请求传递给Server Stub，对参数进行解包，并调用实际的函数。在D

20、COM中，客户端的桩称为proxy，服务器端的桩称为stub；在COBRA中，客户端的桩称为 stub，服务器端的桩称为skeleton。 假设有一种Grid对象服务，Grid对象维护一个二维的整数，支持两组方法：第一组是get和set，可以设置某个格子上的数值；第二组是reset， 复位某个格子上的数值。则对于COBRA，需要定义三个接口，接口Grid1支持get和set；接口Grid2支持reset；接口Grid继承 Grid1,Grid2。使用DCOM，则定义两种IGrid1和IGrid2。 采用DCOM调用，则客户端端的处理步骤如下：1 客户端调用COM库函数CoCreateInsta

21、nce，使用CLSID_Grid和IID_IGrid1作为参数。2 COM库请求服务器创建对象3 服务器端COM获取指向CLSID_Grid的类工厂指针，调用其CreateInstance函数。4 类工厂创建一个对象，然后服务器端调用QueryIntreface获取指向IID_IGrid1接口的指针。5 COM库将指向pIGrid1接口的指针返回给客户。6 客户端调用pIGrid1接口的get方法。 采用COBRA调用，则客户端端的处理步骤如下：1 客户端调用桩函数grid:_bind()。2 ORB向Server发起请求3 服务器端创建实例，调用CORBA:BOA:impl_is_ready

22、()，通知ORB对象已经准备好。4 ORB向客户端返回对象的引用5 客户端调用对象的方法。在上面的处理步骤中每个步骤，COM库或者ORB都需要进行很多操作，因此调用的效率不高，只能够进行粗粒度的调用。例如一个服务上有几十个对象，如果通过上述方法获取对象的内容并进行显示，处理和流程将会多么复杂。 对象引用在客户端应用中创建，并且是动态创建的，因此当服务器端组件是细粒度，对象很多时，这种代价是非常高的。 相比Web Service，WSDL描述的服务方法参数和返回值，类似于组件对外的接口，但是在进行Web Service进行调用时，不需要创建对象，也没有对象的概念。而是直接使用URL，定位到了需要

23、调用的服务器端的对象。因此，Web Service与组件模型相比，调用需要的交互要少一些。 在DCOM和COBRA中，由于对象的创建导致交互很多，不适合于细粒度的模型。但是如果将服务器端组件的对象预先创建好，并引入对象管理功能，在客户端访问服务器端时，一次性的在客户端创建相应的对象，则可以解决这个问题，如下图： DCOM和COBRA在开发和部署上都相对复杂，影响了其发展和应用。=SRP分布式对象的概念 作为游戏中的一个角色。在服务器端和客户端同时存在，服务器端负责角色对象的逻辑，以及各种属性的更新；客户端负责角色对象的显示，与玩家进行交互。这应 该是一种非常典型的分布式对象模式。但是目前的分布

24、式对象技术，能够支持这种模式吗；答案是不支持，没有使用Web Service或者Cobra/DCom开发的游戏。因此可以说目前的分布式对象的 概念，还存在不完善的地方。本节针对此问题进行讨论，并提出SRP分布式对象的概念。目前对于分布式对象的概念，一般指RMI、COBRA、DCOM等分布式组件技术。但是我们认为对象应该是具有属性的，不应该只有方法；在面向对象编程语 言中的对象概念更加贴切。而目前的组件技术，都是只提供了一个抽象的接口，即便是Web Service，也只供了远程调用的方法（可以看作是一个抽象的接口），并没有提及属性，而且也不支持定义属性。在分布式应用中，对象的属性重要吗？目前 的

25、组件技术和Web Service技术，都没有定义属性，不是发展的很好，也能够方便的应用于各种场合下吗？回答这个问题，这里简单的给出一个例子：对象在某些状态下（例如：忙），某些接口不能够调用（例如：查询），调用会返回错误。按照目前组件技术的描述方法，如下：Interface objectclasschar *Query( in int arg, out int result); ; 对于该组件的使用者，如何调用呢，反复调用Query函数，直到正确的结果吗？这个例子非常简单，但是使用目前的分布式组件技术，很难实现。对象的属性分 布到客户端（调用者），有利于客户端根据对象的状态，更加灵活地进行服务调

26、用，为客户提供更好的服务。仅仅是对象的属性分布到客户端就够了吗？回想前面对于Web技术的发展过程中，javascript为什么引入，并得到迅速发展。在客户端和服务器端进行交互时，如果客户端能够进行一些预先的处 理，也能够提供更好的服务。比如简单类似输入参数的校验问题，如果在客户端能够进行，则不再需要再发送到服务器，并等待几秒甚至几十秒之后，再得到错误的 反馈。这需要把部分对象的脚本（甚至代码）也需要部署到客户端，Web Service和组件模型提出了一种新的编程模型，这也是出现和发展起来的原因。但是快速发展不能够说明这些技术本身不存在问题，对于相对复杂的Web服 务，细粒度的组建服务，这些技术还不是很成熟，或者说，不能够进行处理。本文提出的SRP分布式对象模型，解决了这些问题。这里提出的分