JP2012016539A - Game terminal and program of the same, and game system using the same - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a game terminal to be used for a hands-on game system so that a game user safely enjoys the game.SOLUTION: The game terminal forcibly prevents an event to be generated under a predetermined condition from being generated in a predetermined place which is determined as dangerous when a user concentrates on the game, i.e., a place where the game event is to be controlled.

Description

  The present invention relates to a game terminal and a mobile experience type game system using the game terminal.

  There are game systems that play games outdoors or in facilities. For example, when a game user moves within a facility with a game terminal and receives signals from signal generators installed at various positions in the facility, the game user uses the game terminal Can play.

  Such a game system is not limited to a specific space such as an amusement facility, but has recently been introduced to a commercial facility such as a shopping mall or a sightseeing spot. It is possible to enjoy a game using a large space in a commercial facility with a user (Patent Document 1).

Japanese Patent Registration No. 3425033

  However, if a game event occurs on the game terminal only in the field, such as outdoors or in a facility, where the signal generator is installed, the game user may take action of other game users who are experiencing it. Thus, the position where the game event occurs can be identified, and the pleasure of searching for the position where the game event occurs may be reduced.

  In order to solve such a problem, it is conceivable to provide a game event that does not exist to other game users by providing a game event that occurs regardless of the position of the game user. In other words, it is possible to give game users a special feeling that they can play game events that have not occurred to other game users by making the occurrence conditions of game events that occur independently of the position different. Become.

  However, when a game event that occurs regardless of the position is provided as described above, it is dangerous if the game user is immersed in the game event, for example, near an escalator in a commercial facility or a food court where general users gather. Game events sometimes occurred even in places.

  The present invention has been made in view of the above-described problems, and an object thereof is to provide a game terminal used in a mobile experience type game system that can be enjoyed safely by a game user.

  In order to achieve the above object, a game terminal of the present invention has the following configuration.

  When the portable game terminal satisfies a predetermined condition that does not depend on the control means, the position detection means for detecting the position of the game terminal, and the position of the game terminal, the first game event is First game event generation means for generating, and storage means for storing information on a position where the generation of the game event should be controlled, wherein the control means is a position of the game terminal detected by the position detection means. Is the position where the generation of the game event stored in the storage means is to be controlled, and the first game event is sent to the first game event generation means even when the predetermined condition is satisfied. It is characterized by controlling so that it does not occur.

  With this configuration, according to the present invention, it is possible to provide a game terminal used in a mobile experience type game system that can be enjoyed safely by a game user.

1 is a system configuration diagram of a game system according to an embodiment of the present invention. 1 is an overview diagram of a game terminal according to an embodiment. The block diagram which shows the function structure of the game terminal which concerns on embodiment. The flowchart which shows the whole process of the game system which concerns on embodiment. The figure which shows the example of GUI displayed on a game terminal in the locator event process which concerns on embodiment. The flowchart which shows the locator battle event process which concerns on embodiment. The figure which shows the example of GUI displayed on a game terminal in the locator battle event process which concerns on embodiment. The flowchart which shows the step count battle event process which concerns on embodiment. The figure which shows the example of GUI displayed on a game terminal in the event control process in the dangerous position which concerns on embodiment. The figure which shows the example of GUI displayed on a game terminal in the advice event process which concerns on embodiment. The table with which the identification information of the locator which concerns on embodiment, and the positional information on the said locator were matched.

  Hereinafter, a preferred embodiment of the present invention will be described in detail with reference to the drawings. In the embodiment described below, the signal generation device is referred to as a “locator”, and a game event that occurs in a game terminal by receiving a locator signal generated from the locator is referred to as a “locator event”. .

(System configuration)
FIG. 1 is a system configuration diagram of a game system according to an embodiment of the present invention. As shown in the figure, the game system includes one or more game terminals 100 carried by each game user, one or more locators 200 arranged in the facility, management of game users, and transfer of game settings to the game terminals 100. , And a server 300 that controls the locator 200.

  A game program is stored in the game terminal 100, and the game program is always executed while the game user is using it. The game terminal 100 and the other game terminals 100 can communicate with each other by a wireless communication method in which communication is possible only within a predetermined distance. In this embodiment, team play in the game is realized.

  In addition, game terminal 100 and locator 200 communicate with each other by a wireless communication method that allows communication only within a predetermined distance from locator 200. The locator 200 periodically transmits a unique signal including the identification information of the locator 200. When the game terminal 100 receives the signal, the game terminal 100 analyzes the signal so that the current game terminal 100 The position in the existing facility can be specified. Communication between game terminals 100 and between game terminal 100 and locator 200 may be the same communication method.

  In the present embodiment, one or more locators 200 and the server 300 exist on the same network, and the locator 200 can be controlled by the server 300. Further, the system administrator can set whether or not to generate a game event in the game program of the game terminal 100 for each of the one or more locators 200 in the facility by using the server 300. In this case, information on whether or not to generate the set game event may be transferred by connecting the server 300 and the game terminal 100 before the game user starts the game experience.

  The server 300 stores log information related to the game, such as information on characters raised by the game user experiencing the game, collected items, battle win / loss information, and the like for each game user. The log information regarding the game stored in this way is read and transferred to the game terminal 100 when the game user performs the experience again, so that the game user can continuously develop the character. It becomes like this. The game user information is managed by the ID information attached to the user ID card created when the experience is performed for the first time. That is, the server 300 stores log information related to the game in association with the ID information.

(Game terminal)
Here, details of the game terminal 100 will be described in detail with reference to the drawings. FIG. 2 is an overview diagram of the game terminal 100, and FIG. 3 is a block diagram illustrating a functional configuration of the game terminal 100.

  The CPU 101 is a block that controls the operation of each block included in the game terminal 100. The CPU 101 controls the operation of each block of the game terminal 100 by reading the operation program of each block of the game terminal 100 stored in the ROM 102 and developing it in the RAM 103 and executing it. The ROM 102 is a non-rewritable nonvolatile memory, and stores a game program in addition to an operation program for each block of the game terminal 100. The game program is stored in the ROM 102 at the time of shipment from the factory, but in this embodiment, the game program can be updated from a recording medium connected to a recording medium I / F 112 described later in addition to the server 300. And The RAM 103 is a rewritable volatile memory, and is used as a temporary storage area for data output in the operation of each block provided in the game terminal 100. Further, the RAM 103 stores information such as play data and status for each game user so that the game user can take over the previous play data when performing the experience again. The information for each game user may be stored in the RAM 103 via the recording medium I / F 112 described later using a recording medium such as a memory card from the server 300, for example.

  The GPU 104 is a block that performs drawing processing of a game graphic displayed on the display unit 105 to be described later, and performs processing such as displaying GUI data read from the ROM 102 and drawing a game screen. The display unit 105 is a display device provided in the game terminal 100 and uses, for example, a TFT liquid crystal.

  In addition, the game terminal of the present embodiment includes four sensors: a step sensor 106, a position detection sensor 107, an orientation sensor 108, and an acceleration sensor 109. The step sensor 106 counts the number of steps the game user walks with the game terminal. The step count data measured by the step count sensor 106 is sequentially transmitted to the CPU 101.

  The position detection sensor 107 includes the identification information of the locator 200 included in the signal received from the locator 200 via the wireless communication unit 111 described later, the locator identification information stored in the RAM 103 at the start of the experience, and the locator identification information. The position where the game terminal 100 exists is determined based on the table associated with the position information, and the information on the detected position is transmitted to the CPU 101. In the present embodiment, the position detection sensor 107 has been described as determining the position of the game terminal 100 based on the signal received from the locator 200. However, the present invention is not limited to this, and the position detection sensor 107 is, for example, A sensor that detects an absolute position or a relative position of the game terminal 100 such as GPS may be used. The embodiment of the present invention only needs to be able to determine whether or not at least the position where the game terminal 100 currently exists is a position where the event should be controlled. For example, the position detection sensor 107 is dangerous when the game user is immersed in the game. The position information may be output to the CPU 101 only in a predetermined area.

  Note that the table in which the identification information of the locator and the position information of the locator are associated with each other may be a table as shown in FIG. 11, for example. As shown in the figure, in the table, for the locator identification information, the presence or absence of a locator event described later, the attribute of the field to be displayed on the locator, the setting of whether or not the location of the locator is a dangerous area, and the locator Information on the location where is installed. In the present embodiment, it is assumed that the table is transferred from the server 300 and stored in the RAM 103 at the start of the experience. The dangerous area refers to a place that is determined to be dangerous when a game event occurs, that is, a place where the occurrence of a game event is to be controlled. As described above, a locator is arranged near the escalator, and the like. Assume that an attribute that is a dangerous area is set for the identification information of the arranged locator and included in the table.

  The direction sensor 108 is a sensor that detects the attitude of the game terminal 100, and outputs information on the detected attitude to the CPU 101. In the present embodiment, the orientation of the game terminal 100 detected by the orientation sensor 108 is the yaw direction and pitch when the direction perpendicular to the plane formed by the display unit 105 provided in the game terminal 100 is the traveling direction. Although the description will be made assuming that the direction is detected, the orientation information detectable by the azimuth sensor 108 may be all three rotation axes.

  The acceleration sensor 109 is a sensor that detects the direction and magnitude of acceleration generated in the game terminal 100, and outputs detected acceleration information to the CPU 101. Although details will be described later, in this embodiment, the jump of the game user is detected by the acceleration sensor 109 and used for the game.

  The operation input unit 110 is a user interface that is provided on the game terminal 100 such as a cross key or a function button and receives an input from the game user. The operation input unit 110 analyzes the operation input made by the game user and operates the CPU 101 on the user interface. A signal indicating the contents is transmitted.

  The wireless communication unit 111 is a communication interface included in the game terminal 100, and the game terminal 100 according to the present embodiment is intended for a game user to carry and experience, so wireless inter-terminal communication and anti-locator communication. Can be performed. Note that the wireless communication unit 111 does not particularly limit the wireless communication method, but in the present embodiment, the communication range is limited to a narrow range such as a radius of 10 m for both terminal-to-terminal communication and anti-locator communication. To do.

  The recording medium I / F 112 is an interface of a recording device that is detachably connected to the game terminal 100, such as a memory card or an HDD. The recording medium I / F 112 is used, for example, for writing game user play data, status information, and the like to the RAM 103. Information such as game user play data may be transferred from the server 300 via the wireless communication unit 111 and written in the RAM 103, for example.

  The sound generation unit 113 is, for example, a speaker, and is a block that reproduces and outputs sound source data for which an output command is issued in the game program. Note that the sound source data output from the sound generator 113 is processed so as to have a sound source localization, and the game user uses, for example, a earphone connected to the sound generator 113 to which direction the character exists. It is possible to perform character search by understanding the above.

(Game experience contents)
A basic flow of the game experience using the game terminal 100 of the present embodiment having such a configuration will be described with reference to the flowchart of FIG. In the game, the game user aims to carry a battle event with an enemy character existing in the facility, an item search event, and the like by carrying a character with a monster motif in the game terminal 100. The content of the game described below is one form, and the implementation of the present invention is not limited to this. In other words, the present invention is not limited as long as various places in a facility can be used in a game in which a game user carries a game terminal and travels.

  First, the game user receives the game terminal 100 in S401. For example, the game user registers the game user information at a reception provided in a store or the like in the installation location, and then receives the game terminal 100 from the reception staff. At this time, it is assumed that the game user can select the game experience time. When the game experience is the first time, a user ID card is issued to the game user.

  The game user can select a character to be operated at the start of the first experience, and can also develop the character by discovering battle events and items during the experience. When experiencing the game again after the experience, information such as the character and play data operated by the game user and managed with the identification information of the user ID card is written into the game terminal 100 at the start of the experience. Further, at the start of the experience, the game user can set the experience time, and information on the experience time set by the game user is stored in the RAM 103. At this time, the CPU 101 starts counting the experience time by a built-in timer (not shown) of the game terminal 100.

  In S402, the game user selects a mission to be experienced from the missions displayed on the display unit 105 of the game terminal 100. There are various types of missions, such as those that progress according to a specific story, and those that progress by performing the required goals one after another, such as “Go to XX”, “Collect XX”, etc. There shall be. It should be noted that by selecting a mission that can be selected according to the degree of character growth, it is possible to avoid selecting a mission that is too difficult for the character operated by the game user. Note that the mission information selected by the game user may be stored in the RAM 103 by the CPU 101.

  In S403, the game user starts moving along the content of the mission. When the game user moves to the communicable range of the locator 200, the game program of the game terminal 100 determines whether to generate a forced mission event in S404. For example, if the game user has selected a story mission in S402, when the user moves to a communicable range of the locator 200, for example, a transition to a conversation event as shown in FIG. At this time, if the CPU 101 determines from the locator signal received by the wireless communication unit 111 that the game terminal 100 is in a range where the game terminal 100 can communicate with the locator 200, the CPU 101 stores the selection in the RAM 103. From the mission information and the mission progress status information, it is determined whether or not the status is that a compulsory mission event is generated in the mission. If it is determined that a compulsory mission event occurs, the CPU 101 reads out the conversation event information from the ROM 102 in step S <b> 405, transmits it to the GPU 104, and displays it on the display unit 105.

  When it is determined that a forced mission event is not generated when the game user moves to the communicable range of the locator 200, the display unit 105 of the game terminal 100 displays the all-round field corresponding to the locator position in S 406. The field in the direction of the game terminal, that is, the direction in which the game user faces is cut out and displayed. As shown in the table of FIG. 11, field attributes such as a sea area, a mountain area, and a forest area are assigned to each of the locators 200 arranged in the facility, and the CPU 101 determines the locator position according to the field attributes. The perimeter field corresponding to is different. For example, in the case of a mountain area, the background of the field is a mountainous landscape, and in the case of a forest area, the background of the field is a landscape with trees and plants. The field displayed on the display unit 105 is, for example, as shown in FIG. 5B, and the game user looks around the field with the game terminal 100 actually holding the enemy character placed in the field at the locator position. To find out and shift to a battle event to be described later. In addition to the enemy character, an event trigger arranged in the field may be a treasure box or the like from which items or money can be obtained, and the event trigger arranged differs depending on the mission selected in S402. To do.

  When the locator event is completed or the game user moves to a range where communication with the locator 200 is impossible, the CPU 101 determines in S407 whether or not the experience time has ended. Specifically, the CPU 101 determines whether or not the experience time count started by a built-in timer (not shown) in S 401 is equal to or greater than the experience time set by the game user stored in the RAM 103. If the experience time count is equal to or greater than the set experience time, the CPU 101 moves the process to S408, and if not, the process returns to S403.

  When a game user completes a locator event in one locator 200, the CPU 101 is connected to the wireless communication unit 111 in the game terminal 100 of the game user so that the locator event does not continuously occur in the locator 200. Even if a signal is received from the locator 200, the signal is ignored for a predetermined time from the end of the previous locator event.

  In S408, a display indicating the end of the experience is displayed on the display unit 105, and the game user ends the experience and returns to reception. When returning to the reception, the game user returns the game terminal 100. At this time, along with the game user identification information of the user ID card of the game user, the character data, the acquired item, the information of the completed mission, etc. are transferred from the game terminal 100 to the server 300 and managed. And

  In the game program of this embodiment, it is also possible to experience by teaming up with a plurality of game users. When performing a team experience by a plurality of game users, the plurality of game users register as a team at the reception at the start of the experience. The fact that the experience is a team experience and the identification information of the game user 100 of the team game user are stored in the RAM 103. In addition, one of the plurality of game users registered as a team has the right to select a mission in the team experience.

  When a locator event occurs in the team experience, the game terminals 100 possessed by a plurality of game users registered as a team can communicate with each other and share the event if they are within a communicable range. For example, when a battle event described later occurs, a game user who first finds an enemy character to be a battle opponent becomes a host of the battle event. Then, a GUI for selecting whether or not to participate in the battle event is displayed on the display unit 105 of the game terminal 100 of the game user of the team that exists in a range where communication with the host game terminal 100 is possible. When a game user other than the host participates in a battle event, the game user can participate as a guest in the battle event.

(Battle event)
Hereinafter, battle events that occur during the game experience will be described in detail with reference to the drawings. In the game program of the present embodiment, when the battle event as a locator event that occurs within the communicable range of the locator 200 and the number of steps of the game user counted by the game terminal 100 reach a randomly determined number of steps. A battle event occurs as a step event that occurs. The timing of occurrence of the latter differs for each game user depending on the step length of the game user and the number of steps determined at random. In the case of a team experience, both battle events are hosted by the game user who first started the battle event as described above, and the game users of the team can participate in the battle event as guests.

(Locator battle event)
First, specific processing of the locator battle event process when a battle event as a locator event of the game terminal 100 of the present embodiment occurs will be described using the flowchart of FIG. The processing corresponding to the flowchart can be realized by the CPU 101 reading out a corresponding processing program stored in, for example, the ROM 102, developing it in the RAM 103, and executing it. Note that this locator battle event process is assumed to be started when, for example, the game terminal 100 is within a communication range with the locator 200 and the game user finds an enemy character in the field and moves to the battle. To do.

  In step S <b> 601, the CPU 101 causes the display unit 105 to display a screen that prompts the user to encounter an enemy character and move to a place that does not interfere with surrounding people in order to perform a battle. In step S <b> 602, the CPU 101 determines whether an input indicating that the game user has moved from place to place and the battle is ready is made on the operation input unit 110. The CPU 101 moves the process to S603 if an input indicating that the game user is ready for the battle is made, and repeats the process of S602 if no input is made.

  In S603, the CPU 101 confirms whether or not the current experience is a team experience. Specifically, the CPU 101 determines whether or not the experience information stored in the RAM 103 is a team experience. If the experience information is a team experience, the CPU 101 moves the process to S604, and if the experience information is a one-person experience, the process moves to S605.

  In S <b> 604, the CPU 101 requests the game terminal 100 of the team game user to participate in the battle event. Specifically, the CPU 101 refers to the identification information of the game user 100 of the team game user stored in the RAM 103, and requests to join the game terminal 100 of the team game user via the wireless communication unit 111. Send the signal. Note that the processing in this step may wait for, for example, about 10 seconds after the participation request signal is transmitted. In addition, it is assumed that the guest can participate in the battle not only in this step but also during the battle. In addition, when a guest participates in a battle, information on the guest to participate and the game terminal 100 of the guest is stored in the RAM 103 of the host game terminal 100.

  In S605, a battle with the enemy character starts. In the following steps, for example, when there is progress in a battle such as an attack or damage, all game users participating in the battle share the progress of the battle through inter-terminal communication via the wireless communication unit 111. And

  In S606, the CPU 101 first refers to the game users participating in the battle, and causes the GPU 104 to draw the battle screen on the display unit 105 as shown in FIG. In the example of FIG. 7, three game users participate in the battle as guests. In addition to the characters operated by the enemy character and the host, battle command options, the names of the battle participants and the enemy characters, the battle Participants and enemy character health gauges and the like are displayed.

  In S <b> 607, the CPU 101 waits for selection of a battle command by all game users participating in the battle. For example, the battle command includes commands such as “attack (attack)”, “guard (defense)”, and “item”, and the CPU 101 receives signals from the operation input unit 110 for host commands, and commands for guest commands. Determine the selected command. In step S <b> 608, the CPU 101 executes the command selected by each game user of the team in step S <b> 607 and the action of the enemy character and causes the GPU 104 to draw the command.

  In step S <b> 609, the CPU 101 determines whether the enemy character's physical strength has become zero. The enemy character's physical strength is determined in advance, and if the damage caused by the attack of the game user of the team during the battle exceeds the remaining physical strength of the enemy character, the game user has won the battle. Become. If the enemy character's physical strength is 0, the CPU 101 moves the process to S614, and if the enemy character's physical strength is not 0, the CPU 101 moves the process to S610.

  In step S610, the CPU 101 determines whether the physical strength of the character operated by the host has become zero. Specifically, when the damage received by the enemy character due to the attack made on the host character is equal to or greater than the physical strength of the character being operated, the game user of the team has lost to the battle. It will be. If the physical strength of the character operated by the host is 0, the CPU 101 moves the process to S615. If the physical strength of the character operated by the host is not 0, the CPU 101 moves the process to S611.

  In the battle event of the present embodiment, when the physical strength of the character operated by the guest game user becomes 0, it is possible to rejoin the battle by recovering the physical strength and returning. When the physical strength of the character operated by the host game user becomes zero, the battle is defeated even if the physical strength of the character operated by the guest is not zero.

  In step S611, the CPU 101 determines whether or not the game terminal 100 of the host game user exists within the communicable range of the locator 200 where the locator battle event has occurred. Specifically, CPU 101 determines whether radio communication unit 111 continues to receive a signal from locator 200. If the CPU 101 has received a signal from the locator 200 in which a locator battle event has occurred, the process proceeds to S612. If the signal has not been received, the CPU 101 determines that it has left the battle and proceeds to S616.

  Similarly, regarding the departure of the battle, if the guest game terminal 100 moves to a range where communication with the host game terminal 100 is impossible, it is determined that the battle is temporarily removed, and it is possible to rejoin the battle. However, if the host game terminal 100 moves to a range where it cannot communicate with the locator 200 in which the battle event occurs, it is compulsory even if the character operated by the guest has not left the battle. The battle participant has left the battle.

  In S612, the CPU 101 determines whether or not the experience time has expired. Specifically, the CPU 101 determines whether or not the experience time count started by a built-in timer (not shown) at the start of the experience is equal to or greater than the experience time set by the game user stored in the RAM 103. . If the experience time count is equal to or greater than the set experience time, the CPU 101 limits the number of remaining battle turns to a predetermined number in S613, returns the process to S606, and proceeds to the next battle turn.

  In addition, when the process reaches S612 in the subsequent turns, that is, when this step is reached in a state where the number of battle turns is limited, the number of battles is counted, and the count reaches the limited number of times In this case, the enemy character forcibly leaves the battle and the locator battle event process is terminated.

  Also, if it is determined in S612 that the experience time has not ended, the CPU 101 returns the process to S606 and proceeds to the next battle turn.

  If it is determined in S609 that the enemy character's physical strength is 0, in S614, the CPU 101 causes the GPU 104 to draw a display regarding the battle victory and display it on the display unit 105, and the locator battle event process ends. The display related to the battle victory includes, for example, a result display such as acquisition of an experience value or acquisition of an item.

  If it is determined that the physical strength of the character operated by the host is 0 in S610, the CPU 101 causes the GPU 104 to display a display regarding the defeat of the battle on the GPU 104 and display it on the display unit 105, and the locator battle event process ends. .

  If it is determined in S611 that the host has left the battle, in S616, the CPU 101 causes the GPU 104 to display a display related to the departure of the battle and display it on the display unit 105, and the locator battle event process ends. At this time, the CPU 101 sets the number of steps required until the next event occurs as a penalty for leaving the battle. That is, a game user who leaves the battle is not limited to the same event until he / she walks for the set number of steps, and a penalty is imposed so that at least one of the locator event and the step event described later does not occur. Shall be. Also, after the penalty is eliminated, even when the same locator 200 comes within the communicable range, the direction in which the enemy character that triggers the previous locator battle event is changed, and the game user again becomes the locator. It is set so that it is necessary to search for enemy characters in the position field.

  In the above description of the flowchart, only the processing in the game terminal 100 of the host game user has been described. In the process at the game terminal 100 of the guest game user, when a request to participate in the battle is received from the host game terminal 100, a screen for allowing the user to select whether or not the CPU 101 participates is displayed on the display unit 105. The number of processes to be increased increases, but the basic battle process flow and the difference in how the host and guest are handled are as described above.

  Further, during the battle, the game user can change the standing position of the character operated in the battle by jumping while holding the game terminal 100. That is, the operating character can go behind the enemy character, and the battle can be advanced. Further, it is assumed that the character being operated can be recovered and revived at a recovery point installed in the facility, for example, by placing a locator 200 near a pharmacy or fountain existing in the facility.

(Steps Battle Event)
Next, specific processing will be described with reference to the flowchart of FIG. 8 regarding the step count battle event processing of the game terminal 100 that occurs according to the number of steps the game user walks with the game terminal 100. The processing corresponding to the flowchart can be realized by the CPU 101 reading out a corresponding processing program stored in, for example, the ROM 102, developing it in the RAM 103, and executing it. In addition, this step number battle event process demonstrates as what is started at the time of experience start, for example. Also, in the step count battle event process, steps that perform the same process as the locator battle event process described above are denoted by the same reference numerals and description thereof is omitted, and description of steps characteristic to the step count battle event process is provided. Keep on.

  In step S <b> 801, the CPU 101 sets the number of steps until a step number battle event occurs. It is assumed that the number of steps until the step number battle event occurs is set randomly for each game terminal 100, for example. In the present embodiment, the number of steps until the step battle event occurs is described as a value that is different for each game terminal 100. However, the present invention is not limited to this, and a fixed value is assigned. Also good. In step S <b> 802, the CPU 101 causes the step sensor 106 to start measuring the number of steps of the game user.

  In step S803, the CPU 101 determines whether or not the number of steps of the game user started by the step number sensor 106 in step S802 exceeds the number of steps until the set step number battle event occurs. If the number of steps exceeds the set number of steps, the CPU 101 moves the process to S804, and if not, repeats the process of S803.

  In step S <b> 804, the CPU 101 determines whether the location where the game terminal 100 currently exists is a location that is predetermined as dangerous when a game event is generated. Specifically, the CPU 101 is dangerous when the wireless communication unit 111 receives a signal from the locator 200 and the identification information of the locator 200 included in the received signal causes a game event. It is determined whether or not the locator 200 is installed at a predetermined position. In the present embodiment, the locator 200 is placed at a location that is predetermined as dangerous when a game event occurs, and the identification number of the placed locator 200 is determined as dangerous when a game event is generated. And stored in the server 300 as the locator 200 existing at the location. Information indicating the role of the locator 200 stored in the server 300 may be stored as the above-described table in the RAM 103 of the game terminal 100 at the start of the experience, for example. If the place where the game terminal 100 currently exists is a place that is predetermined to generate a game event, the CPU 101 moves the process to S805, and if a game event is generated, the CPU 101 is dangerous. If it is not a predetermined place, the process moves to S601 to generate a step count battle event.

  In step S <b> 805, the CPU 101 causes the display unit 105 to display a display that prompts the game user to leave the current location as illustrated in FIG. 9, for example, without generating a step count battle event. The display prompting the user to leave the current location continues while receiving a signal from the locator 200 that exists in a location that is predetermined as dangerous when the wireless communication unit 111 generates a game event, for example. The CPU 101 may control the display so that no game event progresses during the display.

  CPU 101 does not receive a signal from locator 200 existing in a predetermined place as dangerous when wireless communication unit 111 generates a game event, that is, when game terminal 100 generates a game event, it is dangerous. If it is away from a predetermined location, the process returns to S801 to reset the number of steps until the step number battle event occurs. The number of steps reset at this time is different from the penalty at the time of leaving the battle described above, and is set to be less than the number of steps until a normally set step number battle event occurs, for example.

  In this embodiment, when a step battle event occurs, the host of the step battle event, that is, the game user having the game terminal 100 that has reached the number of steps until the step battle event occurs, Shall not be able to leave.

  In the present embodiment, it has been described that a guest can participate in a step count battle event occurring in the host game terminal 100, but the embodiment of the present invention is not limited thereto. As described above, since the timing at which the step battle event occurs is different for each game user, for example, the step battle event may occur at the game terminal 100 of a plurality of game users of the team at the same time. The guest may not participate. That is, according to the present invention, when a team experience is performed, a plurality of game users of a team need only share at least a locator event.

(Advice event)
Moreover, the game program of this embodiment is provided with various advice functions in addition to the display which avoids the game in the dangerous place mentioned above. For example, when the total number of steps of the step sensor 106 for a predetermined period is less than the predetermined number of steps, the CPU 101 displays a display for prompting the movement as shown in FIG. If the interval is less than or equal to a predetermined period, it may be determined that the game user is running and notify that it is dangerous. Further, since walking while browsing the display unit 105 of the game terminal 100 is dangerous, the CPU 101 warns that the screen is not browsed during walking, for example, as shown in FIG. Only the display may be displayed on the display unit 105.

(Locator management)
Since the game user gets bored when the locator where the event occurs is fixed, the server 300 can set whether or not the event occurs in the locator so that the repeater can be expected. Specifically, a table in which presence / absence of an event for each locator identification information as shown in FIG. 11 is set can be changed by the staff operating the server 300, for example, every day. The change method may be set by the clerk for each locator. For example, for the locator excluding the locator indicating the dangerous area, information indicating the occurrence of the locator event is randomly set by the server 300 program. Also good. The information in the event table indicating the relationship between the changed locators and the occurrence / non-occurrence of events in each locator may be transferred to the game terminal 100 and stored in the RAM 103 at the start of the experience. By doing in this way, a repeater can be increased, without getting tired of a game user.

  As described above, the game terminal according to the present embodiment is generated under random conditions in a place where it is determined that it is dangerous for the game user to concentrate on the game, that is, where the occurrence of the game event is to be controlled. To prevent the event to be forcibly generated. By doing in this way, the mobile experience type game system which a game user can enjoy safely can be provided.

  In the above-described embodiment, the game terminal is described as including the step number sensor and generating an event according to the number of steps of the game user. However, the embodiment of the present invention is not limited thereto. That is, according to the present invention, for an event that occurs when a predetermined condition is satisfied regardless of the position, an event is not generated regardless of the condition in a place where it is dangerous that the game user concentrates on the game. It is easy to understand that the purpose is to control the event and the event generation condition is not limited to the number of steps or time.

(Other embodiments)
The above processing (for example, the processing according to the flowcharts shown in FIGS. 4, 6, and 8 in the above embodiment) is stored as a computer program in a recording medium such as a CD-R, ROM, DVD-ROM, MO, etc. By causing the computer to read (install or copy) the program stored in the recording medium, the computer can function as a game device corresponding to the present invention. Therefore, it is obvious that such a computer program and a recording medium storing it are also within the scope of the present invention.

Claims (10)

A portable game terminal,
Control means;
Position detecting means for detecting the position of the game terminal;
First game event generating means for generating a first game event when a predetermined condition independent of the position of the game terminal is satisfied;
Storage means for storing information on a position where the occurrence of the game event should be controlled,
The control means is a case where the position of the game terminal detected by the position detection means is a position where the occurrence of a game event stored in the storage means is to be controlled, or when the predetermined condition is satisfied. However, the game terminal is controlled so that the first game event generation means does not generate the first game event. A display means,
When the position of the game terminal detected by the position detection means is a position to control the occurrence of a game event stored in the storage means, the control means leaves the display means from the current position. The game terminal according to claim 1, wherein a display prompting the user to make a prompt is displayed. The game user further comprises a measuring means for measuring the number of steps taken by carrying the game terminal,
2. The first game event generating means generates the first game event when the number of steps of the game user measured by the measuring means reaches a predetermined number of steps. Or the game terminal of 2. Receiving means for receiving a signal generated by the signal generator and including identification information of the signal generator;
Analyzing means for analyzing identification information of the signal generator from the signal received by the receiving means;
The storage means further stores a table in which identification information of each of the one or more signal generators arranged in the field is associated with information on a position where the one or more signal generators are arranged. Composed of
The position detection means corresponds to the identification information of the signal generation apparatus that has generated the signal analyzed by the analysis means and is included in the table when the reception means receives the signal. The game terminal according to claim 3, wherein the position of the game terminal is detected based on the position information of the game terminal. When the position of the game terminal detected by the position detecting means when the receiving means receives the signal is not a position to control the occurrence of the game event stored in the storage means, the second A second game event generating means for generating the game event of
The control means receives a signal received when the second game event is generated until a predetermined time elapses after the second game event is generated by the second game event generation means. 5. The second game event generating means is controlled so that the second game event is not generated even when a signal having the same identification information of the signal generating device is received. The described game terminal. When the receiving means is configured to receive a signal from the signal generator only when the game terminal is within the communication range of the signal generator,
The control means, if the receiving means becomes unable to receive the signal while the second game event is occurring, then at least one of the first and second game events. The game terminal according to claim 5, wherein a condition for the occurrence of one game event is newly set.   Next, the condition for the occurrence of at least one of the first and second game events is measured by the measuring unit after the receiving unit cannot receive the signal. The game terminal according to claim 6, wherein the game terminal is a step count. Wireless communication means for wirelessly communicating with another game terminal set in advance when the other game terminal is within a predetermined distance range,
The control means determines that the other game terminal exists within the predetermined distance range by the wireless communication means when at least one of the first and second game events occurs. The game terminal according to claim 5, wherein the game event is shared with the other game terminal by the wireless communication unit.   The program for functioning a computer as each means of the game terminal of any one of Claims 1 thru | or 8. A game system comprising one or more game terminals according to any one of claims 5 to 8, one or more signal generators arranged in a field, and a server,
The server
For each of the one or more signal generators arranged in the field, setting means for setting whether or not to generate a second game event in the game terminal;
Transfer means for transferring, to the game terminal, a table in which identification information of the one or more signal generators is associated with information on whether or not to generate the second game event set by the setting means. And comprising
In the game terminal,
The control means stores in the storage means a table transferred by the transfer means and indicating whether or not to generate the second game event.
When the second game event generating means receives the signal of the signal generating apparatus by the receiving means, the signal generating apparatus that has generated the signal analyzed by the analyzing means generates the second game event. A game system that generates the second game event when the second game event is associated with the signal generation device that generates the second game event.

Images