现在的移动电话是小型的计算机，它的处理能力与台式机的标准处理能力相比很有限，
但是足够运行一个小型的游戏。
　　现在的手机的一个特性就是它们还是网络计算机，能够高速发送和接收数字数据。除
了语音数据以外，它们还可以发送和接收其它类型的数据。所以类似《传奇》、《千年》这
样的网络游戏也可以在手机上实现。
　　当然就处理能力和性能而言，当前阶段的支持Java 的手机很接近第二代控制台游戏机、
80 年代中期的家用电脑和早期的手持游戏机。内存通常很有限--一般128KB 到500KB--虽
然有些智能手机比如Nokia 3650 有4 MB 内存。与PC 相比，它们的输入和显示功能也很
有限；小屏幕（许多仍然是黑白屏幕），为电话拨号优化的小键盘并不针对文本输入，以及
有限的声音处理能力。

二、移动游戏是如何实现的

目前在移动电话实现游戏的技术主要有以下几种：
1、嵌入式游戏
　　一些游戏在出厂前就固化在芯片中了，象Nokia 的贪吃蛇就是一个最著名的例子。但
由于用户不能自己安装新的游戏，所以它们逐渐变得不太流行了。

2、短消息服务游戏
　　短信息服务(SMS)被用来从一个手机向另一个手机发送简短的文字信息。用户一般为每
条信息支付1 毛钱的信息费。短消息服务游戏的玩法通常是发送一条信息到某个号码，这
个号码对应游戏供应商的服务器，服务器接收这条消息，执行一些操作然后返回一条带有结
果的消息到游戏者的手机中。短消息服务不是一个特别好的用于实现移动游戏的技术，因为
它依靠用户输入文字，因此本质上它是一个命令行环境。而且它还很昂贵，即使和服务器只
交换10 次信息也要花费1 块钱或者更多的钱。虽然多媒体消息服务( MMS)技术的推出使得
基于消息的游戏更加具有吸引力，但是仍然不是一种重要的游戏环境，所以在此我们不会深
入探讨它。

3、浏览器游戏
　　差不多1999 年以后出厂的每台手机都有一个无线应用协议(WAP)浏览器。WAP 本质
上是一个静态浏览载体，非常像一个简化的Web，是为移动电话小型特征和低带宽而专门
优化的。要玩WAP 游戏的话，可以进入游戏供应商的URL（通常通过移动运营商门户网站
的一个链接），下载并浏览一个或多个页面，选择一个菜单或者输入文字，提交数据到服务
器，然后浏览更多的页面。WAP (1.x)版本使用独特的标记语言WML，允许用户下载多个
页面，即卡片组。新版本的WAP(2.x)使用XHTML 的一个子集，一次传递一个页面并且允
许更好的控制显示格式。两种版本的WAP 都提供一个比SMS 更友好的界面，而且更加便
宜，只要根据使用时间付费而不是根据信息数。但是它是一个静态的浏览载体；手机本身几
乎不需要做任何处理过程，并且所有游戏必须通过网络，所有的操作都是在远程服务器上执
行的。手机将继续带有WAP 浏览器，而且开发者可能发现WAP 有利于传送比游戏应用程
序提供的更详细的帮助信息或者规则，因为大部分的游戏仍然受有限的内存制约。然而，
WAP 没能达到高使用率的目标（在欧洲和北美洲，只有6%的手机使用WAP），而且移动
运营商和游戏开发者正在远离WAP 技术。我们也不会在这里探究任何WAP 的细节。

4、J2ME 和其它的解释语言
　　Java 2 Micro Edition (J2ME)是一种针对移动电话和PDA 这样的小型设备的Java 语
言。大部分的手机厂商都迫切希望Java 手机推广应用。上千万的Java 手机已经到了消费
者的手中。J2ME 与台式机中的Java 相比还是有很大的限制，但是它已经极大的提高了移
动电话支持游戏的能力。它有比SMS 或WAP 更好控制的界面，允许使用子图形动画，并
且可以通过无线网络连接到远程服务器。支持Java 的手机的普及，所以它成为目前最好的
移动游戏开发环境，我们在这里将详细研究J2ME 游戏的开发。J2ME 不是手机上配置的唯
一的解释语言，但是它是一个许多厂商支持的行业标准。一些专用的解释语言也在某些区域
有上佳的表现，如北美的Qualcomm 的BREW ( Binary Runtime Environment for Wireless，
用于无线应用程序的二进制运行环境)和一些韩国移动运营商支持的名为GVM 的标准。在
这个系列文章中，我们将要重点讨论使用J2ME 开发移动游戏，并且将介绍在Nokia 平台
上开发移动游戏的方法。

5、C++应用程序或其它编译语言
　　另外一种开发方式是使用C++开发移动游戏，把程序编译为本机机器代码。编译语言
程序一般说来提供更好的控制用户界面，以及与解释语言相比更快的速度。C++开发者可以
定位于Series 60 平台设备。此外，Microsoft 的.Net CF 也可以以编译的形式开发移动设备
上的游戏，在以后的文章中我将介绍Pocket PC 平台上游戏开发的方法。

三、移动游戏开发与传统游戏开发的区别

移动游戏开发与传统游戏开发区别在许多方面：
1、开发团队的大小
　　传统的PC 和控制台游戏一般需要12 到30 人的开发团队。因为大部分移动游戏规模
比控制台游戏小，所以一般情况下只需要3 到5 人的团队开发，有的时候甚至设计者和编
程者是同一个人。
2、预算
　　传统游戏的预算在一百万美元到五百万美元之间。大部分移动游戏的预算则通常少于一
百万美元。实际上，移动电话有限的显示能力和对应用程序大小的限制使得不可能象传统游
戏那样投入大量的财力物力。从某种意义上来说，这也算是一个优点。

3、开发周期
　　传统的游戏一般要开发两到三年。而大部分移动游戏几月之内就能开发完毕。换句话说，
只要有一个小型开发团队和一个小的预算，你就可以开发并推广一个专业品质的移动游戏。
因此，对于许多在传统游戏领域遇到挫折的开发者来说，移动游戏开发有很强的吸引力。

4、网络设备
　　移动游戏可能不同于我们之前看到的任何游戏：它受载体因素的限制，但是支持网络并
且可多人游戏。用于PC 的调制解调器也只是8 年前才大范围应用；控制台游戏只不过现在
才能上网。移动电话的特性决定它是一种网络设备。即使它们的处理能力使人想起以前的老
式计算机技术，但是它们的网络性能却更加出众。

5、开放标准
　　控制台游戏开发需要从控制台游戏厂商取得授权和支持，需要支付给他们"平台使用费
"。在无线应用程序世界（如同在PC 游戏开发中一样），你可以免费的开发任何款式的游
戏，而不要支付Nokia、Sun 或其他平台提供商一分钱。此外，这些移动游戏开发平台标准
可以向开发者发布、开放并可免费取得。

6、部署
　　传统的游戏主要是在软件市场上购买。而移动游戏主要是由用户从移动门户网站下载并
安装。在有些情况下，它们是通过无线网络下载的。有些手机允许你下载一个应用程序到计
算机中，然后通过数据线传送到手机中。
　　因此，移动游戏的销售渠道是非常不同的。用户一般通过移动运营商的游戏菜单、手机
厂商预装在手机中的游戏菜单或者无线应用程序门户网站上找到移动游戏。

四、载体的优点

1、庞大的潜在用户群
　　现在全球超过十亿部移动电话正在被使用，并且这个数目正在逐渐增加。在除美国之外
的每个发达国家，拥有手机的人数比拥有计算机的人数更多。虽然那些手机只有一小部份是
支持Java 的手机，但是这个数目正在快速地提高并且在几年内Java 手机将要成为行业标
准。移动游戏潜在的市场比其它任何平台，比如Playstation 和GameBoy 都要大。

2、便携性
　　GameBoy 比任何其他控制台游戏卖出的多的一个原因就是：便携性。人们可以随时随
地玩他们选择的游戏。与现在的游戏控制台或者个人电脑相比，手机可能不是一个好的游戏
设备，但是人们基本上是随时随刻都把它们带在身边。在他们离开家的时候或者想玩的时候，
给开发者应该为他们提供好玩的游戏。

3、支持网络
　　因为移动电话是网络设备，所以可以实现多人游戏，虽然有某些限制因素。

五、载体的缺点

1、屏幕小
　　你面对的是小型的屏幕。虽然屏幕分辩率持续提高，并且彩屏即将成为标准，但是屏幕
尺寸还是一直很小，因为没有人乐意拿着砖块一样大的手机。
还有一个相关的问题：不同的手机的屏幕大小是不同的。比如说Nokia Series 60 平台
设备就提供了和Nokia 5100 这样的Series 40 设备不同的屏幕尺寸。虽然各个厂商已经标
准化它们产品的屏幕尺寸以避免分割市场，但是开发者仍然需要为不同的电话优化他们的游
戏--你肯定想使用特定的手机上所有可用的屏幕空间。

2、有限的颜色和声音支持
　　大部分使用者手中的手机仍然是黑白的，虽然现在出售的支持Java 的手机大部分都是
彩屏手机。在这些手机中12bit 彩色非常流行。
　　即使手机本来就有声音设备，但是应用程序播放声音的能力却非常有限。J2ME 规范根
本不需要硬件厂商支持声音，虽然基本的Java 手机允许使用一些声音并且MIDI 支持正在
成为标准。通常，手机中只有一个语音或者一个声道可用。

3、应用程序大小限制

　　大部分的Java 手机只有很少的内存空间用于运行MIDlet。此外，对MIDlet 的大小始
终有一个限制。实际的限制取决于手机设备和移动运营商的规定。
　　在这样的限制条件下设计开发移动游戏固然是非常困难的，但是我们要知道，第一台家
用电脑只有64 KB 内存，但是仍然有人热衷于在其上开发游戏软件。在一些智能手机上内
存的限制就少一些，比如Nokia 3650 甚至可以运行几兆字节的应用程序。

4、高等待时间
　　等待时间----机器发出请求和接到响应之间所花费的时间----在计算机上是以微秒计算；
在有线因特网上是以毫秒计算；而在无线网络则要以秒计算。
　　等待时间是网络游戏中一直存在的一个问题，开发者们总是在努力消除它带来的问题。
无线网络等待时间非常长，这就不可能有效的开发多人快速动作移动游戏。然而基于回合制
的多人游戏是相当可行的，我们在后面的文章中将讨论如何使用各种方法来处理这个问题。
虽然移动运营商总是在努力增加移动电话可用的带宽，但是他们却没有把降低等待时间
当成首要解决的问题，因为它对于别的应用程序并不重要。
　　还有一种特殊情况：使用蓝牙技术或其他无线局域网技术的手机可以和附近的蓝牙设备
使用因特网等待时间（一般200-400 毫秒）通讯。这样，使用像Nokia 3650 这样的智能手
机，你就可以和附近的移动用户一起玩多人快速动作游戏了。

5、可中断性是关键
　　当用户接听电话的时候，手机都会中断进行中的游戏。游戏程序必须能够暂停并且继续，
而且不会造成游戏问题（例如，游戏者在打电话的时候老怪仍然在移动，打死玩家扮演的角
色，导致输掉游戏）并且不会造成内存溢出。这需要在编程的时候多注意，Nokia 提供了技
术文档帮助J2ME 和Symbian C++开发者了解并解决这个问题。

6、正在发展的技术
　　用于开发移动游戏的技术并不是针对游戏设计的，因此常常有特定的限制条件。例如，
J2ME 规范不需要支持透明度，这就使得子图形除了在空白的背景上以外，在任何背景上都
会很难看。
　　幸运的是，大部分设备厂商的Java 手机都补充了J2ME，支持了透明度。为了充分利
用J2ME 的性能，你需要支持手机特定的API；为了得到最好的效果，就需要为一个游戏编
写好几个版本。最近发行的MIDP 2.0 规范解决了一些此类问题，但是对不兼容MIDP 2.0
的手机是无效的。

六、避其短处取其长处

　　游戏有惊人的可塑性；它们可以使用从石器时代到现代高科技的每一种技术来实现。每
当你使用你以前从来没有使用过的技术进行开发的时候，你需要了解它的性能和局限，努力
把它的性能发挥到极限，同时回避或者解决它的局限性。

我们可以从我们的移动游戏的性能和局限性的讨论中得出什么结论呢？
1、短的游戏时间
　　人们迟早要打电话或者接电话，并且他们不想把所有的电量都用来玩游戏。理想的情况
是每一回合游戏应该保持在五个分钟或更短时间之内。这不意味着一个完整的游戏必须在五
分钟之内结束--而是你应该允许游戏者中断、保存和继续游戏。

2、玩家有自己的时间表，而不是必须遵循你的时间表
　　让人们在想要玩游戏的时候玩，不要强迫他们等待（如果你可以避免），也不要要求他
们在任何时间都在游戏中。

3、避免等待时间
　　这对单人游戏来说很容易实现。在多人游戏中，你就需要解决等待时间的问题了。（我
们将在后面讨论这个问题。)

4、使用网络
　　网络不一定对于每个移动游戏都是必需的，但是那种与人竞争的感觉，即使只有一个排
行榜，也能吸引更多的游戏者。要记住，手机实际上是一种社会性设备，添加某种社会性因
素到你的游戏中会使它更加受欢迎。

5、尽可能地让游戏保持小型
　　记住一点，人们仍然热中于80 年代的优秀的游戏。在某些方面，技术的限制强迫你把
更多的注意力放到基本的游戏中去。
当我们在后续文章中探讨开发的时候，我们将讨论一些技术问题。

6、做好支持多种手机的准备
　　至少，需要支持不同的屏幕尺寸，这对Nokia 系列手机很容易做到。为Series 40 开发
一种版本，为Series 60 开发另一种版本。多数情况下，你还要利用特定手机的性能和API，
比如Nokia 的用户界面和SMS API，你要为不具备相同特性的手机开发不同的版本。

7、为国际化做好准备
　　全世界都在使用移动电话，每一种语言都有自己的市场。在你开发的时候你就要做好计
划，以便更利于本地化。

七、处理等待时间

移动游戏如何解决无线网络的高等待时间呢？
1、单人游戏
　　游戏者的游戏不需要用到网络，除非是把高分传送到排行榜中，或允许游戏者浏览排行
榜。这种网络通讯对于游戏影响不大，几秒钟的延迟不会引起用户的反感。
实质上，在大多数的单人游戏中并没有这个问题。

2、"多玩家"单人游戏
　　在一个"多玩家"单人游戏中，游戏者感觉他们是在玩一个多人游戏，但是事实上，每个
人只是面对相同的游戏，在游戏或者回合结束时比较分数。
　　当一个游戏者加入游戏时，他告诉其他游戏者他的ID 号，然后开始玩单人游戏。服务
器要么给每个游戏者发送一个包含相同消息的游戏状态文件，要么发送一个来自构造启动游
戏状态的客户软件的代码。每个游戏者玩游戏，设法取得最高的得分。当一个游戏者结束游
戏后，他的客户端程序把他的得分提交到服务器。当所有的游戏者都完成游戏后（或者超过
某个时间以后），服务器告诉每个游戏者谁取得了最高分，以及每个游戏者取得的分数。
　　这种风格的游戏在因特网上相当成功；AOL 最受欢迎的游戏Slingo 就是一个很好的例
子。
　　因为只有在服务器开始或者结束游戏的时候才需要交换消息，所以等待时间只有在这些
时候才成为一个问题。

3、基于回合的游戏
　　在一个基于回合的游戏中，游戏者进入他们的回合，并在接收结果之前需要等待一段时
间。几秒钟的延迟是可以容忍的。
有两种基于回合的游戏：
3.1、轮流游戏
　　在一个轮流游戏中，每个游戏者按次序进入回合。像象棋、红心大战这样的经典游戏就
是很好的例子。
　　这种游戏的缺点就是游戏者在重新进入回合之前无事可做。虽然经典游戏在因特网上有很多
玩家，但这多多少少有点无趣，。
　　因此，限制轮流游戏的游戏者数是个非常好的主意，这样延迟就不会变得非常长。两到
四个游戏者是比较理想的情况。
3.2、同时动作游戏
　　在一个同时动作游戏中，每个游戏者独立于其它游戏者计划他自己的行动。当一个游戏
者就绪时，他发送指令到服务器。服务器等到从所有的游戏者那里都接到指令，然后分解回
合，再把结果发送到所有的游戏者那里。

4、"即时动作"游戏
　　在一个"即时动作"游戏中，游戏可能会持续很长时间（几天、几个星期、几个月甚至到
永远）。游戏者可以在任何时候进入游戏，执行游戏中的动作。在一些游戏中，他们可能只
能与其他的同时进入游戏的用户交互；在其它的游戏中，他们也许能与任何其他游戏者交互，
即使这些游戏者已经下线。

5、把等待时间分布到游戏中
　　让游戏者接受高等待时间的另一种简单方法就是把等待时间分布到游戏本身中。例如，
大部分星际飞船战斗游戏让人都感觉到象是二次大战时的空战，战船在你身边呼啸而过，向
你开炮。然而，在手机上要实现这种火爆的场面好像困难很大。我们可以换一种思路，我们
可以把星际战舰类游戏做成一个类似第一次世界大战海战的游戏，星际飞船慢慢地移动，彼
此之间一发一发的发射炮弹，导弹缓慢的移动奔向它们的目标。你可以使用这种方法来隐藏
几秒钟的等待时间。肯定还有更多的解决长等待时间的方法。这是一个值得花时间去思考解
决的问题。

在后续的文章中，我们将深入的探讨移动游戏开发的技术。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10294527/viewspace-126233/，如需转载，请注明出处，否则将追究法律责任。