多人视频游戏系统及方法

专利名称：多人视频游戏系统及方法
技术领域：
本发明涉及一种多人视频游戏系统及方法。
背景技术：
移动电话、个人数字助理(PDA)、以及类似的手持移动电子装置有时提供诸如玩视频游戏的能力之类的附加功能。针对这样的移动装置的游戏已趋向于变得更加复杂，具有更逼真的图形、更复杂的游戏玩法以及其它改进。所述装置本身已变得更加复杂，同时具有更多存储容量、更快的处理器、图形加速器和其他升级。结果，一些游戏仅仅能在昂贵的、高度复杂的装置上玩。开发这样的游戏是复杂的并且可能需要绘画艺术家和非常熟练的编程人员。对于视频游戏开发来说，一个游戏花费超过一百万美元并不罕见。

发明内容
根据本发明的一个方面，提供一种多人视频游戏系统及方法，用于同时在多个移动手持机(handset)上显示彼此相同的游戏，所述多个移动手持机彼此具有不同尺寸的显示屏。
本发明提供一种用于移动手持机上的多人游戏的方法，包括第一用户经由第一移动装置的小键盘输入多个输入以玩第一游戏；将所述第一用户在所述第一移动装置上的小键盘输入传送到第二移动装置；第二用户经由所述第二移动装置的小键盘输入多个输入以玩第二游戏，所述第一和第二游戏是在各自移动装置上提供的基本上相同的游戏；以及将所述第二用户在所述第二移动装置上的小键盘输入传送到所述第一移动装置，所述第一游戏使用来自所述第二移动装置的所述小键盘输入并且所述第二游戏使用来自所述第一移动装置的所述小键盘输入以使得能够在所述第一和第二游戏之间进行多人游戏。
本发明提供一种用于移动手持机的多人游戏，包括游戏组件，可在第一用户的第一移动手持机上操作以在所述第一移动手持机上玩游戏，所述游戏组件提供与所述第一用户使用所述第一移动手持机进行的动作有关的第一玩家指示器，并且还提供与第二用户使用第二移动手持机进行的动作有关的第二玩家指示器；以及通信组件，可操作用于接收与来自在所述第二移动手持机上玩所述游戏的第二用户玩游戏的小键盘输入有关的数据，其中所述游戏组件可操作用于根据从所述第二移动手持机接收的小键盘输入来更新在所述第一移动手持机上的所述第二玩家指示器。
本发明提供一种用于多人游戏的系统，包括在第一计算平台上的第一游戏；在第二计算平台上的第二游戏，所述第一和第二游戏基本上是相同的游戏；第一通信组件，可操作用于接收第二用户的、与在所述第二计算平台上玩所述第二游戏有关的游戏输入；以及第二通信组件，可操作用于接收第一用户的、与在所述第一计算平台上玩所述第一游戏有关的游戏输入，其中，所述第一游戏可使用来自所述第二计算平台的、第二用户的游戏输入来运行，并且所述第二游戏可使用来自所述第一计算平台的、第一用户的游戏输入来运行以使得能够在所述第一和第二游戏之间进行多人游戏。


为了更完整地理解本说明及其优点，现在将结合详细说明的附图来进行简短说明，其中类似的附图标记代表类似部分。
图1图解了根据本公开一个实施例的、用于游戏开发和玩游戏的系统的方框图。
图2图解了根据本公开一个实施例的、其中可显示游戏中的场景的全景图的俯视透视图。
图3图解了根据本公开的一个实施例的、可以显示游戏中的场景的视频屏幕。
图4图解了根据本公开的一个实施例的、可在游戏的场景中呈现的层。
图5图解了根据本公开的一个实施例的、处理将在游戏中使用的文件的运行时引擎(runtime engine)。
图6A-6E图解了根据本公开的一个实施例的、可用于创建游戏的创作工具。
图7图解了登记成功射击的现有技术。
图8a和8b图解了根据本公开的一个实施例的用于登记成功射击的技术。
图9图解了根据本公开的一个实施例的在不同尺寸的屏幕上的图像显示。
图10图解了根据本公开的一个实施例的在游戏中使用的雷达。
图11图解了根据本公开的一个实施例的在游戏中使用的文件的容器。
图12图解了可操作用于本公开的各种实施例中的一些实施例的移动装置的方框图。
图13图解了可操作用于本公开的各种实施例中的一些实施例的计算机系统的方框图。
具体实施例方式
首先应当理解虽然下面描述了本发明的一个实施例的示范性实现，但是可以使用任何数量的技术(无论当前已知还是现有的)来实现本系统。本公开将决不应限于下面描述的示范性实现、附图和技术(包括在此描述和图解的示范性设计和实现)，而是可以在所附权利要求及其等价内容的全部范围内进行修改。
本发明提供一种用于移动手持机上的多人游戏的方法，所述方法包括第一用户经由第一移动装置的小键盘输入多个输入以玩第一游戏。所述方法包括将所述第一用户在所述第一移动装置上的小键盘输入传送到第二移动装置。所述方法包括第二用户经由所述第二移动装置的小键盘输入多个输入以玩第二游戏，所述第一和第二游戏是在各自的移动装置上提供的基本上相同的游戏。
而且，所述方法包括将所述第二用户在所述第二移动装置上的小键盘输入传送到所述第一移动装置，所述第一游戏使用来自所述第二移动装置的所述小键盘输入并且所述第二游戏使用来自所述第一移动装置的所述小键盘输入以使得能够在所述第一和第二游戏之间进行多人游戏。
而且，根据本发明的另一方面，提供一种用于移动手持机的多人游戏，包括游戏组件，可在第一用户的第一移动手持机上操作以在所述第一移动手持机上玩游戏，所述游戏组件提供与所述第一用户使用所述第一移动手持机进行的动作有关的第一玩家指示器，并且还提供与第二用户使用第二移动手持机进行的动作有关的第二玩家指示器；以及通信组件，可操作用于接收与来自在所述第二移动手持机上玩所述游戏的第二用户进行的游戏的小键盘输入有关的数据，其中所述游戏组件可操作用于根据从所述第二移动手持机接收的小键盘输入来更新在所述第一移动手持机上的所述第二玩家指示器。
而且，根据本发明的再一方面，本发明提供一种用于多人游戏的系统，包括在第一计算平台上的第一游戏；在第二计算平台上的第二游戏，所述第一和第二游戏基本上是相同的游戏；第一通信组件，可操作用于接收第二用户的、与在所述第二计算平台上玩所述第二游戏有关的游戏输入；以及第二通信组件，可操作用于接收第一用户的、与在所述第一计算平台上玩所述第一游戏有关的游戏输入，其中，所述第一游戏可使用来自所述第二计算平台的、第二用户的游戏输入来操作，并且所述第二游戏可使用来自所述第一计算平台的、第一用户的游戏输入来操作以使得能够在所述第一和第二游戏之间进行多人游戏。
公开了可被称为360-3D的游戏格式。所述360-3D格式允许在具有有限存储器和处理能力的移动装置上玩具有高质量的三维图形和复杂故事情节的游戏。在一个实施例中，例如，所述移动装置可以具有以大约120MHz执行的处理器，以及在移动装置中可用的、用于载入360-3D游戏数据的存储空间可以处于从大约3兆字节到大约28兆字节的范围中。一般地，获得高质量视频图形需要具有图形加速器的移动手持机。在一些实施例中，本系统可以运行在不具有图形加速器的移动手持机上。也公开了用于开发360-3D游戏的系统和方法。所述系统和方法允许开发者通过指定将在移动装置的显示屏上如何操纵一组预呈现(pre-rendered)图像而容易地创建360-3D游戏。可以在不使用程序代码的情况下创建游戏，减少了对编程知识或经验的要求，并且大大减少了游戏开发的成本。
图1是在360-3D游戏开发和游戏运行系统的实施例中的主要部件的方框图。创建360-3D游戏的开发者一般通过利用标准的、商业可得到的图形程序110来创建将在游戏中被操纵的三维图像集而开始游戏开发过程。如在下面更详细讨论的，所述图像被预呈现(pre-render)和存储为一组targa或.tga格式的图形文件120。
创作工具130因而用于导入图形文件120并且将它们从.tga格式转换成可被称为.pic文件140的格式。如在下面更详细讨论的，从.tga文件到.pic文件140的转换涉及通过游程长度(run length)编码处理来压缩文件。创作工具130因而用于创建一组可被称为.act或动作文件(action file)150的文件。如下所讨论的，每一.act文件150包含一系列描述将如何操纵.pic文件140中的图像来创建360-3D游戏的指令。在已创建.pic文件140和.act文件150之后，所述文件可被一起存储为可称为容器160的单个数据文件组。
一般在单个计算机170上存在创作工具130、.pic文件140、.act文件150和容器160。虽然在图1中图形程序110和图形文件120被示出在计算机170之外，但是在其他实施例中，可以在存在所述创作工具130、.pic文件140、.act文件150和容器160的同一计算机170上存在所述图形程序110和图形文件120。
当将要在移动电话、PDA或类似装置上安装360-3D游戏时，将容器160从计算机170拷贝到移动装置180中。可替换地，在被传送到移动装置180之前，所述容器160可以存储在中间地点中。例如，可在网站上得到所述容器160以便下载到移动装置180中，或者，所述容器160可存储在CD或其他存储介质上以便拷贝到所述移动装置180中。本领域技术人员熟悉其中可将容器160从计算机170传送到移动装置180的其他方式。
可以预期，在容器160中的文件将是与计算机170和移动装置180都兼容的格式，并且不需要对所述文件进行修改作为传送过程的一部分。但是，即使为了兼容性需要微小的修改，所述文件也应当被认为基本上等同并且在此将被称为处于容器160中，而不管所述容器160是在计算机170中，还是在移动装置180中。
在移动装置180中还存在运行时引擎190，其可以读取在容器160中的文件。如在下面更详细讨论的，引擎190读取在.act文件150中的关于应当如何操纵.pic文件140中的图像的指令。然后引擎190检索合适的.pic文件140，按照指示操作它们，并且在移动装置180的显示屏幕200上显示它们。
容器160一般载入到移动装置180中的非易失性存储单元(诸如闪存)中。在容器160中的文件是简单的数据文件，而不是可执行文件，因此，可以预期，当将容器160载入到移动装置180中时，不会产生诸如病毒或编码错误之类的问题。
在优选实施例中，引擎190被嵌入到移动装置180的操作系统中。可以稍微修改引擎190以便与不同装置和不同操作系统兼容，但是可以在任何移动装置180上安装基本上相同的引擎190，并且所述引擎190可以读取任何容器160。通常，仅仅可以修改引擎190以使用等价的操作系统调用来初始化一定时器功能，该定时器功能每秒调用引擎190大约十五次，以写存储单元、触发显示更新、和使引擎190进入休眠状态。引擎190是360-3D游戏的唯一的可执行部分。一旦针对特定移动装置180和操作系统测试和调试了引擎190，则不需要为在那种类型的移动装置180上安装360-3D游戏而做进一步的测试或调试。当将在移动装置180上安装新360-3D游戏时，作为任何现有的其他游戏的容器160的替代或附加，将该游戏的容器160简单地载入到所述装置的存储器中。引擎190随后可以读取新容器160以运行所述新游戏。
在详细讨论创作工具130如何创建360-3D游戏以及运行时引擎190如何运行游戏之前，讨论通常在360-3D游戏中出现的360-3D游戏的格式和游戏动作(gaming action)的类型可能是有益的。
360-3D游戏可能落在称为第一人称射击者游戏(first-person shooter game)的类别之中。也就是说，360-3D游戏的玩家采用在移动装置180的视频屏幕200上显示的场景中呈现的虚拟玩家(virtual player)的视角(perspective)。所述虚拟玩家一般能够在所述场景中进行某些移动，并且一般可以进行某些动作，诸如向该场景中的人物(character)或目标射击。应当理解如本领域人员所熟悉的那样，所述动作不限于射击，并且可以是在场景中的虚拟玩家和人物之间的其它类型的交互作用。例如，所述动作可以是选择人物以执行某种活动。但是，为了便于参考，在下文中，虚拟玩家和人物之间的交互作用将被称为射击和/或开火(firing a shot)。也应当理解射击可能涉及向多种不同种类的目标投射多种不同种类的抛射物。一个例子是军事动作的游戏，其中玩家射击其他军事动作形象，诸如士兵、坦克、直升机等等。其他例子包括其中玩家射击恐龙、或从水下透视向鲨鱼射击的游戏，或者其他射击图库类型的游戏。所述游戏可以是救火游戏，其中玩家向火喷射水以浇灭火苗。射击和/或开火可以包括喷射、瞄准、选派、和/或选择。可以利用现有系统或针对现有系统创建的其他类型的游戏的例子将容易地向本领域技术人员表明这些。
在360-3D游戏的一个实施例中，虚拟玩家在场景中的单个点上保持固定，但是可以绕着该点自由地旋转。这通过在原地顺时针或逆时针转动或旋转来进行，虚拟玩家可以具有其看上去处于中心的虚拟世界的360°视野。虚拟玩家在其中旋转的场景的背景是一个全景图(panoruma)，该全景图向其自身无缝地环绕(wrap)回来，以便产生虚拟玩家可以在真实世界的场景中无穷尽地转动的景象。因此，玩家可以以顺时针或逆时针的旋转运动转动360°、720°、1080°和其他数量。
真实玩家一般通过按压移动装置180的小键盘上的键来控制虚拟玩家的动作。例如，左和右光标键可以被用于使虚拟玩家向左或右旋转。‘回车’键或其他键可以被用于开火。在其他实施例中，可以使用其他键或用于提供用户输入的其他装置来执行这些动作。
图2是向下看虚拟玩家210和该虚拟玩家位于其中央的圆形全景图220的俯视透视图。诸如山230或其他布景之类的物体可以出现在背景中，同时，建筑物240和其他人造物体，树木250和其他自然物体，以及人、动物、或不动的人物260可以出现在前景中。可以适当地缩放背景和前景物体以便创建三维景象。当虚拟玩家210旋转时，圆形全景图220的不同部分可以看上去像是进入视野。
图3是对实际玩家在玩360-3D游戏时可能在视频显示屏200上看到的场景的描述。在该图中，示出了圆形全景图220的一部分，并且该部分在显示屏上看上去是平的。在显示屏200上出现如在全景图220上排列的山230、建筑物240、树木250和人物260。人物260、车辆、和其他可移动的物体可以从虚拟玩家210的视角并相对于背景向左和向右移动(下文中，任何能够在场景中移动的物体将被称为人物260，而不管该物体是具有人、动物、车辆、还是其他类型的可移动物体的外观)。人物260也可以在尺寸上放大和缩小以看起来象是在向虚拟玩家210移动和离开虚拟玩家210。也可以使用缩放来给出固定物体接近或离开虚拟玩家210的感觉。
场景包括多个不可见的层，所述层指示人物260相对于背景和前景的深度。当向左或向右移动时，人物260向多个层之一移动。也就是说，人物260可以尽可能地接近前景、尽可能地接近背景、或在最近的前景和最远的背景之间的几个层中的任意一个中。这允许处于不同层中的人物260看起来象是在彼此前面或后面移动，当其在前面经过时，上层的人物260掩蔽下层的人物260。当在尺寸上放大或缩小以创建向前或向后移动的景象时，人物260也可以改变层。
图4描述该分层原理。山230可以处于最远的层或背景中，其可被称为层0。树木250可以呈现在位于层0之前的层10中；另一树木250可以呈现在位于层10之前的层20中。两个建筑物240可以呈现在位于层20之前的层30中。人物260可以呈现在位于层30之前的层40中。虽然仅仅示出了五个层，但是，在其他实施例中，也可以呈现其他数目的层。在同时显示所有的层并且选择在所述层中的物体的合适尺寸时，当物体出现在其他物体之前或之后并且出现相关的掩蔽时，在屏幕200上产生了三维景象。
返回图3，在屏幕200上呈现十字准线270以示出虚拟玩家210正在瞄准的地方。在其他实施例中，可以使用诸如指针、瞄准指示器或目标刻线之类的其他目标指示器来代替十字准线270。下文中，任何这样的目标指示器将被称为十字准线270。十字准线270在屏幕200从左到右的中央。真实玩家使得虚拟玩家210向左或向右旋转的效果是在场景中的图像旋转，但是十字准线270保持在从左到右的中央。真实玩家也可以利用在移动装置180的小键盘上的向上和向下光标键或类似的输入机构使得十字准线270向上和向下移动。以这种方式，真实玩家可以尝试在场景中的人物260或其他目标上设置十字准线270。通过敲击在移动装置180的小键盘上的合适的键或通过提供一些其他的合适输入，真实玩家使得在十字准线270的中央实施动作(例如开火)。如果十字准线270正确地定位在人物260上，则该动作引起人物260的反应(例如，使人物260受伤)。
人物260具有向虚拟玩家210实施动作的能力，诸如射击。人物260也可以移到建筑物或布景之中或之后，例如移到在比主体人物260高的层中的建筑物之后，以防止虚拟玩家击中他们。
在屏幕200上呈现可称为‘雷达(radar)’280的图形显示，其指示对虚拟玩家210造成有效威胁的人物260所处的位置，其中所述人物260包括位于在当前可视场景之外的任何人物260。雷达280也可以称为威胁指示器。将在后面详细说明雷达280。
屏幕200也可以包括得分290，其指示虚拟玩家210已杀死多少人物260和/或在多人游戏中虚拟玩家的伙伴或竞争者已杀死多少人物260。将在后面详细讨论多人游戏。在屏幕200上还可以显示其他状态信息，例如剩余的储备、剩余的弹药、和剩余的游戏时间。
象任何第一人称射击者游戏一样，360-3D游戏的游戏玩法的一般原理是虚拟玩家210在人物260杀死该虚拟玩家210之前杀死所有的人物260。此外，虽然讨论是针对射击游戏进行的，但是应当理解类似的原理可以应用于其他类型的游戏。可以预期，其上安装360-3D游戏的装置180的拥有者将主要使用装置180的通话或管理器(orgainzer)功能，而玩游戏将是辅助特征，其将是仅仅偶尔用作临时的娱乐。因此，设计360-3D游戏以允许用户快速和直观地了解规则和其他特征，而不需要大量的指导或实践。诸如雷达280、其垂直位置由特定输入键控制的水平中央定位的十字准线270、使用特定输入键的开火、和由特定输入键控制的虚拟玩家的旋转之类的特征是惯例，这将使得用户能够快速地了解如何使用新360-3D游戏。还将游戏设计为以便最小化设置和启动时间。
虚拟玩家210可以具有能够对人物260造成指定级别的伤害的武器。武器能够造成的伤害的级别可被称为武器的能力。人物260经受的伤害量可以称为损伤(damage)。例如，在虚拟玩家210使用来自具有能力5的武器的子弹击中人物260时，该武器可以对人物260造成5点的损伤。人物260可以具有在他们死之前或在对人物260出现某些其他动作之前能够经受的指定水平的损伤。例如，人物260可能在受到20点的损伤之后死亡。这样的人物260在被具有能力5的武器击中4次之后将死亡。
类似地，人物260可以具有能够对虚拟玩家210造成指定级别的损伤的武器，并且虚拟玩家210可以具有在他被杀死之前能够经受的指定级别的损伤。通常，如果虚拟玩家210在人物260杀死该虚拟玩家210之前杀死了所有人物260，则可以赢得游戏，或达到游戏的新级别。在一般游戏原理上的许多变化是可能的，并且对于本领域人员来说是明显的。例如，能力和损伤的概念容易地扩展到不是针对格斗的游戏，例如救火游戏。
当启动360-3D游戏时，执行各种动作的各种人物260可以出现在场景中的不同位置上。将在下面详细描述其中游戏开发者使用创作工具130来指定将出现那些人物260、他们的特征是什么、他们将出现在哪里和他们将干什么的方式。
在启动游戏时，虚拟玩家210可以以上述方式开始转动、设置十字准线270的位置、和射击。人物260也可以开始射击虚拟玩家210。在一个实施例中，可以使用监视例程来确定在游戏开始时虚拟玩家210开始射击的时间，并且以及可能直到虚拟玩家210开始射击才允许人物260开始射击。以这种方式，可以给虚拟玩家210在游戏开始时安全地观察场景的机会。这也可以给新玩家了解游戏的机会。
人物260的行为由游戏开发者在一个或多个.act文件150中指定或描述，这将在下面详细描述。作为一个例子，人物260可以躲在物体后面规定长度的时间，从该物体后面升起，射击虚拟玩家210，然后返回躲藏处。人物260可以重复该行为直到他被虚拟玩家210杀死为止。
该行为可以被存储成单个.act文件150。应当重申.act文件150仅包含数据，而不包含可执行代码。.act文件150的第一部分可包含与人物260的特征的设置有关的数据，诸如人物260在死亡之前可以忍受的损伤量和如果人物260死亡将采取的动作。.act文件150的第二部分可以包含用于描述人物260升起的指令。.act文件150的第三部分可以包含用于描述人物260射击虚拟玩家的指令。.act文件150的第四部分可以包含人物260应当在隐藏处逗留的时间长度的指令。.act文件150的第五部分可以包含返回第二部分以便重复事件序列的指令。在一些实施例中，这些活动的所有信息可被保存在具有多个分开的部分的单个.act文件150中，或这些活动可以被保存在分开的多个.act文件150中。
如果虚拟玩家210杀死了人物260，则应当查询在.act文件150的第一部分中的设置。这些设置可以标识在人物260死亡时将调用的一个或多个其他.act文件150，并且这些其他的.act文件150可以使得一个或多个其他人物260出现并且执行其他的动作序列。游戏开发者可以使得.act文件150如期望的那样复杂以便描述人物260的复杂的行为。开发者也可以定义多个.act文件150，以便在游戏开始时初始化，来创建如期望的那样复杂的开始情节。
另外，.act文件150可以指令引擎190在任何时间运行或调用如期望的那样多的其他.act文件150。在对人物260发生指定的动作时，一个.act文件150可以指令引擎190启动其他.act文件150。例如，如果第一人物260被杀，则第二人物260可以在场景的一个位置中产生，并且第三人物260可以在另一位置产生。第二人物260和第三人物260的行为将由其他.act文件150来描述。这些其他的.act文件150可描述第二人物260和第三人物260的复杂的动作序列，并且可以标识在对第二人物260或第三人物260出现指定动作时引擎190将启动的其它.act文件150，人物的.act文件150可以指令引擎190在不同环境下调用不同的.act文件150。例如，如果人物260受伤，则通过描述人物260受伤之前的行为的.act文件150，引擎190可被指令调用描述人物260的蹒跚行为的不同.act文件150。如果人物260被杀，则引擎190可被指令调用描述人物260的垂死行为的另一.act文件150。如果人物260移动到特定位置，则.act文件150可以指令引擎190改变人物260的武器的能力或人物260能够经受的损伤量。对于本领域人员来说，可以根据游戏环境改变人物260的行为的其他方式是很明显的。
以这种方式，.act文件150可以指令引擎190在整个游戏的进行过程中启动或调用其他的.act文件150。可以仅仅通过下述方式在运行过程中产生复杂的游戏情节其中虚拟玩家210与人物260交互的方式、其中人物260的动作由它们的.act文件150控制的方式、以及其中根据与旧人物260相关的.act文件150中的数据来产生新人物260的方式。当对特定人物260出现特定动作时或当达到某一得分290时，一般将存在使得游戏结束或使得进入新的游戏级别的.act文件150。
如上所述，当引擎190读取包含在.act文件150中的数据时，引擎190产生使得在.pic文件140中的图像显示在屏幕200上或使得发生其他类型的动作的指令序列。指令序列可称为动作定义。应当理解.act文件150仅仅包含数据，而不包含可操作用于处理的指令或代码。具体而言，.act文件150不包含适合载入到用于由处理器单元，例如中央处理器(CPU)或数字信号处理器(DSP)运行的指令寄存器的机器指令。在此对指令、指导或从事处理功能的.act文件150的任何引用意欲指由读取.act文件150和处理指令以运行游戏的引擎190所完成的处理。.act文件150可被认为是一系列的帧(frame)，其中每一帧保存在被运行时引擎190读取时将执行的一个命令。帧也可以保存其他类型的指令。
在一个实施例中，.act文件150的每一帧包括32字节的数据。在其他实施例中，帧可以是其他尺寸。一个字节可以包含描述或指定将由引擎190执行的命令的指示符(indicator)。其他字节可以包含命令所施加的文件的名称和/或位置，所述文件例如是将被显示为在场景中的图像的特定.pic文件。在一个实施例中，可以由到容器160的地址偏移量来标识文件。除了命令，在其他字节中可以放置其他类型的指令。使用下面描述的创作工具130的游戏开发者可以指定每一帧将保存的命令指示符、文件名称、和其他指令，从而指定当由运行时引擎190读取每一帧时将发生的动作。
当运行时引擎190运行.act文件150时，运行时引擎190可以被描述为启动一个活动。一个活动也可被称为一个动作。一个活动或动作可被认为是.act文件150的一个实例。例如，可以通过启动定义奔跑士兵动画的单个.act文件150三次而在场景中创建三个奔跑的士兵。每一单独的奔跑士兵是一个可区分的和唯一的活动。一个活动包含对描述所述活动的行为、所述行为的当前帧、所述行为所承受的累积损伤、所述行为在场景中的当前位置的.act文件150进行标识的信息，和其他状态信息。本领域技术人员将理解可以根据每一单独活动已承受多少损伤、每一活动是什么时候启动的、以及因此与该活动关联的人物已从原始启动位置移动了多远来区分例如定义由公共.act文件150启动的奔跑士兵的实例的状态的三个活动。在一个实施例中，运行时引擎190向每一活动分配运行路线并且可以在一个时间分段(time tick)或时钟分段(clock tick)内处理多个运行路线。
运行时引擎190在称为时间片或时钟分段或分段的一小部分时间期间执行在多个.act文件150中的多个指令。图5图解了运行时引擎190读取一组四个.act文件150中的帧300。在其他实施例中，可以提供其他数目的.act文件150。.act文件150被示出为相同尺寸，但是不是必须如此。箭头310指示引擎190当前正在读取的帧300。在该例子中，可以看出引擎190正在读取在每一.act文件150中的不同的帧300。当引擎190在同一时间分段期间读取多个.act文件150时，这可以使得在显示屏200上同时出现多个图像。
可在帧中提供的一个命令是‘.pic’命令。如果一个帧包含‘.pic’命令，则运行时引擎190搜索合适的.pic文件140并且在显示屏200上显示在.pic文件140中包含的图像。将在下面更详细描述.pic文件140中的图像。
作为使用‘.pic’命令的一个例子，可以创建.act文件150以便给出人物260正在奔跑的景象。例如可以知道，需要依序显示大约十四种不同的奔跑姿势(每一姿势描述稍微不同的身体位置)来创建逼真的奔跑动作。每一姿势可以存储在分开的.pic文件140中。在.act文件150中的一个帧可以包含调用检索和显示第一奔跑姿势的‘.pic’命令，下一帧可以包含调用搜索和显示第二奔跑姿势的‘.pic’命令，等等。另一帧可能指定将重复先前的十四帧。当在视频屏幕上循环地依序显示十四幅图像时，创建奔跑动作。
已知在视频屏幕上的运动的平滑、逼真描述需要以每秒大约十五或更多次地更新在屏幕上的运动图像。剧场电影通常每秒更新屏幕图像24次，而电视通常每秒更新屏幕图像30次。因此，运行时引擎190以每秒大约15或更多个命令或指令组、或大约每67毫秒至少一个命令的速率来执行在.act文件150中的命令。这67毫秒的时间段可被称为一个时间片、一个时钟分段或分段。对于大部分，在时间分段和帧之间存在一对一关系。即，每一分段从每一行动.act文件150读取一个帧。但是，在一些场合下，诸如当在一个帧存在被称为‘多个(muti)’的指令选项，则在单个分段中可以读取多于一个的帧。将在下面详细讨论‘多个’指令选项。应当理解在当前描述的实施例中提供上述帧显示速率、分段处理速率和读取.act文件150的帧的速率，但是可以在其他实施例中使用其他速率。
可能需要区分对于在此使用的词‘帧’的两种不同用法。在通常的用法中，胶片被描述成以每秒某一数目的帧显示，意思是每秒显示的图像数。利用这种用法，360-3D游戏可以被描述成以每秒大约15帧来显示。词‘帧’也可指在此称为.act文件的‘帧’的.act文件150的数据分组或部分。
在一个实施例中，除了‘.pic’命令之外，在.act文件150的帧中可能出现下述命令‘启动(launch)’、‘转向(go to)’、‘如果.act转向自己(if.act go to self)’、‘损伤(damage)’、‘删除(delete)’、‘删除自己(delete self)’、‘重新载入(reload)’、‘奖励(bonus)’、‘声音(sound)’、‘声音停止(sound stop)’、‘射击(shoot)’、‘说(say)’和‘听(hear)’。‘启动’命令使得在当前.act 150a继续运行的同时，.act 150b的一个实例开始运行。例如，根据对说明奔跑形象的动画所需要的‘.pic’命令的序列进行描述的单个.act 150，可以启动奔跑士兵的多个实例。正在运行的.act150的每一实例可被称为一个活动。术语活动也可以指由引擎190读取.act 150的帧。
‘启动’命令产生由在启动命令中标识的.act文件150定义的一个活动。可以使用启动命令来许可一个人物260使得产生另一人物260。例如，如果第一人物260被杀死，则可以产生第二人物260，作为例如发送以替代伤亡的援军。这可以通过在与第一人物260有关的.act 150a的帧中放置用于启动与第二人物260有关的.act 150b的‘启动’命令来实现。可以期望在第二人物260处于有效的同时，使第一人物260的尸体保持可见。‘启动’命令将允许在使得与第二人物260有关的.act 150b开始运行的同时与第一人物260有关的.act150a保持有效并且显示尸体。本领域技术人员将认识到其中可以使用‘启动’命令来控制在3D-360游戏中的动作的其他方式。
‘转向’命令类似于‘启动’命令，因为在由第一.act 150a定义的第一活动中的‘转向’命令可以使得由第二.act 150b定义的第二活动开始运行。但是，和‘启动’命令不同，在第一活动中的‘转向’命令使得第一行为停止运行并且被删除。在上述例子中，如果不期望在第一人物260被杀死之后第一人物260的尸体保持可见，则可以使用‘转向’命令。如果当第一人物260被杀时使用‘转向’命令来产生第二人物260，则由第一.act 150a定义的并且和第一人物260有关的活动将停止操作，并且通过在下一时间分段不显示，第一人物260将消失。
‘转向’命令也可以提供上述奔跑人物的例子中的循环能力。在这种情况下，‘转向’命令用于使得.act 150转向自己。当使用‘转向’命令时，可以指定在.act 150中的哪一帧是‘转向’命令的目标。为了下面讨论的原因，可能不希望.act 150的第一帧作为‘转向’命令的目标。因此，当使用‘转向’命令来创建在.act 150中的循环时，‘转向’命令一般将.act 150的执行重置到.act 150的第二帧。这样的命令使得.act 150的运行在‘转向’命令所在的点停止并且返回.act150的第二帧。.act 150的第二帧到最后一帧将因此被重复执行。360-3D游戏开发者可以使用‘转向’命令来描述人物260的其他行为的其他方式对于本领域技术人员来说将是明显的。
‘如果.act转向自己’命令是向360-3D游戏开发者提供用于描述人物260的行为的许多能力的强大命令。利用该命令，文件.act 150a可以确定第二.act150b当前是否是运行的。如果第二.act 150b是运行的，则第一.act 150a的运行移到在第一.act 150a中的不同帧或采取其他动作。这可以允许由第一.act150a控制的人物260根据第二.act 150b是否正在运行而执行不同的动作以便提供附加游戏功能。
例如，如果在第一层中不存在特定物体，则可能期望使得由第一.act 150a控制的人物260在第一层中在屏幕200上从左向右移。如果在第一层中存在该物体，则可能期望使得人物260在第二层中移动。为此，控制人物260的.act150a可以包含使得人物260看上去象在第一层中移动的第一组指令以及使得人物260看上去象是在第二层中移动的第二组指令。.act 150a也可以包含检查是否存在物体的‘如果.act转向自己’命令。
人物260可以开始在第一层中移动并且控制人物260的.act 150a可以周期地运行‘如果.act转向自己’命令以确定该物体是否存在。如果该物体不存在(即如果控制该物体的.act 150b当前不是运行的)，则控制人物260的.act 150a可以继续运行第一组指令并且留在第一层中。如果该物体存在(即如果控制该物体的.act 150b当前是运行的)，则控制人物260的.act 150a可以跳转到第二组指令并且因此使得人物260看上去象是移动到了第二层。这可能使得人物260看上去象是移到了该物体背后。本领域技术人员将能够找到可以使用‘如果.act转向自己’命令来组织360-3D游戏的编程逻辑的许多其他方式。
使用‘损伤’命令来指定在人物260被杀死或对人物260发生某些其他动作之前人物260能够忍受的损伤量。‘损伤’命令也指定当到达人物260的损伤阈值时将发生的动作。例如，如果在第一.act 150a中的‘损伤’命令给出20的损伤级别并且与称为‘die1’的第二.act 150b相关联，则当由第一.act 150a控制的人物260经受到20的损伤时，将开始运行‘die1’.act 150b。‘die1’.act 150b可以描述人物260倒向地面。
‘损伤’命令一般放置在.act 150a的第一帧中。在该帧中指定的损伤阈值和在到达该阈值时将启动的.act 150b的名称在运行.act 150a的整个过程中保持有效，除非被随后的‘损伤’命令修改。改变在到达阈值时将运行的.act 150可以使得人物260在不同环境下以不同方式死亡。例如，在地上的人物260可以具有die1’.act 150b，其使得人物260在垂死时看起来以一种方式倒地。如果人物260随后移到升高的位置，则可以调用‘损伤’命令以改变人物260死亡的方式。通过‘损伤’命令可以指定‘die2’.act 150c以便人物260在垂死时看起来是以不同方式倒地。
‘删除’命令使得由具有特定名称的.act 150控制的所有活动停止运行并且因而使得由主.act 150控制的人物260从屏幕200消失。例如，穿过屏幕200从左向右跑的人物260可以由称为‘run3’的.act文件150来控制。这样的奔跑的人物260或奔跑活动的多个实例可以从‘run3’.act文件150产生。应用于文件名称‘run3’的‘删除’命令可以使得从‘run3’.act文件150产生的所有奔跑的人物260或奔跑活动同时停止运行，以及使人物260或奔跑活动的所有实例同时消失。
相反，‘删除自己’命令将仅仅使得运行其‘删除自己’命令的活动停止运行。例如，因为由‘run2’.act文件150产生的第一活动是循环的，因此当处理第一活动时引擎190不会遇到在‘run2’.act文件150内的‘删除自己’命令。然而，当处理由‘run2’.act文件150产生的第二活动时，由于可以将不同的事件(例如由虚拟玩家210开火)应用于第二活动，所以引擎190可能会遇到‘删除自己’命令，这使得对第二活动的处理和循环脱离，并且进一步前进以处理‘删除自己’命令。在这种情况下，与由‘run2’.act文件150产生的第二活动相关的人物260将消失，但是与由‘run2’.act文件150产生的第一行为相关的人物260将继续可见。
‘重新载入’命令使得能够改变虚拟玩家210可获得的弹药量。虚拟玩家210一般以固定量的弹药开始游戏。由虚拟玩家210进行的每一射击将该量减少虚拟玩家210正使用的武器的威力值。例如，如果虚拟玩家210以100的弹药级别开始游戏，并且如果虚拟玩家210使用的武器具有威力5，则虚拟玩家210在用完弹药之前可以进行20次射击。‘重新载入’命令可以增加或减少虚拟玩家的弹药级别。例如，如果虚拟玩家210赢得游戏的一个级别，并且移到另一级别，则可以调用‘重新载入’命令来将虚拟玩家的弹药级别重新设置到其最大值。此外，如果虚拟玩家210击中无辜的人物260而不是敌人，则可以调用‘重新载入’命令来从虚拟玩家210扣除弹药。可以使用‘重新载入’命令来增加或减少属于玩主游戏的任何储备。
‘奖励’命令允许在某些环境下给虚拟玩家210附加的点。通常，虚拟玩家210接收的点数等于杀死人物260所需要的损伤。也就是说，如果杀死人物260需要20点的损伤，则虚拟玩家210将接收用于杀死人物260的20点。通过在.act 150的帧中插入‘奖励’命令，游戏开发者可以允许虚拟玩家210接收大于用于杀死人物260的正常点数。当其他事件发生时，也可以给奖励点。
‘声音’命令使得可以在帧中播放声音。可以在包含‘声音’命令的帧中指定包含声音的文件的位置和名称。循环值可以和‘声音’命令相关联以使得声音可以重复指定的次数。可以使用‘声音停止’命令在声音正常停止之前停止该声音。
使用‘射击’命令来给予一个.act 150对当前正在播放的另一.act 150造成损伤的能力。作为例子，‘射击’命令可以允许物体爆炸以杀死人物260。
‘说’命令允许.act 150向另一.act 150发送消息。‘听’命令给予一个.act 150收听来自其他.act 150的消息的能力。
对于本领域技术人员来说，很明显，上述命令及其变形可以向360-3D游戏开发者提供描述复杂游戏情节的能力。本领域技术人员也将认识到可以对这些命令使用其他名称，可以使用其他的命令，可以使用这些命令的较小的组，可以使用各种所描述的功能的组合，或可以使用其他功能，而不会脱离本公开的精神。
为了减小每个帧300的尺寸和产生的.act文件150的尺寸，.act 150的每一帧包括大约1个字节长度的指示符，其指定在该帧中将执行哪个命令。例如，指示符‘1’可以指定‘.pic’命令，指示符‘2’可以指定‘启动’命令，指示符‘3’可以指定‘转向’命令，等等。在其他实施例中，可以使用其他指示符。指示符也指示将与命令相关的文件的类型。也就是说，应该理解，如果在帧中指示了‘.pic’命令，则在该帧中的文件指针或文件名指示将显示的.pic文件140。如果在帧中指示了‘启动’命令，则在该帧中的文件指针或文件名指示将启动的.act文件150，等等。应当理解已采用诸如这些的多个方面在存储、存储器要求和其他方面减小了360-3D游戏的大小以便使得游戏能够在具有标准硬件能力的移动装置180上运行。可以看出可以将每一帧认为是在.act数据文件中的一个记录，其中在记录中的每一字段包括代表数据。例如，第一字段可以用在与所指示的命令相关的字段中的数据来与上述命令相关联。
除了命令之外，在帧中还可以提供其他指令。在一个实施例中，附加指令包括‘绝对x(absolute x)’、‘绝对y(absolute y)’、‘Δx(delta x)’、‘Δy(delta y)’、‘比例(scale)’、‘层(layer)’、‘威力(power)’和‘多个(multi)’。‘绝对x’和‘绝对y’分别指定在出现对象(例如由该帧所指向或引用的.pic文件定义的图像)的水平和垂直位置的像素数目。‘绝对x’和‘绝对y’指令一般仅仅出现在.act 150的第一帧中以指定对象的开始位置。在运行由.act 150定义的活动期间，一般不返回在其中出现‘绝对x’和‘绝对y’指令的帧，这是因为返回到该帧将导致人物260从其当前位置移到其开始位置。这可能造成可能不希望的大的、突然的跳跃。
‘Δx’和‘Δy’指令分别指定人物260相对于该人物在前一帧中的位置而要水平和垂直移动的像素数目。在上述例子中，其中十帧的奔跑运动创建人物260奔跑的景象，人物260将看上去正在原地奔跑，除非指定穿过该场景的移动。为了创建移动的景象，在每一帧中的‘Δx’指令可以指定人物260将相对于背景水平位移的距离。
‘比例’指令指示人物的相对尺寸，并且一般被指定为标准尺寸的百分比。逐帧地增大人物260的比例可以创建人物260正在向虚拟玩家210移动的景象，而逐帧地减小人物260的比例可以创建人物260正在离开虚拟玩家210的景象。
‘层’指令指定如在图4中所描述的对象出现的层。当通过改变比例，人物260看起来向前或向后移动时，游戏开发者一般将指定改变人物的层。
‘威力’指令指定人物的武器所拥有的威力值，以及因此，当人物260击中虚拟玩家210时，对虚拟玩家210所造成的损伤量。在人物260没有射击时，游戏开发者可以将人物的武器的威力设置为零，而在人物260射击时，将威力改变成某一其他值。这可以通过使用两个描述人物260的不同.act文件150来实现，所述两个文件中的一个示出人物260射击，而另一个示出人物260未射击。当在两个.act文件150之间交替如何描述人物260的控制时，可以调用‘威力’指令在零和某一正值之间交替威力。虽然上面参照面向射击的游戏描述了‘威力’指令，但是应当理解‘威力’指令可以推广到其他游戏情节中。
可以在每一帧中选择或不选择的‘多个’指令选项允许基本上同时读取和运行两个或多个帧。如上所述，一般在一个时间分段期间，或每67毫秒，读取每一.act文件150的一个帧。当在帧中选择了‘多个’选项时，在单个分段期间，读取和处理在同一.act文件150中的该帧和下一帧。这提供了大量描述能力并且可以被用于例如当执行‘转向’时，在一帧期间通过无闪烁地显示动画来保证运动图像按照要求运转。
例如，在上述奔跑运动的例子中，描述了.act 150的十四个帧可以包含导致将要显示的奔跑运动的不同姿势的‘.pic’命令，而第十五帧可以包含返回第一奔跑帧的‘转向’命令。如果在任何一帧中都没有选择‘多个’选项，则在不同的时间分段中将读取所述帧的每一个。在第十五帧中运行‘转向’命令期间，在读取该帧时并且在第一奔跑帧被再次读取和由引擎190处理以用于显示之前，将不显示任何图像，并且将在屏幕200上出现67毫秒的闪烁。
通过在第十四帧中选择‘多个’指令选项可以防止该闪烁。‘多个’指令将指示在同一时间分段期间，将读取和处理第十四帧和第十五帧。也就是说，在同一时间分段中处理使得将显示第十四奔跑姿势的‘.pic’命令和使得.act150返回第一奔跑帧的‘转向’命令。然后可以在下一时间分段或67毫秒时间段中运行第一奔跑帧。
单个‘多个’指令使得将在同一时间分段中运行当前帧和仅仅是紧随的帧。但是，可以在如期望的那样多的连续帧中选择‘多个’指令选项，以便使得在同一时间分段中运行如期望的那样多的帧。例如，如果在显示人物260的图像时，期望同时返回到在当前.act150a中的循环的开始、启动另一.act150b、并且改变杀死人物260所需要的损伤值，则可以使用多个具有‘多个’指令的连续帧。第一帧可以具有‘.pic’命令和‘多个’指令，第二帧可以具有‘转向’命令和‘多个’指令，第三帧可以具有‘启动’命令和‘多个’指令，而第四帧可以具有‘损伤’命令。在第一帧中的‘多个’指令使得在与第一帧相同的时间分段中运行第二帧，在第二帧中的‘多个’指令使得在与第二帧相同的时间分段中运行第三帧，而在第三帧中的‘多个’指令使得在与第三帧相同的时间分段中运行第四帧。因此，将在同一时间分段中运行所有四个帧。本领域技术人员将能够确定可以使用‘多个’选项来控制360-3D游戏的流程的其他方式。
可以有利地利用可被称为帧0的.act150的第一帧来指定设置，该设置直到它们在.act150的随后帧中被改变为止都将保持有效。例如，可以在帧0中放置‘损伤’命令以设置杀死人物260所需要的损伤量。帧0也可以包含绝对值x、绝对值y、层和比例的指令以建立人物260的初始位置和尺寸。如上所述，在已在帧0中定义绝对值x和/或绝对值y位置的情况下，由于转向帧0可能导致人物260突然从一个位置跳转到另一位置，所以不能将帧0列为‘转向’命令的目标。
可以通过创作工具130容易地指定组成.act150的一帧中的32个字节的数据。图6图解了计算机实现的创作工具130的一个实施例。通常，创作工具130可操作用于有效地创建360-3D游戏。虽然下面描述了创作工具130的一个具体实施例，但意图是本公开应用于用于构建在引擎190上运行的360-3D游戏的其他可选的GUI配置和控制。
创作工具130包括图形用户界面(GUI)500，用于指定将插入到帧中的命令和其他指令；文件选择框900，用于标识将由帧检索的文件；以及仿真器920，用于观看在GUI 500和文件选择框900中进行的选择的效果。仿真器920模仿在玩360-3D游戏时将在移动装置180上出现的显示屏200。
GUI 500包含按钮、文本框、复选框和允许360-3D游戏开发者指定将在帧中包含的命令和其他指令的其他数据输入机构。输入GUI 500的一个实例的数据被保存作为.act150的一个帧。开发者可以通过对于每一帧将数据输入到GUI 500的不同实例来逐帧构建.act150。
为了开始创建新.act150，开发者一般将点击命名为‘新’的按钮600。开发者然后可以输入用于.act150的第一帧(一般为帧0)的数据，可以在命名为‘帧’的文本框610中指定输入到GUI 500的信息所施加到的帧。在输入帧的数据之后，开发者可以更改在帧文本框610中的帧编号并且开始输入下一帧的数据。该过程可以继续到已创建了针对当前.act150的所有帧。开发者然后可以点击‘保存’按钮890以保存.act150。
命名为‘类型’的下拉框620用于指定将在帧中运行的命令。在一个实施例中，命令是如上所述的‘.pic’、‘启动’、‘转向’、‘如果.act转到自己’、‘损伤’、‘删除’、‘删除自己’、‘重新载入’和‘奖励’，而在其他实施例中可以使用其他命令。在本实施例中，仅将一个命令输入到每一帧中。下拉框620列出了可以应用于帧的所有可能的命令，并且开发者可以利用鼠标点击列表中的项来选择期望的命令。
在GUI 500上出现的数据输入机构可以根据在命令下拉框620中选择的命令来改变，这使得GUI 500是上下文有关的GUI。在图6的实施例中，已选择‘损伤’命令，并且这使得出现命名为‘损伤(Damage)’的文本框630。损伤文本框630允许开发者指定将应用于当前帧的损伤。如果在命令下拉框620中已选择其他命令，则可出现其他文本框以替代损伤文本框630。例如，如果已选择‘.pic’命令，则可以出现下述文本框，所述文本框将允许开发者指定将应用于由特定.pic文件140描述的人物260的能力。如果已选择‘转向’命令，则可以出现下述文本框，所述文本框将允许开发者指定接着将读取和运行的帧的编号。
命名为‘动作’的文本框640允许开发者指定当前帧将使得其开始运行的任何.acts 150。在图6的实施例中，已在命令下拉框620中选择‘损伤’命令，因此，在动作文本框640中列出的.act 150指定在当前人物260达到指定的损伤阈值时将开始运行的.act 150。例如，动作文本框640可以列出描述人物260垂死的.act 150。如果已在命令下拉框620中选择‘启动’命令或‘转向’命令，则在动作文本框640中列出的.act 150将指定当达到当前.act 150a中的当前帧时将开始运行的.act 150b。
可以手动将数据输入到动作文本框640中。可替换地，可以使用文件选择框900来选择.act 150以输入到动作文本框640中。也就是说，开发者可以浏览文件选择框900直到找到期望的.act文件150为止。然后可以点击在文件选择框900中的选择按钮910来自动将所选择的.act文件150插入到动作文本框640中。
命名为‘路径’的文本框650指定可以在其下找到在动作文本框640中所列出的.act文件150的目录路径。可以手动地将数据输入到路径文本框650中，或可以根据由开发者在文件选择框900中选择的.act文件150的位置自动输入路径数据。
动作文本框640和路径文本框650可以仅仅当在命令下拉框620中选择了诸如‘损伤’命令之类的特定命令时才出现。通过将GUI 500描述成上下文有关的GUI来说明该行为。当选择了其他命令时，在图6中动作文本框640和路径文本框650所处的位置中可出现其他文本框。例如，如果在命令下拉框620中选择了‘.pic’命令，则在属于当前帧将检索的.pic文件140的动作文本框640和路径文本框650的位置可以出现文本框。
命名为‘Abs x’的文本框660和命名为‘Abs y’的文本框670允许开发者指定人物260将在屏幕200上出现的绝对水平和绝对垂直像素位置，其可以相对于360度背景景观图像的坐标。可以手动地输入绝对x和绝对y位置，或可替换地，可以使用文件选择框900和仿真器920来设置绝对x和绝对y位置。例如，开发者可以浏览文件选择框900直到找到期望的.pic文件140。当开发者选择.pic文件140时，在仿真器920中出现在.pic文件140中的人物260的图像。在Abs x文本框660和Abs y文本框670中出现图像的绝对x和绝对y位置。开发者可以在仿真器920中移动图像直到该图像处于期望的位置为止。然后可以将该位置设置为人物260将首次出现的位置。
也可以使用Abs x文本框660和Abs y文本框670来设置非移动物体的位置，诸如在仿真器920中示出的卫星反射器925。可以向诸如此的非移动物体给予可由来自虚拟玩家210的射击破坏的能力。
如上所述，一般将仅在.act 150的帧0中指定图像的绝对x和y位置。下文中，将使用Δx指令和Δy指令来指定相对于先前帧、图像应在当前帧中移动的像素数目。可以在文本框680中指定Δx值，可以在文本框690中指定Δy值。对于.act 150的每一帧，可以手动输入Δx和Δy值。可替换地，在GUI 500中可用快捷方式，以使得Δx和Δy值的输入更容易。复制按键700位于Δx文本框680和Δy文本框690附近。当选择了复制按键700时，在与复制按键700相关联的Δx文本框680或Δy文本框690中的值将针对.act 150的每一帧而自动重复。以这种方式，可以容易地使得人物260在.act 150的每帧中移动相同的距离。
命名为‘层’的文本框710允许开发者指定在当前帧中人物260将出现的层。复制按键700与层文本框710相关联，以允许开发者指定将相同层应用于.act 150中的每个帧。
开发者可以使用命名为‘比例’的文本框720来指定在当前帧中人物260将具有的相对尺寸。一般以百分比来给出比例，并且缺省值是100％。另一复制按键700与比例文本框720相关联以允许开发者指定在.act 150的每帧中人物260将具有相同的尺寸。
在一个实施例中，在层文本框710中的数据和在比例文本框720中的数据可以自动地彼此相关以便可以在调整比例时自动地对层进行合适的调整，反之亦然。例如，如果开发者逐帧地将人物260的比例减小恒定的量，以创建向背景移动的景象，则人物260所处的层可以自动地逐帧以成比例的量改变以便该人物移向逐渐靠近背景的层。
命名为‘重复’的文本框730提供了快捷方式，其使得如在重复文本框730中所指定的那样多的时间分段期间重复读取和运行当前帧。这为非移动图像在显示屏200中临时出现提供了一种便利方式。例如，如果开发者需要物体出现大约10秒(大约150个时间分段)，则可以在命令下拉框620中放置‘.pic’命令，可以在动作文本框640中放置包括期望物体的图像的.pic文件140，并且可以在重复文本框730中放置数值150。
可以使用命名为‘多个’的复选框740来指定是否对当前帧应用‘多个’指令。如上所述，如果选择了多个框740，则将在同一时间分段中读取和运行当前帧和下一帧。
命名为‘定位视图(Locate View)’的按钮750将在仿真器920中显示的视图返回到当前.act150开始的场景。当开发者使用创作工具130对在.act150中的多个帧工作时，在仿真器920中显示的视图改变以匹配在GUI 500中的当前帧的数据。如果开发者点击定位视图按钮750，则仿真器920返回由.act150指定的初始场景。
命名为‘插入’的按钮760使得一个新帧插入到GUI 500中当前正对其进行操作的帧之前(或，在另一实施例中为之后)。‘删除’按钮770使得当前帧被删除。‘削减(Chop)’按钮780使得在当前.act150中从当前帧开始向前的所有帧被删除。
命名为‘添加(Append)’的按钮790提供快捷方式，其用于对于几个连续、紧密相关的帧输入类似的数据到GUI 500中。具体地，添加按钮790使得在帧文本框610中的帧编号增加1，并且使得在.pic文件140的文件夹中的下一.pic文件140的名称被插入到动作文本框640中。当递增一帧至下一帧时，在GUI 500中的所有其他信息保持相同。该特征是有用的，例如在其中使用每一个都包含运动动画的不同阶段的.pic文件140的序列创建动画运动时。
作为一个例子，可以使用添加按钮790来使得能够便利地创建描述人物260奔跑的.act150。描述每一奔跑姿势的.pic文件140可排列在下述文件夹中其具有包含列在第一的第一奔跑姿势的第一.pic文件140，包含列在第二的第二奔跑姿势的第二.pic文件140，等等。开发者可以将命令下拉框620设置成‘.pic’命令，将在帧文本框610中的帧编号设置为1，并且将第一.pic文件140的名称放置在动作文本框640中。这将导致当前.act150的帧1显示在第一.pic文件140中的图像。
如果开发者随后点击添加按钮790，则在帧文本框610中的帧编号将变为2，并且在动作文本框640中将放置第二.pic文件140的名称。在添加按钮被点击之前的在GUI 500中的其他信息将保持相同。这将使得当前.act150的帧2显示在第二.pic文件140中的图像。开发者可以继续点击添加按钮790直到说明了包括奔跑姿势的所有.pic文件140为止。可以看出，使用添加按钮790比手动改变帧编号和手动改变.pic文件140的名称更有效。这可以为没有编程经验的人提供一种快速和方便的方式来将运动加入到游戏中。
可以使用一组按钮800、810、820和830在当前.act150的帧之间导航。第一帧按钮800将GUI 500带到当前.act150的第一帧。前一帧按钮810将GUI500带到当前.act150的前一帧。下一帧按钮820将GUI 500带到当前.act150的下一帧。最后一帧按钮830将GUI 500带到当前.act150的最后一帧。
命名为‘停止’的按钮840从仿真器920清除除了背景图像之外的所有图像。可以使用命名为‘命令1’850、‘命令2’860、和‘命令3’870的按钮来设置在开始新游戏时或在到达游戏的新级别时有效的参数。在优选实施例中，360-3D游戏可以具有三个级别的游戏，其中玩家只有在成功完成第一级别之后才可以移到第二级别，以及只有在成功完成第二级别之后才可以移到第三级别。其他实施例可以具有不同数量的级别。在一个实施例中，启动第一、第二和第三级别的.act150可被分别称为command1.act、command2.act和command3.act。在一个实施例中，command.act仅仅包含启动在一个级别的游戏开始时发生的动作的.act文件150组的命令。当选择命令1按钮850时，开发者将被带到GUI 500以输入与command1.act有关的数据。选择命令2按钮860或命令3按钮870将把开发者带到GUI 500以分别输入与command2.act或command3.act有关的数据。
可以使用一组按钮880在仿真器920中指定人物260的位置和尺寸。向左按钮881和向右按钮882通过仿真器920水平移动人物260，而向上按钮883和向下按钮884通过仿真器920垂直移动人物260。比例按钮885和886增大或减小人物260的尺寸。可以使用这些按钮880来替代Abs x文本框660、Absy文本框670和比例文本框720，以快速地设置人物的初始尺寸和位置。
创作工具130提供了方便地将包括背景全景图的背景.bmp文件和人物.tga文件导入.pic文件140格式，创建.act文件150以及其他游戏描述操作。创作工具130一般将被安装在标准的台式计算机170上，并且可以通过计算机的标准键盘和鼠标将数据输入到GUI 500中。可替换地，可以使用自定义键盘来输入数据。所述自定义键盘可以具有与在GUI 500中的按钮和其他数据输入机构等同或相关的键。在自定义键盘上的键可以被颜色编码(colorcoded)以作为对开发者的记忆辅助。例如，属于与.pic相关的数据的键可以是一个颜色，而属于与帧相关的数据的键可以具有另一颜色。‘添加’键可以具有两种颜色，因为所述添加功能涉及.pic数据和帧数据两者。熟悉创作工具的开发者可能会发现，这样的自定义键盘比使用鼠标指向和点击在GUI 500中的控制键要快。
由于创作工具130一般安装在计算机170上，所以仿真器920将一般出现在计算机170的视频监视器上。由计算机使用的视频格式一般和由诸如移动电话之类的移动装置使用的格式不同。在下面详细说明的转换过程将在.pic文件140中的图像转换成计算机170的视频显示系统可读的格式。转换是数据在仿真器920中显示之前的最后步骤，其仅仅涉及对其中以两种不同视频显示模式编码色彩的方式的改变。这保证了通过创作工具130开发的360-3D游戏将与其在仿真器920出现基本相同地出现在移动装置180上。
创作工具130允许具有较少或没有编码技能的游戏开发者创建360-3D游戏。开发者可以只选择将在游戏上出现的图像，并且然后使用创作工具130来创建将由引擎190用来按照需要来操纵图像的.act文件150。可以通过使用放置在.act文件150的每一帧中的命令和其他指令来创建复杂的游戏故事情节。没有编程知识的单纯的绘画艺术家能够在相对短的时间内创建360-3D游戏。这可与开发视频游戏的传统方式形成对照，在所述传统方式中，可能雇用编码员来进行编程工作，并且可能雇用绘画艺术家来做艺术工作。以传统方式传间视频游戏会花费相对长的时间，并且会花费大量的金钱。
创作工具130支持对360-3D游戏的快速和方便的测试和改进。在一个典型的涉及开发编程语言指令形式的计算机软件的游戏开发环境中，在测试游戏的修改之前，可能需要编译和链接游戏的新版本并且将可执行图像传送到运行平台。与之相对，使用创作工具130的仿真功能，可以立即测试360-3D游戏的修改。而且，可以使用创作工具130完整地测试360-3D游戏，并且不需要在目标移动平台或移动装置上测试。
当已创建了360-3D游戏所需的所有.act文件150时，可以将用于游戏的.pic文件140和.act文件150放置到容器160中，并且该容器160可被载入到移动装置180中。安装在移动装置180上的运行时引擎190可读取载容器160中的文件，并且运行在.act文件150中的命令和其他指令。为了更快、更有效地运行，运行时引擎190可被嵌入到装置180的操作系统中。也就是说，在优选实施例中，引擎190是对操作系统的扩展，而不是与操作系统独立的外部应用程序。在其他实施例中，引擎190可以位于其他位置。
通过操作系统的定时机制在某种程度上控制或协调运行时引擎190的操作。如在图5中所述，在同一时间单位分段，运行时引擎190可以读取和运行在多个.act文件150中的帧，这可被称为“同时”运行多个帧。可以预期可针对将嵌入引擎190的每一操作系统创建引擎190的稍微不同的版本，但是这些不同版本可以被认为是基本等同的。
引擎190是运行360-3D游戏所需的唯一可执行文件，虽然在某些实施例中，引擎190可包括多个文件或组件。一旦引擎190已被嵌入到移动装置180的操作系统中，仅通过载入不同的容器160就可以在装置180上安装不同的游戏，所述容器160仅包含数据文件，而不包含可执行文件或代码。在为移动装置180开发多个应用时，使用单个可执行文件以运行多个不同游戏可以简化一般跟随在后的认证过程。移动装置180的制造商要求测试和/或认证将安装在他们的移动装置180上的游戏和其他应用，以确保应用不隐匿病毒并且不会导致死机或其他问题。对于以前存在的、其中每一游戏包含可执行代码的游戏，该测试可能需要针对每个游戏和针对将安装该游戏的每个平台来进行。对于360-3D游戏，仅仅需要认证和/或测试引擎190。一旦针对特定平台认证了引擎190，就可以将容器160载入到该平台上，而没有病毒、死机或其他问题的威胁，这是因为如上所述，容器160仅包含数据。
将360-3D游戏分成用于所有游戏和所有移动装置180的单个可执行引擎190以及保存使得每个游戏为唯一的数据文件的多个容器160，可以简化开发者的游戏创建过程。开发者不需要对于不同平台写同一游戏的不同版本。可以由其上已安装运行时引擎190的任何装置180来读取通过创作工具130创建的任何容器160。
运行时引擎190是相对小的文件(通常小于大约100千字节)，这使得对于操作系统，仅仅要求两个图形功能。首先，引擎190向操作系统询问保存在移动装置180的显示屏幕200上的每一像素的数据的存储块的位置。屏幕200一般使用存储缓冲器，其对于每一像素包含两个字节的数据。当引擎190了解了该缓冲器的位置时，它将合适的像素数据放置在合适的字节中，并且然后通知操作系统将该数据发送到屏幕200。
除了读取和运行.act文件150以及执行图形功能之外，运行时引擎190执行几个其他功能。它接收和处理来自在移动装置180上的小键盘或来自其他输入源的输入，并且它按照层来对图像排序，并且以合适的前后顺序显示它们。引擎190命名和记住当前运行的不同人物260的不同版本，并且登记和记住虚拟玩家210对人物260的、以及人物260对虚拟玩家210的成功的射击。引擎190显示得分290，操作雷达280，以及接收和处理来自在多人游戏中的同伴的输入(后面将更详细说明多人游戏)。
引擎190以比以前登记击中的方法提供更高的精确度的方式来登记从虚拟玩家210对人物260的成功射击。如图7中所示，一般将在移动装置180的屏幕200上的目标410再现为矩形方框420的部分。没有被目标410占据的方框(box)420的部分不可见，并使得背景可见。以前，如果方框420的任何部分被子弹击中，则将在目标410上登记击中，而不管目标410是否占据方框的被击中的部分。例如，击中位置X430的射击将被登记为对目标410的击中，这是因为它落在方框420中，即使它没有落在目标410(诸如人物260)中也是如此。而且，如果在屏幕200上呈现多个目标410，则控制游戏的代码可能需要顺序询问所有的目标410以确定哪一个占据了被击中的方框420，这是没有效率和费时的。
图8图解了在360-3D游戏中登记击中的方法的一个例子。在图8a中，三个目标占据诸如移动装置180之类的视频显示屏幕440，所述视频显示屏幕具有八个像素的长度445和八个像素的宽度445。方形目标占据像素(1，1)、(1，2)、(2，1)和(2，2)。三角形目标占据像素(4，3)、(4，4)、(4，5)和(5，4)。X形目标占据像素(6，6)、(6，8)、(7，7)、(8，6)和(8，8)。在屏幕440上的其他像素445可以被认为是背景图像的部分。
在一个实施例中，存储缓冲器包含与在实际屏幕440中的每一像素445有关的数据。存储缓冲器可被看作如在图8(b)中所示的轮廓屏幕450，其中在轮廓屏幕450中的每一数据位置455对应于在实际屏幕440中的像素445。也就是说，由于实际屏幕440具有8行和8列的像素445，所以轮廓屏幕450可被认为是具有8行和8列的数据位置455。
无论何时目标占据在实际屏幕440中的一组像素445，关于目标的身份的信息存储在轮廓屏幕450中的相应数据位置455中。在一个实施例中，目标可以是活动，例如，都是由common.act文件150启动的奔跑士兵的可能的多个实例的一个实例。例如，如果方形目标被标识为目标编号‘1’，则‘1’可被存储在轮廓屏幕450的数据位置(1，1)、(1，2)、(2，1)和(2，2)中。如果三角形目标被标识为目标编号‘2’，则‘2’可被存储在轮廓屏幕450的数据位置(4，3)、(4，4)、(4，5)和(5，4)中。如果X形目标被标识为目标编号‘3’，则‘3’可被存储在轮廓屏幕450的数据位置(6，6)、(6，8)、(7，7)、(8，6)和(8，8)中。可将‘0’放置在轮廓屏幕450中的所有其他数据位置455中以指示实际屏幕440中的背景图像的存在。当目标在实际屏幕440上移动时，轮廓屏幕450以相应方式变化。仅处于实际屏幕440中的目标可以作为轮廓屏幕450的部分。
如果向实际屏幕440开火，运行时引擎190记录在开火的时刻十字准线270所指向的实际屏幕440中的像素445。引擎190然后检查对应于被击中的像素445的数据位置455中的数据，以确定哪一个目标当前占据该像素445(如果有的话)。如果在对应于在实际屏幕440中被击中的像素445的、在轮廓屏幕450中的数据位置455中呈现‘0’(背景)，则该射击被记录为未击中或仅导致除了减少贮备之外无变化。如果在该数据位置455中呈现非零数值，则引擎190将该射击记录为击中由在数据位置455中的数据所标识的目标。
继续上面的例子，如果在虚拟玩家210开火的时刻，十字准线270指在实际屏幕440中的像素(4，4)上，则将记录在像素(4，4)上的击中。引擎190将读取在轮廓屏幕450中的数据位置(4，4)上的数据，找到‘2’，并且将该射击登记为在目标编号‘2’(三角形目标)上的击中。例如，如果在实际屏幕440中的像素(5，5)被击中，则该射击被登记为未击中，这是因为非零数值没有占据对应于像素(5，5)的数据位置(5，5)。
该登记击中的方式提供了比先前存在的方法更高的精确度，这是因为通过目标的实际尺寸和形状而不是目标所占据的方框的尺寸和形状来确定击中。例如，在图8a中的X形目标可以占据由像素(6，6)、(6，7)、(6，8)、(7，6)、(7，7)、(7，8)、(8，6)、(8，7)和(8，8)限定的方框。在先前的方法中，由于像素(6，7)、(7，6)、(7，8)或(8，7)在X形目标占据的方框之内，所以击中这些像素的射击将被登记为击中。在当前方法中，由于这些像素是背景图像的部分，所以这样的射击将不被登记为击中。当前登记击中的方式也可比先前的方法快，这是因为运行时引擎190可以查阅轮廓屏幕450并且几乎马上确定被击中的目标。因此，不需要询问所有运行的目标来确定是否一个目标占据了被击中的像素。而且，通过将在像素中的诸如1、2、3等等的数字与相关的动作相关联，引擎190可以迅速地将击中登记到合适的动作。回想动作是引擎190当前运行的.act文件150的一个实例，并且可以从公共的.act文件150启动几个不同的动作。
在移动装置180从其制造商出货之前，运行时引擎190一般被预编译到移动装置180的操作系统中。移动装置180的制造商一般将不允许他们的竞争者访问他们的装置180的操作系统。为此，创建运行时引擎190的企业一般能将引擎190仅嵌入到其自己的装置180的操作系统中，而不是其竞争者的操作系统中。因此，360-3D游戏一般仅仅在由创建运行时引擎190的实体制造的装置180上以上述方式运行。但是，存在可以在竞争者的装置180上运行360-3D游戏的其他方式。
在一个实施例中，运行时引擎190的一个版本可以被嵌入到Java运行时环境中，并且然后该修改的Java版本可以安装在竞争者的装置180上。保存360-3D游戏的.pic文件140和.act文件150的容器160然后可以以上述方式载入到装置180上并且所述容器160可以由基于Java的引擎190读取。由于在引擎190可以和操作系统通信之前它将不得不通过软件的几个层来通信，所以在这种配置下，360-3D游戏的运行可能会较慢。但是，360-3D游戏开发系统和方法的其他优点将仍然是有用的。也就是说，对于各种操作系统和/或装置180的每一个，具有嵌入的运行时引擎190的修改的Java版本可以被认证一次，并且其后可以将容器160载入到装置180中而不需要进一步的测试。而且，开发者可以以上述方式创建360-3D游戏而不管将运行该游戏的引擎190的类型。
在另一个实施例中，可以以类似方式使用由Qualcomm生产的Brew系统。也就是说，可以创建下述的运行时引擎190的版本其可以和Brew通信，以及通过Brew和其上已安装Brew的装置180的操作系统通信。再次(again)，以这种方式运行的360-3D游戏可能比由直接嵌入到操作系统中的引擎190运行的游戏运行得慢很多，但是，再次，将保持360-3D游戏开发方法和系统的许多其他优点。本领域人员将认识到可以在不具有嵌入在它们的操作系统中的运行时引擎190的移动装置180上运行360-3D游戏的其他方式。
也可以使用Java、Brew和类似产品来作为分发360-3D游戏的手段。例如，容器文件160可以被提供在Java包装(wrapper)中，以便容器160具有与Java兼容的接口。Java包装的容器160可以被安装在具有嵌入Java的引擎190的装置上，并且对于本地的容器160和引擎190，可以如上所述读取和运行所述Java包装的容器160。在Java中包装容器160将允许360-3D游戏通过现有的分发通道来分发，其中通过所述现有的分发通道分发其他的基于Java的游戏，诸如可以通过其下载游戏的网站。对于浏览网站的用户，360-3D游戏将看起来是在现有系统上可下载的标准的基于Java的游戏。
如上所述，在屏幕200上显示的图像存储在可被称为.pic文件140的文件中。在.pic文件140中的图像是对于在360-3D游戏中的所有人物260和其他对象需要显示的所有姿势的预呈现的图像。如本领域所公知的，可以使用两个通常的方法来创建视频游戏中的高质量图形预呈现以及多边形和纹理方法(polygon and textured method)。在多边形和纹理方法中，目标被描述成由有纹理和着色的表面覆盖的多边形的网格(mesh)或框架(framework)。当使得目标在游戏的过程中在视频屏幕上移动时，算法计算其中多边形的网格将改变形状以及然后有纹理的表面在多边形的网格上伸展以创建期望的运动的景象的方式。该过程称为对目标图像的呈现，并且通过算法在工作时(on thefly)完成。
利用预呈现，在游戏的过程中目标可能采用的各种可能姿势的每一图像在游戏的开发过程中创建并且存储。当玩游戏并使得目标移动时，从存储器检索合适的图像并且在合适的的时间在合适的位置显示，以创建期望的运动的外观。
可以看出每一方法都有优点和缺点。使用多边形和纹理方法，不需要大量的存储器，这是因为在工作时创建图像，而不是存储在存储器中。但是，在该方法中使用的算法是计算强化的(computationally intensive)，并且需要大量的处理能力来足够快地执行算法以创建逼真的运动。在多边形和纹理方法中，还需要图形加速器。利用预呈现，由于仅仅从存储器检索图像而不是在工作过程中产生，所以需要的处理能力不那么大。但是，需要更多的存储器来存储大量的用于表示目标可能采用的所有可能姿势的预呈现图像。
在任一情况下，对于要在移动装置上运行的、先前存在的具有高质量图形的游戏，所述装置一般将需要是专门设计的、具有高速处理器、图形加速器和/或大存储容量的游戏装置。这样的装置对于主要对装置的通话或管理器功能而不是游戏特征感兴趣的消费者来说可能是惊人的昂贵。
在当前系统和方法的一个实施例中，预呈现方法的改进版本被用在仅仅预呈现描述有限组期望运动所需的图像。游戏开发者可选择人物260将在游戏期间采用的少量运动，并且然后仅仅预呈现逼真描述这些运动所需的图像。由于运行时引擎190将图像的比例处理至不同的尺寸，仅仅需要预呈现一种尺寸的图像。可以通过标准的数据压缩例程来压缩所选择的图像以减小它们的尺寸。对有限数量的图像的预呈现和压缩创建足够小以适合许多移动装置180并且还能够提供高质量图形的图形文件。消除了多边形和纹理方法一般需要的处理能力和图像加速器以及预呈现大量图像一般需要的大存储容量。
在移动装置180上的显示屏200的小尺寸使得该预呈现技术是行得通的。由于在移动装置180的显示屏200上出现的图像在所使用的像素的数量方面较少，所以需要相对少量的存储器来保存高质量压缩图像。足够数量的这些小的高质量图像可容易地适合在许多标准移动装置180的存储容量之内。在诸如通常计算机监视器之类的较大屏幕上以较大尺寸显示的类似质量的图像将消耗大量的存储容量。存储大量的这样的较高质量的图像将要求更多存储容量，但是现在的台式计算机趋向于具有充足的存储容量。如下所述，可以利用可以在计算机屏幕上以和移动装置180的显示屏200大致相同的尺寸出现的仿真器，在计算机上运行360-3D游戏。
创建.pic文件140的过程一般以下述步骤开始游戏开发者使用标准图形操纵程序110(例如True Space、Maya、LightWave、或3DS Studio)来创建、导入和/或编辑合适的一组图像。开发者然后可以将所述图像存储为一组.tga格式的图形文件120，例如，每个.tga文件一个图像。使用.tga格式提供了高质量图像，这是因为.tga文件支持透明度，即允许通过前景图像的透明部分来显示背景图像的属性。.tga文件也支持反混叠，即允许目标的边缘平滑地呈现的属性。虽然这些属性提供了逼真的图像，但是.tga格式的缺点是.tga文件可能十分大。例如，单个图像可能消耗多达七兆字节的存储器。
在一个实施例中，在.bmp文件中定义背景全景图。背景.bmp文件不包含透明信息，这是因为按照定义，背景不是透明的，也就是说，在背景之后不能看到任何东西。背景全景图包含在末端相连的连续区域，以提供360°的视野。在一个实施例中，背景全景图可以包括水平范围的十二个显示屏幕。在一个实施例中，在背景全景图的第一端上的第一屏幕的显示被复制作为在背景全景图的第二端上的最后屏幕的显示，以使得对背景中的一个点的扫描更容易。例如，背景的任何一个屏幕的位置可以被标识为其最左端、最上端的像素的x和y坐标。由于图像环绕分界点，通过从.bmp文件的邻近部分完整读取比从.bmp文件的末端读取第一部分并且在从.bmp文件的开始处读取的第二部分上接合可以更容易地显示在屏面和全景图的开始点重叠的位置开始的屏面。本领域技术人员将理解该问题和利用该常规以解决该问题。
以几种方式来缩小在360-3D游戏中使用的图形文件的尺寸。例如，使用称为游程长度编码的压缩算法以将.tga文件转换成.pic文件140。游程长度编码处理通过指定图像中透明的连续像素的数目而不是每个单独透明像素来缩小文件尺寸。由于在.tga文件中的典型图像的大部分是透明的，所以可以通过使用该方法而不是指定在图像中的每个单独像素的透明性或非透明性来显著缩小文件尺寸。通过对预呈现图像的游程长度编码可以在.tga文件到.pic文件140的转换中获得10∶1的压缩率。作为将.tga图形文件120导入到创作工具130中的部分，发生通过游程长度编码从.tga文件到.pic文件140的转换。在利用图形程序110来产生期望的.tga文件120之后，游戏开发者可以通过选择在创作工具130中的按钮、菜单项、或类似机构来启动导入和转换处理。
而且，在.tga文件120中的每一像素的色彩一般以24位的色彩来编码，并且在总共32位中，8位用于透明性。8位用于红色调(shade)，8位用于绿色调，8位用于蓝色调，并且8位用于表示透明度。.tga文件120被预呈现和转换成16位色彩格式的专门的.pic文件140，这是所需要的全部，因为大多数移动装置仅具有16位彩色显示。在16位.pic文件140数据格式中，5位用于红色调，6位用于绿色调，5位用于蓝色调，由此每像素用于编码彩色信息的位数减少了8位。已知人眼对于可见光谱的绿色区域中的色差相对更敏感。
通过从8R-8G-8B数据中截去低有效位来获得从8位红色、8位绿色、8位蓝色格式(8R-8G-8B)到5位红色、6位绿色、5位蓝色格式(5R-6G-5B)的转换。也就是说，对于每个像素，删去红色数据的三个最低有效位、绿色数据的二个最低有效位和蓝色数据的三个最低有效位。通过游程长度编码处理在.pic图像中编码.tga图像中的完全透明的部分。利用8位的透明性信息来维持倾斜(feathered edge)薄边或其他透明信息。
.pic文件140包括可以是三种不同类型的数据的分组。分组标识符将每一分组标识为具有这三种不同类型之一的图像数据。包括图像的完全透明部分的第一类型被编码出来并且具有零字节。包括图像的主要的不透明颜色部分的第二类型被利用如上所述的16位来转换和编码。包括图像的其他部分透明的部分和/或在主要图像周围的倾斜薄边的第三类型利用如上所述的16位和附加的用于透明性的8位(总共24位用于包括透明信息的图像部分)来转换和编码。
在.pic文件140将在显示屏幕200上呈现时，通过游程长度编码的、从.tga文件120到.pic文件140的压缩允许高速解压缩。由于对于多个透明的连续像素可以跳过呈现处理，所以对游程长度编码的文件的呈现可能实际上快于对未压缩文件的呈现。当360-3D游戏启动时，不立即解压缩.pic文件140。当运行时引擎190在游戏期间检索用于显示的.pic文件140时，它解压缩图像并且几乎立即在运行过程中显示它们。如果对原始图形文件120使用了.tga之外的文件格式(如.jpg或.gif)，则这样的快速解压缩将是不可能的。
当在计算机屏幕上在创作工具130的仿真器920中显示.pic文件140时，发生另一转换处理。在.pic文件140中的图像为上述的16位格式，但是诸如基于Windows的计算机之类的典型台式机以24位格式(其中每一颜色使用8位)显示图像。因此，基于Windows的计算机不能直接读取.pic文件140。为了在计算机170上显示.pic文件140，进行下述转换其中针对.pic文件140中的每一像素中的每一颜色的最低有效位被填充零，以便对于每一颜色使用8位。也就是说，在像素的数据的红色部分中的5位被向左移三位，在像素的数据的绿色部分中的6位被向左移二位，在像素的数据的蓝色部分中的5位被向左移三位。然后，三个零被添加到5个红色位的右侧，两个零被添加到6个绿色位的右侧，三个零被添加到5个蓝色位的右侧。虽然在.pic文件140中的图像以24位格式显示在计算机170上，但是图像仅仅具有16位的质量，因此，开发者将在仿真器920中看到一图像，该图像具有与其在移动装置180上显示时所具有的相同的景象。
基于Windows的计算机170能够读取以这种方式转换的视频数据，并且在仿真器920中正确地显示所述数据。在仿真器920中的图像的质量将基本上等同于将出现在移动装置180的屏幕200上的质量，这是因为在每一情况下显示16位的可用数据。
在通常用于在计算机170的视频监视器上显示图像的双缓冲处理期间，可能发生这种转换。在双缓冲中，如本领域技术人员所公知的，当在监视器或其他显示装置上显示在第二存储缓冲器中存储的图像的同时，在第一存储缓冲器中构建图像。当下次更新监视器或显示器时，在第一存储缓冲器中存储的图像随后显示在监视器或显示装置上，同时在第二存储缓冲器中构建下一图像。以这种方式缓冲图像防止了当直接在监视器上构建图像时可能发生的闪烁效应。
在一个实施例中，在从第一缓冲器向第二缓冲器传送构建的图像期间，发生从16位色彩的.pic格式到24位色彩的格式的转换。也就是说，在第一缓冲器中构建在屏幕以外(off-screen)的16位彩色图像，所述图像被转换成24位的色彩格式，并且所述24位色彩的图像被传送到第二缓冲器。这保证了从基于移动装置的格式到基于计算机的格式的转换在显示图像之前的最后的可能时刻发生。该转换仅对基于.pic的图像而不是包含图像的.pic文件140进行。由于不需要将实际的.pic文件140转换成计算机170可读的格式，所以使用创作工具130的游戏开发者可以对在玩360-3D游戏期间将由移动装置180使用的相同.pic文件140进行工作。这保证了在创作工具130上创建的游戏将与它在仿真器920上呈现的几乎完全一样地出现在移动装置180的屏幕200上。
如上所述，除了已描述的游戏动作的类型之外，可以以多人模式来玩360-3D游戏。两个或多个玩家可以在不同的移动装置180上同时一起或彼此对抗地玩游戏。装置180一般将能够通过WiFi、蓝牙或其他无线通信技术彼此无线地通信。也可以使用有线通信。所有玩家可以看到基本相同的全景图220，但是，每一玩家能够看到并与该全景图220的不同部分交互。从第一玩家的视角看，看起来第二玩家处于与第一玩家相同的位置，但是第二玩家正在独立地旋转、瞄准和射击。
在所有类型的装置180上的所有运行时引擎190基本上相同，并且特定游戏的所有容器160基本上相同。因此，两个在不同移动装置180上玩相同游戏的真实玩家当在每一装置180上的引擎190开始读取和执行在每一装置180上初始的command.act文件时将看到相同的初始屏幕200。在一个实施例中，在每次读取帧时，每一玩家的击键被无线地发送到另一玩家的装置180，并且由在另一玩家的装置上的引擎190处理所述击键。两个引擎190同时开始读取和执行相同的command.act文件并且其后接收来自小键盘的相同输入。因此，两个引擎190将读取和执行相同的.act文件150。如果产生更多的.act150，则两个引擎190将同时产生相同的.act 150。以这种方式，由一个引擎190正在读取和执行的所有.act 150将由另一引擎190在相同帧上读取和执行。因此，在两个装置180上的两个游戏逐帧地同步。
两个游戏的同步意味着在由每一引擎190创建的全景图220中呈现的整个360°场景对于两个玩家来说基本上相同。但是，由于每一虚拟玩家210可以在全景图220中独立于另一虚拟玩家210旋转，因此，每一虚拟玩家210能够看到全景图220的不同部分并且每一真实玩家在其装置180的屏幕200上看到的显示可以是不同的。
每一真实玩家也可以独立于另一玩家而上下移动它的十字准线270。由于当虚拟玩家210旋转时十字准线270保持在左右的中央，并且由于每一虚拟玩家210可以独立于另一玩家旋转，所以可以独立于另一虚拟玩家的十字准线270而设置一个虚拟玩家的十字准线270的上下和左右位置。因此，每一虚拟玩家210可以射击与另一虚拟玩家210不同的人物260。在玩家都看着在360度全景图上的大约相同位置时，每一虚拟玩家的十字准线270将出现在另一玩家的屏幕200上。每一虚拟玩家的十字准线270可以例如通过不同的颜色来彼此区分。
当第一真实玩家敲击他的装置180上的键以进行射击时，该击键将被发送到第二真实玩家的装置180。在第二装置180上的引擎190将以与第一装置180上的引擎190相同的方式处理该击键。因此，将在两个装置180上的两个引擎190中同时启动可作为第一玩家的射击结果而启动的任意附加.act150。每一引擎190然后将继续与另一引擎190同步地处理附加.act 150。同时在相同帧启动.act 150、以相同速率读取和执行.act 150、以及使用来自两个装置180的击键作为对两个引擎190的输入足以保持引擎190同步。在一个优选实施例中，对于多人游戏，两个装置180不需要交换除了每一玩家按压的键入之外的任何数据来维持在两个引擎190之间的同步。在本实施例中，对于多人游戏，在装置180之间仅仅需要四个字节的数据来交换击键信息。
当在多人游戏中使用的所有装置180上的运行时引擎190同步地读取和执行相同的.act150时，由每一引擎190存储的数据中存在一些不同。在每一装置180上的引擎190可以使用可被称为‘伙伴模块(buddy module)’的模块来记住针对每一玩家的玩家专用数据。例如，当玩家杀死人物260时，伙伴模块登记哪一个玩家得分并且将该分数加到正确玩家的总分中。该伙伴模块也可以保证针对每一玩家的正确得分290呈现在显示屏幕200的合适位置中。而且，伙伴模块可以记住和正确地显示在不同玩家的显示屏200中呈现的不同雷达280。
作为在两个不同装置180上的引擎190可以如何执行相同的多人游戏的例子，第一玩家可以选择游戏的多人模式。当其装置180正与第一玩家的装置180通信的第二玩家选择了同一游戏的多人模式时，在两个玩家的装置180之一中的同步组件确保在每一装置180上的引擎190在大致相同的时刻读取针对该游戏的初始command.act文件的第一帧。其后，由于每一引擎190以相同速率读取在每一command.act文件中的后续帧，所以每一引擎190在相同时刻读取在command.act文件中的相同帧。
当第一真实玩家敲击他的装置180上的键以进行射击时，所述击键被发送到第二真实玩家的装置180。在第二装置180上的引擎190将以与在第一装置180上的引擎190相同的方式处理该击键。例如，如果第一玩家的射击杀死了第一人物260，则控制第一人物260的第一.act 150a将启动产生第二人物260的第二.act 150b。由于第一.act 150a正在两个玩家的装置180上的相同帧执行，并且由于两个装置180在大致相同的时刻从两个装置180的小键盘接收相同的输入，所以第一玩家的射击将使得在两个装置180上同时开始执行第二.act 150b。在两个装置180上的引擎190随后将逐帧地同时读取和执行第二.act 150b。任一真实玩家的附加击键可以使得附加.act 150在两个装置180上基本上同时开始执行。在整个游戏中，这些附加.act 150和它们启动的任何进一步的.act 150将在两个装置180上启动并且将被两个引擎190同步地读取和执行。
伙伴模块确保杀死了第一人物260归功给第一玩家。当每一玩家得分时，该伙伴模块将该分数加入到恰当的玩家的总分中。
如上所述，运行时引擎190一般嵌入在移动装置180的操作系统中。可替换地，引擎190可以通过诸如Java或Brew之类的软件的几层来和装置的操作系统通信。由于在不同平台下运行的、安装在装置180上的引擎190基本上相同，所以具有不同移动装置180的玩家可以参与多人游戏。
而且，使用移动装置180的玩家可能能够和使用计算机的玩家参与一个多人游戏。如上所述作为创作工具130的一部分的仿真器920一般用于创建360-3D游戏。但是，可以容易地将仿真器920修改成可以在计算机上执行360-3D游戏的单机组件。当这样的修改的仿真器920被安装在具有与移动装置180通信所需硬件(例如WiFi接口)的计算机上时，使用计算机的玩家和使用移动装置180的玩家可以加入多人游戏。
上述基于移动装置的16位色彩格式的图像被转换成基于Windows的24位色彩格式的图像的转换过程将允许计算机和移动装置180都使用基本上相同的.pic文件140和.act文件150，并且允许基于Windows的计算机和移动装置180一起加入多人游戏。
在不同类型的装置180上的显示屏幕200可能具有不同尺寸。例如，在PDA上的显示屏一般大于在移动电话上的显示屏。在一个实施例中，在360-3D游戏中出现的图像并不与在其上出现它们的显示屏200的尺寸成比例地进行缩放。也就是说，适合较小显示屏的场景不被放大以适合较大的显示屏，并且适合较大显示屏的场景不被缩小以适合较小显示屏。将根据像素以相同尺寸来显示特定图像，而不管它是显示在PDA上还是显示在移动电话上。为了补偿不同显示屏在尺寸上的差异，在较大显示屏上能看到在较小显示屏上看不到的场景的附加部分。
在图9中图解了这种情况，其中较小的移动电话尺寸的显示屏460被示出为叠加在较大的PDA尺寸的显示屏470上。在移动电话上玩游戏的玩家将仅看到在方框460中出现的场景部分。在PDA上玩同一游戏并且看着同一方向的玩家将看到在方框460中出现的场景部分并且还看到该场景的附加部分。即，使用PDA的玩家还将看到在该场景的上方的上部水平部分480、该场景的下方的下部水平部分485、该场景的左侧的垂直部分490和在该场景的右侧的垂直部分495。这些附加部分与在较小显示屏460中的场景无缝配合以创建该场景的较大视图。换句话说，较小显示屏460可以被看作是较大显示屏470的中间部分的剪切块(cutout)。
如果利用PDA的玩家和利用移动电话的玩家正在玩多人游戏并且两个玩家都使得他们的虚拟玩家210在相同方向上旋转，则两者都将看到较小区域460中的相同场景。例如，两个玩家将看到建筑物240和人物260，并且这些图像在两个显示屏上将是相同尺寸的。但是，利用PDA的玩家还将看到在上部水平部分480中的山230以及在下部水平部分485中的树250。这些图像对于使用移动电话的玩家是不可见的，这是因为在其显示屏460上不呈现上部水平部分480和下部水平部分485。
在一些实施例中，上部水平部分480和下部水平部分485仅仅是背景图像的扩展，并且在这些部分中不发生任何活动或动作。在其他实施例中，上部水平部分480和下部水平部分485是人物260可以移入和移出并且可以发生活动的有效区域。在一些实施例中，上部水平部分480是相同结构区域(例如天空)的扩展，并且下部水平部分485是相同结构区域(例如沙滩)的扩展。
在一些实施例中，雷达280和得分290出现在较小的显示区域460上，而不管该游戏是在具有较小显示屏460的装置180上还是在具有较大显示屏470的装置180上运行。在其他实施例中，雷达280和得分290在具有较小显示屏460的装置180上出现在较小显示区域460中，而在具有较大显示屏470的装置180上出现在上部水平部分480和下部水平部分485中。
当使用不同移动装置180的玩家加入一个多人游戏时，第一玩家可能具有第一装置180，所述第一装置180具有大于由第二玩家使用的第二装置180上的显示屏幕460的显示屏幕470。如果允许第一装置180的整个显示区域470保持完全有效，则第一玩家可具有优势。也就是说，第一玩家可能能够射击在对于第二玩家将是不可见的上部水平部分480和下部水平部分485中的人物260，并且因而得到第二玩家不能得到的分数。
为了消除这种差异，可以防止在第一装置180的屏幕470上的十字准线270进入在第一装置180的屏幕470的上部水平部分480和下部水平部分485。这些部分对于第一玩家仍将是可见的，并且第一玩家可能能够观察正在移入和移出这些部分的人物260，但第一玩家不能射击在这些部分中的人物260。以这种方式，可以使得两个玩家可获得的分数相同。将不需要防止十字准线270移到左垂直部分490和右垂直部分495中，这是因为通过向左或右旋转，这些区域对于第二玩家来说将是可见的。
在移动装置180的屏幕中出现的雷达280帮助在单人或多人游戏中的真实玩家确定可对虚拟玩家210造成损伤的人物260的位置。图10图解了雷达280。雷达280构建到引擎190中并且对于每一不同的360-3D游戏基本上相同地运转。雷达280可以采取包含一组等尺寸的部分940的水平条930的形式。条930的长度对应于全景图220的周长，并且在条930中的每一部分940对应于在全景图220中的成比例尺寸的部分。条930的中央对应于正好在虚拟玩家210前面的全景图220的部分。条930的最左端的部分940a和条930的最右端的部分940x可以看作彼此重叠，并且两者代表在虚拟玩家210之后180°的全景图的部分。因此，二维条930符号化了在全景图220中的三维的360°视图。
在雷达中的部分940可以改变颜色或类似地变成高亮以指示正在射击虚拟玩家210的人物260的位置。(正在有效射击的人物260将在下文中称为敌人，以将这样的人物260和当前不能对虚拟玩家210造成损伤的人物260区分开。)例如，接近条930的中央的高亮部分950a可以指示在虚拟玩家210前面的敌人。在条930的最右端的高亮部分950b可以指示在虚拟玩家210右侧、但是在屏幕200的当前可见区域之外的敌人。当虚拟玩家210在全景图220内旋转时，在条930中的高亮部分950移动以指示虚拟玩家210的位置相对于敌人的位置的变化。
在条930中的高亮部分950可以改变颜色或明暗以指示敌人正对虚拟玩家210造成的损伤的损伤量。在一个实施例中，假定敌人进行的每一射击都击中虚拟玩家210。当敌人射击虚拟人物210时，对虚拟玩家210的损伤累积，并且，如果损伤到达阈值，则虚拟玩家210死亡，并且游戏结束。例如，由敌人进行的每一射击可能导致对应于敌人位置的高亮部分950变得更暗或更红。真实玩家可以观察在雷达280中的高亮部分950的颜色或明暗来了解存在最大威胁的敌人的位置。
暗的高亮部分950例如可以表示一个敌人，该敌人已对虚拟玩家210造成比由亮的高亮部分950表示的敌人大的损伤量。优选地，在杀死其他敌人之前可以杀死已造成更大损量失的敌人，这是因为，已造成更大损失的敌人更接近于杀死虚拟玩家210。在一个实施例中，当虚拟玩家210杀死敌人时，表示敌人位置的高亮部分950失去其亮度以表示所杀死的敌人不再造成威胁，并且由该敌人对虚拟玩家210造成的损失量已被复位到零。因此，可以仅仅基于每个部分来累积损伤。
在一个实施例中，箭头960或指针可以定位在条930的末端上以向真实玩家提供对虚拟玩家210将转动的方向的指示，以便对付最大的威胁。例如，如果由在虚拟玩家的左侧的敌人造成的损失的总量大于由在虚拟玩家的右侧的敌人造成的损失的总量，则在条930的左侧的箭头960可变得高亮，开始闪烁，或给出虚拟玩家210应当关注左侧的一些其他指示。
雷达280的功能由运行时引擎190控制。当敌人射击虚拟玩家210时，每一射击的威力级别被报告给引擎190并且引擎190以敌人已对虚拟玩家210造成的新的总损伤级别来更新雷达280。该损伤级别反映在雷达280的高亮中。当虚拟玩家210杀死敌人时，引擎190从表示被杀死敌人的位置的、条930的部分940去除高亮。在多人游戏中，在每一玩家的引擎190中的伙伴模块控制每一玩家的雷达280的外观。
在上述的当前实施例中，可以被称为容器160的文件保存在游戏过程中可能使用的所有的.pic文件140和所有的.act文件150。容器160也保存用于指定将在开始新游戏时或到达游戏的新级别时将执行的.act文件150的命令文件。图11图解了典型的容器160。可以看到.act文件150是相对小的文件，这是因为它们仅包含指向.pic文件140的指针和每一个仅消耗存储器的几个字节的其他数据单元。由于.act文件150的每一帧使用存储器的32个字节，所以.act文件150的实际尺寸将依赖于在.act文件150中的帧的数目。可以预期典型的.act文件150将具有在大约1千字节以下的尺寸。由360-3D游戏使用的.act文件150的数目依赖于游戏的复杂度。
.pic文件140一般需要比.act文件150更多的存储器，并且.pic文件140的尺寸依赖于在其中包含的图像的复杂度。可以预期游程长度编码将分配给一般的.pic文件140大约10千字节的大小。由360-3D游戏使用的.pic文件140的数目依赖于将在游戏中使用的不同人物260的数目以及人物260将采取的不同姿势的数目。
应当注意需要的.pic文件140的数量不取决于根据相同.act文件150启动的不同活动的数目。例如，从相同的.act文件150启动的奔跑士兵的5个活动的每一个将从由公共.act文件150所引用的一组相同的.pic文件140来产生。不管根据单个.act 150启动多少不同的活动并因而可见到人物260的多少不同版本，仅仅需要一组.pic文件140来描述人物260的特定运动。与之相对，使用上述多边形和纹理方法，附加的人物260将可能需要分配给每一附加人物260的网格和纹理的附加存储器。每一.act 150仅仅使用针对描述人物260的.pic文件140的指针并且如所需的那样多的指针可以同时指向相同的.pic文件140。因此，可以在执行类似动作(诸如奔跑和射击)的游戏中的不同位置上提供多个相同人物260，而不需要消耗附加存储器或需要附加的存储容量。还应当注意，每一活动独立地运行，并且例如因为主活动经历诸如被射击之类的不同事件，每一活动可能展示与根据相同的.act 150启动的其他活动不同的行为。
命令文件980也仅消耗最小量的存储器，这是因为它们仅包含在游戏的每一级别的开始时运行的一组.act文件150。根据这些考虑，可以看出容器160不消耗在移动装置180上的大量存储空间。回想容器160包含360-3D游戏的完整说明和描述。可以预期典型的容器160将具有在大约两到三兆字节范围中的大小。这允许在没有为游戏而特别增强的标准移动装置180上运行360-3D游戏，这是因为，这样的装置180一般具有少于5兆字节的存储容量。
在一个实施例中，在容器160中的.pic文件140可以顺序地排列以使得360-3D游戏的开发更容易。如上所述，游戏开发者可以使用在创作工具130中的添加按钮790来增加帧编号并且同时指定将由下一帧调用的在当前目录中的下一.pic文件140。为了添加按钮790工作正常，.pic文件140必须以正确的顺序排列在容器160中。例如，如果将描述奔跑动作，则包括第一奔跑姿势的.pic文件140应当在容器160中的.pic文件140的目录中列在第一，包含第二奔跑姿势的.pic文件140应当列在第二，等等。
通过使用仿真器920在计算机上的玩360-3D游戏的能力表明了360-3D游戏的各种销售策略。例如，可以使得360-3D游戏的演示版本可在计算机上自由运行。其可以如在移动电话上那样在计算机监视器上显示，其中可以在该移动电话的显示屏上玩该游戏。例如可以以低费用或无费用下载这些演示。在计算机上玩游戏的限制版可以鼓励游戏玩家购买在移动装置180上使用的完整版，或购买具有能玩360-3D游戏的引擎190的移动装置180。
上述系统可以在如本领域技术人员所公知的任何手持移动电子装置180上实现。在图12中图解了用于实现在此公开的一个或多个实施例的例证性移动手持系统180。移动手持机180包括处理器1210(其可被称为中央处理单元或CPU)，耦接到第一存储区域1220、第二存储区域1230、诸如小键盘的输入装置1240、和诸如显示屏幕200的输出装置。
处理器1210可以被实现为一个或多个CPU芯片并且可以执行从第一存储区域1220或第二存储区域1230存取的指令、代码、计算机程序、或脚本。第一存储区域1220可以是诸如闪存的非易失性存储器。容器160和其他移动手持机180数据将一般被安装在第一存储区域1220中。第二存储区域1230可以是固件或类似形式的存储器。运行时引擎190和该装置的操作系统一般将安装在第二存储区域1230中。
上述的创作工具130可在任何通用计算机上实现，该通用计算机具有足够的用于处理置于其上的必需工作负荷的处理能力、存储器资源、和网络吞吐能力。图13图解了一种典型的、通用计算机系统，其适于实现在此公开的一个或多个实施例。计算机系统1300包括处理器1332(可被称为中央处理单元或CPU)，其与包括辅助存储器1338、只读存储器(ROM)1336、随机存取存储器(RAM)1334的存储器、输入/输出(I/O)装置1340、和网络连接装置1312通信。
辅助存储器1338一般包括一个或多个盘驱动器或磁带驱动器，并且用作数据的非易失性存储器，以及如果RAM 1334不是足够大以保存所有工作数据，则用作溢出数据存储装置。可以使用辅助存储器1338来存储在程序被选择以用于执行时载入到RAM 1334中的程序。ROM 1336用于存储指令和或许在程序运行期间读取的数据。ROM 1336一般是具有相对于辅助存储器的大存储容量的小存储容量的非易失性存储器。RAM 1334用于存储易失性数据和或许是存储指令。对ROM 1336和RAM 1334的存取一般比对辅助存储器1338的存取要快。
I/O装置1340可以包括打印机、视频监视器、液晶显示器(LCD)、触摸屏显示器、键盘、小键盘、开关、刻度盘、鼠标、跟踪球、语音识别器、读卡器、纸带读取器、或其他已知输入装置。
网络连接装置1312可采取调制解调器、调制解调器集、以太网卡、通用串行总线(USB)接口卡、串行接口、令牌环卡、光纤分布式数据接口(FDDI)卡、无线局域网(WLAN)卡、诸如码分多址(CDMA)和/或全球移动通信系统(GSM)无线收发器卡的无线电收发器卡和其他已知网络装置的形式。这些网络连接装置1312可以使得处理器1332能够与因特网或一个或多个内部网通信。利用这样的网络连接，可以预期在执行上述方法步骤的过程中，处理器1332可以从网络接收信息或可以输出信息到网络。
可以例如以计算机数据基带信号或在载波中包含的信号的形式，从网络接收和向网络输出下述信息，该信息可以包括数据或将使用例如处理器1332来执行的指令。由网络连接装置1312产生的基带信号或包含在载波中的信号可以在电导体中或表面上、在同轴电缆中、在波导中、在例如光纤的光媒体中、或在空气或自由空间中传播。按照处理或产生信息、或发送或接收信息的需要，可以根据不同顺序来排列在基带信号或在载波中包含的信号中包含的信息。可以根据本领域技术人员已知的几种方法来产生基带信号、或在载波中包含的信号、或当前使用或以后开发的其他类型的信号(在此称为传输媒体)。
处理器1332执行其从硬盘、软盘、光盘(这些不同的基于盘的系统都可以被认为是辅助存储器1338)、ROM 1336、RAM 1334、或网络连接装置1312存取的指令、代码、计算机程序或脚本。
虽然已在本公开中提供了几个实施例，但是应当理解，所公开的系统和方法在不脱离本公开的精神或范围的情况下可以以许多其他特定形式来体现。本示例将被认为是描述性的，而不是限制性的，并且不想限于在此给出的细节，而是可以在所附权利要求及其等价内容的完全范围内进行修改。例如，可以在其他系统中组合和集成各种单元或组件，或可以省略或不实现某些特征。
而且，可以在不脱离本公开的范围的情况下，与其他系统、模块、技术或方法组合或集成在各个实施例中分开或单独描述的技术、系统、子系统和方法。被示出或描述为彼此直接耦接或通信的其他项可以通过某一接口或装置来耦接，以至于所述项可能不再被认为是彼此直接耦接，而是还可以彼此电、机械或其他方式地间接耦接和通信。本领域技术人员可确定修改、替代和更换的其他例子，并且可以在不脱离在此公开的精神和范围的情况下进行上述的修改、替代和更换。
权利要求
1.一种用于多个移动手持机上的多人游戏的方法，包括第一用户经由第一移动装置的小键盘输入多个输入以玩第一游戏；将所述第一用户在所述第一移动装置上的小键盘输入传送到第二移动装置；第二用户经由所述第二移动装置的小键盘输入多个输入以玩第二游戏，所述第一和第二游戏是在各自的移动装置上提供的基本上相同的游戏；以及将所述第二用户在所述第二移动装置上的小键盘输入传送到所述第一移动装置，所述第一游戏使用来自所述第二移动装置的所述小键盘输入并且所述第二游戏使用来自所述第一移动装置的所述小键盘输入，以使得能够在所述第一和第二游戏之间进行多人游戏。
2.如权利要求1所述的方法，其中实际上在所述第一和第二移动装置之间传送的、用于多人游戏的唯一数据是在所述第一和第二移动装置之间传送的小键盘输入。
3.如权利要求1所述的方法，其中实际上仅仅在所述第一和第二移动装置之间传送的小键盘输入被用于同步用于多人游戏的游戏。
4.如权利要求1所述的方法，其中在所述第一和第二移动装置之间的传送是经由无线连接的。
5.如权利要求1所述的方法，其中在所述第一和第二移动装置之间的传送是经由有线连接的。
6.如权利要求1所述的方法，其中所述第一和第二移动装置是从包括移动电话和个人数字助理(PDA)的多个装置中选择的。
7.如权利要求1所述的方法，其中被传送到所述第二移动装置的、来自所述第一移动装置的用户小键盘输入被进一步定义为大约3字节的数据，以及其中被传送到所述第一移动装置的、来自所述第二移动装置的用户小键盘输入被进一步定义为3字节的数据。
8.如权利要求1所述的方法，其中所述小键盘输入是包括向上键、向下键、向左键、向右键和中间键的5个键输入之一。
9.一种用于移动手持机的多人游戏，包括游戏组件，可在第一用户的第一移动手持机上操作以在该第一移动手持机上玩游戏，所述游戏组件提供与所述第一用户使用所述第一移动手持机进行的动作有关的第一玩家指示器，并且还提供与第二用户使用第二移动手持机进行的动作有关的第二玩家指示器；以及通信组件，可操作用于接收与来自在所述第二移动手持机上玩所述游戏的第二用户玩游戏的小键盘输入有关的数据，其中所述游戏组件可操作用于根据从所述第二移动手持机接收的小键盘输入来更新在所述第一移动手持机上的所述第二玩家指示器。
10.如权利要求9所述的多人游戏，其中所述游戏组件进一步可操作用于根据所述第二玩家指示器的最后已知位置来更新所述第二玩家指示器。
11.如权利要求9所述的多人游戏，其中所述第一和第二玩家指示器中的至少一个被进一步定义为目标组件、指针组件、十字准线、瞄准指示器和目标刻线之一。
12.如权利要求11所述的多人游戏，其中游戏进一步被定义为第一人称射击者游戏。
13.如权利要求9所述的多人游戏，其中所述游戏组件进一步可操作用于提供与由使用第三或更多移动手持机的第三或更多用户进行的动作有关的第三或更多玩家指示器，以及其中所述通信组件进一步可操作用于接收与由在所述第三或更多移动手持机上玩游戏的所述第三或更多用户玩游戏的小键盘输入有关的数据，其中所述游戏组件可操作用于根据从所述第三或更多移动手持机接收的小键盘输入来更新在第一移动手持机上的所述第三或更多玩家指示器。
14.如权利要求9所述的多人游戏，其中从所述第二移动手持机传送到所述第一移动手持机的小键盘输入被进一步定义为大约3字节的数据。
15.一种用于多人游戏的系统，包括在第一计算平台上的第一游戏；在第二计算平台上的第二游戏，所述第一和第二游戏基本上是相同的游戏；第一通信组件，可操作用于接收第二用户的、与在所述第二计算平台上玩所述第二游戏有关的游戏输入；以及第二通信组件，可操作用于接收第一用户的、与在所述第一计算平台上玩所述第一游戏有关的游戏输入，其中，所述第一游戏可使用来自所述第二计算平台的、第二用户的游戏输入来操作，并且所述第二游戏可使用来自所述第一计算平台的、第一用户的游戏输入来操作，以使得能够在所述第一和第二游戏之间进行多人游戏。
16.如权利要求15所述的系统，其中所述游戏输入被进一步定义为是从包括小键盘输入、键盘输入、鼠标输入和触摸屏输入的组中选择的。
17.如权利要求15所述的系统，其中所述第一和第二计算平台被进一步定义为移动电话、个人数字助理、个人计算机、便携式计算机和电视机顶盒系统之一。
18.如权利要求15所述的系统，其中所述第一游戏可进一步操作用于在所述第一计算平台上提供与由使用所述第一计算平台的第一用户进行的动作有关的第一玩家指示器，以及进一步提供与由使用所述第二计算平台的第二用户进行的动作有关的第二玩家指示器，所述第一通信组件可进一步操作用于接收与来自由所述第二用户在所述第二移动平台上玩游戏的、第二用户的游戏输入有关的数据，其中所述第一游戏可操作用于根据从所述第二计算平台接收的、所述第二用户的游戏输入而在所述第一计算平台上更新所述第二玩家指示器。
19.如权利要求18所述的系统，其中所述第一游戏可进一步操作用于根据所述第二玩家指示器的最后已知位置来更新所述第二玩家指示器。
20.如权利要求18所述的系统，其中所述第一和第二玩家指示器中的至少一个被进一步定义为目标组件、指针组件、十字准线、瞄准指示器和目标刻线之一。
21.如权利要求18所述的系统，其中第一和第二游戏进一步被定义为第一人称射击者游戏。
22.如权利要求15所述的系统，其中所述第一和第二计算平台被进一步定义为个人计算机和便携式计算机之一。
23.如权利要求15所述的系统，其中所述第一计算平台被定义为移动电话、个人数字助理、移动游戏平台之一，而所述第二计算平台被进一步定义为个人计算机和便携式计算机之一。
24.如权利要求15所述的系统，其中所述第一计算平台被定义为移动电话和个人数字助理之一，而所述第二计算平台被定义为移动电话和个人数字助理之一，并且其中所述第一和第二用户的游戏输入被进一步定义为包括向上键、向下键、向左键、向右键和中间键的5个键输入之一。
25.如权利要求15所述的系统，其中所述第一和第二游戏被进一步定义为包括3维图形的第一人称射击者游戏。
26.如权利要求16所述的系统，其中实际上在所述第一和第二计算平台之间的、用于提示多人游戏的唯一通信是向所述第二计算平台的第一用户的游戏输入和向所述第一计算平台的第二用户的游戏输入。
27.如权利要求26所述的系统，其中在所述第一和第二计算平台之间的、与多人游戏有关的唯一通信是向所述第二计算平台的第一用户的游戏输入和向所述第一计算平台的第二用户的游戏输入。
全文摘要
提供一种用于在多个移动手持机上的多人游戏的方法。所述方法包括第一用户经由第一移动装置的小键盘输入多个输入以玩第一游戏，将所述第一用户在所述第一移动装置上的小键盘输入传送到第二移动装置，第二用户经由所述第二移动装置的小键盘输入多个输入以玩第二游戏，所述第一和第二游戏是在各自的移动装置上提供的基本上相同的游戏，以及将所述第二用户在所述第二移动装置上的小键盘输入传送到所述第一移动装置，所述第一游戏使用来自所述第二移动装置的所述小键盘输入并且所述第二游戏使用来自所述第一移动装置的所述小键盘输入，以使得能够在所述第一和第二游戏之间进行多人游戏。
文档编号A63F13/12GK101049539SQ200710091500
公开日2007年10月10日 申请日期2007年3月30日 优先权日2006年3月30日
发明者戴维·C·爱德华兹 申请人:三星电子株式会社