KR100876739B1 - Multiplayer Video Game System and Method - Google Patents

Abstract

A method for multiplayer gaming on mobile handsets is provided. The method includes a first user entering inputs via a keypad of a first mobile device to play a first game, communicating the first user's keypad inputs on the first mobile device to a second mobile device, a second user entering inputs via a keypad of the second mobile device to play a second game, the first and second games being substantially the same games provided on separate mobile devices, and communicating the second user's keypad inputs on the second mobile device to the first mobile device, the first game using the keypad inputs from the second mobile device and the second game using the keypad inputs from the first mobile device to enable multiplayer gaming between the first and second games.

Description

Multiplayer video game system and method {SYSTEM AND METHOD OF MULTIPLAYER VIDEO GAMING}

1 is a block diagram of a system for game development and execution in accordance with one embodiment of the present invention.

2 is a perspective view of one panorama displayed in a game scene according to one embodiment of the invention.

3 illustrates a video screen displaying scenes in a game in accordance with one embodiment of the present invention.

4 illustrates layering that appears in a scene of a game in accordance with one embodiment of the present invention.

FIG. 5 illustrates runtime engine processing files used for a game in accordance with one embodiment of the present invention. FIG.

6A-6E illustrate an authoring tool used to create a game in accordance with one embodiment of the present invention.

7 shows a prior art for registering successful shots.

8 illustrates a technique for registering successful shots in accordance with an embodiment of the present invention.

9 illustrates an image display on a screen of different sizes according to an embodiment of the present invention.

10 illustrates a radar used in a game according to an embodiment of the present invention.

11 illustrates a container of files used for a game according to an embodiment of the present invention.

12 is a block diagram of a mobile device that may be implemented in some various embodiments of the present invention.

13 is a block diagram of a computer system that may be implemented in some various embodiments of the invention.

The present application, at least in accordance with the provisions of section 119 (e) of the United States Patent Act, provides the inventors with Mr. David. United States of America, filed June 28, 2005, by David C. Edwards, "PUGS Game Engine for 3-D Gaming on Handsets," for playing 3D games on mobile devices. Provisional Application No. 60 / 694,785, US Provisional Application No. 60 / 694,496, filed June 28, 2005, entitled "PIC Format for 3-D Gaming," and "3D." Claims interest in the priority of U.S. Provisional Application No. 50 / 694,569, filed June 28, 2005, entitled "TGA Format for 3-D Gaming," all contents of the above applications Is included in this specification in connection with various purposes. The present application is filed by the inventor (David C. Edwards) on the same date as the present application, and pending US patent "Video Gaming System and Method" (patent attorney Docket No. 2005.06.011.WTO , 4133-00600), US Patent "Tool for Video Gaming System and Method" (Attorney Docket No. 2005.06.012.WTO, 4133-00700), US Patent "Graphic Imaging System and Method (Graphics Images System and Method) (patent attorney Docket No. 2005.06.013.WTO, 4133-00800), and US patent "Mobile Handset Video Game System and Method" (attorney Docket No.) 2005.09.001.WTO, 4133-01100, the entire contents of which are hereby incorporated by reference for various purposes.

The present invention relates to video game systems and methods for mobile devices and computers. More particularly, the present invention relates to a multiplayer video game method and system that enables a plurality of users to play a game through a plurality of mobile devices.

Mobile phones, personal digital assistants (PDAs) and similar portable mobile electronic devices sometimes provide additional functionality, such as the ability to play video games. Such games for mobile devices are becoming more complex with realistic graphics, complex game execution and other improvements. Currently, the devices themselves are also becoming more sophisticated with larger memory capacities, faster processors, graphics accelerators and other upgrades. As a result, some games can only run on expensive, very sophisticated devices. The development of such games is complicated and requires graphic artists and highly skilled programmers. It's not unreasonable to spend more than $ 1 million per game on video games.

SUMMARY OF THE INVENTION An object of the present invention is to provide a multi-player video game system and method for executing a game on mobile terminals having displays of different sizes, so that the same game can be simultaneously displayed between the mobile terminals. have.

According to an aspect of the present invention, there is provided a multiplayer game method, comprising: input signals for executing a first game by a first user through a keypad of a first mobile device; Communicating keypad input signals of a first user on the first mobile device to a second mobile device; Inputting, via a keypad of the second mobile device, input signals for executing a second game that is substantially identical to the first game provided on each mobile device by a second user; And communicating second user keypad input signals on the second mobile device to the first mobile device, wherein the first game is enabled to enable a multiplayer game between the first and second games. 2 uses keypad input from the mobile device and the second game uses keypad input from the first mobile device.

The multiplayer game system according to the present invention for achieving the above object is characterized in that the first user is operable on the first mobile terminal to play a game on the first mobile terminal, and uses the first mobile terminal. A game component that provides a first player indicator associated with an action by a first user and provides a second player indicator associated with an action by a second user using a second mobile terminal; The first mobile device operable to receive data related to keypad inputs from game play by the second user executing the game on a terminal, the first mobile device based on the keypad inputs received from the second mobile device; And a communication component operable to update the second player indicator on the tablet. The.

The multiplayer game system according to the present invention for achieving the above object includes a first game on a first computing platform and a second game on a second computing platform, wherein the first and second games are actually the same game. A first communication component operable to receive second user game inputs associated with executing the second game on the second computing platform, and executing the first game on the first computing platform; A second communication component operable to receive associated first user game inputs, wherein the first game can operate using the second user game inputs from the second computing platform, Operate using the first user game inputs from the first computing platform to enable a multiplayer game between first and second games. Characterized in that it can.

Although an implementation of one embodiment of the present invention is illustrated below as an example, it should be understood from the beginning that the present system may be implemented using any number of techniques known or present. This embodiment is in no way limited to the embodiments, drawings, and techniques illustrated below, including the configuration and implementation examples illustrated and described herein, but are within the scope of the appended claims and their equivalents. You can improve in.

The present invention proposes a multiplayer game method on mobile terminals.

According to an embodiment of the present invention, the method includes a first user who inputs through a keypad of a first mobile device to execute a first game. The method also includes communicating a keypad input of a first user on the first mobile device to a second mobile device. The method also includes a second user entering through a keypad of the second mobile device to execute a second game that is substantially identical to the first game provided on each mobile device.

On the other hand, the first game uses keypad input from the second mobile device and the second game uses keypad input from the first mobile device to enable a multiplayer game between the first and second games. It is characterized by.

According to another embodiment of the present invention, in a multiplayer game for a mobile terminal, a first user is operable on the first mobile terminal to execute a game on the first mobile terminal, and uses the first mobile terminal. A game component that provides a first player indicator associated with an action by the first user and provides a second player indicator associated with an action by a second user using a second mobile terminal; Operable to receive data related to keypad inputs from game play by the second user executing the game on a mobile terminal, the first movement based on the keypad inputs received from the second mobile device; A communication component operable to update the second player indicator on the device. This multi-player game that features that are provided.

According to another embodiment of the invention, in a multiplayer game system, the first game on a first computing platform, the second game on a second computing platform, the first and second games are actually the same game, A first communication component operable to receive second user game inputs associated with executing the second game on the second computing platform, and associated with executing the first game on the first computing platform A second communication component operable to receive first user game inputs, wherein the first game can operate using the second user game inputs from the second computing platform, and And using the first user game inputs from the first computing platform to enable a multiplayer game between second games. This multi-player game system wherein you can move is provided.

These features and advantages will be apparent from the following detailed description with reference to the accompanying drawings and claims.

A game format called 360-3D is disclosed. The 360-3D format allows games with high quality three-dimensional graphics and complex story lines to run on mobile devices with limited memory and processing power. For example, in one embodiment the mobile device may include a processor running at about 120 MHz, and the memory capacity for loading 360-3D game data in the mobile device is about 3 to 28 Mbytes. In general, a mobile terminal having a graphics accelerator may be required to obtain high quality video graphics. In some embodiments, the system may operate in a mobile terminal without a graphics accelerator. Also disclosed are systems and methods for developing 360-3D games. The system and method allows developers to easily create 360-3D games by specifying how to handle a series of pre-rendered images upon display on a mobile device. The game can be made without the use of programming code, eliminating the need for programming knowledge or experience and significantly reducing game development costs.

1 is a block diagram of the major components in one embodiment of a 360-3D game development and game execution system. Developers producing 360-3D games generally begin the game development process using a commercially available graphics program 110 of a standard specification for producing a series of three-dimensional images to be covered in the game. As will be described in detail below, the images are pre-rendered and stored as a series of graphic files 120 in 'taga' or '.tga' format.

An authoring tool 130 is then used to import the graphics files 120 and convert the '.tga' format into a format called '.pic' file 140. As will be described in detail below, the conversion of '.tga' files to '.pic' files 140 is accompanied by compression through a run length encoding process. The production tool 130 is then used to generate a series of files called '.act' or action files 150. Each '.act' file 150 described below includes a series of instructions describing how the images of the '.pic' files 140 are handled to produce a 360-3D game. After the '.pic' file 140 and the '.act' file 150 are generated, the files may be stored together in a single set of data files called a container 160.

The production tool 130, '.pic' file 140, '.act' file 150 and container 160 are generally represented on a single computer 170. While the graphics program 110 and graphics files 120 are shown outside the computer 170 of FIG. 1, in other embodiments, the graphics program 110 and graphics files 120 may be created using the production tool ( 130, a '.pic' file 140, a '.act' file 150, and a container 170 such as the container 160.

When a 360-3D game is installed on a mobile phone, PDA or similar device, the container 160 is copied from the computer 170 to the mobile device 180. Instead, the container may be stored in an intermediate location before being sent to the mobile device 180. For example, the container 160 may be used for downloading to the mobile device 180 on a website or stored on CD and other storage media for copying to the mobile device 180. Another technique in the art is to transfer the container 160 from the computer 170 to the mobile device 180.

The files in the container 160 may be in a format compatible with both the computer 170 and the mobile device 180, and no file change may be required as part of the transfer process. However, even if some changes are required for compatibility, the files are actually considered to be the same, regardless of whether the container 160 is present in the computer 170 or the mobile device 180 where the files are in the container 160. It will be mentioned that it exists.

In addition, a runtime engine 190 capable of reading a file from the container 160 is present in the mobile device 180. As will be described in detail below, the engine 190 reads commands in a '.act' file 160 regarding how images in the '.pic' file 140 are handled. The engine 190 then searches for appropriate '.pic' files 140, processes them as commands, and displays them on the display screen 200 of the mobile device 180.

In general, the container 160 is loaded into a non-volatile memory location of the mobile device 180, such as flash memory. Since the files in the container 160 are simple data files rather than executable files, viruses or coding bugs may not occur when the container 160 is loaded into the mobile device 180.

In a preferred embodiment the engine 190 is embedded in the operating system of the mobile device 180. The engine 190 may be slightly modified to be compatible with other devices and operating systems, but substantially the same engine 190 may be embedded on any mobile device 180 and any container 160 may be read. Typically, the same operating system calls are used to initialize a timer function that calls the engine 19 about 15 times per second, write to a memory location, trigger a display update, and idle the engine 190. The engine 19 is changed only to make it dormant. The engine 190 is only an executable part of a 360-3D game. Once the engine 190 has been tested and debugged for a particular mobile device 180 and operating system, no further testing or debugging is required to install on this type of device 180. When a new 360-3D game is installed on the mobile device 180, the gaming container 160 is simply loaded into the device's memory instead of or in addition to the existing other gaming container 160. The engine 190 then reads in a new container 160 to play the new game.

Before the production tool 130 creates a 360-3D game and the runtime engine 190 examines in detail how to play the game, the game occurs in the format of a 360-3D game and usually in a 360-3D game. It may be beneficial to look at the type of gaming action.

360-3D games belong to a genre known as first-person shooter games. That is, the player of the 360-3D game confronts the view of the virtual player existing in the scene displayed on the video screen 200 of the mobile device 180. The virtual player can generally move within the scene and take actions such as shooting towards characters or objects. The action is not limited to shooting, but may also be a form of interaction between the virtual player and the person in the game scene which is a technique known in the art. For example, the action may be selecting a person to perform some type of action. However, for convenience of reference, the interaction between the virtual player and the character is hereinafter referred to as shooting and / or firing a shot. The shooting may also include shooting various projectiles on a number of different types of targets. For example, it may be an army action game in which a player fires at the action figures of different armies such as soldiers, tanks, helicopters, and the like. As another example, it may be a game of shooting dinosaurs or underwater sharks or a game in the form of a shooting gallery. The game can also be a firefighter game in which the player fires water on the flames to evolve the flames of fire. Shooting and / or shooting may be spraying, pointing, designing and / or selecting. Examples of other types of games that can be made with the system are already presented in the art.

In one embodiment of a 360-3D game, the virtual player can remain stationary at a single point in a scene or freely rotate about the point. By rotating or rotating clockwise or counterclockwise from one location, the virtual player can see the virtual world 360 degrees from the center he or she is in. Since the background of the scene in which the virtual player is rotated is a panorama which constantly wraps, a situation in which the virtual player can be constantly rotated in the scene of the real world is created. Therefore, the player can rotate 360, 720, 1080 degrees or the like clockwise or counterclockwise.

The real player generally controls the action of the virtual player by pressing keys on the keypad of the mobile device 180. For example, the left or right cursor keys are used to cause the virtual player to rotate left or right. The 'Enter' key or other key can be used to fire. In other embodiments other means for providing other keys or user input may be used to perform these actions.

2 is an overhead perspective view overlooking the virtual player 210 and the circular foreground 220 in which it is located. Objects such as mountains 230 or other landscapes appear in the background while buildings and other objects, trees 250 and other natural objects, humans, animals or lifeless figures 260 are in the foreground. Shown in Objects in the background and foreground are properly proportioned to create a three-dimensional appearance. As the virtual player 210 rotates, different portions of the circular foreground 220 appear in the field of view.

3 illustrates one scene that a real player can see on the video display 200 when executing a 360-3D game. As shown, a portion of the circular foreground 220 is shown in plan view on the display 200. Mountains 230, buildings 240, trees 250, and figures 260 arranged in the foreground 220 appear on the display 200. The figures 260, vehicles and other moving objects may move from side to side with respect to the background from the perspective of the virtual player 210. (Hereinafter, any object that can move within the scene, regardless of whether it is a human, an animal, a vehicle, or some other type of moving object, is referred to as a character 260.) The characters 260 are also referred to as the virtual player 210. You can scale up and down to show the approach or withdrawal. Scaling may also be used to represent scenes where the stationary object is approaching or away from the virtual player 210.

The scene includes invisible layers indicating the depth of person 260 relative to the background and foreground. When moving left or right, the figures 260 move only in one of the layers. That is, person 260 may be on either floor as close as possible to the foreground or background or between the layers closest to the background from the layer closest to the foreground. This obscures when the upper layer person 260 passes in front of the person 260 in the lower layer while allowing the person 260 present in the different layers to move in front of or behind each other. When scaled down in size to create a forward or backward view, person 260 can also vary floors.

4 illustrates this concept of layering. The mountains 230 may appear in the farthest layer or background, called layer zero. The tree 250 may appear in layer 10 located in front of the layer 0, and the other tree 250 may appear in layer 20 located in front of the layer 10. Two buildings 240 may appear on floor 30 located in front of the floor 20. Person 260 may appear on floor 40 located in front of floor 30. While five layers are shown in FIG. 4, different numbers of layers may appear in other embodiments. When all the layers are displayed simultaneously and objects of the appropriate size are selected for the layers, a three dimensional view is created on the screen 200 as objects appear before and after other objects and occulting in relation to them.

Referring again to FIG. 3, a crosshair 270 (crosshair) appears to show where the virtual player 270 is targeting. In other embodiments, a targeting indicator such as a pointer, an aiming pointer, or a targeting reticle may be used instead of the cross cursor 270. Any target representation below is referred to as a cross cursor 270. The cross cursor 270 is located at the center from the left to the right on the screen 200. The effect of the actual player rotating the virtual player 210 left or right is that the images rotate in the scene but the cross cursor 270 is centered from left to right. In addition, the actual player may move the cross cursor 270 up and down by using the up and down cursor keys on the keypad of the mobile device 180 or through a similar input mechanism. As such, the real player may attempt to have the crosshair cursor 270 aim at the person 260 or another object in the scene. A suitable key on the keypad of the mobile device 180 or other appropriate input is provided to allow a real player to take action (eg, fire) at the center of the crosshair 270. If the cross cursor 270 is properly positioned on the person 260, the action causes a reaction of the person 260 (eg, injuries to the person 260).

The person 260 has the ability to take actions such as shooting toward the virtual player 210. In addition, the person 260 may move into or behind the structure or the landscape, for example, to move behind the structure higher than the main person 260 to prevent the virtual player 210 from shooting.

A graphic display called 'radar 280' appears on the screen 200 and includes characters 260 that threaten the virtual player 210, including any persons 260 located outside the currently visible scene. Point to where it is located. The radar 280 is also referred to as a threat indicator. The radar 280 will be described in detail below.

The screen 200 also displays a score 290 that indicates how many characters 260 the virtual player 270 killed and / or how many characters 260 the partner or competitor of the virtual player killed in the multiplayer game. , scores). Multi-player games are described in detail below. For example, other status information such as remaining storage, ammunition, and game time may be displayed on the screen 200.

The general concept of game execution for a 360-3D game is to kill all of the figures 260 before the figures 260 kill the virtual player 210 in the single person shooting game. By focusing again on shooting games, similar concepts can be applied to other types of games. The owner of a device 180 with a 360-3D game installed first uses the device 180 for a telephony or organizer function, and the second feature is game play for occasional transient moods. will use it. Thus, the 360-3D game allows the user to learn the rules and other features of the game quickly and intuitively without requiring much teaching or practice. A radar 280, a horizontally centered crosshair 270 whose vertical position is controlled by a specific input key, firing with a specific input key, and rotation of the virtual player 210 controlled by specific input keys; The same features make it possible for the user to quickly learn how to play the new 360-3D game. The game is also designed to have a minimum set-up and start-up time.

The virtual player 210 has a weapon capable of inflicting a character 260 at a specified level of harm. The level of damage that can be inflicted by a weapon is called the weapon's power. The amount of damage sustained by the person 260 is called damage. For example, a weapon having a power of 5 may inflict 5 points of damage to the person 260 when the virtual player 210 shoots the person 260 through the weapon. The person 260 may have a specified level of damage that can withstand until death or another action occurs on the person 260. For example, the person 260 may die after taking 20 points of damage. This character 260 is killed after being hit four times by a weapon with 5 power.

Similarly, the figures 260 may have weapons capable of inflicting a specified level of damage to the virtual player 210, and the virtual player 210 may have a certain level of damage that can be tolerated before dying. If the virtual player 210 kills all the figures 260 before the figures 260 kill themselves, they can usually win the game or reach a new level of game. Numerous variations on this general game concept are possible and are apparent in the art. For example, the concept of power and damage is already extended to non-combat games, such as firefighter games.

When the 360-3D game starts, various figures 260 performing various actions may appear at various positions in the scene. The manner in which a game developer uses the development tool 130 and what characters 260 appear, what are their features, and where and how they will act is described in detail below.

When the game starts, the virtual player 210 can turn around to set the position of the cross cursor 270 and start shooting in the manner described above. In addition, the person 260 may also start shooting toward the virtual player 210. In one embodiment, a monitoring routine may be used to determine when the virtual player 210 begins shooting early in the game, and the figures 260 may also begin shooting by the virtual player 210. Shooting may not be allowed until In this way, the virtual player 210 may have the opportunity to survive safely in the early stages of the game. It may also give new players the chance to learn the game.

The behavior of person 260 is specified or described by the game developer in one or more '.act' files 150, which will be described in detail below. As an example, one person 260 hides behind an object for a specified time. It may take place behind an object, shoot towards the virtual player 210 and then hide again. The person 260 may repeat this operation until being killed by the virtual player 210.

This action may be stored as a single '.act' file 150. As described above, the '.act' files 150 include only data and no executable code. The first portion of the '.act' file 150 is set for the characteristics of the person 260 such as the amount of damage that the person 260 can withstand before the person dies and the actions that can be taken if the person 260 dies. It may include data related to. The second portion of the '.act' file 150 may include a command for the person 260 to depict the appearance. The third portion of the '.act' file 150 may include a command depicting the person 260 shooting towards the virtual player 210. In addition, the fourth portion of the '.act' file 150 may include a command for the length of time that the person 260 should be hidden. The fifth portion of the '.act' file 150 may include instructions to return to the second portion to repeat a series of events. In some embodiments, all information about these actions may be stored in a single '.act' file 150 with separate portions, or in separate '.act' files 150.

When the virtual player 210 kills the person, the settings of the first portion of the '.act' file 150 are retrieved. These settings identify one or more other '.act' files 150 for requesting the death of person 260, and these other '.act' files 150 may include one or more other person 260. You can let it perform a series of different actions. The game developer can make the '.act' file 150 as complex as desired to depict the complex behavior of the person 260. In addition, the game developer may define a plurality of '.act' files 150 for initialization at the start of the game in order to create an initial scenario as complex as desired.

In addition, the '.act' file 150 may cause the engine 190 to launch or call as many other '.act' files 150 as desired at any time. When a specified action occurs in person 260, one '.act' file 150 may cause the engine 190 to generate other '.act' files 150. For example, when the first person 260 dies, the second person 260 may appear at one location in the scene, and the third person 260 may appear at another location. The behavior of the second and third persons 260 will be described by other '.act' files 150. These '.act' files 150 describe a series of complex actions for the second and third persons 260, and the engine when a specified action occurs in the second and third persons 260. Other '.act' files 150 generated by 190 may be checked.

The '.act' file 150 for the person may cause the engine 190 to call another '.act' file 150 in different situations. For example, if a person 260 is injured, the engine 190 may display the person (" act ") by a '.act' file 150 that depicts the person 260's behavior before the person 260 is injured. 260 calls another '.act' file 150 that depicts the lame behavior. If person 260 dies, the engine 190 calls another '.act' file depicting the person's dying behavior. When the person 260 moves to the designated place, the '.act' file 150 may change the amount of damage that the engine 190 may sustain or the weapon power of the person 260. Other ways in which the behavior of person 260 changes based on the game environment will be apparent in the art.

As such, the '.act' files 150 may allow the engine 190 to generate or call other '.act' files 150 through the progress of the game. The virtual player 210 interacts with the figures 260, the action of the figure 260 is controlled by its '.act' file 150, and the '.act' associated with the previous person 260. Based on the data of the file 150, a complex game plot may be generated and progressed through methods of introducing a new person 260. In general, when a certain action occurs in a certain person 260 or reaches a certain score 290, there are '.act' files 150 to end the game or enter a new game level.

As described above, when the engine 190 reads data included in the '.act' file 150, images of the '.pic' file 140 are displayed on the screen 200 or other types of actions. It generates a series of commands to make this happen. A series of commands can be called an action definition. The '.act' files 150 contain code that can contain or process only data, not instructions. More specifically, the '.act' files 150 may be executed by an instruction register for execution by a processing unit such as, for example, a central processor unit (CPU) or a digital signal processor (DSP). It does not contain machine instructions suitable for loading into registers. Here, the '.act' file 150 commands, instructs or initiates processing functionality, such that the engine 190 reads the '.act' file 150 and processes a command for executing a game. This means that the processing is performed by. The '.act' file 150 can be thought of as a series of frames, each frame having one command that can be performed when read by the runtime engine 190. In addition, one frame may have another type of instruction.

In one embodiment, each '.act' file 150 consists of 32 bytes of data. In other embodiments, the frames may have different sizes. One byte may include an indicator that describes or specifies an instruction that may be executed by the engine 190. The other bytes may include, for example, the name or location of the file that applies the command to a particular '.pic' file displayed as an image of the scene. In one embodiment, the file may be identified by an address offset into the container 160. In addition to the above instructions, other types of instructions may occupy other bytes. Game developers using the authoring tool 130, which will be described later, specify command indicators, file names, and other commands that each frame has, so that each frame can read the action that will occur when the frame is read by the runtime engine 190. Can be specified.

When the runtime engine 190 executes the '.act' file 150, it can be said that activity has started. An activity can also be called an action. An action or activity may be considered an example of a '.act' file 150. For example, three running soldiers can be created in the scene by creating a single '.act' file 150 that defines the running soldier's movements three times. Each running soldier has a unique and unique activity. One activity includes information identifying the '.act' file 150 that describes the activity's action, current frame, accumulated damage retained by the activity, current location in the scene, and other status information. . For example, the three activities that define the running soldier's status generated from a common '.act' file 150 may indicate how much damage is left in the individual activity, when each activity was created and thereby associated with the activity. The character may be distinguished based on how far the person moved from the initial generation position and the like. In one embodiment, the runtime engine 190 assigns execution tracks to each activity and may process multiple execution tracks during a time tick or clock tick.

The runtime engine 190 executes instructions in a number of '.act' files 150 during a small portion of time called a time slice, clock tick or tick. 5 illustrates a runtime engine 190 reading frames 300 from a set of four '.act' files 150. In other embodiments, a different number of '.act' files 150 may appear. The '.act' files 150 are shown in the same size, but are not limited thereto. Arrow 310 indicates the frame 300 currently being read by the engine 190. In this case, it can be seen that the engine 190 is reading a different frame for each '.act' file 150. When a plurality of '.act' files 150 are read during the same tick as the engine 190, a plurality of images may be simultaneously displayed on the display 200.

One of the commands that can appear in a frame is the '.pic' command. If the frame contains one '.pic' command, the engine 190 searches for the appropriate '.pic' file 140 and includes the '.pic' file 140 on the display 200. Display the image. Images in the '.pic' file 140 are described in detail below.

As an example of using the '.pic' command, the '.act' file 150 may be made to have the figure 260 running. For example, it can be seen that as many as 14 different poses depicting slightly different body postures need to be displayed sequentially to produce the actual running motion. Each pose is stored in a separate '.pic' file 140. One frame in the '.act' file 150 may include a '.pic' command requesting the search and display of the first running pose, and the next frame may request the search and display of the second running pose. May contain a '.pic' command. Another frame may specify that the previous 14 frames are to be repeated. The legs are actuated when the fourteen images are sequentially and repeatedly displayed on the video screen.

The depiction of smooth, realistic motion on the video screen requires that the video on the screen be updated 15 or more times per second. Movie film typically updates 24 screen images per second, and television typically updates 30 screen images per second. Thus, the runtime engine 19 executes instructions in the '.act' file 150 at a rate of at least 15 commands or sets of instructions per second, or at least one instruction rate about every 67 milliseconds. do. This 67 millisecond time period may be called one time slice, clock tick or tick. In most cases, there is a one-to-one relationship between ticks and frames. That is, one frame is read from each active '.act' file 150 every tick. However, in some cases, more than one frame can be read in a single tick, such as when a command option known as 'multi' exists in a frame. The 'multi' command option will be described in detail later. The above-mentioned frame display rate, tick processing rate and frame read rate of the '.act' file 150 are provided in this embodiment, but other speeds may be used in other embodiments.

It is necessary to distinguish two cases where the term 'frame' is used here. In common terms, a movie is displayed at a certain number of frames per second, which means the number of images displayed per second. In the present invention, it can be said that a 360-3D game is displayed at 15 frames per second. The term 'frame' may be referred to as a data packet or part of an '.act' file 150, which is referred to herein as a frame of a '.act' file.

In one embodiment, the following commands as well as the '.pic' command may occur in a frame of the '.act' file 150. -'launch', 'go to', 'if .act go to self', 'damage'. 'delete', 'delete self', 'reload', 'bonus', 'sound stop', 'shoot', 'say', and 'hear'. The 'launch' command causes the current '.act' file 150a to continue to be executed while the '.act' file 150b is executed. For example, multiple instances of a running soldier can be generated based on a single '.act' file describing a series of '.pic' commands needed to describe the running motion. Each case of the '.act' file 150 to be executed may be referred to as one activity. The term 'activity' may refer to reading a frame of the '.act' file 150 by the engine 190.

The 'launch' command creates an activity defined by the '.act' file 150 that matches the command. The 'launch' command may be used to cause one person 260 to create another person 260. For example, when the first person 260 dies, the second person 260 may be generated as an example of a support force sent to replace the casualty. This may be done by placing a 'launch' command in the frame of the '.act' file 150a related to the first person 260 to generate a '.act' file 150b related to the second person 260. It is desirable for the body of the first person 260 to be visible while the second person 260 is active. The 'launch' command causes the '.act' file 150a associated with the first person 260 to be active and the '.act' file 150b associated with the second person 260 to begin execution. Allow the body to be displayed. Other methods are known in the art that the 'launch' command can be used to control the action in a 360-3D game.

The 'go to' command executes the second activity defined by the second '.act' file 150b in the 'go to' command in the first activity defined by the first '.act' file 150a. Similar to the 'launch' command in that it starts. However, unlike the 'launch' command, the 'go to' command in the first activity causes the first activity to be stopped and deleted. In the above example, the 'go to' command may be used when the body is not desired to be visible after the first person 260 dies. If the 'go to' command is used to appear as the second person 260 after the first person 260 dies, the 'go to' command is defined by the '.act' file 150a and associated with the first person 260. The operation stops and disappears so that it is not displayed on the next tick.

In addition, the 'go to' command may provide a looping capability as described above in the example of running a person. In this case, the 'go to' command is used to cause the '.act' file 150 to return to itself. When the 'go to' command is used, it becomes possible to specify which frame of the '.act' file 150 is the target of the 'go to' command. For reasons described below, it is not preferable that the first frame of the '.act' file 150 is the target of the 'go to' command. Thus, if the 'go to' command is used to create a loop within the '.act' file 150, the 'go to' command generally causes execution of the '.act' file 150 to be executed in the '.act' file ( To a second frame of 150). This command stops execution of the '.act' file 150 at the point where the 'go to' command is located and returns to the second frame of the '.act' file 150. Therefore, the second frame is repeatedly executed through the last frame of the '.act' file 150. Other ways in which the 360-3D game developers describe the different behaviors of the characters 260 using the 'go to' command are clearly known in the art.

The 'if.act go to self' command is a powerful command that gives 360-3D game developers considerable power to describe the behavior of the person 260. With this command, the first '.act' file 150a determines whether the second '.act' file 150b is currently activated. When the second '.act' file 150b is activated, execution of the first '.act' file 150a moves to another frame or takes another action within the first '.act' file 150a. do. This means that the person 260 controlled by the first '.act' file 150a takes different actions or provides additional game functions depending on whether the second '.act' file 150b is executed. You can do that.

For example, if a specific object does not exist on the first floor, the person 260 controlled by the first '.act' file 150a may move from the left side to the right side of the screen 200. If the object exists in the first floor, it is preferable to allow the person 260 to move in the second floor. To implement this, the '.act' file 150a that controls the person 260 causes the person 260 to appear in the first and second layers of instructions that cause the person 260 to move and appear in the first floor. It may include a second set of instructions to cause it to move and appear. The 'act' file 150a may also include an 'if .act go to self' command that checks whether an object exists.

The person 260 starts moving on the first floor, and the '.act' file 150a controlling the person 260 periodically checks whether the 'if .act go to self' command exists. You can run If the object does not exist (ie, the '.act' file 150b controlling the object is not currently active), then the '.act' file 150a controlling the person 260 is the first instruction set. Run it and stay on the first floor. If the object exists (ie, the '.act' file 150b controlling the object is currently active), the '.act' file 150a controlling the person 260 is skipped to the second instruction set. The person 260 jumps to the second floor and appears. This may cause the person 260 to emerge from behind the subject. Numerous other ways in which the 'if. Act go to self' instruction may be used to construct the programming logic of a 360-3D game may be known in the art.

The 'damage' command is used to specify the amount of damage that can be maintained before the person 260 dies or other actions take place. In addition, the 'damage' command designates an action that occurs when the threshold damage of the person 260 is reached. For example, 20 levels of damage are given to the 'damage' command of the first '.act' file 150a and the person 260 controlled by the first '.act' file 150a has 20 damage. If it is associated with a second '.act' file 150b called 'die1' when maintaining, the 'die1' '.act' file 150b will begin execution. The 'die1' '.act' file 150b may depict the person 260 falling on the floor.

In general, the 'damage' command is located in the first frame of the '.act' file 150a. The name of the '.act' file 150b generated upon reaching the specified damage and threshold within this frame is valid while the '.act' file 150a is executed unless changed by a subsequent 'damage' command. do. Changing the '.act' file 150 executed upon reaching critical damage may cause the person 260 to die in different ways under different circumstances. For example, the person 260 may have a 'die1' '.act' file 150b that causes the person to fall down on the floor. If the person 260 subsequently moves to a higher position, the 'damage' command may cause the person 260 to die differently. A 'die2' '.act' file 150c may be specified by the 'damage' command to cause the person 260 to fall to the floor in other ways when dying.

The 'delete' command stops execution of all actions controlled by the '.act' file 150 having the specified name, and displays the screen 200 as the person 260 controlled by the dependent '.act' file 150. ) To disappear. For example, the person 260 running from left to right across the screen 200 may be controlled by the '.act' file 150 called 'run3'. Several instances of these running figures 260 or running actions may occur from the 'run3' '.act' file 150. The 'delete' command applied to the 'run3' file name causes all running people 260 or running actions from the 'run3' '.act' file 150 to stop running at the same time, running people 260 or running All cases of actions can be made to disappear at the same time.

In contrast, the 'delete self' command causes only the activity on which the 'delete self' command is executed to stop execution. For example, since the first activity is looping, 'delete self' in the 'run2' '.act' file 150 when processing the second activity generated by the 'run2' '.act' file 150. Command to avoid collision by the engine 190. However, the engine 190 may collide with the 'delete self' command when processing the second activity generated by the 'run2' '.act' file 150. The reason is that other events can be applied to the second action, such as the firing made by the virtual player 210, which causes the processing of the second action to exit the loop and process the 'delete self' command. In this case, the person 260 associated with the second activity generated by the 'run2' '.act' file 150 disappears, but the first activity generated by the 'run2' '.act' file 150 The associated person 260 remains visible.

The 'reload' command changes the amount of ammo available to the virtual player 210. The virtual player 210 usually starts a game with a fixed amount of ammunition. Each launch made by the virtual player 210 reduces the amount of ammunition by the power of the weapon used by the virtual player 210. For example, if the virtual player 210 starts a game with a weapon having a power of 5 and ammunition of 100 levels, the player may fire 20 rounds until the ammunition runs out. The 'reload' command may increase or decrease the ammunition level of the virtual player. For example, when the virtual player 210 wins at one level and moves to another level, the 'reload' command resets the virtual player's ammunition level to its maximum. Optionally, when the virtual player 210 fires at an innocent person rather than an enemy, the 'reload' command may deduct ammunition from the virtual player 210. The 'reload' command can be used to increase or decrease the stock of ammunition suitable for executing one level.

The 'bonus' command may cause the virtual player 210 to obtain additional points in some circumstances. Usually, the number of points received by the virtual player 210 is the same as the damage required to kill one person 260. That is, if 20 points of damage are required to kill the person 260, the virtual player 210 gets 20 points each time one person 260 is killed. By inserting the 'bonus' command into the frame of the 'act' file 150, the game developer can make the virtual player 210 score more points than the normal score obtained by killing the person 260. FIG. Bonus points can also be given when other events occur.

The 'sound' command may cause a sound to be generated in an arbitrary frame. The location and name of the file containing the sound may be specified in the frame including the 'sound' command. The loop value may be combined with the 'sound' command so that the sound is repeated a predetermined number of times. The 'sound stop' command can be used to stop the sound earlier than it normally does.

The 'shoot' command is used to give the other '.act' file 150 the ability to inflict damage on one '.act' file 150 currently being executed. As an example, the 'shoot' command may cause the person 260 to die due to the explosion of the object.

The 'say' command causes one '.act' file 150 to send a message to another '.act' file 150. The 'hear' command gives one '.act' file 150 the ability to hear a message from another '.act' file 150.

It is clearly known in the art that the above-described instructions and variations thereof can provide a 360-3D game developer the ability to describe complex game scenarios. Also, other names may be used for these commands, additional commands may be used additionally, sets of commands similar to these commands may be used, combinations of various described functions may be used, and other functions. It is well known in the art that they can be used without departing from the scope of the present invention.

In order to reduce the size of each frame 300 and the resulting '.act' file 150, each frame of the '.act' file 150 specifies which command is executed in that frame. And an indicator of 1 byte length. For example, indicator 1 can specify the '.pic' command, while indicator 2 and indicator 3 specify the 'launch' command and the 'go to' command, respectively. In other embodiments, other indicators may be used. The indicator also indicates the type of file associated with the command. That is, when the '.pic' command is displayed in one frame, the file pointer or file name of the frame refers to the '.pic' file 140 displayed. If the 'launch' command is displayed in the frame, the file pointer or file name of the frame refers to the generated '.act' file 150. These aspects have been adopted to reduce the size of the 360-3D game in terms of storage and memory specifications and to allow the game to run on mobile device 180 with standard hardware capabilities. Each frame is considered a record in the '.act' data file, where each field of the record contains representative data. For example, the first field relates to the aforementioned command with data in the field associated with the indicated command.

In addition to the above instructions, other instructions may appear in one frame. In one embodiment, the additional instructions include 'absolute x', 'absolute y', 'delta x', 'delta y', 'scale', 'layer', 'power' and 'multi'. 'absolute x' and 'absolute y' respectively specify the number of pixels in the horizontal and vertical position at which the object appears, such as an image defined by a '.pic' file specified or referenced by a frame, respectively. The 'absolute x' and 'absolute y' commands appear only in the first frame of the '.act' file 150 that specifies the initial position of the object. The frame in which the 'absolute x' and 'absolute y' commands appear does not normally return while the activity defined by the '.act' file 150 is executed. This is because returning to the frame causes the person 260 to move from the current position to the initial position. This can cause undesirably large and sudden jumps.

The 'delta x' and 'delta y' commands designate the number of pixels moving horizontally and vertically with respect to the position of the person 260 in the previous frame, respectively. In this example where a 10-frame running motion created a running figure of the person 260, the person 260 would run in place if no movement through the scene was specified. In order to create a motion image, the 'delta x' command of each frame may designate a distance that the person 260 moves horizontally with respect to the background.

The 'scale' command specifies the size associated with the person and is usually specified as a percentage of the standard size. Increasing the scale of the inter-frame person 260 can produce a picture approaching the virtual player 210, and decreasing the scale of the inter-frame person 260 can reduce the scale of the person 260. You can make a figure away from).

The 'layer' command designates a layer in which one object appears, as shown in FIG. 4. In general, a game developer designates a change in a floor of a character when the character 260 moves back and forth through a change in proportion.

The 'power' command designates the amount of power possessed by the weapon of the person 260 to designate the amount of damage inflicted when the person 260 fires at the virtual player 210. The game developer may set the power of the weapon to zero when the person 260 does not fire, but may set the power to a different value when firing. This can be done by indicating whether or not to fire using two different '.act' files 150 depicting the person 260. As the control of the depiction of the person 260 changes between the two '.act' files 150, the 'power' command may change the power between zero and a positive constant value. The 'power' command is described above with reference to a shooting oriented game, while the 'power' construct may be generalized in other game scenarios.

The 'multi' command option, which can be selected or deselected in each frame, allows two or more frames to be read or executed simultaneously. As mentioned above, one frame is typically read from each '.act' file 150 every one tick or every 67 milliseconds. When the 'multi' option is selected in a frame, the corresponding frame and the next frame in the same '.act' file 150 are read and processed for a single tick. This provides significant descriptive power and can be used to move the video as desired, for example when motion is displayed without flicker during one frame upon execution of the 'go to' command.

For example, in the example of the above-described running operation, 14 frames of the '.act' file 150 may include a '.pic' command for displaying different poses, and the fifteenth frame is referred to as the first frame. It can include a 'go to' command to go back. If the 'multi' option is not selected in any of the frames, each frame is read at a different tick. While the 'go to' command is executed at the fifteenth frame, no image is displayed, and 67 millisecond flicker is displayed while the first frame is read back and processed by the engine 190 for display. Appears on 200.

This flicker can be prevented by selecting the 'multi' command option in the 14th frame. The 'multi' command indicates that the 14th and 15th frames are read and processed during the same tick. That is, the '.pic' command for displaying the 14th running pose and the 'go to' command for returning the '.act' file 150 to the first frame are processed in the same tick. The first frame can then be executed for the next tick or 67 milliseconds time.

A single 'multi' instruction ensures that only the current frame and the immediately following frame are executed during the same tick. However, the 'multi' command option can be selected in as many consecutive frames as desired to have as many frames as desired in the same tick. For example, while the image of the person 260 is being displayed, the initial loop of the current '.act' file 150a is also returned, and another '.act' file 150b is generated and the person 260 is killed. If it is desired to change the required damage, multiple consecutive frames with 'multi' instructions can be used. The first frame is the '.pic' command and the 'multi' command, the second frame is the 'go to' command and the 'multi' command, the third frame is the 'launch' command and the 'multi' command, and the fourth The frame may have a 'damag' command. A 'multi' instruction in the first frame causes the second frame to be executed in the same tick. Like the first frame, the 'multi' instruction in the second frame causes the third frame to be executed at the same tick, and as in the second frame, the 'multi' instruction in the third frame has the fourth frame at the same tick. To be executed. Thus, all frames run in the same tick. Other ways in which the 'multi' option can be used to control the flow of a 360-3D game are known in the art.

The first frame of the '.act' file 150, referred to as frame 0, is preferably used to specify the settings that are activated until the settings are changed in the next frame of the '.act' file 150. For example, the 'damage' command may be placed in frame 0 to set the amount of damage required to kill the person 260. Frame 0 may also include 'absolute x', 'absolute y', 'layer', and 'scale' instructions that set the initial position and size of the person 260. As discussed above, frame 0 is defined as' going to frame 0 where the absolute x and / or absolute y positions are defined as frame 0, causing person 260 to suddenly jump from one position to another. It may not be listed as the target of the go to 'command.

Data constituting 32 bytes in the frame of the '.act' file 150 can be easily specified by the authoring tool 130. Illustrates one embodiment of a computer-implemented production tool 13. In general, the production tool 130 may effectively produce a 360-3D game. Although a particular embodiment of the production tool 130 is described below, the present invention may be applied to other optional GUI configurations and controls for constructing a 360-3D game executed on the engine 190.

The production tool 130 may include a graphical user interface 500 for specifying the above-described commands and other commands to be inserted into the frame, a file selection box 900 for confirming a file retrieved by the frame, and Emulator 920 for showing the effect of the selection made in GUI 500 and file selection box 900. The emulator 920 activates the display 200 appearing on the mobile device 180 when the 360-3D game is executed.

The GUI 500 includes buttons, text box check boxes, and other data entry tools that allow a 360-3D game developer to specify commands and other instructions contained in a frame. Data input as an example of the GUI 500 serves as one frame of the '.act' file 150. The game developer constructs a '.act' file 150 for each frame by inputting data as different examples of the GUI 500 for each frame.

To create a new '.act' file 150, the game developer usually clicks a button labeled 'New'. Then, the game developer inputs data for the first frame of the '.act' file 150, which is usually frame 0. The frame applied to the information input to the GUI 500 may be designated in the input box 610 labeled 'Frame'. After entering the data for the frame, the game developer changes the frame number in the frame text box 610 and enters the data for the next frame. This process continues until all the frames of the current '.act' file 150 have been created. Thereafter, the game developer clicks the 'Save' button 890 to save the '.act' file 150.

Drop down box 620 labeled 'Type' is used to specify the instruction to be executed in the frame. In one embodiment, as described above, the commands are 'pic', 'launch', 'go to', 'if .act go to self', 'damage', 'delete', 'delete self', 'reload' 'And' bonus' commands. However, other instructions may be used in other embodiments. The drop-down box 620 lists all the commands applicable to the frame, and the game developer can select a desired command by clicking an item in the list with a mouse.

The data entry tools appearing in the GUI 500 may be changed according to the command selected in the command drop down box 620 that makes the GUI 500 a context sensitive GUI. In the exemplary embodiment of the present invention, the 'damage' command is selected and represented by a text box 630 written as 'Damage'. The damage text box 630 allows the game developer to specify the damage to be applied to the current frame. If another command is selected in the command drop-down box 620, another text box may be displayed instead of the damage text box 630. For example, if the '.pic' command is selected, the game developer may display a text box to specify the power to be applied to the person 260 depicted by the designated '.pic' file 140. If the 'go to' command is selected, the game developer may display a text box specifying a frame number to be read and executed next time.

Text boxes 640 labeled 'Action' may allow game developers to specify '.act' files 150 to be executed by the current frame. In the above embodiment, if the 'damage' command is selected in the command drop-down box 620, the '.act' file 150 listed in the action text box 640 is the damage threshold that the current person 260 is assigned The '.act' file 150 to be executed when is reached. For example, the action text box 640 may enumerate a '.act' file 150 depicting the person 260 dying. When the 'launch' or 'go to' command is selected in the command dropdown box 620, '.act' file 150 listed in the action text box 640 is executed when the current frame reaches the current frame. act 'file 150b.

Data may be manually entered into the action text box 640. Instead, the file selection box 900 may be used to select the '.act' file 150 input into the action text box 640. That is, the game developer may browse through the file selection box 900 until the desired '.act' file 150 is found. In the file selection box 900, the selection button 910 is clicked to automatically insert the selected '.act' file 150 into the action text box 640.

The text boxes 650 labeled 'Path' designate a directory path where the '.act' files 150 listed in the action text box 640 can be found. Data may be manually entered in the path text boxes 650 or path data may be automatically entered based on the location of the '.act' file 150 selected by the game developer in the file selection box 900. do.

The action text boxes 640 and path text boxes 650 may only appear when arbitrary commands, such as a 'damage' command, are selected in the command drop down box 620. This behavior can be demonstrated by describing the GUI 500 as a context sensitive GUI. If other commands are selected, the action text boxes 640 and path text boxes 650 may be displayed at the position where. For example, if a '.pic' command is selected in the command drop-down box 620, the text boxes may contain action text boxes 640 and path text to which the '.pic' file 140 searched in the current frame belongs. It can be shown at the location of the boxes 650.

Text boxes 660 and 670, labeled 'Abs x' and 'Abs y', respectively, allow game developers to specify absolute horizontal and vertical positions where characters appear on the display 200, with a 360 degree background. You can retrieve the coordinates of an image. The absolute x and y positions may be entered manually or the file selection box 900 and emulator 920 may be used to set the absolute x and y positions. For example, a game developer may browse through the file selection box 900 until he finds the desired '.pic' file 140. When the game developer selects the '.pic' file 140, an image of a person in the '.pic' file 140 appears in the emulator 920. The absolute x and y coordinates of the image appear in Abs x and Abs y text boxes 660 and 670. The game developer may move the image in emulator 920 until the image is placed in the desired position. This position may then be set as the position where the person 260 first appears.

The Abs x and Abs y text boxes 660 and 670 may also be used to position objects that do not move, such as the satellite dish 925 shown in the emulator 920. Objects that do not move as described above may be destroyed by firing from the virtual player 210.

As mentioned above, the absolute x and y position of the image is usually specified only at frame 0 of the '.act' file 150. The delta x and delta y instructions then specify the number of pixels the current frame should move relative to the previous frame. The delta x and delta y values may be specified in text boxes 680 and 690, respectively. The delta x and delta y values may be manually input for each frame of the '.act' file 150. Instead, a shortcut may be used in the GUI 500 so that the delta x and delta y values are easily entered. Duplicator button 700 is located near the delta x and delta y text boxes 680 and 690. When the duplicate button 700 is selected, the values of the delta x or delta y text boxes 680 and 690 associated with the duplicate button 700 are automatically repeated for each frame in the '.act' file 150. In this manner, the person 260 may be made to move the same distance in the frames of all the 'act' files 150.

The text box 710 labeled 'Layer' allows the game developer to specify the layer in which the person appears in the current frame. The clone button 700 is connected with a layer text box 710 to specify that the game developer applies the same layer to all frames of the '.act' file 150.

The game developer may designate the size of the person 260 in the current frame using the text box 720 written as 'Scale'. scale is usually given as a percentage, which is the default value. Another duplicate button 700 may be associated with the scale text box 720 to allow the game developer to specify that the person 260 may have the same size in every frame of the '.act' file 150.

In one embodiment, the data in layer text box 710 and scale text box 720 are associated with each other such that proper scaling and scaling occurs automatically on the layer when the scale is adjusted. For example, if the game developer reduces the scale of the person 260 by a certain amount in each frame in order to create a movement toward the background, the layer to which the person 260 belongs is automatically changed by a proportional amount in each frame, thereby Person 260 moves through the layers to continuously approach the background.

The text box 730 labeled 'Repeat' provides a shortcut to read the current frame and execute iteratively for as many ticks as specified in the reapeat text box 730. This provides a simple way for a stationary image to appear temporarily on the display 200. For example, if a game developer wants to display a target for approximately 10 seconds (about 150 ticks), the '.pic' command can be placed in the command dropdown box 620, containing an image of the desired target. pic 'command may be placed in the action text box 640 and the value of the' .act 'file 150 may be placed in the repeat text box 730.

A check box 740 labeled 'Multi' may be used to specify whether the 'multi' command is applied to the current frame. If the multi box 740 is checked, the current and next frames are read and executed in the same tick as described above.

The button 750 labeled 'Locate View' returns the time displayed on the emulator 920 to the scene where the current '.act' file 150 starts. When a game developer uses the authoring tool 130 to operate on multiple frames of a '.act' file 150, the time presented in the emulator 920 will match the data of the GUI 500 for the current frame. Is changed. When the game developer presses the locate view button 750, the emulator 920 returns to the initial scene specified by the '.act' file 150.

An 'Insert' button 760 allows a new frame to be inserted before (or after, in other embodiments) a frame currently operating in the GUI 500. 'Delete' button 770 causes the current frame to be deleted. 'Chop' button 780 causes all frames of '.act' file 150 after the current frame to be removed.

A button 790 labeled 'Append' provides a shortcut for entering similar data for several consecutive and related frames into the GUI 500. In detail, the append button 790 causes the frame number to be incremented by one in the frame text box 610 and the next '.pic' file name is inserted into the action text box 640 in the folder of the '.pic' files 140. do. All other information in the GUI 500 is equal to being incremented from one frame to the next. This feature is useful, for example, when creating a moving motion used for each 'pic' file 140 that includes different motion movement steps.

In one example, the append button 790 can be used to easily create a '.act' file 150 depicting the person 260 running as described above. The '.pic' files 140 depicting each running pose are the first '.pic' file 140 containing the first running pose and the second '.pic' file 140 containing the second running pose. Can be arranged in a folder with). The game developer sets the command dropdown box 620 to the '.pic' command, sets the frame number of the frame text box 610 to 1, and sets the first '.pic' file in the action text box 640. The name of 140 can be placed. This may cause Frame 1 of the current '.act' file 150 to display an image of the first '.pic' file 140.

When the game developer presses the append button 790, the frame number of the frame text box 610 is changed to 2, and the name of the second '.pic' file 140 is placed in the action text box 640. The other information in the GUI 500 prior to pressing the append button is in the same state. This causes Frame 2 of the current '.act' file 150 to display an image of the second '.pic' file 140. The game developer can continue to press the append button 790 until all '.pic' files 140 containing running poses are described. Using the append button 790 may be more effective than manually changing the frame number and renaming the '.pic' file 140. This can provide an easy and quick way to add motion to a game even for people with no program experience.

A set of buttons 800, 810, 820, 830 can be used to advance the frames of the current '.act' file 150. The first button 800 applies the GUI 500 to the first frame of the current '.act' file 150. The previous frame button 810 applies the GUI 500 to the previous frame of the current '.act' file 150. The next frame button 820 applies the GUI 500 to the next frame of the current '.act' file 150. The last frame button 830 applies the GUI 500 to the last frame of the current '.act' file 150.

A button 840 labeled 'Stop' clears all images except the background image from the emulator 920. Buttons 850, 860 and 870, labeled 'Commmand1', 'Command2' and 'Command3', respectively, are used to set valid parameters when starting a new game or reaching a new level of the game. In this preferred embodiment, the 360-3D game has three run levels, which can only move to the second and third levels respectively when the player successfully completes the first and second levels. Other embodiments may have different levels of numbers. In one embodiment, the '.act' files 150 starting the first, second and third levels may be called command1.act, command2.act and command3.act, respectively. In one embodiment, the command.act files include only those commands that initiate a set of '.act' files 150 of actions that occur when the game's level begins. When the command1 button 850 is selected, the game developer applies the GUI 500 for inputting data associated with the command1.act file. In addition, when the command2 and command3 buttons 860 and 870 are selected, the game developer applies the GUI 500 for inputting data associated with the command2.act and command3.act files, respectively.

A series of buttons 880 can be used to specify the location and size of person 260 in the emulator. The left and right buttons 881 and 882 move the person 260 horizontally through the emulator 920, and the up and down buttons 883 and 884 move the person 260 vertically. Zoom in and zoom out buttons 885 and 886 increase or decrease the size of person 260. These buttons 880 can be used to quickly set the initial size and position of a person instead of Abs x text box 660, Abs y text box 670, and scale text box 720.

The authoring tool 130 provides a background.bmp file containing background parameters and character.tga files for the '.pic' file 140 format, the creation of the '.act' file 50 and other game technology operations. do. The production tool 130 is usually installed on a standard desktop computer 17, and data can be entered into the GUI 500 via a standard keyboard and mouse. The standard keyboard has the same or related keys as the buttons and data entry tools in the GUI 500. The keys on the standard keyboard are coded in several colors to aid memory for game developers. The append function is related to '.pic' and frame data, so the 'append' key can have two colors. Game developers familiar with the development tool 130 may find that this standard keyboard is faster than using a mouse to point or click on the control of the GUI 500.

The authoring tool 130 is typically installed on the computer 170 so that the emulator 920 will typically appear on the video monitor of the computer 170. Video formats used in computers are generally different from the formats used by mobile phones, such as mobile phones. The conversion process, which will be described in greater detail below, converts the image of the '.pic' file 140 into a format that can be read by the video display system of the computer 170. The conversion is the last step that occurs before the data is displayed on the emulator 920 and is involved in a variation of how color is encoded in the heterogeneous video display mode. This allows the 360-3D game developed through the production tool 130 to appear on the mobile device 180 which is substantially the same as that shown in the emulator 920.

The production tool 130 allows game developers with little or no coding skills to produce 360-3D games. Game developers can simply select the image that appears in the game and then use the authoring tool 130 to generate '.act' files 150 that are used to manipulate the desired image through the engine 190. Complex game plots may be generated using commands or instructions located in each frame of the '.act' files 150. A graphic artist with programming knowledge can produce a single 360-3D game in a relatively short time. This may be in contrast to a conventional video game development method that employs coding staff for programming work and graphic artist staff for art work. Making video games in the conventional way is quite time consuming and expensive.

The production tool 130 supports easy and fast testing and refinement of 360-3D games. In a typical game development environment involving computer software development in the form of programming language instructions, new versions of the game require compilation and linking, as well as executable images that are passed to the execution platform before testing game changes. In contrast, 360-3D game changes can be tested directly using the emulation capabilities of the production tool 130. In addition, 360-3D games can be fully tested using the authoring tool 130 and need not be tested on a mobile platform or mobile device.

When all the '.act' files 150 required for the 360-3D game are generated, the '.pic' file 140 and the '.act' file 150 for the game may be located in the container 160. The container 160 may be loaded into the mobile device 180. The runtime engine 190 installed on the mobile device 180 may read files from the container 160 and execute commands and instructions in '.act' files 150. For faster and more efficient execution, the runtime engine 19 may be embedded in the operating system of the mobile device 180. That is, in the preferred embodiment the runtime engine 190 is an extended form of the operating system rather than an external application that is not dependent on the operating system. In other embodiments, the engine 190 is located in other ways.

The operation of the runtime engine 190 is controlled or adjusted to some extent by the timing mechanism of the operating system. As shown in FIG. 5, the runtime engine 190 can read and execute frames of multiple '.act' files 150 during the same tick, which can be said to execute multiple frames 'simultaneously'. . Slightly different versions of engine 190 may be built for each operating system on which they are built but may be considered identical in practice.

In some embodiments the engine 190 may include a number of files or components, but the engine 190 is an executable file required to play a 360-3D game. Once the engine 190 is embedded in the operating system of the mobile device 180, different games can be installed on the mobile device by simply loading another container 160 containing only executable files and data files, not code. . Running multiple different games using a single executable file can simplify the certification process normally involved in developing applications for mobile device 180. Developers of mobile device 180 require that games and other applications installed on mobile device 180 be tested and / or guaranteed so that applications do not contain viruses, crashes, or other problems. In previous existing games, where each game contained executable code, these tests needed to be done on every game and platform on which the game was installed. Once the engine 190 is guaranteed for a particular platform, the container 160 only contains data as described above so that the container 160 can be loaded onto the platform without threats, crashes or other problems of the virus. .

Separating 360-3D games into a single executable engine for all games, mobile devices 180, and multiple containers 160 with data files that make each a unique game will simplify the game standard process for game developers. Can be. Game developers do not have to record different versions of the same game for different platforms. Any container 160 produced by the production tool 130 can be read by any mobile device 180 with the runtime engine 190 installed.

The runtime engine 190 is a relatively small file (typically about 100 kbytes or less) that requires only two graphics functions in the operating system. First, the engine 190 requires the operating system to locate a memory block including data for each pixel on the display screen 200 of the mobile device 180. Normally, the screens 200 use a memory buffer containing two bytes of data for each pixel. When the engine 190 learns the location of this buffer, it places a pixel with a predetermined byte and then instructs the operating system to send this data to the screen 200.

In addition, in order to read and execute the '.act' files 150 and perform graphic functions, the runtime engine 190 performs various other functions. The engine 190 accepts input from a keypad or other input source on the mobile device 180, processes it, sorts it by floor, and displays it in the appropriate back and forth order. The engine 190 names and maintains tracks of different versions of the figures 260 that are currently active, and registers and maintains tracks of successful launches of the figures 260 and vice versa in the virtual player 210. The engine 190 displays the screen 200, operates the radar 280, and processes the partner's input in a multiplayer game. (The multiplayer game is described in detail below.

The engine 190 registers a successful launch from the virtual player 210 to the person 260 via a method that provides greater accuracy than the previous launch registration method. As shown in FIG. 7, one object 410 on the screen 200 of the mobile device 180 is rendered as a part of a box 410 which is usually in a rectangular shape. A part of the box occupied by the object 410 is visible, and the background is visible. When any part of the box 420 is hit by firing, a hit is registered to the object 410 regardless of whether the object 410 occupied by a portion of the box 420 is hit. For example, even if no shot is made in the target 410 such as the person 260, the shot is dropped into the box 420, so the shot hitting the position X 430 is registered as a hit on the target 410. Also, if multiple targets 410 appear on screen 200, the code that controls the game needs to query all targets 410 to determine which box 420 was hit. This is inefficient and time consuming.

8 shows an example of how a strike is registered in a 360-3D game. In FIG. 8A, three objects occupy the video screen 440 of the mobile device 180 having 8 × 8 pixels 445. The square shaped object occupies (1,1), (1,2), (2,1) and (2,2) pixels. The triangular object occupies (4,3), (4,4), (4,5) and (5,4) pixels. The X-shaped object occupies (6,6), (6, 8), (7,7), (8,6) and (8,8) pixels. The other pixels 445 on the screen 440 are considered part of the background image.

In one embodiment, the memory buffer includes data associated with each pixel 445 in the actual screen 440. As shown in FIG. 8B, the memory buffer may be viewed as the silhouette screen 450, where each data location 455 is one pixel 445 on the actual screen 440. Corresponds to). That is, since the actual screen 440 has eight columns and eight rows of pixels 445, the silhouette screen 450 may be regarded as having a data position 455 of 8 ㅧ 8.

Each time one object occupies a set of pixels 445 on the actual screen 440, the identification information of the object is stored at a corresponding data location 455 of the silhouette screen 450. In one embodiment, the subject may be one of a number of examples of running soldiers generated from a common '.act' file 150. For example, when the object having a square shape is identified as object number 1, '1' represents (1,1), (1,2), (2,1) and (2,2) of the silhouette screen 450. ) Is stored in the data location. When the object having a triangular shape is identified as object number 2, '2' is located at (4,3), (4,4), (4,5) and (5,4) data positions of the silhouette screen 450. Stored. In addition, if the X-shaped object is identified as the object number 3, '3' is (6,6), (6,8), (7,7), (8,6) and (8,8) are stored in the data location. '0' may be disposed at all remaining data positions of the silhouette screen 450 to indicate the presence of a background image on the actual screen 440. When the objects move to the actual screen 440, the silhouette screen 450 is also changed in a corresponding method. Only objects existing on the actual screen 440 may be part of the silhouette screen 450.

When the launch is made on the actual screen 440, the runtime engine 190 records the pixel 445 of the actual screen 440 indicated by the crosshair cursor 270 at the moment of launch. The engine 190 then examines the data at data location 455 corresponding to the hit pixel 445 to determine which object occupies the pixel 445. If a background of '0' is present at the data position 455 of the silhouette screen 450 corresponding to the pixel 445 of the actual screen 440 hit, the shot is recorded as a false shot or other than a reduction in stockpile. No change is seen. If a non-zero number exists at the data location 455, the engine 190 records the launch as a strike on the object identified by the data at the data location 455.

In the above example, if the crosshair cursor 270 points to (4,4) pixels of the actual screen 440 at the moment the virtual player 210 fires, the shot is recorded at (4,4) pixels. The engine 190 reads data from the (4,4) data position of the silhouette screen 450, finds '2', and registers the shot with the hit of the target number '2', which is a triangular object. For example, if the (5,5) pixels of the actual screen 440 were correct, the firing would be because a nonzero number did not occupy the (5,5) data position corresponding to the (5,5) pixel. It will be registered as wrong.

Since the blow is determined by the actual size and shape of the object rather than the size and shape of the box occupied by the object, this method of registering the hit provides greater accuracy than existing methods. For example, the X-shaped object in FIG. 8 (a) is (6,6), (6,7), (6,8), (7,6), (7,7), (7, It can occupy a box bounded by 8), (8,6), (8,7) and (8,8) pixels. In previous methods, these pixels are part of the background image so this shot is not recorded as a strike. In addition, since the engine 19 may immediately determine the hit target with reference to the silhouette screen 450, the current method of registering the hit may be much faster than the previous methods. Therefore, it is not necessary to query all the activated objects to determine whether or not the pixel has been hit. In addition, by concatenating a number such as 1, 2, 3 in a pixel having an associated action, the engine 190 can quickly register the hit as an appropriate action. One action recalls that the engine 190 is currently an example of an '.act' file 150 in which several separate actions are generated from a common '.act' file 150.

In general, the runtime engine 190 is precompiled into the operating system of the mobile device 180 before the mobile device 180 is released from the manufacturer. Manufacturers of mobile devices 180 usually do not allow competitors to access the operating system of the devices 180. For this reason, a company that manufactures the runtime engine 190 embeds the engine 190 only in the operating system of its own device 180, not the competitor's operating system. Thus, the 360-3D game is usually executed in the above-described manner only on the devices 180 manufactured by the company that manufactures the engine. However, there are other ways in which a 360-3D game can be played on a competitor's device 180.

In one embodiment, the version of the runtime engine 190 may be embedded in a Java runtime environment, and the modified Java version may be installed on a competitor's device 180. Containers 160 including 'pic' files 140 and '.act' files 150 for 360-3D games are loaded on device 180 in the manner described above, and the containers 160 Can be read by the base engine 190. Since the engine 190 must communicate through several layers of software before communicating with the operating system, execution of the 360-3D game can be slowed under this arrangement. However, other advantages of the 360-3D game development system and method will be used. That is, once a modified Java version with a built-in runtime engine 190 for each of the various operating systems and / or devices 180 is guaranteed, then the containers 160 are loaded into the device 180 without the need for testing. do. In addition, the game developer may produce a 360-3D game by the above-described method without considering the type of the engine 190 that executes the game.

In another embodiment, Binary Runtime Environment for Wireless (Brew), manufactured by Qualcomm, may be used in a similar manner. That is, a version of the runtime engine 190 capable of communicating with Brew with the operating system of the device 180 on which Brew is installed may be manufactured. The 360-3D game executed in this manner may operate slower than the game executed by the engine 190 directly embedded in the operating system, but the advantages of the method and system for developing the 360-3D game remain. It is known in the art that 360-3D games can be executed in a mobile device 180 that does not have a runtime engine 190 embedded in such operating systems.

Java, Brew and similar products can also be used as a means to distribute 360-3D games. For example, the container file 160 may be provided in a Java wrapper so that the container 160 has an interface compatible with Java. The Java-wrapped container 160 may be installed on a device with a Java-embedded engine 190, and as described above, the original container 160 and the engine 190. Can be loaded and executed for Wrapping the engine 190 in Java allows a 360-3D game to be distributed over an existing distribution channel through which other Java-based games are distributed, such as a website from which the game can be downloaded. . For users browsing a web site, the 360-3D game will appear as a standard Java-based game that can be downloaded to an existing system.

As described above, the images displayed on the screen 200 are stored in files called '.pic' file 140. The images of the '.pic' files 140 are pre-rendered images of all poses that need to be displayed for the person 260 and other objects in a 360-3D game. As is known in the art, two general methods can be used to produce high quality graphics in video games, which are a pre-rendering method and a polygon and texture method. In the polygon and texture method, the object is depicted as a polygonal framework or mesh covered with a textured and colored surface. When a moving object is created on the video screen during the game, the algorithm calculates how the polygon mesh changes shape and then the textured surface is spread over the polygon mesh to create the desired behavior. . This process is called target image rendering and is fast by algorithms.

With pre-rendering, images of all possible poses that the subject selects during the game are generated and stored during development for the game. As the game runs and the generated images move, the appropriate images are retrieved from memory and displayed at the appropriate time and location to create the look of the desired action.

It can be seen that each method has advantages and disadvantages. In the polygon and texture method, images are generated faster than they are stored in memory, so a large amount of memory is not needed. However, the algorithms used in this method are sensitive to the use of a computer, and a great deal of processing power is needed to run the algorithm fast enough to produce the behavior in place. The polygon and texture methods also require graphics accelerators. Since the images are recalled from memory rather than being generated quickly, the processing power through pre-rendering need not be very large. However, more memory is required than when selecting a target to store the numerous pre-rendered images used to represent all possible poses.

In both cases, for existing games with high quality graphics running on a mobile device, the mobile devices usually needed to specifically design game devices with high speed processors, graphics accelerators and / or large memory capacities. Such devices would be incredibly expensive for consumers who are primarily interested in telephony or subscriber features rather than gaming features.

In one embodiment of the present systems and methods, a modified version of the pre-rendering method is used in which only the images necessary to depict a limited set of desired behaviors are pre-rendered. The game developer can select a small number of actions taken by the person during the game, and then pre-render only the images needed to realistically depict these actions. The selected images are compressed by standard data compression routines to reduce their size. . This pre-rendering and limited number of image compression produce small graphics files that are suitable for most mobile devices 180 and can provide high quality graphics. Usually the processing power and graphics accelerators required for the polygon and texture methods and the large memory capacity for pre-rendering numerous images are eliminated.

The small display 200 on the mobile device 180 makes this pre-rendering technique practically applicable. Since images appearing on the display 200 of the mobile device 180 are small in terms of the number of pixels used, a relatively small amount of memory is required to have high quality compressed images. This small, high quality number of images fits the memory capacity of most standard mobile devices 180. Smaller images displayed at larger sizes on larger screens, such as a typical computer monitor, consume significant storage capacity. Storing many of these high quality images requires larger memory capacities, but modern desktop computers tend to have sufficient storage capacity. As described below, 360-3D games may be displayed on a computer using an emulator that appears on the computer screen in the same size as the display 200 of the mobile device 180.

The process of creating '.pic' files 140 begins by a game developer usually creating, importing and editing an appropriate set of images using a standard graphics processing program 110 such as True Space, Maya, LightWave or 3DS Studio. The game developer stores the images, for example, as a series of graphics files 120 in a '.tga' format with one image per '.tga' file. The use of the '.tga' format provides high quality graphics because '.tga' files support transparency that allows the background image to be displayed through the transparent portion of the foreground image. '.Tga' files also support anti-aliasing, a feature that allows the edges of objects to be rendered smoothly. While these features provide realistic images, the disadvantage of the '.tga' format is that the '.tga' file is quite large. For example, a single screen consumes 7 Mbytes of memory.

In one embodiment, the background panorama is defined as a '.bmp' file. The background '.bmp' file does not contain opaque information because the definition of the background is opaque, ie it cannot be seen behind the background. The background foreground includes a continuous field of view that meets at the distal end to provide a 360 degree field of view. In one embodiment, the background foreground may include a display screen having 12 horizontal ranges. Also, the first screen displayed at the first end of the background foreground is duplicated to the second screen displayed at the second end of the background foreground to more easily scan a point of the background. For example, the position of an arbitrary background screen may be identified by x and y coordinates of the left and right sides. Because of the image wrap-around dividing point, it is prerequisite to read from the contact portion of the '.bmp' file to display a screen starting at the position of the screen overlapping the beginning of the foreground. It is easier than reading the first part from the end of the file and overwriting the second part from the beginning of the '.bmp' file. It is known in the art to use this method and to solve this problem.

The size of graphics files used in 360-3D games can be reduced in several ways. For example, a compression algorithm known as run length encoding is used to convert a '.tga' file into a '.pic' file 140. By specifying the number of consecutive pixels of a transparent image rather than each transparent pixel, the run length encoding process reduces the file size. Since most of the common images in a '.tga' file are transparent, this method can be used to significantly reduce the file size rather than specifying the transparency or opacity of individual pixels in the image. Through execution length encoding of the pre-rendered image, a '.tga' file may be converted into a '.pic' file 140 with a compression ratio of 10: 1. The conversion of the '.tga' file through the execution length encoding into the '.pic' file 140 occurs during the process of importing the '.tga' graphic file 120 into the production tool 130. After creating the desired '.tga' files 120 using the graphics program 110, the game developer selects a button, menu item, or similar tool in the authoring tool 130 for importing and conversion. ) Can be initialized.

In addition, the color of each pixel in the '.tga' file 120 is usually encoded with 24-bit color with 8-bit transparency for a total of 32 bits. Among them, 8 bits are used to indicate red contrast, green contrast, blue contrast and transparency levels. The '.tga' file 120 is converted to a proprietary '.pic' file 140 which is pre-rendered and in 16-bit color format, which is necessary since most mobile devices only have a 16-bit color display. Do. In the 16-bit '.pic' file 140 data format, 5 bits are used for encoding color information by 8 bits per pixel, with 5 bits being used for red contrast, 6 bits for green contrast, and 5 bits for blue contrast. Can be reduced.

The 8R-8G-8B data by converting each 8-bit red, green, and blue format (8R-8G-8B) to 5-bit red, 6-bit green, and 5-bit blue format (5R-6G-5B). You can truncate unimportant bits in. That is, the least significant three bits of red, two bits of green and three bits of blue data are erased pixel by pixel. The completely transparent portions of the '.tga' image are encoded into the '.pic' image through the run length encoding process. Feathered edges or other transparency information is maintained using 8-bit transparency information.

The '.pic' file 140 includes three separate data packets. Having image data in one of these three separate forms, a packet identifier identifies each packet. The first form, which completely includes the transparent portion of the image, is encoded to have zero bits. The second form comprising the opaque color portion of the image is converted as described above and encoded using 16 bits. The third form, which includes the edges around the main image and / or partially transparent portions of the image, is changed as described above and encoded using 16 bits. In addition, a total of 24 bits for the image containing transparency information are added up by adding 8 separate bits for transparency.

When the '.tga' file 120 is compressed into a '.pic' file 140 through execution length encoding, fast decompression occurs when the '.pic' file 140 is rendered on the display screen 200. (uncompression) is possible. Since the rendering process can be skipped over a large number of transparent pixels, rendering of the run-length coded file can be done substantially faster than rendering the decompressed file. The '.pic' files 140 are not decompressed as soon as the 360-3D game starts. As runtime engine 190 searches for '.pic' files 140 for display during the game, it decompresses the images and displays them at about the same time. If a file format other than '.tga' (.jpg or .gif) was used for the original graphics file 120, such fast decompression is not possible.

Another conversion process occurs when the '.pic' files 140 are displayed on the computer screen in part of the emulator 920 of the authoring tool 130. The images of the '.pic' file 140 are in 16-bit format as described above, but a typical desktop computer such as a Windows-based computer displays an image in 24-bit format where 8 bits are used for each color. Therefore, a Windows-based computer cannot read the '.pic' files 140 directly. To display the '.pic' files 140 on the computer 170, the least significant bits for each color at each pixel of the '.pic' are padded with zeros and 8 bits are used for each color. . That is, for one pixel, 5 bits in the red portion of the data are shifted 3 bits to the left, 6 bits in the green portion are shifted 2 bits to the left, and 5 bits in the blue portion are shifted 3 bits to the left. . Then, three zeros are added to the right of the five red bits, two zeros are added to the right of the six green bits, and three zeros are added to the right of the five blue bits. Although the images of the '.pic' file 140 are displayed on the computer 170 in a 24-bit format, the images have only 16 bits of quality so that the game developer has a display when displaying on the mobile device 180. The same appearance can be seen in the image of the emulator 920.

The window-based computer 170 reads the video data converted in this manner and displays the data on the emulator 920 as appropriate. Since 16 bits of unusable data are displayed in each case, the quality of the image in the emulator will be substantially the same as the quality that appears on the screen 180 of the mobile device 180.

This conversion occurs during the double buffering process commonly used to display an image on the video monitor of the computer 170. As is well known in the art, in double buffering, an image is constructed in a first memory buffer while an image stored in a second memory buffer is displayed on a monitor or other display device. When the monitor or display device is next updated, the image stored in the first memory buffer is displayed on the monitor or display device, while the next image is configured in the second memory buffer. Buffering the image in this way prevents the flickering effect that can occur when the image is constructed directly on the monitor.

In one embodiment, the conversion from the 16-bit color '.pic' format to the 24-bit color '.pic' format occurs while transferring the configured image from the first buffer to the second buffer. That is, an off-screen 16-bit color image is configured in the first buffer, the image is converted into a 24-bit color format, and a 24-bit color image is transferred to the second buffer. This allows the conversion from mobile device based format to computer based format happening at the last moment before the image is displayed. The conversion is done only on the '.pic' based image, not the '.pic' file 140 containing the image. Since the actual '.pic' files 140 do not need to be converted into a format that can be read by the computer 170, a game developer using the authoring tool 130 may use a mobile device 180 while the 360-3D game is running. You can work with the same '.pic' files 140 used for. This allows the game created in the production tool 130 to appear on the screen 200 of the mobile device 180 almost exactly as it appears on the emulator 920.

As mentioned above, in addition to the types of game actions already described, 360-3D games may be executed in a multiplayer mode. Two or more players can play on the same mobile device 180 as the same side or the other side at the same time. The mobile devices 180 may communicate with each other, usually via WiFi, Bluetooth, or other wireless communication technology. In fact, the same foreground 220 may be visible to all players, but each player may see or interact with a different portion of the foreground 220. From the point of view of the first player, it may appear that the second player is in the same position as the first player but the second player is independently rotating, aiming and shooting.

All runtime engines 190 on all types of devices 180 are actually the same, and all containers 160 for a particular game are actually the same. Therefore, two real players playing the same game on different mobile devices 180 see the same initial screen 200 when the engine 190 of each device 180 executes the initial command '.act' file. In one embodiment, each player's keystrokes are transmitted wirelessly to another player's device 180 whenever the frame is read and processed by the engine 190 on the other player's device 180. do. Both engines 190 read and execute the same command.act file at the same moment and then receive the same input from the keypad. Thus the same '.act' file 150 is read and executed by both engines 190. After the 'act' files 150 are generated, the same '.act' files 150 are generated by both engines 190 simultaneously. As such, all '.act' files 150 that are read and executed by one engine 190 are read and executed in the same frame by the counterpart engine 190. Thus, two games on the two devices 180 are synchronized frame by frame.

Synchronization of the two games means that the entire 360 degree scene shown in the foreground 220 generated by each engine 190 is actually the same for both players. However, since each virtual player 210 rotates independently of the opponent virtual player in the foreground 220, each virtual player 210 can see a different portion of the foreground 220, and each real player can see each device ( The display seen on the screen 200 of 180 may vary.

Each real player can also independently move his or her cross cursor 270. The cross cursor 270 is positioned at the center of the left and right while the virtual player 210 is rotated, and each virtual player 210 can be rotated independently, so that the top and bottom and left and right of the cross cursor 270 of the virtual player are rotated. The positions may be set independently of the crosshairs 270 of the opponent virtual player. Accordingly, each virtual player 210 may shoot toward a person 260 different from the opponent virtual player 210. The cross cursor 270 of each virtual player is displayed on the opponent's screen 200 when both sides view the same position on the 360 degree foreground. The crosshairs 270 of each virtual player may be distinguished from each other by, for example, different colors.

When the first real player presses a key on his device 180 to fire, the keystroke is sent to the second real player's device 180. The engine 190 of the second device 180 processes the key input in the same manner as the engine 190 of the first device 180. Thus, separate '.act' files 150 generated as a result of the firing of the first player are simultaneously created in the engines 190 of both devices 180. Then, each engine 190 is synchronized with the counterpart engine 190 to process the '.act' files 150. Start the '.act' files 150 simultaneously in the same frame, read the '.act' files 150 at the same speed, and key input from both devices 180 as input to both engines 190. If used, synchronization of the engines 190 can be achieved sufficiently. In this preferred embodiment, no data need be exchanged by the two devices 180 in addition to the key each player presses to maintain synchronization between the two engines 190 for the multiplayer game. Also only 4 bytes of data need to communicate keying information with the devices 180 for the multiplayer game.

The runtime engines 190 on all devices 180 used in the multiplayer game are synchronized so that some changes in the data stored by each engine 190 may occur while the same '.act' files 150 are read and executed. It exists. The engine 190 on each device 180 may maintain a track of player-specific data for each player using a module called a 'buddy module'. For example, if a player kills a person 260, the buddy module registers which player records the score and adds it to the appropriate player's total score. In addition, the buddy module allows the appropriate score to be displayed for each player at an appropriate position on the display screen 200. In addition, the buddy module maintains and properly displays the tracks of the different radars 280 that appear on the display 200 of different players.

As an example where the engines 190 on two different devices 180 run the same multiplayer game, the first player may select a multiplayer mode of the game. If a second player in communication with the first player's device 180 selects a multiplayer mode of the same game, one of the players 180's device 180's synchronization component may be located in the initial commmand.act file of the game. The first frame is read simultaneously by the engine 190 on each device 180. Since each engine 190 then reads subsequent frames of each command.act file at the same rate, the same frames of the command.act file are read simultaneously by each engine 190.

When the first real player presses a key on his device 180 for firing, the keystroke is sent to the second real player's device 180. The engine 190 on the second device 180 processes the key input in the same way as the engine 190 on the first device 180. For example, when the firing of the first player kills the first person 260, the first '.act' file 150a controlling the first player 260 may control the second '.act' file that presents the second person 260. 150b may be generated. The first '.act' file 150a runs on the same frame on both players' devices 180, and both devices 180 receive the same input from their keypads almost simultaneously, thus firing the first player. Causes the second '.act' file 150b to run simultaneously on both devices 180. Then, the engines 190 on both devices 180 read and execute the second '.act' file 150b at the same time for each frame. Additional keystrokes by either real player cause additional '.act' files 150 to be executed on both devices 180 at the same time. These additional '.act' files 150 and subsequent '.act' files 150 they create are created on both devices 180 and synchronized by the game and read by both engines 190. Indented.

The buddy module allows a first player to score points for killing the first person 260. As each player scores, the buddy module adds the score to the total score of the appropriate player.

As noted above, the runtime engine 190 is usually built into the operating system of the mobile device 180. Instead, the engine 190 may communicate with the operating system of the device through several layers, such as Java or Brew. Since the engines 190 installed on the devices 180 operating under different platforms are actually the same, players with each mobile device 180 can participate in a multiplayer game.

In addition, a player having the mobile device 180 may participate in a multiplayer game with a player using a computer. The emulator 920 described above as part of the production tool 130 is commonly used for the production of 360-3D games. However, the emulator 920 may be modified to be a stand-alone component that executes a 360-3D game on a computer. If this modified emulator 920 is installed on a computer with the necessary hardware to communicate with the mobile device 180, such as a WiFi interface, then the player using the computer and the player with the mobile device 180 will be able to play the multiplayer game. I can participate.

The conversion process for converting a mobile device-based 16-bit color format image to a Windows-based 24-bit color format actually involves the same '.pic' file 140 and '.act' file 150 with a computer. Used by both mobile devices 180 and allowing a Windows-based computer to participate in the multiplayer game included in mobile device 180.

Display screens 200 on different types of devices 180 may have different sizes. For example, displays on PDAs are generally larger than displays on mobile phones. In one embodiment, images appearing in a 360-3D game are not scaled up or down in proportion to the size of the display 200 in which they appear. That is, a scene suitable for a small display is not enlarged to fit a large display, and a scene suitable for a large display is not reduced to fit a small display. Certain images are displayed at the same size in terms of pixels, whether or not they are displayed on a PDA or mobile phone. To compensate for the different sizes of the different displays, separate scene parts are shown on the large display, which is not visible on the small display.

This is illustrated in FIG. 9, where a small, mobile phone sized display 460 is superimposed on a large PDA sized display 470. The player playing the game on the mobile phone will see only a portion of the scene visible within the box 460. Players playing the same game on the PDA and looking in the same direction will see part of the scene visible within the box 460 and at the same time a separate scene part. That is, a player with a PDA also has an upper horizontal portion 480 at the top of the screen, a lower horizontal portion 485 at the bottom of the screen, a vertical portion 490 on the left side of the screen and a vertical portion 495 on the right side of the screen. You see. These separate portions are tailored to match the scene of the small display 460 to produce a larger field of view of the screen. In other words, the small display 460 may appear to cut out the center portion of the large screen 470.

If players with PDAs and mobile phones, respectively, are playing multiplayer games and have virtual players 210 facing in the same direction, both players will see the same scene in a small area 460. For example, both players are looking at building 240 and person 260 and these images will appear the same size on both displays. However, a player with a PDA will also see the mountain 230 of the upper horizontal portion 480 and the tree 250 of the lower horizontal portion 485. Since the upper and lower horizontal portions 480 and 485 do not appear on the display 460 of the player with the mobile phone, these images are not visible to the player with the mobile phone.

In some embodiments, the upper and lower horizontal portions 480 and 485 are simply extended portions of the background image, and no action or activity occurs in these portions. In other embodiments, the upper and lower horizontal portions 480 and 485 may be activated areas where characters can enter and exit and action may occur. In some other embodiments, the upper horizontal portion 480 may be an extension of a homogeneous range, such as the sky, and the lower horizontal portion 485 may be an extension of a homogeneous range, such as a desert. .

In some embodiments, the radar 280 and score 290 relate to whether the game is run on a device 180 with a small display 460 or a device 180 with a large display 470. Will appear in the small display area 460. In other embodiments, the radar 280 and score 290 may appear in a small display area 460 on a device 180 with a small display 460 and a device with a large display 470. It may appear in the upper and lower horizontal portions 480 and 485 on 180.

When players with each mobile device 180 join the multiplayer game, the first player displays a display screen 470 that is larger than the display screen 460 on the second mobile device 180 used by the second player. It may have a first device 180 provided. If the entire display area 470 of the first device 180 is active, the first player may have an advantage, ie, the upper and lower horizontal portions where the first player can see the second player. In the fields 480 and 485, the player can shoot toward the people 260, thereby obtaining points that are impossible for the second player.

To remove this imbalance, the cross cursor 270 on the screen 470 of the first device 180 is moved to the upper and lower horizontal portions 480 and 485 on the screen 470 of the first device 180. You can prevent entry. These parts continue to be visible to the first player, and the first player can observe the person 260 entering and exiting the parts, but cannot shoot towards the person 260 in these parts. As such, the points earned by the two players can be the same. It is not necessary to prevent the crosshairs 270 from moving to the left and right vertical portions 490 and 495 because these areas are visible to the second player by rotating left or right.

The radar 280 shown on the screen of the mobile device 180 helps the real player determine the positions of the characters 260 that damage the virtual player 210 in the single player or multiplayer game. 10 shows one radar 280. The radar 280 may be configured in the engine 190 and operate the same for each of the different 360-3D games. The radar 280 may have the form of a horizontal bar 930 that includes a series of sectors 940 of the same size. The length of the bar 930 corresponds to the environment of the foreground 220, and each sector 940 of the bar 930 corresponds to a sector proportionally divided in the foreground 220. The leftmost sector 940a and the rightmost sector 940x of the bar 930 may overlap each other, and both may represent a portion of the foreground 220 of 180 degrees behind the virtual player 210. Accordingly, the two-dimensional bar 930 represents a three-dimensional view in the foreground 220.

Sectors 940 in the radar 280 may appear bright to indicate the location of the person 260 that changes color or shoots towards the virtual player 210. (In order to distinguish one person 260 from another person 260 currently unable to do damage to the virtual player 210, the person who shoots actively 260 is called an enemy.) For example, the brightly visible sector 950a near the center of the bar 930 may indicate an enemy in front of the virtual player 210. The brightly visible sector 950b at the right edge of the bar 930 may indicate an enemy on the right side of the virtual player 210 but deviating from the currently visible area of the screen 200. As the virtual player 210 rotates in the foreground 220, the brightly visible sectors 950 move to inform the change occurring in the virtual player's position relative to the enemy's position.

The brightly visible sectors 950 of the bar 930 may vary in color or contrast to indicate the amount of damage the enemies do to the virtual player 210. In one embodiment, assume that every shot the enemy takes is hitting the virtual player 210. As the enemy fires toward the virtual player 210, the damage of the virtual player 210 accumulates, and when the damage reaches the threshold, the virtual player 210 dies and the game ends. Each shot the enemy shoots causes the brightly visible sector 950 corresponding to the enemy's position to appear darker or redder. The actual player can locate the most threatening enemies by observing the color or contrast of the brightly visible sectors 950 of the radar 280.

For example, if a brightly visible sector 950 becomes dark, it indicates that more damage is done to the virtual player 210 than the enemy indicated by the brightening sector 950. Since enemies that do greater damage are more likely to kill the virtual player 210, it is desirable to kill the enemies that do greater damage first before killing other enemies. In one embodiment, when the virtual player 210 kills the enemy, the dead enemy can no longer threaten and the brightly visible location indicating the enemy's position to indicate that the damage level inflicted on the virtual player 210 from the enemy has been reset to zero. Sector 950 loses its brightness. Therefore, the damage is accumulated only sector by sector.

In one embodiment, arrows 960 or pointers may be placed at the end of bar 930 to inform the actual player of the direction the virtual player is switching to deal with the most threatening enemy. For example, if the total amount of damage done by the enemies on the left side of the virtual player is greater than the total amount of damage done by the enemies on the right side, the left arrow 960 of the bar 930 flashes and becomes brighter or the virtual player 210. Can be given another indication that the camera focuses on the left side.

The function of the radar 280 is controlled by the runtime engine 190. When an enemy fires toward the virtual player 210, the power level of each shot is reported to the engine 190, and the engine 190 reports the new total damage level the enemy has inflicted on the virtual player 210 on the radar 280. Update to This damage level is reflected by the light on the radar 280. When the virtual player 210 kills the enemy, the engine 190 removes lightening from the sector 940 of the rod 930 indicating the location of the mapped enemy. In a multiplayer game, the buddy module in each player's engine controls the aspect of each player's radar 280.

As described above, in this embodiment, one file called the container 160 includes all '.pic' files 140 and '.act' files 150 used during the game. The container 160 also includes command files that specify '.act' files 150 that are executed when a new game starts or a new game level is reached. 11 shows a typical container 160. Since the '.act' files 150 only contain pointers to the '.pic' file 140 and other data elements that consume only a few bytes of memory, the '.act' files 150 are relatively small files. Since each frame of the '.act' file 150 uses 32 bytes of memory, the actual size of the '.act' file 150 may vary depending on the number of frames of the '.act' file 150. A typical '.act' file 150 may have a size of less than approximately 1 kbytes. The number of '.act' files 150 used in the 360-3D game depends on the complexity of the game.

The '.pic' file 140 usually requires a larger memory than the '.act' file 150 with the size of the '.pic' file 140 depending on the complexity of the images included. Execution length encoding provides a size of about 10 kbytes for a typical '.pic' file 140. The number of '.pic' files 140 used in the 360-3D game may vary depending on the number of figures 260 used in the game and the number of different poses adopted by the figures 260.

Note that the number of '.pic' files 140 required does not depend on the number of different activities generated based on the same '.act' file 150. For example, each of the five activities of a running soldier generated from the same '.act' file 150 is the same series of '.pic' files 140 referenced by a common '.act' file 150. Occurs from the Only one set of '.pic' files 140 are represented by the person 260, although how many activities are generated based on a single '.act' file 150 and how many different versions of the person 260 are visible. It is necessary to describe the specific movement of the. In contrast, using the polygon and texture methods described above, additional memory may be needed that is allocated to the meshes and textures of each separate personage 260. Each '.act' file 150 file uses a pointer to the '.pic' file 140 that depicts the person 260, and as many pointers as desired to the same '.pic' file 140 simultaneously. Can be used. Thus, a number of identical figures 260 may be provided at various locations in a game that performs similar actions such as running or shooting without using separate memory or requiring separate storage capacity. In addition, each activity is done independently, for example, as the main activity experiences different events, such as being shot, so it can show different actions of different activities generated based on the same '.act' file 150.

In addition, the command files 980 include only a set of '.act' files 150 generated at the beginning of each game level, thus consuming only a minimum amount of memory. In view of this, it can be seen that the container 160 does not consume much memory space on the mobile device 180. It should be appreciated that the container 160 includes the complete designation and description of the 360-3D game. Typical container 160 has a memory in the range of about 2 to 3 Mbytes. These devices 180 typically have a memory capacity of 5 Mbytes or less, which allows a 360-3D game to run on a standard mobile device 180 that is not particularly enhanced.

In one embodiment, the '.pic' files 140 in the container 160 may be arranged sequentially to facilitate the development of a 360-3D game. As described above, the game developer can increment the frame number using the append button 790 of the production tool 130, while at the same time the next '.pic' file 140 in the current directory is called by the next frame. Can be specified. In order to properly operate the append button 790, the '.pic' files 140 must be arranged in the proper order in the container 160. For example, if a running motion is depicted, the '.pic' file 140 containing the first running pose must first be listed in the directory of the '.pic' files 140 of the container 160, and the second running The '.pic' file 140 containing the poses should be listed second.

The ability to run 360-3D games on a computer through the emulator 920 provides various marketing strategies for 360-3D games. For example, a demo version of a 360-3D game can be made available for free on a computer. Like a mobile phone where a game is played on the display of the mobile phone, it can be displayed on a computer monitor. Such demo games can be downloaded, for example, at low or no cost. When running a limited version of a game on a computer, a mobile device with an engine 190 that allows the game player to purchase the full version used on the mobile device 180 or to play a 360-3D game. Can promote to buy.

The system described above may be implemented on any portable mobile electronic device 180 well known in the art. An example of a mobile terminal system 180 for implementing one or more embodiments disclosed herein is shown in FIG. 12. The mobile terminal 180 may be referred to as a processor 1210 (a central processing unit or a CPU) connected to the first storage area 1220, an input device 1240 such as a keypad, and an output device such as a display screen 200. It includes.

The processor 1210 may be implemented with one or more CPU chips, and execute instructions, code, computer program, or scripts to access from the first storage area 1220 or the second storage area 1230. The first storage area 1220 may be a non-volatile memory such as a flash memory. Container 160 and other mobile terminal 180 data is typically installed in the first storage area 1220. The second storage area 1230 may be a firmware or a similar type of memory. The runtime engine 190 and operating system for the device are typically installed in the second storage area 1230.

The fabrication tool 130 described above may be implemented in any general purpose computer having sufficient processing power, memory resources, and network throughput capability to allow the necessary workload to be located. 13 illustrates a general general purpose computer system for implementation in one or more embodiments disclosed herein. The computer system 1300 may also be referred to as a processor 1332 (a central processing unit or a CPU) in communication with memory devices including a second storage unit 1338, and a read memory device 1336 (ROM: Read Only). Memory), random access memory 1334 (RAM: Random Access Memory), input / output (I / O) device 1340 and network connection device 1312. The processor 1332 may be implemented in one or more CPU chips.

The second storage unit 1338 typically includes one or more disk drives or tape drives and is used for non-volatile storage of data, and overflow data when the RAM 1334 is not large enough to accommodate all work data. Used as a storage device. The second storage 1338 can be used to store such a program that is loaded into the RAM 1334 when the programs are selected for execution. The ROM 1336 is used to store perhaps data that is read during execution of instructions and programs. The ROM 1336 is a non-volatile memory having a small memory capacity for the larger memory capacity of the second storage. The RAM 1334 stores instructions using volatile data and speculative data. Access to the ROM 1336 and RAM 1334 is usually faster than the second storage 1338.

The I / O device 1340 may include a printer, a video monitor, a liquid crystal display (LCD), a touch screen display, a keyboard, a keypad, a switch dial, a mouse, a trackball, a voice recognizer, a card reader, a paper tape reader, Or other well known input devices.

The network connection device 1312 may include a modem, a modem bank, an Ethernet card, a universal serial bus (USB) interface card, a serial interface, a token ring card, a fiber distributed data interface (FDDI) card, a wireless local area network (WLAN) card, Wireless transceiver cards, such as Code Division Multiple Access (CDMA) and / or Global System for Mobile communications (GSM) wireless transceiver cards, and other well-known network devices. These network connection devices 1312 allow the processor 1332 to communicate with the Internet or one or more intranets. The processor 1332 may output information to the network while receiving the information from the network or performing the above-described method steps.

For example, such information, which may include data or instructions executed using processor 1332, may be transmitted and received over a network in the form of computer data baseband signals and signals carried on carrier waves. The signal carried on the carrier generated by the baseband signal and the network connection device 1312 may be transmitted to the surface of the conductor, optical media such as coaxial cable, waveguide, optical fiber, air or free space. The information included in the baseband signal and the signal on the carrier may be ordered according to a different order when processing or generating information or transmitting and receiving information. The baseband signal, the signal on the carrier or other types of signals currently used or later developed and called transmission media may be generated according to various methods known in the art.

The processor 1332 may include a hard disk, a floppy disk, an optical disk (all of the various disk-based systems may be recognized as the second storage unit 1338), a ROM 1336, a RAM 1334, or a network connection device ( Execute instructions, code, computer programs, or scripts that are accessed from

While some embodiments have been provided in the present application, it will be understood that the disclosed systems and methods may be embodied in various specific forms without departing from the spirit and scope of the invention. The embodiments are intended to illustrate but are not limited to such. The spirit of the present invention is not limited to the detailed description herein, but may be modified within the scope of the appended claims and their equivalents. For example, multiple elements or components may be coupled to or integrally formed with another system. In addition, certain elements may be omitted or may not be implemented.

In addition, the techniques, systems, subsystems, and methods mentioned in the above embodiments may be combined with other systems, modules, or methods without departing from the scope of the present invention. Terms such as 'directly coupled' or 'communicating with each other' are combined through some interface or device so that the terms are not considered 'directly coupled' but are 'indirectly coupled' and 'electrically and mechanically communicating with each other'. It's like that. Those skilled in the art to which the present invention pertains may modify or change in various forms within the principles and scope described in the claims herein.

As described above, the present invention provides a multi-player video game system and method for executing a game on mobile terminals having displays of different sizes so as to simultaneously display and play the same game between the mobile terminals. Can provide.

Claims (27)

delete delete delete delete delete delete In the multiplayer game method on mobile terminals, Input signals for executing the first game by the first user through a keypad of the first mobile device; Communicating keypad input signals of a first user on the first mobile device to a second mobile device; Inputting, via a keypad of the second mobile device, input signals for executing a second game that is substantially identical to the first game provided on each mobile device by a second user; And Communicating second user keypad input signals on the second mobile device to the first mobile device, The first game uses keypad input from the second mobile device and the second game uses keypad input from the first mobile device to enable a multiplayer game between the first and second games, During execution of a first game and a second game, the first mobile device displays a first player indicator that provides information related to the action by the first user, and the second mobile device displays the second user. Display a second player indicator that provides information related to the action The user keypad inputs from the first mobile device communicated to the second mobile device are defined as 3 bytes of data, and the user keypad inputs from the second mobile device communicated to the first mobile device are 3 bytes. Multiplayer game method, characterized in that defined by the data. delete In the multiplayer game system for a mobile terminal, Providing a first player indicator that is associated with an action by the first user using a first mobile terminal, the first user being operable on the first mobile terminal to play a game on the first mobile terminal; A game component for providing a second player indicator associated with an action by a second user using a second mobile terminal, Operable to receive data related to keypad inputs from game play by the second user executing the game on the second mobile terminal, and based on the keypad inputs received from the second mobile device. And a communication component operable to update the second player indicator on the first mobile device. The method of claim 9,  And wherein the game component is operable to update the second player indicator based on a last known position of the second player indicator. The method of claim 9, Wherein at least one of the first and second player indicators is defined as one of a target component, a pointer component, a crosshair, an aiming indicator and a target reticle. The method of claim 11, The game is a multiplayer game system, characterized in that it is defined as a single player shooting game. The method of claim 9, The game component may be operable to provide three or more player indicators related to an action by three or more users using three or more mobile terminals, and execute the game on the three or more mobile terminals. Operate to receive data related to keypad inputs from a game play by the three or more users, wherein the data on the first mobile terminal is based on the keypad inputs received from the three or more mobile terminals. And operable to update the three or more player indicators. The method of claim 9, And the keypad inputs from the second mobile terminal to the first mobile terminal are defined as 3 bytes of data. delete delete delete In a multiplayer game system, A first game on a first computing platform, Include a second game on a second computing platform, The first communication component is actually the same game and is operable to receive second user game inputs related to executing the second game on the second computing platform, and A second communication component operable to receive first user game inputs associated with executing the first game on the first computing platform, The first game may operate using the second user game inputs from the second computing platform, and the first game from the first computing platform to enable a multiplayer game between the first and second games. A first player indicator that is operable using user game inputs and that provides information related to the action by the first user on the first computing platform during execution of the first game and the second game; A second player indicator is provided on the second computing platform providing information related to the action by the second user, The first game may operate to provide the first player indicator on the first computing platform using the first computing platform, and to provide the second player indicator using the second computing platform. The first communication component is operable to receive data related to the second user game inputs from a game execution by a second user on the second mobile platform, and the first game. Is operable to update the second player indicator on the first computing platform based on the second user game inputs received from the second computing platform. The method of claim 18, And wherein the first game is operable to update the second player indicator based on a last known position of the second player indicator. The method of claim 18, Wherein at least one of the first and second player indicators is defined as any one of a target component, a pointer component, a crosshair, an aiming indicator and a target reticle. The method of claim 18, The first and second games are multiplayer game system, characterized in that it is defined as a single-player shooting game. delete delete In a multiplayer game system, A first game on a first computing platform, Include a second game on a second computing platform, The first communication component is actually the same game and is operable to receive second user game inputs related to executing the second game on the second computing platform, and A second communication component operable to receive first user game inputs associated with executing the first game on the first computing platform, The first game may operate using the second user game inputs from the second computing platform, and the first game from the first computing platform to enable a multiplayer game between the first and second games. A first player indicator that is operable using user game inputs and that provides information related to the action by the first user on the first computing platform during execution of the first game and the second game; A second player indicator is provided on the second computing platform providing information related to the action by the second user, The first computing platform is defined as one of a mobile phone and a personal digital assistant, and the second computing platform is defined as one of a mobile phone and a personal digital assistant. The first and second user game inputs A multiplayer game system, characterized by any one of five key inputs consisting of lower, left, right, and center keys. delete delete delete

Images