JP5718037B2 - Game program - Google Patents

Description

  The present invention relates to a game program.

  2. Description of the Related Art Conventionally, an action game has been developed in which a player operates a predetermined character to fight an enemy character in a virtual game space. Hereinafter, the character operated by the player is referred to as “player character”, and the enemy character is referred to as “enemy character”.

  In such an action game, generally, when a player character is attacked by an enemy character, the player character is damaged, and the physical strength value preset for the player character is reduced. When the received damage accumulates and the player character's physical strength value becomes zero, the game is over because the player character is defeated. When the game is restarted after the game is over, generally, the game starts from the beginning (or the beginning of the stage), the points and items that have been acquired disappear, and the player character that has gone up The level returns to the original level.

  On the other hand, a game has been developed in which a condition is set when the player character is defeated and the game can be resumed from the state when the game is over when the condition is cleared. For example, if a player character is defeated in the first game and a rescue request is issued to the second game, and rescue can be performed in the second game, the game resumes from the point where the first game was defeated. There are games that can be. In the game, rescue can be performed by the player character in the second game reaching the position where the player character was defeated in the first game.

JP 2007-135791 A

  In the above-described game, there is no particular limitation on performing rescue in the second game, and rescue can be performed if the player proceeds through the second game as usual. Therefore, when proceeding with the second game, there is no sense of urgency beyond proceeding with the second game as usual.

  Further, in the above-described game, the player who performs the first game and the player who performs the second game are the same person, and the rescue request is made by the player himself. It does n’t fit.

  A game that is communicated with other game devices in real time and is progressing while engaging with a game that is progressing on another game device is called a “synchronized game”, whereas real-time communication is performed. A game that is independently executed on each game device without being called is called an “asynchronous game”. Asynchronous games do not need to communicate with other game devices and servers in real time, so the burden of communication processing on the servers and game devices is reduced. However, since the game is progressed on each game device, it is not possible to engage with a player of a game being played on another game device.

  The present invention has been conceived under the circumstances described above, and although the game is an asynchronous game, the player can engage with each other in a game played on another game device, and rescue It is an object of the present invention to provide a game program that makes players feel tense.

  In order to solve the above problems, the present invention takes the following technical means.

A game program provided by the first aspect of the present invention is a game program for causing a computer to function as a game device that activates a player character operated by a player in a virtual game space, the computer Game progress control means for controlling the progress of the game, request information reception control means for causing the receiving section to receive request information including at least player character information relating to the player character of the other computer transmitted from another computer, and the receiving section other but upon receiving the request information, transmitted with the character based on the request information prescribed period, the virtual game and the character generating means for generating in a space, is performed in the other computers in the predetermined time period determine whether or not a predetermined condition is satisfied outcome of the game To function as a determination unit that, said character generating means, when the predetermined condition is satisfied, the extension or to shorten the predetermined time, after a predetermined period of time, to change the attribute of the character to be generated by the enemy character Features.

  According to the present invention, request information transmitted from a computer functioning as a certain game device (hereinafter referred to as “game device A”) is converted into a computer functioning as another game device (hereinafter referred to as “game device A”). When “game device B” is received, a character based on the request information is generated on the virtual game space of the game device B. At this time, if the request information satisfies a predetermined condition, the generated character is generated as an enemy character.

  Therefore, when request information is received, an enemy character may be newly generated in the virtual game space, so that the player of the game apparatus B can proceed with the game while feeling a sense of urgency. Further, the player of the game apparatus B can engage with the player of the game apparatus A throughout the game.

  Other features and advantages of the present invention will become more apparent from the detailed description given below with reference to the accompanying drawings.

It is a lineblock diagram showing the game device concerning this embodiment. It is a figure which shows the game image of 1 scene of this game. It is a figure for demonstrating rescue request information. It is a figure for demonstrating rescue completion information. It is a figure for demonstrating reward information. It is a flowchart for demonstrating the part regarding a rescue request among game progress processes.

  Hereinafter, a preferred embodiment of the present invention will be specifically described with reference to the accompanying drawings. In the following description, a case where an action game is progressing in a mobile phone terminal (hereinafter referred to as “game device”) in which a game program according to the present invention is installed will be described as an example.

  The action game according to the present embodiment (hereinafter referred to as “main game”) proceeds by causing the player character to fight against an enemy character that is a zombie in the virtual game space, and the player character defeating the enemy character. When the player character is attacked by the enemy character, the physical strength value set in advance for the player character decreases. When the health value becomes zero, the player character cannot move and the game is interrupted, but the player can make a rescue request to other players. In the following description, when it is necessary to distinguish between a player who has made a rescue request and a player who has received the rescue request, the player who has made the rescue request is referred to as “Player A”, and the player who has received the rescue request is represented by “ Player B ”. When the player B receives the rescue request, a character based on the player character of the player A (hereinafter referred to as “player character A”) appears in the game played by the player B.

  If player B receives a rescue request within the time limit for rescue after the player A issues a rescue request (hereinafter referred to as “rescue time limit”), the game being played by player B is drowned. Player character A appears. When the player character of the player B (hereinafter referred to as “player character B”) can touch the dying player character A, the player character A is rescued and the player A performs. Among the existing games, the physical strength value of the player character A is recovered, and the game is resumed. In this case, the game can be resumed while the level of the player character A is maintained and the acquired item is also left as it is. In the present embodiment, the rescue time limit is set to 2 hours, for example.

  On the other hand, when the player B receives the rescue request after the rescue time limit has elapsed since the player A issued the rescue request, the player character A that became a zombie appears in the game played by the player B. The player character A who becomes a zombie attacks the player character B as an enemy character of the player character B. Further, even when the player B receives a rescue request within the rescue time limit, if the player character B cannot touch the moribund player character A within the rescue time limit, the dying player The character A becomes a zombie and becomes an enemy character of the player character B.

  When the player character A is not rescued within the rescue time limit after the player A issues a rescue request, that is, no player receives a rescue request within the rescue time limit after the player A issues a rescue request. In this case, and when the player who has received the rescue request cannot rescue the player character A, in the game of the player A, the player character A has died without being rescued, and the game is over. In this case, when the game is restarted, the game starts from the beginning, the level of the player character A returns to the original level, and the items acquired by the player character A disappear. Details of the rescue request will be described later.

  First, the hardware configuration of this embodiment will be described.

  FIG. 1 is a configuration diagram showing a game device according to the present embodiment. The game apparatus 1 includes a control unit 11, a drawing processing unit 12, a voice processing unit 13, a communication processing unit 14, a memory unit 15, an I / O interface unit 16, a communication unit 17, a display unit 18, a voice output unit 19, and an operation unit. 20 and a touch operation unit 21. The control unit 11 is connected to a drawing processing unit 12, an audio processing unit 13, a communication processing unit 14, a memory unit 15, and an I / O interface unit 16. In addition, a communication unit 17, a display unit 18, an audio output unit 19, an operation unit 20, and a touch operation unit 21 are connected to the I / O interface unit 16.

  In FIG. 1, only the configuration for fulfilling the game processing function of the game apparatus 1 is shown, and the configuration for fulfilling the function as a mobile phone terminal (for example, a microphone for a call function) is shown. The description is omitted. Further, each unit shown in FIG. 1 is divided into functional configurations, and does not necessarily correspond to actual hardware. For example, the drawing processing unit 12, the audio processing unit 13, and the communication processing unit 14 may be included in a CPU 11a (described later) in the control unit 11.

  The game apparatus 1 can communicate with the server 3 via a network line 2 such as an Internet line. The game apparatus 1 downloads the game software from the server 3 and installs it in the memory unit 15. Note that the software installation of this game is not limited to this. For example, the program may be installed in the memory unit 15 of the game apparatus 1 from a recording medium such as a DVD-ROM via a personal computer or the like.

  The game apparatus 1 reads the game program and game data from the memory unit 15 into a RAM 11c (described later) in the control unit 11, and executes this game. The player can operate the player character by operating the operation unit 20 or the touch operation unit 21 to advance the game.

  The control unit 11 has a microcomputer that controls the overall operation of the game apparatus 1. The microcomputer includes a CPU 11a, a ROM 11b, a RAM 11c, and the like, and each unit is connected by a bus line.

  The CPU 11a comprehensively controls the game progress by executing a game program read from the memory unit 15 to the RAM 11c. More specifically, when an operation signal is input by the player operating from the operation unit 20 or the touch operation unit 21, the CPU 11a performs a predetermined game progress process for the operation signal in accordance with the game program. The CPU 11a displays the processing result on the display unit 18 as, for example, a two-dimensional image (hereinafter, referred to as “game image”) representing a three-dimensional space, and outputs the sound output unit 19 as a sound effect or the like.

  The ROM 11b stores a basic program indicating a basic function of the game apparatus 1 such as a loading function, a procedure for reading a game program and game data recorded in the memory unit 15, and the like. When the start of the game is selected by the player, the CPU 11a reads the game program and game data from the memory unit 15 into the RAM 11c according to the basic program stored in the ROM 11b, and sets the game start state.

  The RAM 11c provides an area for storing the game program and game data read from the memory unit 15, and a work area for the CPU 11a to execute the game program.

  The game program is configured by combining a plurality of programs. For example, a game progress program for controlling the movement of the player character displayed on the display unit 18 based on a player operation signal from the operation unit 20 or the touch operation unit 21 and a game image to be displayed on the display unit 18 are controlled. Includes graphic control programs.

  The game data includes character data (including image data) such as player characters and enemy characters, item data (including image data) such as weapons, motion data, image data such as backgrounds, sound data such as sound effects and BGM, and In addition, various tables that are referred to when the game progresses or is drawn are included.

  Based on the player's operation signal from the operation unit 20 or the touch operation unit 21, the CPU 11a reads a game program, image data, etc. from the memory unit 15 into the RAM 11c as necessary, and processes these data or executes the game program. The contents of the game image to be displayed on the display unit 18 are determined.

  The drawing processing unit 12 performs various arithmetic processes necessary for the drawing process. For example, the CPU 11a outputs a drawing command to the drawing processing unit 12 every 1/60 seconds. At this time, the CPU 11a determines an image to be displayed on the display unit 18, reads out character data, item data, image data such as a background, motion data, light source data, and the like necessary for rendering the image from the RAM 11c and performs rendering processing. To the unit 12. In addition, the CPU 11 a supplies the drawing processing unit 12 with position data of each character and operation signals input from the operation unit 20 or the touch operation unit 21.

  The drawing processing unit 12 uses image data or the like based on a drawing command from the CPU 11a to provide data necessary for drawing (positional relationship between each object and background, coordinates of polygons constituting each object on the screen of the display unit 18). , Texture corresponding to each polygon, and data such as reflection characteristics of each polygon) are calculated, and one frame (one frame) is stored in a VRAM (not shown) in the drawing processing unit 12 based on the calculation result. Create game image data. The created game image data is output to the display unit 18 as a video signal every 1/60 seconds, for example, and displayed as a video.

  The sound processing unit 13 performs various arithmetic processes necessary for processing to generate sound such as sound effects. When the CPU 11a determines a sound effect or BGM acoustic content to be output from the audio output unit 19, the CPU 11a outputs an audio command to the audio processing unit 13. The sound processing unit 13 reads out sound effects or BGM sound data from the RAM 11 c based on a sound command from the CPU 11 a, performs predetermined processing and D / A conversion processing, and then outputs them to the sound output unit 19.

  The communication processing unit 14 performs control for transmitting and receiving information when communicating with another game apparatus 1 or the server 3 via the network line 2.

  The memory unit 15 records the installed game program and game data, and includes a rewritable nonvolatile recording medium. Further, the memory unit 15 records information related to the progress of the game (for example, information such as various benefits such as acquired points and items) during the progress of the game or when the game is over. Information relating to the game progress recorded in the memory unit 15 is read into the RAM 11c at the start of the game.

  The I / O interface unit 16 transmits operation signals input from the operation unit 20 and the touch operation unit 21 to the control unit 11, and video signals and audio from the control unit 11, the drawing processing unit 12, and the audio processing unit 13. A signal or the like is transmitted to the display unit 18 or the audio output unit 19. The I / O interface unit 16 transmits information input / output from the communication unit 17 to / from the control unit 11 and the memory unit 15.

  The communication unit 17 transmits and receives information to and from other game devices 1 and the server 3 via the network line 2, and a modulation unit that generates an electromagnetic wave obtained by modulating transmission data at a carrier frequency. A demodulator for demodulating received data from the received electromagnetic wave, and an antenna for transmitting the electromagnetic wave generated by the modulator and receiving the electromagnetic wave and sending it to the demodulator. The antenna transmits and receives electromagnetic waves to and from a base station (not shown), and the game apparatus 1 communicates with other game apparatuses 1 and the server 3 via the base station and the network line 2.

  The display unit 18 displays a game image indicating a game progress state in accordance with the video signal transmitted from the drawing processing unit 12, and a liquid crystal display that converts the input video signal into a game image and outputs the game image. It has.

  The audio output unit 19 is a device for outputting sound such as sound effects according to the audio signal sent from the audio processing unit 13, and an amplifier and amplifier that amplifies the input audio signal with a predetermined amplification degree A speaker or the like for converting the output audio signal into audio and outputting the audio is provided.

  The operation unit 20 is operated by the player to operate the player character or perform various settings related to the game, and includes a plurality of operation buttons and the like. When an operation button or the like is operated by the player, the operation signal is input to the control unit 11, and the player character displayed on the display unit 18 performs a predetermined action. Examples of the predetermined operation include a moving operation such as running, squatting, and jumping, and an attack operation for attacking an opponent using a weapon. Movement, orientation direction, action type, and the like of the player character are assigned to each operation button.

  The touch operation unit 21 is operated by the player in the same manner as the operation unit 20, and includes a transparent touch panel in the present embodiment. The touch panel is provided so as to cover the display screen of the display unit 18, and the player's instruction is input to the control unit 11 when the player directly touches the panel surface with a finger or the like (hereinafter referred to as “touch”). To do. A large number of micro capacitors or micro resistors are arranged in a grid pattern on the panel surface of the touch panel, and the contact position is detected by a change in the capacitance of the micro capacitor or the resistance value of the micro resistor. Is input. CPU11a judges operation by a player based on the information signal of the input contact position.

  The server 3 communicates with each game apparatus 1 via the network line 2. The server 3 records the software of the game, and transmits the software to the game device 1 in response to a download command from the game device 1. Further, the server 3 accumulates and records information transmitted from each game device 1 and transmits information in response to a transmission request received from each game device 1. That is, the server 3 does not control the progress of the game executed on each game device 1, and the progress of the game executed on each game device 1 is controlled by each game device 1. The server that supplies the game software and the server that stores and records information may be separate servers. Also, the server that stores and records information is not limited to a server managed by a game provider. For example, any server managed by an SNS (social network service), a bulletin board server, or the like that has an API (Application Programming Interface) open to the public can be used. Further, information may be transmitted and received between the game apparatuses 1 via the network line 2 without providing the server 3.

  Next, details of the rescue request will be described with reference to FIGS.

  FIG. 2 is a diagram showing a game image of one scene of the game. FIG. 2A shows a scene in progress of the game, where the player character PC is surrounded by a plurality of enemy characters EC.

  A life gauge LIFE and a level gauge LV are displayed on the upper left of the screen of the game image shown in FIG. The life gauge LIFE indicates the remaining physical strength value of the player character PC, and the remaining physical strength value is represented by a hatched area. The level gauge LV indicates the level of the player character PC, and its length represents the level. In addition, the level is displayed numerically on the right side of the level gauge LV. The level increases according to the player's experience in the game. As the level increases, the battle power of the player character PC increases, and the stamina value that decreases when attacked decreases, which is advantageous when fighting the enemy character EC.

  A pause button PAUSE is displayed on the upper right of the screen. The pause button PAUSE is a button for temporarily stopping the progress of the game and proceeding to the menu screen. By touching the pause button PAUSE on the screen or operating the operation button of the operation unit 20 associated therewith, the progress of the game is paused and the menu screen is displayed.

  On the menu screen, an “end menu” for saving the current state and ending the game, a “map menu” for checking the position of the player character PC in the virtual game space, and the like can be selected. Details of the “map menu” will be described later.

  A move button MOVE is displayed at the lower left of the screen of the game image shown in FIG. The move button MOVE is a button for moving the player character PC. On the lower right of the screen, an attack button ATTACK and an item ITEM are displayed. The attack button ATTACK is a button for causing the player character PC to perform an attack. Item ITEM displays items such as acquired weapons, which can be selected and used. The move button MOVE, the attack button ATTACK, and the item ITEM can be selected and functioned by touching each button on the screen. In addition, each button is associated with each operation button of the operation unit 20, and can also be operated by operating the corresponding operation button.

  The player can move the player character PC with the move button MOVE and attack and defeat the enemy character EC with the attack button ATTACK. Further, an item used for attack or defense can be selected and used by the item ITEM. When the player character PC is attacked by the enemy character EC, the physical strength value of the player character PC decreases, and the hatched area indicated by the life gauge LIFE decreases. When the physical strength value does not remain (when the shaded area disappears), the player character PC becomes unable to move and enters a rescue request selection state. The physical strength value also decreases when the player character PC continues to move without procuring food. In this case, if the physical strength value does not remain, the player character PC cannot move and enters the rescue request selection state.

  When the rescue request is selected, for example, “Do you want to make a rescue request?” Is displayed on the screen, and “YES” or “NO” is selected. Hereinafter, a screen displayed in the rescue request selection state is referred to as a “rescue request selection screen”. In addition, you may be made to be able to choose the option which takes over a level and possession item and restarts a game. If “NO” is selected by the player, the game is over without a rescue request. On the other hand, when “YES” is selected by the player, the current game information (the level of the player character PC, the possessed item, the game progress information, etc.) is recorded, and the rescue request information is uploaded to the server 3. The server 3 accumulates and records rescue request information uploaded from each game apparatus 1. In the game apparatus 1, the elapsed time from when the rescue request is made (after the rescue request information is uploaded to the server 3) is counted, and an image in which the remaining time until the rescue limit time elapses is displayed is displayed. . The player of the game apparatus 1 cannot advance the game until rescued.

  FIG. 3 is a diagram for explaining rescue request information.

  The rescue request information includes player information, level information, knockout information, message information, in-game encryption, tag information, and the like. The player information is information for identifying the player, and includes a player's nickname, icon, ID number, and the like. The level information is a numerical value indicating the level value of the player character PC. The knockout information is information relating to the location and the reason why the player character PC has fallen, and is, for example, a character string such as “Toy counter” or “Zero A killed”. The message information is a character string of a message (arbitrary) input by the player. When “YES” is selected on the rescue request selection screen, an input screen is displayed and can be arbitrarily input. The in-game encryption includes character data (image data and the like) of the player character PC, fallen position coordinate data, fallen time data, and the like. The tag information is information for identifying the type of each information stored in the server 3, and is a character string (for example, a character string such as “#HELP”) indicating rescue request information.

  Of the rescue request information uploaded to the server 3, player information, level information, knockout information, and message information can be confirmed on the map menu.

  FIG. 2B shows a game image displayed when “Map Menu” is selected on the menu screen. The game image is created based on the current position coordinate data and orientation data of the player character PC and the rescue request information uploaded to the server 3.

  In the game image shown in FIG. 5B, a simplified view of the virtual game space as viewed from above is displayed, and the player character PC is displayed with an arrow. The position of the arrow is the current position of the player character PC, and the direction of the arrow indicates the direction of the player character PC. The player can know the position and orientation of the player character PC in the virtual game space by viewing the image.

  Further, in the game image shown in FIG. 5B, an object indicating a fallen player character is displayed based on the rescue request information uploaded to the server 3. In FIG. 5B, objects PCa, PCb, and PCc are displayed. The objects PCa, PCb, and PCc are displayed in a color corresponding to the time data at the position indicated by the position coordinate data where the in-game encryption of the rescue request information has fallen. The object indicating the fallen player character is displayed in gray close to white when the time has not passed since the time when the player character fell (see object PCa), and approaches black as time passes (object PCb), when the rescue time limit has elapsed, it is displayed in black (see object PCc). Therefore, the player can know the approximate position where the player character of the game apparatus 1 that made the rescue request has fallen and the approximate elapsed time since the rescue request was made by viewing the image. In addition, the player can see information of the corresponding fallen player character by touching and selecting the objects PCa, PCb, and PCc on the screen. In addition, you may make it display the information of the player character who fell on the game image shown to the same figure (b) from the beginning. Moreover, the display method of the information of the player character who fell is not limited to the method of displaying by the above-mentioned “map menu”. For example, the information of the fallen player character may be displayed in a time series.

  FIG. 7C shows a game image when the player selects the object PCb in the game image shown in FIG. In the game image, the information of the fallen player character corresponding to the object PCb is displayed based on the rescue request information uploaded to the server 3 (see FIG. 3). That is, the player icon and nickname included in the player information, level information, the fallen place and reason included in the knockout information, and message information are displayed.

  In the game image shown in FIG. 2C, choices “YES” and “NO” as to whether or not to rescue are displayed. When “NO” is selected by the player, the player returns to the image shown in FIG. On the other hand, if “YES” is selected by the player, the in-game code and the level information of the rescue request information are downloaded from the server 3 assuming that the player has received a rescue request. Based on these downloaded information, a character appears in the virtual game space. Note that a rescue request may be received by selecting an object in the game image shown in FIG. 5B without displaying an option for whether or not to rescue.

  When “YES” is selected in FIG. 2C, a character based on the player character PCb corresponding to the object PCb appears at the position coordinates (x, y, z) in the virtual game space. At this time, if the rescue time limit has not elapsed since the rescue request was made, a character as a lying shadow appears to represent the drowning player character PCb (see character PCb ′ in FIG. 2A). ). On the other hand, if the rescue time limit has elapsed since the rescue request was made, a character as a zombie appears to represent the player character PCb that has become an enemy character. The character as the zombie processes and displays the character data of the player character PCb. Further, the level information of the rescue request information is used for the level value of the character as the zombie. Therefore, an enemy character that inherits the characteristics of the player character PCb appears. A player who wants to fight against such an enemy character can take a method of receiving a rescue request when the rescue time limit has elapsed. Further, there may be a merit when such an enemy character is defeated. It should be noted that in FIG. 8B, the process after the player makes a rescue request without changing the color of the object indicating the fallen player character (see the objects PCa, PCb, and PCc in FIG. 10B). You may not be able to know the time. In this case, since it is not known in advance whether a character as a lying shadow appears or a character as a zombie appears, the player can enjoy gambling.

  If the player can touch the character as a shadow by operating the player character PC, the player character PCb is rescued. In this case, rescue completion information is transmitted from the game apparatus 1 to the server 3. The server 3 accumulates and records the rescue completion information, and transmits the rescue completion information to the game apparatus 1 that uploaded the rescue request information of the player character PCb. Note that direct transmission may be performed without going through the server 3. When the player character PCb is rescued and when the rescue request of the player character PCb is canceled, information to that effect is added to the rescue request information recorded in the server 3 (or the rescue request information is It has been deleted) and it is no longer possible to receive a rescue request.

  FIG. 4 is a diagram for explaining the rescue completion information.

  The rescue completion information includes rescue player information, rescued player information, message information, in-game encryption, tag information, and the like. Rescue player information is player information of a player who has rescued, and rescued player information is player information of a rescued player. Each includes a player's nickname, icon, ID number, and the like. The message information is a character string of the message input by the player who performed the rescue, and when the rescue is completed (when the shadow character is touched), an input screen is displayed and can be arbitrarily input. Can do. The in-game encryption includes rescue encryption data. The tag information is a character string (for example, a character string such as “#REVIVED”) indicating rescue completion information.

  In the game apparatus 1 that has received the rescue completion information, the elapsed time since the rescue request is made is stopped, a message is displayed based on the message information, and the player character PC is restored. The resurrection process is a process for reviving the player character PC and resuming the game. The game information recorded when the rescue request is made is read, and the health value is recovered while maintaining the level and the item. Then, the game is resumed. At this time, reward information is transmitted from the game apparatus 1 to the server 3. The server 3 accumulates and records reward information, and transmits the reward information to the game apparatus 1 that first rescues (firstly transmits rescue completion information). Note that direct transmission may be performed without going through the server 3. For rescue completion information other than the rescue completion information received first, only a message is displayed. Note that only the rescue completion information from the game apparatus 1 that first transmitted the rescue completion information may be received. Further, the reward information may be transmitted to all the game devices 1 that have rescued.

  FIG. 5 is a diagram for explaining reward information.

  The reward information includes rescue player information, rescue player information, message information, in-game encryption, tag information, and the like. The rescued player information is player information of a rescued player, that is, a player who sends a reward. Rescue player information is player information of a player who has rescued, that is, a player to whom a reward is sent. Each includes a player's nickname, icon, ID number, and the like. The message information is a character string of a message input by the rescued player. When the rescue completion information is received, an input screen is displayed and can be arbitrarily input. The in-game encryption includes reward encryption data for giving a reward to the rescue player. The tag information is a character string (for example, a character string such as “#REWARD”) indicating reward information.

  In the game apparatus 1 that has received the reward information, a message is displayed based on the message information, and a reward based on the reward encryption data is given.

  Before the player character PC rescues (touches) the character PCb ′ (see FIG. 2A) as a shadow that appears as a result of selecting “YES” in FIG. 2C, a rescue request is made. When the elapsed time becomes the rescue limit time, the character PCb ′ as a shadow changes to a character as a zombie and attacks the player character PC. In this case, the character data and level information of the rescue request information are also used for the zombie character.

  Game information recorded before uploading rescue request information (player character PC level, possessed items, game progress information, etc.) when the rescue time limit has elapsed before being rescued despite a rescue request. Is erased and the game is over. In this case, when the game is resumed, the level of the player character PC returns to the default level, and the game starts from the beginning with the items acquired by the player character PC disappearing. The level of the player character PC may be lowered to a predetermined level (for example, an intermediate level between the recorded game information level and the initial setting level) instead of returning to the initial setting level. Instead of erasing all items, only a predetermined item (for example, half the number of items) may be annihilated.

  Note that rescue request information, rescue completion information, and reward information are accumulated and recorded in the server 3 and can be referred to from each game device 1. Thus, the player can know the participation status and level of other players while being an asynchronous game. In addition to the above information, an arbitrary message can be uploaded to the server 3, and communication between players can be achieved. Moreover, since the information of the server 3 is also disclosed to persons other than the game purchaser, there is an effect of giving motivation to participate in the game to those who saw the exchanges between the players.

  FIG. 6 is a flowchart for explaining a portion related to the rescue request in the game progress process performed by, for example, the control unit 11 of the game apparatus 1. In the figure, a game progress process flowchart of the game apparatus 1a that makes a rescue request and a game progress process flowchart when the game apparatus 1b that receives the rescue request receives the rescue request are shown.

  First, a flowchart of the game progress process of the game apparatus 1a will be described.

  First, it is determined whether or not the physical strength value of the player character has become zero (S1), and if not (S1: NO), the process returns to step S1. That is, the determination is repeated until the player character's physical strength value becomes zero. When the physical strength value of the player character becomes zero (S1: YES), a rescue request selection screen is displayed (S2), and it is determined whether or not a rescue request has been selected (S3). Specifically, it is determined which of the options “YES” and “NO” for the rescue request has been selected. When the rescue request is not selected (S3: NO), the game information is deleted (S13), and the game progress process is terminated. On the other hand, when the rescue request is selected (S3: YES), the current game information is recorded (S4). Rescue request information is generated and transmitted (S5), and the elapsed time is started (S6).

  Next, it is determined whether or not the elapsed time exceeds the rescue limit time (S7). If the rescue time limit has elapsed (S7: YES), the game information recorded in step S4 is deleted (S13), and the game progress process is terminated. On the other hand, if the rescue time limit has not elapsed (S7: NO), it is determined whether or not the rescue request has been canceled (S8). If the rescue request is canceled (S8: YES), the game information recorded in step S4 is deleted (S13), and the game progress process is terminated. On the other hand, if the rescue request has not been canceled (S8: NO), it is determined whether or not rescue completion information has been received (S9). If rescue completion information has not been received (S9: NO), the process returns to step S7. That is, steps S7 to S9 are repeated until the rescue time limit elapses (S7: YES), the rescue request is canceled (S8: YES), or rescue completion information is received (S9: YES).

  When the rescue completion information is received (S9: YES), the elapsed time is stopped (S10), and the game information recorded in step S4 is read (S11). Also, reward information is generated and transmitted (S12), and the process returns to step S1 to resume the game.

  Next, the flowchart of the game progress process at the time of the rescue request reception of the game device 1b is demonstrated. The process of the flowchart is started when a rescue request is received.

  First, rescue request information is received (S21). Next, it is determined whether or not the elapsed time from the time information of the received rescue request information is within the rescue time limit (S22). If the rescue time limit has been exceeded (S22: NO), a zombie character (enemy character) is generated based on the rescue request information (S29), and the game progress process when the rescue request is received is terminated. On the other hand, if it is within the rescue time limit (S22: YES), a character as a shadow is generated based on the rescue request information (S23).

  Next, it is determined whether or not the elapsed time from the time information of the received rescue request information has exceeded the rescue limit time (S24). When the rescue time limit is exceeded (S24: YES), the character as a shadow is deleted, a character (enemy character) as a zombie is generated based on the rescue request information (S30), and the game progresses when the rescue request is received Processing is terminated. On the other hand, if the rescue time limit has not been exceeded (S24: NO), it is determined whether or not the rescue has been completed (S25). Specifically, it is determined whether or not the player character of the game apparatus 1b has touched the character as a shadow. If the rescue is not completed (S25: NO), the process returns to step S24. That is, steps S24 and S25 are repeated until the rescue time limit is exceeded (S24: YES) or the rescue is completed (S25: YES). When the rescue is completed (S25: YES), rescue completion information is generated and transmitted (S26), and it is determined whether or not the reward information is received (S27). Step S27 is repeated until the reward information is received (S27: NO). When the reward information is received (S27: YES), the reward is granted (S28), and the game progress process at the time of receiving the rescue request is completed. Is done.

  According to the present embodiment, a player who has received a rescue request cannot perform rescue before the elapsed time from when the rescue request is made reaches the rescue limit time, or when the rescue request is received, the elapsed time has already been reached. When the rescue time limit is exceeded, an enemy character appears, so that the game can proceed while feeling a sense of urgency. Further, since the player character of another game device can be rescued or rescued, the player can engage with the player of the other game device through the game even though the game is an asynchronous game. . In addition, since an enemy character that inherits the characteristics of the player character of another game device appears in the game, it is possible to more strongly recognize the relationship with the player of the other game device.

  In the above embodiment, the case where the character appears (changes) as an enemy character when the rescue time limit has elapsed has been described. However, the present invention is not limited to this. Instead of becoming an enemy character, it may be a character that takes away items or an obstacle that blocks the path of the player character. That is, any object that inhibits the progress of the game may be used.

  In the above embodiment, the case where an enemy character appears based on “falling time data” included in the rescue request information is described, but the present invention is not limited to this. The rescue request information may include information other than the information shown in FIG. 3, and may include information specifying the character attributes that appear on other game devices. For example, when the player wants an enemy character based on the information of his / her player character to appear on another game device, the rescue request information is transmitted by designating the attribute of the character to appear as the enemy character, and the rescue The game device that has received the request information may generate an enemy character in the virtual game space based on the information.

  In the above embodiment, the case where the player selects whether or not to make a rescue request when there is no remaining physical strength value has been described. However, the rescue request may be made without causing the player to make a selection. Moreover, although the said embodiment demonstrated the case where the player selected the rescue request to receive, you may make it receive a rescue request at random, without making a player select. Further, all rescue requests may be received when the player character falls within a predetermined distance from the player character in the virtual game space, or within a predetermined distance from the actual player position (specified by the GPS function). You may make it receive all the rescue requests from a certain game device.

  In the above embodiment, a case has been described in which a fallen player character is revived after being rescued by one player (that is, when one rescue completion information is received), but is not limited thereto. Rescue by two or more players may be a condition for the resurrection.

  In the above-described embodiment, the case where the game cannot proceed until the rescue is requested after the physical strength value ceases and the rescue request is made has been described, but the present invention is not limited to this. Even after the rescue request is made, only a part of the progress of the game may be restricted. For example, restrictions may be imposed such that the movement of the player character is slow, the level is greatly reduced, or the item cannot be used. In this case, the player can wait for rescue while continuing the game. Further, even in a state where this game cannot progress, other mini games may be played. In these cases, the rescue time limit may be extended or shortened according to the outcome of the game.

  Although the case where the rescue request information is uploaded to the server 3 has been described in the above embodiment, the present invention is not limited to this. For example, it may be transmitted to another game device 1 by mail, or may be transmitted to the game device 1 within a predetermined range by passing communication or the like.

  Although the action game has been described as an example in the above embodiment, the present invention is not limited to this. For example, the present invention can be applied to genre games such as adventure games and RPG (role playing games). Further, the present invention is a game in which a character operated by a plurality of players or a character controlled by a CPU forms a team and cooperates with an enemy character, or a character operated by another player as an enemy character. It can also be applied to such games.

  In the above embodiment, the case where the game is executed on the mobile phone terminal has been described. The present invention can also be applied to a case where a game is executed on, for example, a portable information terminal, a personal computer, a portable game device, a home game device, and an arcade game device.

  The game program according to the present invention is not limited to the above-described embodiment. The specific configuration of the game program according to the present invention can be varied in design in various ways.

DESCRIPTION OF SYMBOLS 1 Game apparatus 11 Control part 11a CPU (Game progress control means, Rescue request information transmission control means, Time measuring means, Game end control means, Rescue request information reception control means, Character appearance control means, Discriminating means, Rescue completion information transmission control means , Timing stop means, character change means)
11b ROM
11c RAM
12 Drawing processing unit (character appearance control means, character change means)
13 Voice processing unit 14 Communication processing unit (rescue request information transmission control means, rescue request information reception control means, rescue completion information transmission control means)
15 Memory part (program recording part)
16 I / O interface unit 17 Communication unit (transmitting unit, receiving unit)
18 Display Unit 19 Audio Output Unit 20 Operation Unit 21 Touch Operation Unit 2 Network Line 3 Server

Claims (1)

A game program for causing a computer to function as a game device that activates a player character operated by a player in a virtual game space,
The computer,
Game progress control means for controlling the progress of the game;
Request information reception control means for causing the reception unit to receive request information including at least player character information regarding the player character of the other computer transmitted from another computer;
Character generating means for generating a character based on the request information on the virtual game space for a predetermined period when the receiving unit receives the request information;
Determining means for determining whether or not a result of another game transmitted and transmitted by the other computer during the predetermined period satisfies a predetermined condition;
To function,
When the predetermined condition is satisfied, the character generation means extends or shortens the predetermined period, and changes the attribute of the character to be generated to an enemy character after the predetermined period has elapsed .