J2ME多人游戏注意事项(笔记类) |
| 作者:未知 来源:转载 发布时间:2005-8-2 9:12:21 |
|
一 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) 高分表 玩家之间交谈 显示延时 ... |
| [] [返回上一页] [打 印] |
|
文章评论 |
