KR100895170B1 - Method and mobile terminal for playing video game thereof system - Google Patents

Abstract

The present invention relates to a system for playing a game on mobile terminals having displays of different sizes, in particular a background for stereoscopic games having a horizontal size and a vertical size, and a width less than the total horizontal dimension of the background on a small display. A configuration of the game that can be operated when the game is played on a small mobile terminal having the small display for displaying a first horizontal portion defined by and a first vertical portion defined below a height of the total vertical dimension of the background An element, wherein the component is greater than the height of the first vertical portion and the second horizontal portion and defined as greater than the width of the first horizontal portion and less than or equal to the width of the total horizontal dimension of the background in a large display; Build a large display that displays a second vertical portion defined below the height of the total vertical dimension. The comparison is characterized in that it can operate when the game progresses on a large mobile terminal.

Game, mobile device, display, video, image

Description

METHOD AND MOBILE TERMINAL FOR PLAYING VIDEO GAME THEREOF SYSTEM}

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 a panorama displayed in a game scene according to an embodiment of the present invention.

3 illustrates a video screen displaying scenes in a game according to an embodiment of the present invention.

4 is a diagram illustrating layering that appears in a scene of a game according to an embodiment of the present invention.

5 is a diagram illustrating runtime engine processing files used for a game according to an embodiment of the present invention.

6 illustrates an authoring tool used to create a game according to an embodiment of the present invention.

7A to 7D are detailed views of each part of FIG. 6 in detail.

8 shows a prior art for registering successful shots.

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

10 is a view showing an image display on the screen of different sizes according to an embodiment of the present invention.

FIG. 11 is a view showing a radar used in a game according to an embodiment of the present invention. FIG.

12 is a view showing a container of files used in a game according to an embodiment of the present invention.

13 is a block diagram of a mobile device operable with some of the various embodiments of the present invention.

14 is a block diagram of a computer system operable for some of various embodiments of the present invention.

<Explanation of symbols for the main parts of the drawings>

110: graphics program 120: graphics file

130: Authoring tool 140: '.pic' file

150: '.act' file 160: container

170: computer 180: mobile device

190: engine 200: display

1220: first storage 1230: second storage

1240 input unit 1312 network

1332: Processor 1338: Second Storage

The present invention relates to a method for executing a video game for a mobile device and a computer, a mobile terminal and a system thereof. More specifically, it relates to a mobile terminal video game method and system capable of playing high quality graphics games on a mobile device. In general, mobile phones, personal digital assistants (PDAs), and similar portable mobile electronic devices sometimes provide additional functionality, such as playing 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. Accordingly, the development of video games requires a significant cost of more than $ 1 million per game.

Disclosure of Invention An object of the present invention is to provide a method, a mobile terminal, and a system 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.

A system according to the present invention for achieving the above object is a system for playing a game on mobile terminals having displays of different sizes, comprising a three-dimensional game background having a horizontal size and a vertical size, and a small display The game can be played on a small mobile terminal having the small display for displaying a first horizontal portion defined below the width of the total horizontal dimension of the background and a first vertical portion defined below the height of the total vertical dimension of the background. A second horizontal portion and the first component defined in the game that can be operated when the component is larger than the width of the first horizontal portion in a large display and less than or equal to the width of the total horizontal dimension of the background; A second vertical portion defined as greater than the height of the vertical portion and less than or equal to the height of the total vertical dimension of the background; It is characterized in that which is operable when the game is conducted on a larger mobile handset having a larger display to display.

In addition, the game execution method according to the present invention for achieving the above object, in the method for executing the game on mobile terminals having displays of different sizes, the height and height for use as a background for a game display; Generating a graphic image having a width, displaying only a first portion of the background having a height and width less than the height and width of the graphic image when running the game on mobile devices with small displays; A second background of the background having a width less than the width of the graphic image, a height not greater than the height of the graphic image, and a height and width greater than the height and width of the first portion when the game is executed on mobile devices with a display; Displaying only a portion, and on mobile devices with small displays Limiting movement of a targeting indicator to an area around the height and width of the first portion of the background when the game is executed; and movement of the targeting indicator when the game is executed on mobile devices with large displays. Limiting to an area around the height of the first portion of the background.

Further, the display method according to the present invention for achieving the above object comprises the steps of providing a substantially identical game on the first and second mobile devices, the game is a video image on a small screen of the first mobile device; Displaying a first portion of the display; displaying the second portion of the video image on a small screen of the second mobile device, wherein the game is wider or higher than the width and height of the first portion; Allowing a first game player on the first mobile device a range of motion of the threat indicator around the height and width of the first portion of the video image, and wherein the game is transmitted to the second game player on the second mobile device. Allowing a range of operating heights of the target indicator that is about the same as that provided on the first mobile device with a small display. It characterized.

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. Can be improved in.

The present invention proposes a system for playing a game on mobile terminals with different sized displays. The system includes a background for a game with horizontal and vertical dimensions.

In this case, the system includes the small display for displaying on the small display a first horizontal portion defined below the width of the total horizontal dimension of the background and a first vertical portion defined below the height of the total vertical dimension of the background. A component of the game that can operate when the game is displayed on a small mobile terminal.

Further, according to an embodiment of the present invention, the background is larger than the height of the first horizontal portion and the second horizontal portion defined as greater than the width of the first horizontal portion and less than the width of the total horizontal dimension of the background. The component is operable when the game is displayed on a small mobile terminal with the small display to display a second vertical portion defined below the height of the total vertical dimension of.

Meanwhile, according to another embodiment of the present invention, a method for executing a game on mobile terminals having different sized displays is proposed. At this time, the graphic image for use as a background for a game display has a height and a width. Thus, on running mobile devices with small displays, only a first portion of the background having a height and width less than the height and width of the graphical image is displayed upon game play.

Also, on mobile devices with a large display, the background having a width smaller than the width of the graphic image, a height not greater than the height of the graphic image, and a height and width greater than the height and width of the first portion when the game is executed. Only the second part of is displayed.

On the other hand, the movement of a targeting indicator when running the game on mobile devices with small displays is limited to the area around the height and width of the first portion of the background, and the game on mobile devices with large displays. In practice the movement of the target indicator is limited to the area around the height of the first portion of the background.

Another embodiment of the present invention proposes a display method for actually providing the same game on the first and second mobile devices. That is, when the game displays the first portion of the video image on the small screen of the first mobile device, the game is on the small screen of the second mobile device wider or higher than the width and height of the first portion. Display a second portion of the video image.

Further, the method allows the game to allow a first game player on the first mobile device a range of motion of the threat indicator around the height and width of the first portion of the video image, and the game on the second mobile device. It allows a second game player to have a range of operating heights of the target indicator that is approximately the same as that provided on the first mobile device with the small display.

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

Hereinafter, in the present invention, a predetermined 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. On the other hand, generally, a mobile terminal having a graphics accelerator may be required to obtain high quality video graphics. However, in some embodiments, the system may operate in a mobile terminal without a graphic accelerator.

The present invention also discloses a system and method for developing a 360-3D game. 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. In this case, the game can be produced 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 major components in a 360-3D game development and game execution system according to an embodiment of the present invention. 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 graphics files 120 in 'targa' or '.tga' format.

The authoring tool 130 then imports the graphic files 120 and converts the '.tga' format into a format called a '.pic' file 140 or the like. 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 authoring 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 authoring 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 of the computer 170 of FIG. 1, in other embodiments, the graphics program 110 and graphics files 120 may be created using the authoring tool ( 130, along with the '.pic' file 140, the '.act' file 150, and the container 160, may be displayed on the same computer 170.

On the other hand, if the 360-3D game is installed in a mobile phone, PDA or similar device, the container 160 is copied from the computer 170 to the mobile device 180. Instead, the container 160 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. Alternatively, the container 160 may be transferred from the computer 170 to the mobile device 180.

In this case, the files of 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 transmission process. However, even if some changes are required for compatibility, the files are actually considered to be the same and the files are present in the container 160 regardless of whether the container 160 is present in the computer 170 or the mobile device 180. Done.

In addition, there is a runtime engine 190 that can read files from the container 160 in the mobile device 180. As will be described in detail below, the engine 190 reads instructions 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.

According to a preferred embodiment, the engine 190 may be embedded in the operating system of the mobile device 180. The engine 190 can be somewhat modified to be compatible with other devices and operating systems, but substantially the same engine 190 can be embedded on any mobile device 180 and can read any container 160.

For example, using the same operating system calls 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 put the engine 190 at rest. 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 such mobile 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 other existing gaming container 160. Then, the engine 190 reads a new container 160 to execute a new game.

Before the production tool 130 creates a 360-3D game and looks at how the runtime engine 190 executes the game in detail, the format of the 360-3D game and the normal 360 to aid in understanding of the present invention. Let's look at the types of gaming actions that occur in 3D games.

The 360-3D game belongs 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 a virtual player and a character in a game scene known in the art.

For example, the action may be to select a character 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 at 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. In this case, the shooting and / or firing may be spraying, pointing, designing and / or selecting. Examples of other types of games that can be applied to the system of the present invention are already presented in the known art.

In an embodiment of the 360-3D game, the virtual player may freeze or rotate around a single point of a scene. 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 keys or other means of providing 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 characters 260 are in the foreground. Shown in These background and foreground objects are properly proportioned to create a three-dimensional appearance. In addition, 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 may be represented in a plane on the display 200. Mountains 230, buildings 240, trees 250, and characters 260 arranged in the foreground 220 appear on the display 200. Characters 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 in the scene, regardless of whether it is a human, an animal, a vehicle, or some other type of moving object, is called a character.)

In addition, the characters 260 may be scaled up and down in size to show the approach or withdrawal from the virtual player 210. In addition, scaling of the screen may be used to represent a scene in which the stationary object is approaching or away from the virtual player 210.

The scene includes invisible layers that indicate the depth of the character 260 with respect to the background and foreground. When moving left or right, the characters 260 move only in one of the layers. That is, the character 260 may be in either layer as close as possible to the foreground or background or between layers closest to the background from the layer closest to the foreground. This obscures when the upper layer character 260 passes in front of the lower layer character 260 and allows the characters 260 present in different layers to move in front of or behind each other. When scaling the size to create a forward or backward figure, the character 260 can also vary in hierarchy.

4 illustrates this concept of layering. The mountains 230 may appear in the farthest layer or background, called layer zero. Tree 250 may appear at layer 10 in front of layer 0 and another tree 250 may appear at layer 20 in front of layer 10. Two buildings 240 may appear in Tier 30 located in front of Tier 20. The character 260 may appear in a hierarchy 40 located in front of the hierarchy 30. Although five layers are illustrated 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 in 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 appears to show where the virtual player 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. Hereinafter, any target display including the target display 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 character 260 or other 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 crosshair cursor 270 is properly positioned on the character 260, the action causes a reaction of the character 260 (eg, injury to the character 260).

The character 260 has the ability to take actions such as shooting towards the virtual player 210. Also, the character 260 may move in or behind a structure or landscape, for example, may move behind a structure of a higher hierarchy than the main character 260 to prevent the virtual player 210 from shooting.

On the other hand, a graphic display called 'radar 280 (radar)' is displayed on the screen 200, including any characters 260 located outside the currently visible scene to pose a threat to the virtual player 210 ( 260 indicates where they are 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). The multi-player games will be 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 above characters 260 before the characters 260 kill the virtual player 210 in the single person shooting game. Once again focusing 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 specified level of harm to the character 260. The level of damage that can be inflicted by a weapon is called the weapon's power. At this time, the amount of damage maintained by the character 260 is referred to as damage. For example, a weapon having a power of 5 may inflict 5 points of damage to the character 260 when the virtual player 210 fires at the character 260 through the weapon. The characters 260 may have a specified level of damage that can withstand until they die or other action occurs on the character 260. For example, the character 260 may die after taking 20 points of damage. This character 260 is killed after being hit 4 times by a weapon with 5 powers.

Similarly, the characters 260 may have weapons that can inflict 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 characters 260 before the characters 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 has already been extended to non-combat games such as firefighter games.

When the 360-3D game starts, various characters 260 performing various actions may appear at various positions in the scene. The manner in which the game developer sets the characters 260 using the authoring tool 130, what are their characteristics, where they appear, and how to act will be 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. Also, the characters 260 may start shooting toward the virtual player 210. In one embodiment, a monitoring routine may be used to determine when the virtual player 210 will begin shooting early in the game, and the characters 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 the character 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 character 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 character 260 may repeat this operation until 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 character 260 such as the amount of damage that can be sustained before the character 260 dies and actions that can be taken if the character 260 dies. It may include data related to. The second portion of the '.act' file 150 may include a command depicting the appearance of the character 260. The third portion of the '.act' file 150 may include a command depicting the shooting of the character 260 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 character 260 should be hidden. The fifth portion of the '.act' file 150 may include instructions to return to the second portion and repeat a series of events. In some embodiments, all information about these actions may be stored in a single '.act' file 150 that includes separate portions or in separate '.act' files 150.

When the virtual player 210 kills the character, the settings of the first portion of the '.act' file 150 are searched. These settings identify one or more other '.act' files 150 for requesting the death of the character 260, which may be a series of one or more other characters 260. Can be used to perform other actions. The game developer can make the '.act' file 150 as complex as desired to depict the complex behavior of the character 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 on the character 260, one '.act' file 150 may cause the engine 190 to generate other '.act' files 150. For example, when the first character 260 dies, the second character 260 may appear at a predetermined position in the scene, and the third character 260 may appear at another position. The behavior of the second and third characters 260 will be depicted by other '.act' files 150. These '.act' files 150 describe a series of complex actions on the second and third characters 260 and the engine when a specified action occurs on the second and third characters 260. Other '.act' files 150 generated by 190 may be checked.

The '.act' file 150 for the character may cause the engine 190 to call another '.act' file 150 in different situations. For example, if the character 260 is injured, the engine 190 may cause the character (i.e., the .act) file 150 to describe the behavior of the character 260 before the character 260 is injured. 260 calls another '.act' file 150 that depicts the lame behavior. If the character 260 dies, the engine 190 calls another '.act' file that depicts the death behavior of the character 260. When the character 260 moves to a designated place, the '.act' file 150 may change the amount of damage that the engine 190 can sustain or the weapon power of the character 260. Other ways in which the behavior of the character 260 changes based on the game environment will be apparent to those skilled 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 characters 260, the action of the character 260 is controlled by its '.act' file 150, and the '.act' associated with the previous character 260. Based on the data of the file 150, a complex game plot may be generated and proceed through the method of introducing a new character 260. In general, when a certain action occurs for a certain character 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 starts processing functionality by reading the '.act' file 150 and processing an instruction 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.

According to an embodiment, each '.act' file 150 may be composed of 32 bytes of data. In other embodiments, the frames may have different sizes. In this case, 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. According to an embodiment of the present disclosure, the file may be identified by an address offset to the container 160. In addition to the above instructions, other types of instructions may occupy other bytes. Game developers using authoring tool 130, which will be described later, specify command indicators, filenames, and other commands that each frame has, so as to determine the action that will occur when each frame is read by the runtime engine 190. Can be specified.

In this case, when the runtime engine 190 executes the '.act' file 150, it may 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 character has moved from the initial generation position. In one embodiment, the runtime engine 190 assigns execution tracks to each activity and can 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. An arrow 310 connected to the time slice in the runtime engine 190 indicates the frame 300 that the engine 190 currently reads. In this case, it can be seen that the engine 190 is reading a different frame for each '.act' file 150. As such, when the plurality of '.act' files 150 are read during the same tick as the engine 190, the plurality of images may be simultaneously displayed on the display 200.

On the other hand, one of the commands that can appear in the 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 a character 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 running operation is made when the fourteen images are sequentially and repeatedly displayed on a 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.

According to an embodiment of the present invention, the following commands as well as the '.pic' command may occur in the 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 character 260 to create another character 260. For example, when the first character 260 dies, the second character 260 may be generated as an example of a supporting force sent to replace the casualty. This may be done by placing a 'launch' command in the frame of the '.act' file 150a associated with the first character 260 that generates the '.act' file 150b associated with the second character 260. Preferably, the body of the first character 260 is visible while the second character 260 is active. The 'launch' command causes the '.act' file 150a associated with the first character 260 to be active and the '.act' file 150b associated with the second character 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 is executed by the 'go to' command in the first activity defined by the first '.act' file 150a by the second '.act' file 150b. 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 stop and be deleted. In the above example, the 'go to' command may be used when the body does not want to see the body after the first character 260 dies. If the 'go to' command is used to cause the second character 260 to appear after the first character 260 dies, the 'go to' command is defined by the '.act' file 150a and associated with the activity of the first character 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 character running example. 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 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 character 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 character 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 in the first layer, the character 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 layer, it is preferable to allow the character 260 to move in the second layer. To implement this, the '.act' file 150a controlling the character 260 causes the character 260 in the first and second layers of instructions to cause the character 260 to move and appear in the first layer. May include a second set of instructions to cause a to appear and move. In addition, the 'act' file 150a may include an 'if .act go to self' command for checking whether an object exists.

The character 260 starts moving in the first layer, and the '.act' file 150a controlling the character 260 periodically checks whether an 'if .act go to self' command exists. You can run If the target does not exist (ie, the '.act' file 150b controlling the target is not currently active), then the '.act' file 150a controlling the character 260 is the first instruction set. Run and remain in the first tier. On the other hand, if the target exists (ie, the '.act' file 150b controlling the target is currently active), then the '.act' file 150a controlling the character 260 is skipped to the second instruction set. The character 260 moves to the second layer to appear. This may allow the character 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 the character 260 can maintain before it dies or other actions take place. In addition, the 'damage' command specifies an action that occurs when the threshold damage of the character 260 is reached. For example, 20 levels of damage are given to the 'damage' command of the first '.act' file 150a and 20 characters of the character 260 controlled by the first '.act' file 150a are damaged. 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 character 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 becomes valid while the '.act' file 150a is executed unless changed by a subsequent 'damage' command. . Changing the '.act' file 150 executed upon reaching critical damage may cause the character 260 to die in different ways under different circumstances. For example, the character 260 may have a 'die1' '.act' file 150b that causes the character 260 to fall to the floor. If the character 260 subsequently moves to a higher position, the 'damage' command may cause the character 260 to die differently. A 'die2' '.act' file 150c may be designated by the 'damage' command to fall to the floor in a different way when the character 260 dies.

The 'delete' command stops execution of all actions controlled by the '.act' file 150 with the specified name, and displays the character 260 controlled by the dependent '.act' file 150. 200). For example, the character 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 characters 260 or running actions may occur from the 'run3' '.act' file 150. The 'delete' command applied to the 'run3' file name causes all running characters 260 or running actions from the 'run3' '.act' file 150 to stop running at the same time, running characters 260 or 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 is not collided 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 that the processing of the second action is taken out of the loop to process the 'delete self' command, such as firing made by the virtual player 210, for example. In this case, the character 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 character 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 gain additional points in some circumstances. In general, the number of points received by the virtual player 210 is the same as the damage required to kill one character 260. That is, if 20 points of damage are required to kill the character 260, the virtual player 210 gets 20 points each time one character 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 than the normal score that would be gained by killing the character 260. 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 character 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. Meanwhile, other indicators may be used in other embodiments.

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 above-described command with data in the field associated with the displayed 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 the return to the frame is to cause the character 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' instructions designate the number of pixels moving horizontally and vertically with respect to the position of the character 260 in the previous frame, respectively. In the example in which the running motion of 10 frames produced the running figure of the character 260, the character 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 character 260 moves horizontally with respect to the background.

The 'scale' command specifies the size associated with the character and is usually specified as a percentage of the standard size. Increasing the scale of the inter-frame character 260 may create a state of approach toward the virtual player 210, and decreasing the scale of the inter-frame character 260 may reduce the scale of the virtual player 210. You can create a look away from it.

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 the hierarchy of characters 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 character 260 to designate the amount of damage inflicted when the character 260 fires at the virtual player 210. The game developer may set the power of the weapon to zero when the character 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 character 260. As control of the depiction of the character 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 in the fifteenth frame, no image is displayed, and 67 millisecond flicker is generated while the first frame is read back and processed by the engine 190 for display. Appears on the screen 200.

This flicker can be prevented by selecting the 'multi' command option in the fourth 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 character 260 is being displayed, the initial loop of the current '.act' file 150a is also running, creating another '.act' file 150b and killing the character 260. If it is desired to change the required damage, multiple consecutive frames with 'multi' instructions can be used. The first frame has a '.pic' command and a 'multi' command, the second frame has a 'go to' command and a 'multi' command, the third frame has a 'launch' command and a 'multi' command, and the fourth frame 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, called 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 character 260. Frame 0 may also include 'absolute x', 'absolute y', 'layer', and 'scale' instructions to set the initial position and size of the character 260. As described above, frame 0 is defined as 'going to frame 0 where absolute x and / or absolute y position is defined as frame 0' causes character 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. 6 illustrates an embodiment of a computer-authored authoring tool 13. 7A to 7D are enlarged detail views of FIG. 6 divided into four parts. Hereinafter, a description will be given with reference to FIGS. 6 and 7A to 7D.

In general, the authoring tool 130 may effectively produce a 360-3D game. Although a particular embodiment of the authoring 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 authoring tool 130 includes 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 identifying 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 embodiment of FIG. 6, a 'damage' command is selected, which is 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 present a text box to specify the power to be applied to the character 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 embodiment of FIG. 6, when the 'damage' command is selected in the command drop-down box 620, the '.act' file 150 listed in the action text box 640 is assigned the current character 260. Specify the '.act' file 150 to be executed when the damage threshold is reached. For example, the action text box 640 may enumerate a '.act' file 150 depicting the character 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 the path text boxes 650 may be displayed in the position where they are arranged in FIG. 6. 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 character 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 character 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 way it can be made to move the same distance in the frame of all the 'act' file 150 for the character 260.

The text box 710 labeled 'Layer' allows the game developer to specify the layer in which the character 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 relevant size of the character 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 can be associated with the scale text box 720 to allow the game developer to specify that the character 260 can 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 is automatically made to the layer when the scale is adjusted. For example, if the game developer reduces the scale of the character 260 by a certain amount for each frame in order to create a movement toward the background, the layer to which the character 260 belongs is automatically changed by a proportional amount for each frame, thereby Character 260 moves in 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 character 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 may 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.

The 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 the above preferred embodiment, the 360-3D game has three run levels, which can only move to the second and third levels respectively when the player has successfully completed the first and second levels. In other embodiments, they 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 only include commands that initiate a set of '.act' files 150 of actions that occur when the level of the game 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 position and size of the character 260 in the emulator. The left and right buttons 881 and 882 move the character 260 horizontally through the emulator 920, and the up and down buttons 883 and 884 move the character 260 vertically. Zoom in and zoom out buttons 885 and 886 increase or decrease the size of character 260. These buttons 880 can be used to quickly set the initial size and position of the character 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 that includes background parameters and character.tga files for the '.pic' file 140 format, the creation of the '.act' file 150 and other game description operations. do. The authoring tool 130 is typically installed on a standard desktop computer 170, and data may 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 authoring tool 130 may find that such a standard keyboard is faster than using a mouse to point or click on the controls 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. The video format used by computers is usually different from the format 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 a 360-3D game developed through the authoring tool 130 to appear on the mobile device 180 which is substantially the same as that shown in the emulator 920.

The authoring 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 conventional video game development methods that employ staff coding for programming tasks and graphic artist staff for art work. Making video games in the conventional way is quite time consuming and expensive.

The authoring tool 130 supports quick and easy 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 directly tested using the emulation capabilities of the authoring 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 190 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 program 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 have virus infestation, 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 viruses.

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 authoring tool 130 may be read by any mobile device 180 on which the runtime engine 190 is 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 hierarchically, and displays it in the appropriate back and forth order. The engine 190 names and maintains tracks of the different versions of the characters 260 that are currently active, and registers and maintains tracks of successful launches of the characters 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 the multiplayer game. The multiplayer game will be described in detail below.

The engine 190 registers a successful launch from the virtual player 210 to the character 260 through a method that provides greater accuracy than the previous launch registration method. As shown in FIG. 8, 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 character 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.

9 shows an example of how a strike is registered in a 360-3D game. In FIG. 9A, 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. 9B, the memory buffer may be viewed as a silhouette screen 450, in which 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 in the data location 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 in addition to a reduction in stockpile. No other 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 objects in FIG. 8A are (6,6), (6,7), (6,8), (7,6), (7,7), (7,8), ( It may occupy a box bounded by 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 190 may immediately determine the target hit 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 are Java-based. Can be read by the 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 version of Java 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 not required to be tested on device 180 without testing. Loaded. 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 may be installed. Can be read and executed. 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 character 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 methods, images are generated faster than they are stored in memory, so a large amount of memory is not required. 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 character 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 the '.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 so as 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, the rendering of the run-length coded file can be done faster than the rendering of 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. 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 performed 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, the game developer using the authoring tool 130 may use the 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 authoring 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 perspective 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 wirelessly transmitted to the other 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 located at the center of the left and right while the virtual player 210 rotates, and each virtual player 210 can rotate 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. Therefore, each virtual player 210 may shoot toward a character 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 are read while executing the same '.act' files 150. It will exist. 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 character 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 in which the engines 190 on two different devices 180 execute 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 player 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 character 260, the first '.act' file 150a controlling the first player 260 may control the second '.act' file that presents the second character 260. 150b can 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 concurrently 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 character 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 authoring tool 130 is commonly used in 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.

Meanwhile, the display screens 200 on the 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 scaled down 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. 10, 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 character 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 can be active regions in which characters can enter and exit and action can 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 with a device with a large display 470. It may also appear in the upper and lower horizontal portions 480, 485 on 180.

When players with each mobile device 180 join the multiplayer game, the first player has 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. If the entire display area 470 of the first device 180 is activated, 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 characters 260, thereby obtaining points that are impossible for the second player.

To eliminate 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, who can observe the character 260 entering and exiting the parts, but cannot shoot towards the character 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. 11 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 character 260 that changes color or shoots toward the virtual player 210. (One character 260 is currently a virtual player. In order to distinguish it from other characters 260 that cannot inflict damage to 210, a character 260 that actively shoots hereinafter is called an enemy. For example, near the center of the rod 930 The brightly visible sector 950a 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 of the enemy to indicate that the damage level applied to 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 towards 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 dealt to the virtual player 210. 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 the engine of each player controls the aspect of the radar 280 of each player.

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. 12 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 characters 260 used in the game and the number of different poses adopted by the characters 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). Only one set of '.pic' files 140 may be displayed on the character 260, no matter how many activities are generated based on a single '.act' file 150 and how many different versions of the character 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 required that is allocated to the meshes and textures of each separate character 260. Each '.act' file 150 file uses a pointer to the '.pic' file 140 depicting the character 260, and as many pointers as desired to the same '.pic' file 140 simultaneously. Can be used. Thus, a number of identical characters 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 980a, 900b, and 900c 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. The 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 sequentially arranged 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 authoring 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 action 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. 13. The mobile terminal 180 may be referred to as a processor 1210 (which may be referred to as 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 may execute instructions, code, computer program, or scripts that are accessed 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 authoring tool 130 described above may be implemented on any general purpose computer having sufficient processing power, memory resources, and network throughput capability to allow the necessary workload to be located. 14 depicts a general general purpose computer system for implementation in one or more embodiments disclosed herein. The computer system 1300 may be referred to as a processor 1332 (may be referred to as 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 a 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 while instructions and programs are executed. 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 be a printer, video monitor, liquid crystal display (LCD), touch screen display, keyboard, keypad, switch dial, mouse, trackball, voice recognizer, card reader, paper tape reader, or Other well known input devices may be included.

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.

According to the present invention, by specifying a method of handling a series of pre-rendered images when displayed on a mobile device, developers can easily produce 360-3D games.

In addition, the game can be produced without the use of programming code, eliminating the need for programming knowledge or experience and significantly reducing game development costs.

Claims (28)

A system for executing a game on mobile terminals having displays of different sizes, the system comprising: A background for a stereoscopic game having a horizontal size and a vertical size stored in at least one memory of each memory of the first mobile terminal and the second mobile terminal, A first background that is part of the background for a three-dimensional game and comprises a first horizontal portion defined below a width of a total horizontal dimension of the three-dimensional game background and a first vertical portion defined below a height of a total vertical dimension of the three-dimensional game background The first mobile terminal including a first display configured to display a background of the stereoscopic game as a stereoscopic game proceeds; A portion of the background for the three-dimensional game, wherein the second horizontal portion and the first vertical portion greater than the width of the first horizontal portion and less than the width of the total horizontal dimension of the three-dimensional game background are greater than the height of the three-dimensional game background. A second display configured to display a second background consisting of a second vertical portion defined below a height of a total vertical dimension as the background of the three-dimensional game during the three-dimensional game, and indicating a progress state of the three-dimensional game during the three-dimensional game; A second mobile terminal having a processor for displaying the components of the stereoscopic game on the second display together with the second background, When the first mobile terminal and the second mobile terminal interoperate with each other to simultaneously play the stereoscopic game, the processor may display one or more components of the stereoscopic game from the second background displayed on the second display. A system for executing a game, which is displayed only in an area corresponding to the first background. The method of claim 1, wherein the second vertical portion is defined as including a separate background scene connected to the background scene included by the first vertical portion and not included in the first background. System for running the game. delete The system of claim 1, wherein the second vertical portion is defined to include a separate background scene that is connected to a background scene included by the first vertical portion. delete delete delete delete The mobile terminal of claim 1, wherein the one or more components include an indicator indicating an action state of a character in the stereoscopic game, and a range in which the indicator is displayed is displayed on each of the first mobile terminal and the second mobile terminal. The system for executing a game, characterized in that within the area corresponding to the first background of each background. The stereoscopic gaming background is defined as a graphical image with a 360 degree view, wherein a first portion defining a first edge of the graphical image defines a second portion defining a second edge of the graphical image. And similarly the first portion and the second portion overlap each other when the graphical image is defined as a graphical image of the 360 degree view. delete What is claimed is: 1. A method for simultaneously executing the same game in a state in which mobile terminals having displays of different sizes are connected to each other. Creating a graphic image with height and width for use as a background for a gaming display, Displaying only a first portion of the background having a height and width less than the height and width of the graphic image when playing the game on mobile terminals having a small display; The background having a width not greater than the width of the graphic image, a height not greater than the height of the graphic image, and a height and width greater than the height and width of the first portion when the game is executed on mobile terminals having a large display; Displaying only the second portion of, Limiting movement of a targeting indicator when the game is executed on mobile terminals having a small display to an area within a height and width of a first portion of the background; And limiting the movement of the target indicator to an area within a height of the first portion of the background when executing the game on mobile terminals with large displays. The method of claim 12, wherein the movement of the target indicator is limited to an area within a width of the first portion of the background when the game is executed on the mobile terminals having the large display. . The method of claim 12, wherein each of the mobile terminals automatically detects a display size of each of the mobile terminals when the game is executed. 13. The method of claim 12, further comprising displaying a threat indicator and a score in the area of the first portion of the background on mobile terminals having the small display and the large display. And a method for executing a game, characterized in that. The method of claim 15, wherein the threat indicator, And a directional indicator to indicate the direction of the threat. 17. The method of claim 16, wherein the threat indicator is operable to display the direction indicator indicating a plurality of threats and a direction of a priority threat. 18. The game of claim 17, wherein the plurality of threats have a priority and the priority of the threat is indicated by the color of the threat indicator associated with the threats. How to. The threat indicator of claim 15, wherein the background is operable to generate a 360-degree view, wherein the threat indicator includes a bar where the location is indicated, wherein the threat location on the threat indicator bar is indicative of a threat on the background. And a method corresponding to the position. 13. The method of claim 12, wherein the target indicator is controlled by a game user using direction keys of the mobile terminal. 13. A game according to claim 12, characterized in that the mobile terminal with the small display is a mobile phone and the mobile terminal with the large display is a personal digital assistant. Way. In the display method when playing a game on mobile terminals having different sized display, Providing the same game by the first and second mobile terminals, Displaying, by the first mobile terminal, a first portion of a video image of the game on a first display of the first mobile terminal; Displaying, by the second mobile terminal, a second portion of the video image on the second display of the second mobile terminal, the second portion of the video image being wider or higher than the width and height of the first portion; Allowing, by the first mobile terminal, the operating range of the threat indicator within a height and width of the first portion to a first game player on the first mobile terminal; Displaying, by the second mobile terminal, allowing a second game player on the second mobile terminal to allow a range of operating heights of a target indicator, as provided on the first mobile terminal. . 23. The display of claim 22, further comprising the second mobile terminal allowing the second game player to allow a range of operating ranges of target indicators, as provided on the first mobile terminal. Way. 23. The method of claim 22, wherein the target indicator is defined as any one of a target component, a pointer component, a cross cursor, an aiming indicator, and a target reticle. The display method according to claim 22, wherein the game is a single player shooting game. The display of claim 22, wherein the second display displays the second portion including the first portion, the lower portion of the second portion includes a separate foreground not included in the first portion, and The upper portion of the second portion includes a separate background that is not included in the first portion, and the height of the separate foreground and the separate background is defined as the height difference between the height of the first portion and the second portion. Display method, characterized in that. 27. The display of claim 26, wherein the second mobile terminal further comprises the step of providing no executable action within the separate foreground and background of the second portion displayed on the second display. Way. In a mobile terminal, A memory for storing a three-dimensional game background having a horizontal size and a vertical size, A first background that is part of the background for a three-dimensional game and comprises a first horizontal portion defined below a width of a total horizontal dimension of the three-dimensional game background and a first vertical portion defined below a height of a total vertical dimension of the three-dimensional game background A first display for displaying a background of the stereoscopic game as the stereoscopic game proceeds; And a processor configured to display, on the first display, the components of the stereoscopic game indicating the progress state of the stereoscopic game on the first display as the stereoscopic game progresses. The stereoscopic game when the stereoscopic game is performed as a part of the background for the stereoscopic game, the second background consisting of a second horizontal portion and a second vertical portion that are narrower or lower than the width of the first horizontal portion and the height of the first vertical portion; When any mobile terminal having a second display displaying a background of the mobile terminal and simultaneously executing the stereoscopic game, the processor displays one or more of the components of the stereoscopic game on the first display. And displaying only the area corresponding to the second background among the first background displayed on the mobile terminal.

Images