|
|
楼主 |
发表于 2003-11-7 12:59:00
|
显示全部楼层
移动动作游戏开发中的一些问题
现在，游戏开发领域已经出现了一线新的曙光--移动游戏开发时代已经到来了。在过去的两三年里，业界一直在讨论移动游戏市场，分析家们称移动游戏能够带来极高收益。大家都在热切期待移动游戏市场启动的信号。移动运营商投放的彩屏手机为开发者提供了一个用于开发游戏的理想平台，并且也为移动游戏软件出版商提供了合理的商业模式。这是一个双赢的局面。此外，传统的游戏公司，象SEGA和THQ也进入了这个领域，为这个领域的未来大幅发展提供了许多稳定人心的因素。
在移动游戏开发的第一阶段，并没有传统游戏的开发者参与。移动游戏时代是从WAP游戏开始的，主要是文字，并配有少量的图形。尽管市场上已经有几千万支持WAP的可上因特网的手机，但是纯文本的游戏显然并没有激发起手机用户的兴趣，造成消费者回避移动游戏。WAP游戏环境非常缓慢且笨拙，并且WAP游戏开发过程中没有使用Gameboy和控制台游戏开发者的丰富的资源。
美国的移动运营商很快地注意并分析了这些问题，他们从日本I-mode的巨大成功中获取了经验。I-mode到去年年底已经有3000万用户下载娱乐游戏，这占公司年收入的很大一部分。移动运营商推出了下一代移动电话，能够支持因特网功能。与老式的黑白文字手机相比，这些手机更加快并且功能更加强大，它们带有彩色的屏幕和因特网浏览功能，使用比大部分个人电脑拨号上网速度更快的连接速度。
虽然新手机还不是最理想的游戏平台，但它已经是个良好的开端。处理器、内存和色彩深度提供了游戏开发所需的因素。开发者正努力把其它游戏平台上的质量标准运用到这个平台上。当然了，一些问题仍然存在，然而这些问题终将被解决，就象PC平台游戏开发者使用不断改进的DirectX一样。
市场
在全世界，有许多手机的平台或者操作系统。在欧洲，最流行的是J2ME和Symbian；在亚洲和美国，J2ME和BREW则占据大部分市场。
本文讨论在这些新手机中开发Gameboy风格的动作游戏的一些高水平问题，集中在较重要的移动运营商支持的手机和平台上，象Nextel的Motorola i95cl，Sprint的Samsung A500和Verizon的Sharp Z-800。成功的开发者所开发的游戏必须支持最广泛的手机，只针对一种手机或者一个移动运营商来优化你的游戏是最愚蠢的行为。虽然高度优化的结果很好，但是这种努力却并不合算。
虽然现在许多厂商正在制定游戏开发的标准，但是用于大部分手机的有效的解决方案还要等一段时间才能出现。虽然这些手机有令人难以置信的处理器和高效的游戏API，但是开发丰富的吸引人的游戏还不是一件非常容易的事情。在过渡期间，开发者必须面对当前的事实。
Gameboy
在某些方面，新一代的手机与老式的Gameboy Color（GBC）很相似。其实我们可以把GBC看成是一种很重要的评估标准，大部分开发者都很熟悉它。新手机和GBC有许多共同的特征，像便携性、有限存储器、二维图形等等。这个极其成功的游戏平台是移动游戏最理想的模仿对象。移动游戏开发者可以从小屏幕GBC设备的游戏开发中获取思路，来进行创造性的界面设计并增强移动游戏的可玩性。而Gameboy和手机游戏市场并不完全重叠，全世界大约出售了1亿台这种游戏平台。
虽然现在的手机还不是游戏设备，但是它们已经是功能非常强大的设备了。处理器、存贮器和色彩深度已经大大超过了原来的Gameboy。然而移动电话还存在缺陷，比如显示速度、刷新频率、声音和输入远远不如Gameboy。
在某些方面，把移动电话和Gameboy做比较是不公平的。移动电话决不会是高度专业化的游戏设备。与个人计算机相似,移动电话是多功能设备,使用通用处理器和结构来支持像数字信号处理和模拟调制解调器这样耗费大量时间的处理过程。而另一方面，Gameboy是专门设计的一个游戏平台，从开发环境到硬件结构都只有一个目的，就是提供一个用于游戏的高速图形通道。然而，这并不意味手机厂商和移动运营商就有理由可以不去提高它们的游戏开发环境了。
移动开发
开发移动游戏与传统游戏的开发有很多不同，想开发有吸引力的移动游戏尤其困难。这比开发控制台游戏或PC游戏更困难，因为众多的设备具有不同的存贮器、声音和显示性能。除此之外，你还必须合理利用象BREW和J2ME这样不同的开发环境。
开发移动游戏需要一套与普通游戏不同的方法和思路。移动游戏的预算很小而且时间安排很短。这个平台有许多种硬件和软件的组合，并且在硬件厂商之间没有多少共同点。
第一、花费更多的时间用来设计。开发者都有想用最简捷经济的方式做事的倾向。然而，为了创作一个世界第一流水平的游戏，你就必须使用世界第一流水平的开发过程。应用控制台游戏、PC游戏或者Gameboy游戏中所使用的同样的开发过程。关键步骤是设计思路、试制、生产和产品质量检测。不幸的是，因为设备和移动运营商的多样性，开发者不得不花费更多的时间用于前期的计划。这就存在这一种风险，那就是一个设计可以用于一种设备，但是可能就不能用在另一种设备。
第二、象在PC中一样，为硬件的"最小公分母"（lowest common denominator）开发，这意味着你的代码不能对硬件和操作系统以及程序设计语言之间的交互抱过高幻想。
第三个、类似于硬件中的问题，开发两个API之间的基本功能。比较软件开发环境和围绕它们的不足进行针对性设计。开发者必须花费更多的时间了解这两个平台，但是最后的效果是很值得的。
操作环境的不兼容性
两个领导潮流的移动开发环境是J2ME和BREW。J2ME是获得美国大部分移动运营商支持的移动应用开发平台。然而北美洲最大的移动运营商Verizon和Alltel都支持Qualcomm开发的BREW应用程序接口，这使得BREW将成为北美未来必然的平台标准。
BREW更象一个操作系统，支持像C和C++这样的编程语言，考虑到了非常紧凑和高效的代码。 J2ME是一个解释语言，运行在有虚拟机的任何操作系统（包括BREW）上，通常运行速度很慢，而且在优化代码上有许多的困难。
在这两种开发环境中，开发者随意受着厂商的具体实现的摆布。例如，如果显示速度不是最需要考虑的问题的话，那么厂商可以支持J2ME和BREW的基本版本--这两个平台没有一个有直接访问屏幕的标准内置方法，这会使得程序不能支持快速的全屏幕绘图。
在过渡期间，为这两个环境开发游戏成为一种挑战。BREW应用程序接口处理方法与J2ME非常不同。跨平台开发是必由之路。显然，C++的代码和JAVA是不同的，但是这两个平台应该共享大部分的其它的东西，包括数据流设计、通用接口模型、美工、水平数据和声音资源等等。虽然折中方案不一定高效，但是它可以使你的后端开发过程更加高效。没有必要为一个游戏写两个版本，这是吃力不讨好的事情。
例如，BREW 1.0支持掩盖的位图传送（Masked-Blit），而J2ME MIDP 1.4不支持。而且，一些J2ME手机不支持声音。所以你的代码不应该使用掩盖的位图传送支持或者声音支持。比如说，如果你创建自定义位图字体，你可能认为你需要掩盖的位图传送。然而，你可以使用提前修正背景色来创建字体位图。这两个平台可以在载入一个文件的时候改变调色板，允许动态的调整字体背景色，但是文本必须出现在固定的背景上。
提示
1、 在BREW中使用C++（或其它的面向对象语言），能够很容易的支持J2ME，因为它是一种面向对象的语言。
2、 J2ME和BREW一般说来，任何使用Java写的代码都可以使用C++编写，并且可以更快更好。
3、 把所有的设备输出代码（声音、显示、输入）从你的游戏程序逻辑中分离出来。结构化游戏程序逻辑以便能够在J2ME和BREW之间移植。
显示速度
在移动游戏开发过程中，最大的问题是缺乏对显示速度的重视。虽然移动运营商已经选择了强大的处理器和彩色的显示屏，但是他们忽略了对于游戏来说至关重要的一个方面。
如果你看看位图传送的实现，你就会发现低速的显示和高速的处理器很不协调。现在的手机的最大帧速率大约是10fps，而Gameboy或控制台游戏则是30-60fps，这严重地限制了响应速度。
手机使用许多绘制程序，一些支持双缓冲技术，而另一些不支持。在某些情况下，可以更容易的直接绘制到屏幕上。直接绘制到屏幕有时比双缓冲更快。然而，使用低刷新速率在屏幕上绘制大的图象可能会引起闪烁。
你应该使用不同的绘制函数和不同尺寸的位图来一些构造绘制程序。这提供给手机快速绘屏以及最优化的方法。
提示
1、 使用位图传送和使用固有的绘制程序如矩形填充函数大致得出手机绘制速度。
2、 测试双缓冲和直接描画到屏幕上。
3、 确定一个高效的图形通道。
找出特定手机API或VM的实现上的瓶颈。你可能会发现一些简单的问题，比如调用位图传送函数的频度对帧速率的影响。
掩盖的位图传送（Masked-Blit）
在游戏平台上我们认为理所当然的一件事情就是使用透明背景创建子图形。这不是2D图形的新知识，所以我们假设你们对基本的知识有所了解。然而，如果你的平台不支持掩盖的位图传送，那么你有两种选择：忽略透明背景并且绘制矩形子图形或者创建一个粗略近似的子图形。
在一些游戏中，你可以不使用透明度，这种情况中，子图形很小并且背景是一种单调的暗色。虽然那严重地限制了游戏的种类，然而你的游戏可能会看上去灵活且平滑。
从另一方面来说，你可以把图像分割成小的矩形部分，然后重新在屏幕上的把这些矩形组合成一个子图形，通过这种办法，可以近似的透明位图传送。这不适用于带有许多曲线和角的复杂的子图形。而且，如果这个子图形由许多矩形组成，游戏的帧速率可能会较大地变慢，因为处理器需要为到屏幕上的每个位图传送额外消耗资源。
提示
1、 看看你是否可以修改你的设计来支持不带透明背景的子图形。
2、 把你的子图形分割成小的矩形并实时组合成子图形。你可能需要重新设计你的子图形来最小化矩形的数目。
如果你面对的设备API支持掩盖的位图传送，那么你就应该使用它。
不同的屏幕尺寸
图形是游戏的一个关键的方面，描画速度是一个重要的程序函数。不同于控制台游戏和PC游戏，移动设备没有标准的屏幕尺寸或者长宽比，这就导致了很多兼容性问题。开发者可以通过编写非常灵活的背景和前景描画程序来解决这个问题。关键是创建一个允许快速扩展或者缩小游戏视窗的架构，并且不使图像变形或者生成让人看上去觉得别扭的屏幕比例。
当然，你有很多方法来处理这个问题。最坏的情况就是你可以为每种手机的显示屏重新设计图形。或者，你还可以动态地调节你的游戏背景和其它图形。两种情况下，都没有在移动电话中定制平滑的动作游戏的方法。
提示
1、 使用象DrawRectangle和DrawCircle这样的固有描画函数创建尽可能多的可伸缩的图形。
2、 设计游戏，让位图图形可以伸展或者缩小15％－20％，而不会影响玩游戏。
3、 在可卷轴的游戏中，根据需要扩大或者缩小可玩的区域。
输入问题
输入要么成就要么毁掉一个游戏体验。游戏一般都需要快速响应的反馈。不然的话，你的游戏就会感觉有点迟钝。在过去，移动电话不需要能够快速响应的按键。拨电话号码没有那种需要。
现在，这就有了一些问题。第一，如果你的按键响应速度很慢，你的游戏反馈就会很慢，而且不幸的是没有解决办法来提高它的速度。第二，不太明显的是，你的帧速率，在Playstation和Sega土星上，15-20fps的3D游戏会使得控制感觉有点迟钝。在象BREW这样的单线程环境中，处理绘制屏幕、播放声音和计算图形的物理运动过程花费了大量的时间，就没有时间来读取并处理按键事件了。而且，大部分的手机不支持同时按下多键，而这是格斗游戏和射击游戏所必须的。
移动领域一直在与这些问题斗争。目前，你必须通过你的设计来解决它。你需要把注意力集中在设计基于动量（momentum）的游戏上，这些游戏中角色是可以移动的，并且有一些迟钝。例如，如果角色需要移动，那么不要设计直接左转或右转的游戏，而应该设计需要平缓转动的游戏。而且，不可能创建需要让游戏角色立即停下或者转动的溜冰或滑雪游戏。也不要设计格斗游戏或者类似的游戏，因为在这些游戏中，角色需要大量的移动，并且需要立即反馈的游戏按键。
提示
1、使用基于动量的控制来最小化缓慢的相应速度。
2、设计解决同时按下多键的事件。
3、提高帧速度。它将提高响应速度。
未来
上面我们说到的这些问题在今后几年就能解决。然而，消费者的期望值是很高的，他们已经已经被Gameboy Color和Sega上的精彩游戏和画面惯坏了。就像我们看到的WAP，如果顾客失望了，他们就不会买进服务了。这是显而易见的，所以开发者必须尽自己一份力量。
其中的一些担子落在移动运营商和移动软件发行商的肩上。服务必须可信赖，便于接入并且价格公道。平台所有人必须与手机制造商一起工作，提供一个健壮的、游戏友好的环境，包括耐用的按键、掩盖的位图传送和快速显示能力。
随着对移动游戏兴趣的提高，移动运营商认识到这些问题并且正在快速的解决这些问题。当然了谁也不能保证会出现什么解决方案或者什么时候才能出现一个高效的解决方案。在此期间，开发者必须凑合着使用目前的平台并且要有所创意。 |
|
发表于 2003-11-7 12:54:00
