J2ME多人游戏注意事项(笔记)

一 MIDP通讯技术

1. HTTP:
当网络中的真实电话配置HTTP流MIDlet的时候,不要尝试一次只发送一小段数据:在发完全部数据之前,不会收到什么东西。

当从服务器发送HTTP响应要被延迟到某个事件发生,移动网络中开发连接可能很昂贵,通常会因超时而被中端,这一情况比在互联网上更容易发生。

移动电话通常没有资源去支持多重开放的HTTP连接。在数据结构和数据缓存方面的开销非常大。

HTTP 方法

GET:用于向服务器请求一个静态资源,重复一个GET请求将得到相同的资源响应。GET请求仅提供资源的URL,不包括任何消息体。

POST:用于向服务器请求一个动态资源(如游戏中的一个回合),重复一个POST请求将得到不同的资源响应。POST响应也包括一个带服务响应数据的消息体,是MIDlet的常用方法。

来自某个服务器的HTTP响应可能包含成功(2xx)、重定向(3xx)或错误(4xx, 5xx)之类的状态码。这些代码需要由HTTP客户端处理。

HTTP消息体

发送的信息只是一串字节流,可以对这些字节信息进行编码,包括:

文本;图像文件(至少支持对PNG解码);XML;其它用户定制数据结构。

HTTP会话

服务器把MIDlet发起的一系列连续请求作为一个HTTP会话来跟踪,由于HTTP本身是无状态的,所以必须在HTTP协议层之上实施会话管理。

方法一:各种会话cookie。

方法二:URL重写。

由于cookie还有其它用途,所以处理会话cookie的完整MIDlet实现起来比较复杂,重新URL则简单许多。

HTTP服务器

有包括java servlet, jsp, asp, asp.net, cgi script在内的多种选择。

2. TCP:

互联网上的http通常以TCP实现,TCP连接的端点是一个套接字socket。MIDP 1.0 不包括对TCP的支持,MIDP 2.0 规定了对TCP的支持,制造商可以自己选择是否包含这种支持。

3. UDP:

使用UDP时,两台正在通讯的设备间所发送的数据报(datagram)往往也被称为数据包(data packet), MIDP 1.0 不包括对UDP的支持,MIDP 2.0 规定了对UDP的支持,制造商可以自己选择是否包含这种支持。在诸如GPRS这样的分组交换协议上实现时,考虑到移动网络的响应时间,包的发送量一般并不需要超过每秒一个,并注意包的大小。
4. 串行电缆

MIDP 2.0中通过接口SerialPortConnection实现支持。

5. 红外

MIDP 2.0中通过接口SerialPortConnection实现支持。

6. 蓝牙(MIDP可选包通讯技术)

一种短程无线技术,支持约10米范围最多8台设备一起通讯,响应时间短,非常适合于多人游戏(由于蓝牙超各个方向传输,彼此之间不必正对)。

7. SMS短消息服务

SMS(Short Message Service)可以发送文本消息或者是二进制数据,是一种“存储转发”技术。通过一台短消息服务中心(SMSC)保存消息在队列中,并稍后转发。

8. MMS多媒体消息服务

是SMS的一种升级版本,允许把一段消息分成几部分,包括文本,图片,声音以及视频,也是一种“存储转发”技术。MMS实现综合使用了SMS和HTTP。

二. 游戏服务器技术

HTTP和HTTPS

在服务器端,你可以使用任何一种通常用于HTTP服务器的技术,如:静态网页、CGI、ASP、Java servlet,以及JavaServer Page(JSP)。Java程序员通常的选择是Java servlet。

三游戏类型及相关注意事项

多玩家单人游戏 & 回合制游戏:

这种游戏的特点是玩家轮流上阵,没有用到网络,也不会受网络延世的限制。

循环赛游戏 & 同时行动游戏:

当使用MIDP 1.0,可以选择HTTP,但HTTP有一个重大缺点,游戏服务器无法告知MIDP客户端:现在轮到你了,所以客户端必须测试,定时询问游戏服务器:轮到我了么,所以应该考虑提供一种能中断等待并立即开始下一次查询的方案。

MIDP 2.0,TCP可能是最佳选择,轮到一个玩家时,服务器会立即通知他,这很重要,因此UDP就可能不太适合。另外,在循环赛中,TCP可能导致的额外延时并不成为问题。

“随时玩”类型游戏:

如果游戏中涉及实时动作,HTTP的延时就会显得过于严重。用MIDP 2.0时应该考虑UDP, TCP,或两者结合。移动网络的延时对快速的,实时的多人交互游戏来说影响太大了。

四. 多人游戏共通特性

永久性用户帐户

游戏大厅(Lobby)

高分表

玩家之间交谈

显示延时 …