在“J2ME平台上开发网络即时战略游戏”，这个话题在现今大多数J2ME 开发者听来无异于天方夜谭。即时战略游戏名字的“即时”两个字决定了复杂的运算和数据交互、稳定快速的网络连接要求、庞大的资源和绘制任务，我们都知道J2ME设备的资源和性能都极为有限，现有GPRS网络业不尽如人意……这些似乎都成为了在J2ME上开发网络即时战略游戏不可逾越困难。
困难实实在在的挡在我们面前，但中国三亿手机用户中蕴藏的庞大的潜在即时战略玩家促使我们去克服这些困难，只要还有一点可能，我们也要去寻找一条跨过这些障碍的道路。怎么样才能在手机上实现网络即时战略游戏呢？
从性能和用户量考虑，我们选择诺基亚的60系列作为初期的开发平台。我们不考虑采用HTTP协议，虽然它是J2ME设备中普遍采用的协议，但其相对SOCKET的低效性和本身是无连接协议决定了它不适合即时战略这种游戏形式。从上表可以看出建立连接的时间要高出连接后的数据传送时间许多，HTTP协议需要花费许多额外开销在建立连接上；HTTP平均的数据传送时间也要比SOCKET高许多。我们测试了大部分的60机型（7650, 3650, 3660, 6600, N-GAGE, N-GAGE QD），所有测试的机型均支持socket。
从上面可以看出，socket连接数据往返一次的平均时间在1～2秒间，这对回合制的战略游戏或许足够，但对即时战略游戏来说还是太长了。有什么办法能大幅压缩数据传送的时间呢？我们可以从server和数据包协议考虑。
以上测试的服务器是用Serverlet写的，而serverlet是构建在Web server上的，那么这个数据里包含的服务器反应和处理的时间就不容忽略了，为了获得更快的响应和处理速度，我们必须重新设计和构建游戏的专用Server。传送的数据包大小也是影响速度的一个要害。平时大家开发J2ME的网络应用，习惯于用文本流来传送数据，因为大多数应用Server端都是基于Web Server，而且采用文本表示信息非常直观，也便于Server处理，但对于J2ME平台和gprs网络来说，没有经过压缩的文本还是浪费了一些。
简单考虑一下游戏服务器：一台主机应该能支撑一百到两百名玩家同时在线；为了便于配置，Server应用应该是跨平台的，而客户端也是J2ME的，因此Server的开发环境Java当是首选；采用Java 1.4后新增的Java 异步通信功能，性能上也能达到我们的要求。
因为Server必须我们自己写，所以没有必要使用文本编码协议，代之以字节流编码。简单估算一下，表示相同的信息，采用文本和字节编码方式数据大小的比例大于4：1，而且数据本来以数字为主，省去了文本转换的一大笔开销。更小的数据相应的也带来了更快的速度，另外，也为用户节省了大笔昂贵的GPRS流量开支。
采取以上的措施后，我们再次测试了数据传送的响应时间，平均小于1秒！也许在很多人看来，这个时间还是太长，达不到实时的要求，但应该知道，绝对的实时是不可能实现的，只要在策划和开发中采用一些合理的策略，这小于1秒的延迟完全可以很好的掩盖。
典型的PC即时战略游戏如《星际》，在局域网对战时实际上并不需要服务器的，对战中的一台或多台客户机充当了服务器的角色，即使是上战网，战网服务器完成的也只是社区治理的工作。在手机上实现不能采取这种结构：首先，通过GPRS网络，两部手机无法直接连接（不排除蓝牙或红外的互连，这不在我们的讨论范围内），只能通过服务器中转；另外，手机的运算能力有限，为了游戏能良好的运行，必须把很多的运算转移到资源相对更丰富的Server端，这和一般的CS结构中，尽量让Client分担Server的工作以使得Server能支撑更多的Client的做法背道而驰，也体现了J2ME网络应用的非凡性吧。
再简单说一下整个系统的架构：
服务器按功能分为连接服务器、大厅服务器、游戏逻辑服务器、用户治理服务器和日志服务器五种。视用户的数量，假如数量很小，所有的服务器都可以置于一台主机中；随着用户量增多，各服务器可以移动到不同的主机中，通过调整各服务器主机的数量达到均衡负载。
