大型游戏，小屏幕 -

2008年1月17日
第5卷，第7期

大型游戏，小屏幕

为移动设备开发3D游戏充满挑战，但不断丰富和发展的工具集能够实现令人惊叹的效果。

MARK CALLOW，HI CORPORATION
PAUL BEARDOW，ECCOSPHERE
DAVID BRITTAIN，SUPERSCAPE

在创建和分发移动3D游戏时，立即显而易见的一点是，手机市场与更传统的游戏市场（如游戏机和掌上游戏设备）之间存在根本差异。其中最引人注目的是交付平台的数量；设备的严重限制，包括可以更改方向的小屏幕；有限的输入控制；处理其他任务的需求；非物理交付机制；以及手机性能和输入能力的差异。

在移动市场之外，开发者只需针对两到三种设备，并在高容量介质上交付游戏；而在移动市场中，他们必须考虑每个运营商的数十种设备，并将游戏打包以适应紧凑的下载。设备的数量和类型也在不断变化；在一个12个月的开发周期中，可能会出现许多新的手机。此外，游戏机开发的重点一直是游戏时长和关卡数量，而不是今天移动游戏中典型的短暂而密集的活动。而且，开发时间和预算通常会受到5-10美元的低零售价的限制。

前期规划

处理多个平台以及管理规模合理的开发团队的需求，使得前期规划和游戏设计变得尤为重要。从一开始，开发者就需要考虑目标平台是什么、将是什么以及可能是什么。如果需要通过尽可能多的用户获取收入来获得合理的回报，那么开发者很可能会关注在当今大众市场手机上运行的Java游戏，因为这让他们可以访问约60%的市场。这些游戏将使用嵌入式Java API，如M3G（Java移动3D图形API，又名JSR-184）和MascotCapsule。考虑到典型的开发周期为9到12个月，包括测试和运营商认证，他们还需要对明年将出现的新手机做出有根据的猜测，并考虑引入新技术，如硬件加速，这可能会彻底改变游戏的外观。

游戏设计必须考虑目标设备上屏幕的方向。必须同时支持横向和纵向吗？方向可以即时更改吗？屏幕方向可以即时更改的手机越来越普遍，这受到宽屏电视观看的推动，它们带来了一些独特的机会。例如，迷宫式游戏可能会在正常的第一人称视角和地图视角之间切换，当屏幕旋转时。

另一个重要的设计考虑因素是目标平台上输入能力的多样性。键盘和控制布局各不相同。有些可能比其他更适合游戏动作。更改屏幕方向可能会使键盘和控件更难使用。对角运动和同时按下按钮在某些平台上可能是可行的，但在其他平台上则不可能。无按键触摸屏虽然仍然相对罕见，但也必须考虑。解决方案可能包括多个难度级别——默认为更简单的级别，例如，不可能进行对角输入——将相同的功能放在多个按钮上，或创建用户可自定义的控件。

例如，在赛车游戏中，用户可能能够使用导航控制器或12键键盘上的各种键来控制加速、制动和转向。用户还可以从这些和其他控件（如换档）的按键布局中进行选择。当在对角输入不可能的手机上运行时，游戏可能会选择一个更简单的级别，其中转向不太灵敏，制动反应更快，以允许从转向到制动可能存在的延迟。

一旦估计或更好的是测量了目标平台的潜在性能范围，并计划了输入能力，那么开发者就必须开始考虑游戏的交付。目标手机都是Java的吗？有些是Symbian的吗？或许还有Brew？最重要的是，游戏的下载大小至关重要。大小限制主要受网络性能和稳健性特征的制约，但在许多情况下，运营商或手机会施加具体限制。如今，Java网络，包括大多数3G网络，仅支持约300-500 KB的OTA（空中下载）下载。另一方面，Brew设备可以达到1 MB甚至更多。Symbian游戏可以通过其他方式交付，因此如果需要，可以达到几兆字节，但在OTA下载之外，没有有吸引力的分发渠道。

仔细的前期规划对于确保移植和测试所有这些端口的成本不会失控也很重要。重要的是确保各个软件包之间的更改尽可能少。一种方法是建立具有相似功能的手机系列；另一种方法是使用移植技术，将游戏代码与手机的具体细节分离。有少量商业移植平台可用。无论哪种方式，最小化差异意味着错误修复或修改可以对主版本进行，而不是对各个端口进行，这将更加昂贵。最好的方法是将这两种技术结合起来：拥有一个可以修复已知设备错误的移植平台，让开发者可以专注于创建优秀的游戏，而不是担心如何让游戏在特定手机上运行。设备系列有助于移植、QA和分发，因为它们减少了需要开发、QA、管理和交付的SKU数量。移动游戏交付过程的管理和执行非常复杂，并且在很大程度上，成本随SKU数量而增加：SKU越少，游戏交付成本越低。

API的标准化可以缓解平台多样性问题。OpenGL ES（嵌入式系统）和M3G（有关这两个API的更详细讨论，请参见随附的侧边栏）在很大程度上减轻了游戏开发者的痛苦。然而，手机性能的差异始终意味着游戏设计需要具有可扩展性，以覆盖广泛的手机，对于现在市场上以及毫无疑问明年将出现的更快的3D加速设备而言，更是如此。与可扩展性同步，游戏还需要解决可移植性问题，以便代码段不需要一次又一次地重写。

可扩展性设计

设计可扩展的游戏需要团队从一开始就考虑多组游戏资源或多种显示绘制机制。相同的游戏逻辑可能适用，但模型、纹理和绘制顺序可能会被更改、删除或替换，以允许游戏下载并在所需的手机上执行。这就是保留模式1 API（如M3G）具有明显优势的地方：如果它是场景树渲染，而不是由许多低级调用构建而成，则基本绘制代码可以保持不变。权衡可能是对对象绘制顺序的精细控制，但在考虑移植到许多手机时，这可能是可以接受的权衡。嵌入在手机中的API（如M3G）的另一个优点是，它可以很好地针对可能安装在手机中的任何3D硬件进行调整。手机制造商和3D API供应商可以花费更多时间为硬件调整API，而不是游戏开发者花费时间调整单个游戏，考虑到手机的数量。

在非加速手机上，可以通过混合2D和3D图形调用来抵消较低的帧速率，例如，3D角色可以绘制在2D位图背景之上。例如，Java ME（微型版）已经具有2D API，可以以补充方式与3D一起使用。这在非加速平台上效果最佳。在加速平台上，通常更有效的方法是将屏幕更新全部基于3D，以允许通过低级渲染器和硬件实现最佳代码路径。事实上，通常情况下，如果您在设计游戏资源时考虑到硬件加速，它们也可以在软件渲染器上良好运行；反之则不然。

需要注意的一个领域是文本和国际化。如果开发者决定使用位图作为字体，那么他们需要确保位图的宽度和高度是2的幂，以便直接用作硬件加速器上的纹理。他们还需要确保下载有足够的空间容纳所有需要的语言。

多人游戏设计

由于手机是具有强大社区发展可能的联网设备，因此它们非常适合多人游戏。然而，这些类型的游戏要想成功，就必须跨越一个关键障碍，那就是发展足够多的玩家基础。当玩家想要玩游戏时，他们必须能够找到对手或队友。通常，实现需要用户等待很长时间才能启动多人会话，然后在房间中等待其他玩家加入。好的游戏设计应该允许服务器在短时间后回退到机器人（基于AI或预定义的服务器端玩家）。在许多游戏中，用户可能永远无法区分这些玩家和真实玩家。

这引出了在线游戏的另一个挑战：如何为您的在线对手增加个性？在PC和游戏机游戏中，允许多任务处理相对简单——这样他们既可以玩游戏，也可以通过文本或语音聊天。在受限的移动设备上，这更具挑战性，因为用户界面和键盘非常有限。预定义的“嘲讽”可以帮助简化消息发送过程，但考虑到这些是支持音频的设备，使用该功能必须是长期解决方案的一部分。目前通过设备API提供的技术不允许今天的游戏开发者达到这种访问级别。

当然，多人游戏最大的难题仍然是延迟和设备可变性的困扰，因此需要快速响应的游戏，如第一人称射击游戏或赛车游戏，仍然仅限于高端3G手机。游戏机游戏存在许多解决方案，但在移动领域，挑战更大，因为最佳和最差之间的差距更大。此外，尚不清楚市场上是否有足够数量的设备，或者消费者是否准备为体验支付更多费用。向移动游戏添加在线功能会大大增加整个过程的成本，从开发到移植和QA。

多人和社区游戏与移动受众非常匹配。一款经过深思熟虑的游戏，如果不对3G和高端设备具有排他性，则很容易成为移动游戏的杀手级应用。

开发过程

2D移动游戏的开发已经非常成熟，原则上3D开发与2D开发没有本质区别——毕竟，这只是一种不同的游戏绘制方式。两者都有代码和资源，都需要打包、测试和认证才能交付给最终用户。不同之处在于，3D开发可能具有更复杂的资源创建和潜在的更复杂的游戏代码，尽管情况不一定如此，并且实际上许多3D游戏在概念上，因此在代码上，可以简化为2D等效游戏（许多3D赛车游戏实际上是具有3D模型的2D游戏）。

资源

Java 3D移动游戏所需的基本资源和代码如图1所示。这些资源扩展了2D游戏的资源，并添加了3D几何图形、对象外观纹理、光照和相机参数，以及可能更高级别的构造，如动画轨迹和骨骼。例如，在M3G中，所有这些资源，以及变形数据、分组、图层和2D精灵，都可以存储在一个或多个场景树中，并以数据文件的形式保存。使用数据文件存储3D资源比在代码中运行时构建资源具有巨大的优势，因为它使艺术家和设计师可以使用熟悉的设计工具创建资源。

游戏行业中最流行的3D模型创建工具之一是3D Studio Max。用户通常可以通过插件高度自定义此类工具，其中许多插件可用于3ds Max，以导出M3G内容。然后，艺术家可以在交互式可视化环境中创建和预览3D模型，并通过触摸按钮导出到M3G文件，该文件可以在模拟器中预览，如图2和图3所示。然后，程序员接管并编写代码以在移动设备上加载和操作此内容。

使用多个数据文件允许设计师处理场景的各个元素，并允许在游戏中动态构建场景。这使得一个设计师可以构建游戏的关卡，而另一个设计师可以对角色进行建模。当游戏执行时，可以根据游戏需要以编程方式将所选角色插入到场景中。

开发者会发现不同手机之间的音质差异很大，从低质量的单声道到某些最新型号上的高质量3D定位音频。重要的是以尽可能高的质量创建声音资源。在为特定手机和下载大小量身定制时，降低资源质量远比提高资源质量容易。

编程挑战/约束

在游戏机世界中，游戏是唯一的应用程序；在移动世界中，当来电或短信到达时，游戏必须表现良好。它不能对手机的正常使用造成问题，也不能干扰其他后台应用程序。这对许多开发者来说是一种新的规范，处理它可能会导致一些错误。一种解决方案是创建一个框架，为每个手机或手机系列处理这些问题，并将游戏嵌入到此框架中。为第一个手机系列上的游戏创建此框架将需要更多的开发时间，但从第二个同系列终端或游戏开始，开发者可以专注于编程。

在大多数平台上，来电会向游戏发送暂停事件，游戏必须暂停游戏时间，停止更新游戏世界，并停止渲染。通常，工作线程执行这些更新任务，因此游戏只需记录当前时间并终止工作线程。游戏还必须释放任何共享资源，例如M3G中的3D图形渲染上下文。在更受限制的平台上，应用程序可能需要通过删除一些资源来减少内存使用。在这种情况下，游戏会记录足够的信息，以便在最终收到恢复事件时以相同的状态重新创建资源。

为手机等受限设备编程需要在管理内存使用方面具有高度的规范性。在Java手机中尤其如此，因为内存分配或释放可能会因垃圾回收而导致游戏意外减速。有时很难看到分配发生在何处，但总的来说，出于性能原因，在主游戏循环中不分配任何内存非常重要。同样重要的是管理整体内存使用，尤其是在使用位图或声音时。在需要时加载资源，然后删除它们至关重要，并且必须这样做，以免导致Java堆碎片化。通常，最好的解决方案是游戏开发者编写自己的内存管理器代码，以便严格控制所有资源的分配和释放。这不像编写本机代码那么容易，因为您被限制为使用Java VM的内存分配器，但您可以编写更高级别的资源管理代码，以控制何时加载和卸载图像、文本和其他数据。

例如，一个简单的游戏可能具有各种资源集：（1）启动序列图像，包括启动画面；（2）菜单系统图形；（3）两个游戏关卡中使用的图形。集合1将被加载一次，然后永久丢弃。当用户进入和退出游戏的不同关卡时，可能经常需要集合2。每个关卡的集合3数据可能很大，因此可能无法将其全部保存在内存中。为了管理此内存，您必须在一个连续的内存块中加载集合1中的所有数据，以便在丢弃时，将一个连续的块释放回系统。集合2中的数据应加载一次并始终保留在内存中；否则，在许多手机上，连续加载和释放对象可能会导致问题。同样，此数据应连续加载以避免碎片化。最后，集合3中的关卡数据应在一个操作中在关卡的开始和结束时加载和释放。如果可能，图像或其他数据应在菜单和游戏关卡之间共享，以减少总体堆需求。

在3D游戏开发中，尤其重要的是不断在真实硬件上进行检查，而不是仅在模拟器上进行开发。模拟器在性能方面往往与实际设备几乎没有共同之处，甚至可能使用不同的Java虚拟机和3D API实现。Java ME没有周期精确的模拟器，开发它们将是一项具有挑战性的任务，因为每个设备的性能特征都基于许多不同的因素。开发者需要考虑参考手机——它们应该是合理的设备，而不是最快的设备；否则，他们将在游戏开发结束时面临主要的移植问题。在整个过程中始终记住，如果游戏旨在覆盖尽可能广泛的受众，则必须在多个平台上工作。

移植、测试和打包

在初始开发结束时，游戏必须移植到目标手机。尽管开发者可以选择将游戏端口限制为那些功能最强大或具有特定屏幕尺寸的手机，但一般来说，游戏应该在尽可能多的手机上运行。

因此，第一个挑战是如何创建和管理所有需要构建的手机的代码。如果没有好的工具、库和仔细的游戏设计，源代码副本的数量很容易爆炸式增长，或者源代码变得完全不可读，其中充斥着预处理器语句。最常见的解决方案是前面提到的移植平台。该平台抽象了设备差异，在不同设备之间呈现了一个通用的API，并修复了所有已知的设备问题。然后，可以编写游戏源代码，使其更加设备无关。

移植中面临的最大问题是手机软件中的缺陷、小堆大小、专有API，以及最大的问题，性能。一些最流行的游戏手机也是最便宜的（因此也是最受限制的）设备，运营商通常要求将游戏移植到这些型号。

测试是另一个经常被忽视的领域。交付必须不崩溃的游戏是显而易见的，但同样重要的是，它们不能对手机的正常使用造成问题。它们不应不必要地耗尽电池电量，阻止屏幕上的重要信息，或占用过多的处理器时间，以至于手机变得无响应。

一旦游戏通过QA并准备就绪，开发者必须使其准备好进行运营商测试。一般来说，这意味着在JAD（Java应用程序描述符）文件中使用正确的详细信息对其进行打包，确保其启动画面和菜单结构符合运营商的样式指南，最后，它的大小适合下载。通过运营商测试的游戏经过数字签名，因此可以通过OTA下载安装。

维护跨新手机的端口也很重要。对于一款成功的游戏，开发者需要保持游戏的生命周期内的移植滚动，以确保可以访问最新和最强大的手机。

发布和分发

在移动市场中，OTA分发是唯一可行的途径。任何涉及PC的分发类型都会遇到各种困难——客户难以找到您、对涉及的小额资金进行计费，以及用户无法将游戏从PC传输到手机。此外，通过PC下载并非随意之举——它不能在等待约会时一时兴起地完成。

除了少数高端设备外，通过卡带或光盘介质分发是不可能的。

有三个OTA分发渠道：On Deck、Off Deck和Off Portal。Deck是运营商维护的一组指向游戏下载的链接。例如，通过手机游戏菜单中的“更多游戏”按钮访问这些链接。在On-Deck分发中，运营商提供计费服务，购买费用出现在用户每月的电话账单中。作为回报，运营商会从购买价格中抽取一定比例。在日本，运营商通常抽取约6%。在欧洲，众所周知，他们要求高达90%，而50%到60%是常态。在美国，通常为40%到50%。作为回报，运营商可能会提供营销方面的帮助，但并非总是如此。

Deck位置和运营商关系已成为游戏发行商和开发者成败的关键因素。随着大型公司进入市场，如果没有大品牌或现有的签约发行商，新开发者极不可能将其内容列入列表。如今，Deck经理通常不接受新的发行商，即使他们一直在寻找新内容以保持收入流动，并且他们经常每月发布两次“最新内容”列表。少量的工作人员根本无法应付大量个人提交。

Off Deck是运营商门户网站内一个更难找到的渠道（例如，AT&T Wireless的Beyond Media Mall）。通常，用户通过使用运营商门户网站中的搜索功能来查找游戏。运营商提供计费服务，但抽成比例较小，更重要的是，对于小型发行商而言，进入壁垒远没有On-Deck分发那么高。

Off-Portal分发完全独立于运营商。开发者维护一个网站或使用Off-Portal发行商。就客户找到开发者而言，这是最具挑战性的渠道，尤其是在只有4%的手机用户设法从游戏Deck购买游戏的情况下。由于典型的游戏价格对于信用卡交易来说太低，因此必须提供订阅计划。唯一的其他收入机制是高级SMS消息或广告商资助。

从Deck围墙花园之外的URL获取游戏的能力对于任何发行商的寿命都至关重要，因为Top 10游戏Deck无法维持庞大的发行商社区。为了应对这种情况，网络上涌现了几个Off-Portal发布服务，其中包括一个所有游戏都由广告商资助的服务。Wi-Fi手机的引入也将扩大可能性，Wi-Fi/IR功能的控制台的链接也将如此。传统游戏发行商将开始考虑移动和游戏机游戏之间的交叉营销。当然，游戏机品牌是否会转移到移动市场，目前尚无定论。到目前为止的迹象表明，休闲游戏占据主导地位。

今天开始从事移动游戏业务的开发者将需要与发行商建立良好的关系，或者制定良好的病毒式营销计划，以克服Off-Portal分发的困难。

最大的潜在游戏受众

移动游戏领域显然与游戏机和PC市场截然不同——在设备性质、受众和市场途径方面。成功的游戏开发者和发行商必须愿意适应这些差异；试图在不解决这个新环境的独特功能的情况下移植游戏机或PC内容将导致失败。未来的开发者和发行商必须问自己以下问题：我能找到进入市场的途径吗？我的游戏可以适应手机的功能和限制吗？可能最重要的是，我的游戏适合移动受众吗？

永远不要假设一款好的游戏机游戏会成为一款成功的移动游戏。移动游戏的玩法更类似于街机风格的游戏，需要短暂而快速的娱乐。除非您拥有建立大量玩家群体的可靠机制，否则不要带着多人游戏进入市场。最重要的是，确保您尽可能了解游戏设计、开发和移植任务，以确保您的游戏能够尽可能多地展现在玩家面前——并使其成为一种有益的体验。

移动市场拥有有史以来最大的潜在游戏受众。每年出货超过7亿部新手机，其中大部分都支持某种形式的游戏。这比游戏机领域大很多倍，并且涵盖了更广泛的消费者和娱乐需求。

为了应对这个市场，开发者和发行商可能需要以不同的方式思考什么是“游戏”，并在最终用户的“玩耍”上投入更多思考。这可能意味着趋向于不太传统的游戏，以及更多与将要存在的多个但非常大的受众群体相匹配的想法。

参考文献

一种3D图形编程风格，其中图形对象、它们的空间关系及其外观的持久表示以及查看位置都保存在内存中的场景图中。程序通过单个库调用绘制整个场景，避免了在管理、剔除和渲染数据方面的低级工作。

MARK CALLOW是HI Corporation（东京）的首席架构师，他在那里为移动电话设计3D图形引擎。他是JSR-297 (M3G 2.0) 专家组成员，并为包括OpenGL ES在内的多个Khronos Organization工作组做出贡献。Callow在加入HI之前曾担任多年的独立顾问，在此之前，他在Silicon Graphics工作多年。

PAUL BEARDOW是Eccosphere的首席技术官，该公司正在开发下一代移动社交网络。在此之前，他曾担任英国Superscape的首席技术官，在那里他领导了用于手机和游戏软件开发工具包的3D软件技术的开发，并建立了一个游戏开发工作室，该工作室为迪士尼、20世纪福克斯和索尼影业创作了3D游戏。他是M3G 1.0初始专家组的成员，并在Khronos Organization中代表Superscape。

DAVID BRITTAIN是英国Superscape的技术副总裁。他是创建Superscape的M3G实现的团队成员，现在领导Superscape的移动游戏开发工具的开发。

为嵌入式系统改进OpenGL

Kari Pulli和Jani Vaarala，诺基亚，以及Ville Miettinen

早期的移动3D引擎都是专有的，它们的渲染管线是在通用CPU上运行的软件中实现的。2002年，为了为便携式3D硬件加速提供基准，Khronos Group开始为移动设备设计3D标准。这个想法是将OpenGL（部署最广泛的3D API）作为起点，以生成更精简和更简洁的版本：OpenGL ES（嵌入式系统）。

简化包括删除很少使用的功能（例如，反馈和选择渲染模式，以及主要用于语法糖的功能，例如GL实用程序库）。这也意味着消除冗余。例如，OpenGL提供了许多不同的定义渲染图元的方法。OpenGL ES仅提供一种：所有顶点数据都在数组中提供，这导致更简单的实现和更快的执行。此外，支持的几何图元集仅限于点、线和三角形。

OpenGL ES保留了OpenGL的大部分变换和光照管线。但是，只有后缓冲区可用于绘制和读取，并且仅支持RGBA颜色模式（没有索引颜色模式）。使用纹理映射（位图以及线条和多边形的点划线）轻松模拟的功能被删除；所有关键的2D纹理映射功能都保留了下来。

相邻图中显示的OpenGL ES图形管线只有几个明确定义的点用于提供输入，并且除了渲染到帧缓冲区中的值之外，几乎没有其他输出。因此，后端的功能无法轻易被应用程序程序员替换，与管线前端的功能相比，移除成本更高。因此，OpenGL ES几乎支持OpenGL 1.3的所有后端功能。例如，规定新片段应如何与帧缓冲区中现有像素混合的混合模式被完全保留，用于确定是否应绘制像素的各种测试也被完全保留。

目前只有最高端的移动设备才配备了 FPU（浮点运算单元）；在 2002 年，几乎没有任何设备配备 FPU。如果没有 FPU，设备必须使用软件模拟来执行所有浮点运算；这会使计算速度降低至少一个数量级。OpenGL ES 通过用单精度浮点数替换双精度浮点数，并为每个 API 函数提供整数（定点）变体来解决这个问题。OpenGL ES 的主要且应用最广泛的配置文件 Common profile 支持浮点函数，而面向超低端设备的 Common-Lite profile 则不支持。

自最初的规范以来，已经出现了两个更新版本的 OpenGL ES。1.1 版本是向后兼容的。它保证至少存在两个纹理单元，并提供纹理组合器，以便更灵活地组合多个纹理贴图。例如，通过点积 3 凹凸贴图，可以为 3D 模型添加明显的表面粗糙度。这意味着可以使用更少的三角形来创建模型，同时提供高度精细表面的外观，该表面参与光照效果。其他新功能包括距离衰减的点精灵，可用于粒子效果（例如，火焰或雨）。缓冲区对象允许几何数据存储在图形硬件的内存中。这减少了数据传输并提高了渲染性能。可选扩展可用：一个用于将位图高效粘贴到帧缓冲区，另一个用于使用通常称为蒙皮的技术来实现平滑的角色动画。

OpenGL ES 2.0 与之前的版本不向后兼容。为了保持 API 的简洁性，可以使用可编程着色器（图中白色方框）表达的功能完全取代了管道该部分内的固定功能。顶点变换和光照模块已被可编程顶点着色器阶段取代，而纹理映射、各种颜色分量的求和以及雾计算现在在片段着色器中完成。着色器使用 GLSL ES 编写，GLSL ES 是一种类似于 C 的高级编程语言。预计 2.0 硬件将支持 1.1，从而提供应用程序级别的向后兼容性。

OpenGL ES 被设计为独立于操作系统的 3D 渲染 API，它完全独立于表面和上下文管理。可选的 EGL API 管理和抽象图形系统资源。后来的 EGL 版本允许将 OpenGL ES 与 OpenVG 等 API 结合使用，OpenVG 针对可伸缩的 2D 矢量图形。

几乎所有针对移动设备的硬件设计现在都支持 OpenGL ES。它可以用于实现更高级别的库——例如，M3G 通过 OpenGL ES 访问图形硬件。

KARI PULLI 是诺基亚的研究员，他在诺基亚领导了许多图形研究和标准化工作。目前，他在帕洛阿尔托的诺基亚研究中心领导一个研究团队。他拥有华盛顿大学的博士学位，曾在奥卢大学、斯坦福大学和麻省理工学院工作过。

JANI VAARALA 是诺基亚的图形架构师。他参与了 OpenGL ES 标准化工作，并领导了一个项目，该项目开发了基于软件的 OpenGL ES 引擎，并为 Symbian 适配了 EGL。他于 90 年代初开始从事 3D 图形工作，当时在 Amiga 上开发了多个获奖的图形演示。他是 SIGGRAPH、Eurographics 和 Khronos Group 的成员。

VILLE MIETTINEN 是 Hybrid Graphics 的 CTO 和联合创始人，该公司已并入 NVIDIA。他现在从事自己的项目。在过去的十年中，他参与了游戏和 3D 图形行业中众多软件产品的设计和实施。他的研究兴趣包括动态代码生成和软件光栅化器。他是 SIGGRAPH、Khronos Group 和 JSR-184 专家组的成员。

M3G：将 3D 图形引入移动 Java

Tomi Aarnio、Kimmo Roimela 和 Kari Pulli，诺基亚

M3G（移动 3D 图形 API for Java，又名 JSR-184）是一个易于使用但功能强大的移动 Java 3D 图形 API。它主要是一个保留模式 API：3D 场景的模型在 API 内部维护，并且可以通过 API 函数插入和操作单个对象和渲染资源。底层渲染模型基于 OpenGL ES，更高层的功能层叠在其之上。

与 2D 位图图形相比，3D 允许游戏在相同的内存量中打包更多数量的更平滑和更丰富的动画。它还改善了深度感和透视感，并实现了电影般的摄像机控制，如邻近的图所示。交互式 3D 游戏中的大部分处理时间通常花费在核心 3D 例程中，这些例程在优化的本地代码中执行或使用专用的 3D 硬件。仅在 Java 中实现 3D 渲染将非常缓慢，这就是 M3G 被设计的原因。

在最低级别，M3G 处理的概念与 OpenGL ES 中的概念类似：顶点缓冲区、纹理、光源、材质和变换矩阵。这些是更高级别对象和场景图的构建块。顶点和索引缓冲区可以组合成 Mesh 对象；纹理、材质和其他渲染参数形成用于着色的 Appearance 对象；Group 节点允许场景元素的逻辑分组和分层变换。

通过场景图方法启用的更高级别功能包括游戏和其他交互式 3D 图形应用程序中常用的功能。设计 M3G 的目的是构建大多数应用程序在任何情况下都需要的通用功能，而又不会过于特定于应用程序。这减小了应用程序大小并提高了开发人员的生产力。它还提高了整体应用程序性能，因为提高抽象级别允许 M3G 在本机代码中批量处理整个 3D 场景。

内置动画引擎基于关键帧动画。可以为任意参数（标量、矢量、方向、颜色）的线性或样条插值构建关键帧轨迹，并将其附加到几乎任何对象的任何属性。M3G 还支持通过变形和蒙皮进行顶点变形。单独的 AnimationController 对象控制动画的速度和时间。然后可以使用单个函数调用来动画化整个场景图，并且应用程序可以自由更改调用之间任何关键帧或动画参数以实现动态效果。

紧凑的二进制 M3G 文件格式鼓励代码和内容的分离，以便可以独立修改它们而不会破坏完整的应用程序。该格式足够灵活，可以存储从完整的 3D 动画和场景图到单个对象或其组件的任何内容。M3G 文件中的每个对象都可以被赋予唯一的 ID 号，并且该号码用于在将复杂文件加载到应用程序后查找对象。这使图形设计师能够标记角色模型的头部、脚部和手臂等对象，以便应用程序代码轻松访问。附加的用户数据可以与文件格式中的每个对象相关联，以允许直接在内容工具中编辑特定于应用程序的数据。

为了增加灵活性，M3G 还支持类似 OpenGL ES 的立即模式渲染，其中应用程序仅将渲染图元发送到 API，而没有任何相关的语义结构。这对于特殊效果或当应用程序只想最大程度地控制渲染过程时非常有用。相同的数据对象用于保留模式和立即模式渲染，因此两者可以交错使用。然而，由于减少了 Java 开销以及 API 内部更好的操作批处理，保留模式通常可以提供更好的性能。

本质上，M3G 是 Java 应用程序的强大图形服务器，它高效地处理渲染，而只有应用程序代码需要在较慢的 Java 中运行。通过提供超出渲染的功能，M3G 还减轻了应用程序代码的一些负担。

M3G 2.0 版本将为高端设备提供可编程着色器和其他 OpenGL ES 2.0 功能，并为大众市场提供增强的传统渲染。API 的动画、场景图和实用程序部分也将得到扩展，允许应用程序将越来越多的繁重计算从 Java 代码转移到本机代码。首批 M3G 2.0 设备将于 2009 年上市；到那时，可能已经出货了超过十亿台支持 M3G 的设备。

TOMI AARNIO 是 M3G 标准（JSR-184、297）的规范负责人和编辑。作为诺基亚的高级研究工程师，他参与了多个移动图形引擎的设计和实施，最近领导了 M3G 的实施。他的研究兴趣包括实时渲染、数据压缩和硬件抽象。他是 SIGGRAPH、Eurographics 和 Khronos Group 的成员。

KIMMO ROIMELA 是 M3G 规范的副编辑。作为诺基亚的高级研究工程师，他也积极参与了规范的实施。他拥有坦佩雷理工大学的理学硕士学位，并在芬兰坦佩雷的诺基亚研究中心工作。

最初发表于 Queue vol. 5, no. 7—
在数字图书馆中评论这篇文章

更多相关文章

Walker White, Christoph Koch, Johannes Gehrke, Alan Demers - 更好的脚本，更好的游戏
2007 年，视频游戏产业的收入达到 88.5 亿美元，几乎与电影票房收入持平。这部分收入的大部分来自大型团队创作的热门游戏。虽然大型开发团队在软件行业中并不少见，但游戏工作室往往拥有独特的开发者群体。软件工程师在游戏开发团队中只占相对较小的比例，而团队的大部分由内容创作者组成，例如艺术家、音乐家和设计师。

Jim Waldo - 游戏和虚拟世界中的扩展
我曾经是一名系统程序员，为银行、电信公司和其他工程师使用的基础设施工作。我从事操作系统方面的工作。我从事分布式中间件方面的工作。我从事编程语言方面的工作。我编写工具。我做了硬核系统程序员所做的一切事情。

Nick Porcino - 游戏图形：革命之路
从平铺块背景上的彩色精灵到现代游戏中身临其境的 3D 环境，这是一段漫长的旅程。曾经是单个游戏创作者的工作，现在已成为一项多方面的制作，涉及来自各个创意学科的工作人员。下一代游戏机和家用电脑硬件将带来可用计算能力的革命性飞跃；商品硬件将提供每秒万亿次浮点运算（teraflop）或更高的运算能力。

Dean Macri - 可扩展性问题
在 1990 年代中期，我为一家开发多媒体信息亭演示的公司工作。我们最大的客户是英特尔，我们经常创建在主要计算机零售商（如 CompUSA）的终端货架上的新 PC 中出现的演示。那时，从商业到消费者的所有应用类别都需要性能。例如，我们创建的演示展示了与去年的处理器相比，新处理器上的电子表格重新计算（在当时您必须手动执行此操作）速度快多少。即使是普通的观察者也能立即注意到这些差异 - 而且这很重要。