开发一款网络游戏，不能够回避以下两个问题，
如何吸引玩家安装或者体验我们的游戏；
如何留住玩家，同时吸引更多的玩家。
其中第一个问题是最关键的，如果玩家连安装和体验都不进行，如何谈得上留住玩家，更谈不上吸引更多玩家。目前，网游市场日趋激烈，每年新增的网游都有几十款之多。对于一个玩家来说，每款都下载，都去体验一下；不管游戏是否好玩，是否符合自己的品味，先花几个小时下载安装，不喜欢的话再卸载，其间还可能遇到各种各样的问题，耗费时间和精力，是不会有玩家这样做的。
因此对于一款游戏，一款好游戏。在推广的初期，需要大量的广告和宣传投入。这对于一个小规模的公司或者企业来说，无疑是一个巨大的负担。试想，玩家连装都不安装，如何谈得上留住玩家，拓展玩家。
提高游戏的可体验性，易安装性，乃至于不需要安装。直接在游戏中体验游戏的优劣，比之宣传广告，能够给玩家更加直观的感受，是最佳的游戏推广方式。这应该是游戏开发的一个趋势。易安装，不安装，类网页游戏应该成为游戏发展的一个方向。
类网页游戏是一个概念，不是专指在浏览器中运行的游戏，而是指任何不需要下载和安装的网络游戏。近二十几年来，internet技术发展很快，甚至连中小学生都能够上网，浏览各种信息。这一方面归功于底层网络的建设和发展，也要归功于Web浏览器技术的发展。如果每个网站制作的页面，都需要下载安装之后才能够进行浏览，那么，internet技术不会发展如此之快，也不会这么快进入到信息时代。
当然，Web浏览器和游戏毕竟不是一个事物。Html超文本协议(虽有VB，javascript等脚本语言作为补充)也不完全适用于网游。之所以类比，是进一步强调免安装，易于体验性的重要性。当然，Web技术也在不断发展，不仅出现很多Web浏览器上运行的网游，其图形和图像方面的功能也在不断丰富，本文将在第二部分，对Web相关技术的发展进行一个探讨。
针对免安装，这里提出一种新的基于分布式对象的网游程序架构，通过分布式对象管理功能，构建一个类似于Web浏览器的通用网游平台，实现网游的免安装特性。内容和章节如下安排：
Web相关技术的发展和网页游戏。
分布式组件模型DCOM/COBRA
分布式对象的概念
分布式对象的特点
分布式对象引出的系列技术
基于分布式对象的网游程序结构和优点
这里所提出或者提及的观点，不是空洞的概念。本文分析了Web技术发展中可能遇到的问题，指出了DCOM和COBRA等组件模型存在的缺憾，随之提出一种分布式的对象模型，并基于此模型设计了一种类网页的游戏程序结构。文中提到的大部分概念，目前已经由星河平台在最新发布的版本实现。其最新版本同时包含有一个相对完整的2D网游引擎和相关工具，可用于大型2D网游的开发。有兴趣的朋友可访问网站http://www.srplab.com。
在星河平台上开发应用，据其特点，或许可以不必担心受平台的限制。一方面，在平台上开发的应用脚本，可以完全导出为XML文本文件；另一方面，开发的对象的动态库，基于平台相对简单的规范，依据其接口，完全可以自行进行开发（这与Dcom，Cobra，Web服务等技术不同，相对比较简单，并且诸如DCOM，已经成为操作系统的一部分，纵然知道其原理，自行开发DCOM模块基本是不可能的）当然，这不是必要的，星河工作室将一直维护星河平台，共同建立一个统一的网游开发平台，减少重复开发导致的资源浪费。使游戏公司将更多的精力放在游戏的内容开发上，打造更多的精品游戏。
虽然目前星河平台仅仅实现2D部分，但是，到3D可以平滑过渡，目前定义的2D对象和类，仍然可以使用。下图是一个Irrlicht引擎中的一个例子，使用目前平台2D引擎中的对象，完全可以嵌入到3D的例子中显示帧频[显示的帧频是一个平台中的2D Label对象]：
1 Web技术的发展和网页游戏
Web技术之所以能够如此快速发展,究其根源,在于基于BS结构的分布式应用,客户端不再需要部署其它软件,降低了发布成本和维护成本。并且使用浏览器,能够浏览各种网页,且与平台无关,不管网页服务器运行在Windows,Unix,还是其它操作系统上面。如果不是这个特性,Web技术和浏览器应用不会发展如此之快,这点谁都不能够否认。也正是由于这点特性,带动了整个Internet的发展,促进了Web相关的各种技术的研究。
提到Web,我们都会联想到各种名词和概念,Http,Java,ASP,SOAP等等,一方面反映了技术发展蓬勃向上,欣欣向荣的趋势,也在另一个侧面,说明了Web技术发展本身缺乏系统性和完整性。也就是说,在各种Web应用过程中,发现缺少什么,还有什么不方便,那么就补充什么,继而引入新的概念和技术。
最早超文本描述语言HTML是静态的,在客户端表现力不丰富。服务器端存储的网页,只能够下载到客户端进行显示浏览,客户端的操作需要提交到服务器进行处理,即便类似于简单的输入参数的验证,在客户点击确认之后,也由服务器进行校验;如果输入错误,客户端需要等到几秒甚至几十秒的时间,才能够得到反馈。改变这一现状的是1995年,Netscape引入的javascript,使得在客户端能够执行脚本。解决了这一问题,程序员可以使用脚本语言,创建内容和表现力更加丰富的HTML页面。
AJAX进一步提高了页面的表现力和客户的体验。AjAX不是一个新的技术,1999年,微软的IE5就支持这种特性,只不过当时并没有得到认可。AJAX的核心思想是异步操作,可以通过javascript和VBScript调用。客户端在提交请求之后,不再需要等待响应。当收到服务器响应之后,使用javascript和CSS更新页面相应的部分,而不需要更新整个页面。
在服务器端,最早的Web服务器只是简单的接收Http请求,并将存储在服务器上的Html页面,传送给浏览器。CGI技术的出现,使动态页面生成成为可能。允许服务器端的应用程序,根据客户端的请求,动态生成HTML页面。使客户端和服务器端能够进行动态信息交换,可以根据客户端请求,当前服务状态,以及数据库的内容,为客户订制页面。随着CGI技术的发展,聊天室,论坛,电子商务等各种各样的Web应用程序也蓬勃兴起。
早期的CGI是可执行程序,用C/C++等语言开发。为了简化CGI程序的修改,发布和编译。逐渐采用脚本语言编写CGI程序。最早出现的是Perl语言编写的CGI程序,后来出现了多种脚本语言,PHP,ASP,Servelet等。
Web技术的发展,也促进了基于Web的各种分布式应用的技术的提出和发展,最具代表性的是Web Service技术。简单的说,Web Service就是一种应用程序,可以使用标准互联网协议进行远程调用。其核心的内容是简单对象访问协议SOAP,和Web Service描述语言(WSDL)。SOAP定义了消息格式,以及如何通过Http协议传输SOAP。WSDl用于描述Web Service及其函数,参数,以及返回值。WSDL是文本格式,可以通过工具,生成对应的调用的桩函数代码。
基于浏览器Web应用和服务可以用下面的图形象的描述:
[见附件文档]
HTML描述了Web Server和浏览器之间的数据格式。WSDL描述了Web Service的特性,但是它不描述Web Service和浏览器之间的数据包格式。
从概念上讲,Web Server及其上的各种应用,诸如:各种网站,论坛,博克等,都可以看作是Web Service,它们提供的是一种信息服务。目前对Web Service的概念诠释为一种可以通过Web远程访问的者一组函数库。根据词义来说,服务和函数不是一个概念,正如函数不是应用程序一样。一组函数放在一起,绝不能够说是一个应用程序,应用程序具有整体上的完整性,能够对外提供某些功能。从这一点上说,对于稍微复杂一些的Web服务,都不是简简单单的远程调用。因此说,目前Web Sevice的发展还处于初级阶段,就好像90年代初的静态网页一样,随其发展和需求的不断增加和明确,肯定会不断出现新的概念和技术。
在Web Service中,比较重要的两个名词是SOAP和WSDL。SOAP描述了调用接口的传输格式,WSDL描述了提供的服务的内容,参数,返回数值等。在Web技术的发展过程中,形成了一种既定的概念或者结论,那就是服务器端和客户端是独立的应用,两者之间只在底层传输接口上进行交互。虽然也出现了一些浏览器的插件,将某些功能由服务器端下载到客户端执行,但是并没有打破这种概念。这就要求客户端,特别是客户端的开发者,从接口上去观察和理解Web服务。虽然WSDL可以描述服务的内容参数,但是随着服务变得越来越大,功能越来越多,各式各样,不同类型的服务,势必导致WSDL越来越复杂。
即便简单的Web服务,用WSDL描述起来也不简单;其文本格式,与其说是为了方便进行开发人员参考,还不如说主要为避免了通信上的问题(不同操作系统,不同模式的计算机都能够解析)。作为开发者,直接使用底层的Web Service接口,难度比较大。相当于将通信处理,接口的编解码全部由开发者承担,而且不同的Web服务,这些是不同的,可以想象是多么大的一个工作量;因此,一般是利用一些工具,根据WSDL生成客户端调用的桩,自动生成的代码有时不能够完全满足要求,此时还需要进行一些直接面对底层的开发工作。
客户端使用桩函数进行开发,上图略为做些修正:
[见附件文档]
Web Service Stub虽然是自动生成的,但是其代表了Web Service定义的功能在浏览器或者客户端的映射。开发者直接了解Stub提供的功能和如何调用即可,不再需要关心如何编码,如何传输,也不用关系如何在Stub和Web Service之间传递消息的。这不仅仅简化了开发工作,而且在概念和Web Service整体架构上,前进了很大的一步。不再通过传输接口调用服务器提供的Web服务,而是在本地,直接调用Web服务的桩,是一个概念和思路的转变。
试想一下,如果我们将Web Service对上的接口标准化,将会是什么结果呢?明显一点,在Web Service Stub与Web Service服务器之间的过程,对使用者来说变成透明的,不再需要关心。Web Service可以采用任何语言实现,可以用javascript,VBScript,还可以是效率高的C/C++,两者之间的通信是Web服务的内部事务,可以使用SOAP,也可以使用任何自定义的或者任何熟知的协议。这将对Web技术的发展产生深远的意义。
在这种思想下,上图修正如下:
[见附件文档]
Web Service Stub对上的标准接口,需要体现Web Service提供的各种服务,需要能够描述任何Web服务。最适合的方法是采用对象的概念,描述一个Web服务。一个Web服务,由多个对象组成,每个对象有属性和方法。客户端可以通过对象的方法,完成对服务的调用。比如,Web Service中包含有一个当前天气的对象,有温度,风速等属性,在客户端,直接读取对象的属性,即可完成对Web Service的调用。
基于这种概念提出的模型,就是本文重点研究的分布式对象模型,
其中,蓝色的部分构成了分布式对象平台。
基于BS的各种Web应用,其优点是不需要部署和安装。但是,HTML,HTTP最初都是针对文本信息的,虽然扩充了很多内容,诸如:动态网页,客户端插件等,力求丰富客户端的功能。但是其本身存在一些固有的缺憾,这对某些方面的应用,如网页游戏的应用,将是一个很大的限制。
1. 数据和资源文件反复下载
在BS应用中,通过URL定位资源或者数据文件,在打开网页时,虽然图像等文件已经下载到本地了,但是在刷新时,还需要下载。虽然浏览器都提供了本地的Cache,针对相同的URL可以减少一些重复下载。但是,基于URL的缓存并不能够说明数据的内容是否发生变化了,是否应该下载,这在有些应用的时候会产生一些问题,以致于对于同一资源,需要使用不同的URL才能够在客户端正确刷新。数据本身的变化(例如图片发生变化),需要通过更新URL才能够正确下载,这本身就不是一种合理的处理方式。
2. 不方便维护客户端状态维护
服务器端不维护客户的状态,客户端重新打开网页,与第一次打开网页,对于服务器来说,没有什么不同。虽然使用Cookie能够在一定程度上解决这个问题,但是不是一种很好的方式,Cookie每次在客户端和服务器端的传输,都增加了通信的开销,再者Cookie在数量和大小上是有限制的。
3. 服务器端不能够主动发起数据的传输。
由于服务器端与客户端是无连接的,在某些应用场合,如果服务器端需要主动给客户端发消息,比如实现聊天室的功能,一个用户的发言,需要广播给其他客户端,实现就存在一些困难,需要用其它途径解决。这点恰巧是网友中必须实现的重要功能。
4. 编码简单,通信传输的开销大
在服务器和客户端传输使用文本方式编码,对于需要大量信息交互和频繁交互的应用场景下,通信传输占据的开销很大。
基于BS结构的网页游戏,不可避免的存在这些问题。近些年来,网页游戏作为网络游戏的一个特殊的分支,发展也很快。其优点来自于BS架构,不需要安装,并且可以穿越防火墙(一般防火墙对于80或者8080端口都是开放的),因此针对与上班一族,有着先天的优势。在网站http://www.webgame.com.cn上,有当前很多流行的网页游戏介绍。
目前网页游戏的特点都是偏向于休闲,交互性不是很强,画面表现力也不丰富。网页游戏只能够在游戏内容上,力求新颖,吸引玩家。其进一步,特别是在表现力和交互性上的发展,将受到BS结构上述问题的限制。