TWI863760B - Programs and gaming devices - Google Patents

Abstract

The purpose of the present invention is to provide a highly interesting game. The present invention is a program that enables a game device composed of a computer to execute a battle game. The program enables the computer to function as the following mechanisms: a game element registration mechanism that registers the game elements of the first player; a team setting mechanism that sets the first player and the second player as a team; a game execution mechanism that uses the registered game elements of the first player to execute the battle game between the first player and the opponent player; and a support execution mechanism that can execute the support of the second player's game elements for the battle game during the execution of the battle game between the first player and the opponent player, on the condition that the second player chooses to support the first player.

Description

Programs and gaming devices

The present invention relates to a program and a game device.

There are multiplayer games in which multiple players are matched with each other and played by multiple people. Most of these multiplayer games have pre-set mission contents, and the same players or players with high skills compete in missions repeatedly. Therefore, there are problems such as missing opportunities to communicate with non-specific multiple players, and players with low skills cannot participate in multiplayer games.

Therefore, a game system is proposed that can determine the content of a task based on information related to each matched player (e.g., Patent Document 1). [Prior Art Document] [Patent Document]

[Patent Document 1] Japanese Patent Gazette No. 2019-041919

[The problem the invention is trying to solve]

However, since the matched players jointly perform the mission, the skill of each player still affects the execution of the mission. Especially for beginners, they may miss the opportunity to participate in the game because they are hesitant about the content of their own competition and have a negative impact on other players. As a result, multiplayer games have become more difficult for players to enter, and there is a problem that the fun of the game is reduced.

Therefore, the present invention provides a program and a game device that provide a highly interesting game. [Technical means for solving the problem]

One aspect of the present invention is a program that enables a gaming device composed of a computer to execute a battle game, and enables the gaming device to function as the following mechanisms: a game element registration mechanism that registers the game elements of a first player; a team setting mechanism that sets the first player and a second player as a team; a game execution mechanism that uses the registered game elements of the first player to execute the battle game between the first player and the opposing player; and a support execution mechanism that can, during the execution of the battle game between the first player and the opposing player, execute the game elements of the second player to support the battle game on the condition that the second player chooses to support the first player.

One aspect of the present invention is a gaming device, which comprises: a gaming element registration mechanism for registering the gaming elements of the first player; a team setting mechanism for setting the first player and the second player as a team; a gaming execution mechanism for executing a battle game between the first player and the opposing player using the registered gaming elements of the first player; and a support execution mechanism for executing the game elements of the second player to support the battle game during the execution of the battle game between the first player and the opposing player, on the condition that the second player chooses to support the first player. [Effect of the invention]

According to the present invention, a highly interesting game can be provided.

The implementation form of the present invention is described.

<First Implementation Form> <Overall Configuration> FIG. 1 is a diagram showing the system configuration of the game system of this implementation form. As shown in FIG. 1, the game system is composed of one or more game devices 1 and a server 2. One or more game devices 1 and the server 2 can be connected to a communication line N and can communicate with each other. The communication line N means a communication path that can perform data communication. That is, in addition to a LAN (Local Area Network) such as a dedicated line (dedicated cable) or Ethernet (registered trademark) for direct connection, the communication line N also includes a telephone communication network or a cable network, the Internet, and the communication method is not limited to wired/wireless.

The game device 1 is a computer that can execute game programs, is connected to a communication line N via a wireless communication base station, etc., and can communicate data with a server 2. The game device 1 is, for example, a business game device (arcade game device), a smart phone, a portable phone, a portable game device, a fixed home game device, a personal computer, a tablet computer, a controller of a fixed home game device, etc.

There are basically a plurality of game devices 1, which are operated by each player. For example, a plurality of game devices 1 are installed in a store, and become the operation object of the player who comes to the store.

The server 2 is a server system composed of a single or multiple server devices or memory devices. The server 2 provides various services for operating the game of this embodiment, and can manage the data required for the operation of the game, publish the game program or data required to execute the game on the game device 1, etc. In addition, as described in detail later, when the server 2 identifies the player when using the game device 1, that is, when the service of the battle game is provided under the state of identifying which player it is, the server 2 updates the information managed for each player based on the usage content (game competition history). In addition, as described later, the server 2 pairs up the players and matches the paired players in order to achieve a battle with other players.

In this embodiment, by means of such a system configuration, a battle game between players using a plurality of game devices 1 can be realized via the server 2 and the communication line N, but it is not limited to a battle game between players (between people), and also includes a case where one of the players is a non-player character provided by the server 2. In addition, the game that provides a competitive experience in the game device 1 is not limited to a battle game between players, and can also include a game configured for one person.

In the embodiments described below, the present invention is applied to a gaming device that executes a battle game displayed on a screen with game elements arranged on a gaming field as an example of a gaming device. However, the present invention can also be applied to any machine that can execute a game displayed on a screen with game elements arranged on a gaming field.

<Overview of Game Elements and Battle Game> In order to facilitate understanding of the structure of the present embodiment below, the game elements used in the battle game of the present embodiment and the overview of the battle game are explained.

In the fighting game of this embodiment, multiple game elements appear. Game elements are characters (characters, vehicles, props, etc.), which are embodied as images, virtual or real objects, etc. Images include static images and dynamic images. In the fighting game of this embodiment, there are the first type of game elements and the second type of game elements.

First, the first type of game element of this embodiment is explained.

The first type of game element is to establish a correspondence with an item with a physical volume. An example of an item that exists in a physical form is a game card that is an item with a physical volume (real item). In addition, the item is not limited to a game card, as long as it is an item that constitutes a game element that can be specifically associated with an item. The item can be, for example, a doll or other shape that has the appearance of a game element.

In this embodiment, the plurality of items corresponding to the first type of game element are all tangible game cards, and are described as corresponding to one game element appearing in a battle game that provides a competitive experience in the game device 1. The game element to which the game card corresponds can be identified by obtaining identification information (element ID) for identifying the game element attached to the game card by the game element reading unit described later. Attaching identification information (element ID) to a game card can be achieved, for example, by printing a one-dimensional or multi-dimensional code obtained by converting identification information used for a specific game element onto the game card, or by other means such as recording it on a tag or IC (Integrated Circuit) chip for near field communication (NFC) contained in the game card.

In a battle game, each player can use multiple game elements. Before the game starts (before the actual operation of the game elements begins), information is obtained from the game card, and the game elements corresponding to the game card can be registered as game elements that appear in the game (used by the player).

In this embodiment, there are multiple first game elements that players can play in the game, but they are mainly two types: the first game element and the second game element. Furthermore, the first game element is the pilot, and the second game element is the vehicle operated by the pilot. Furthermore, each of the first game element and the second game element is divided into multiple types.

As the first game element, i.e., the type of pilot, there are, for example, attack type (first type) and defense type (second type). The attack type is a type that attacks the game elements of the opposing player as the main purpose, and attacks the game elements of the opposing player without protecting the other game elements of the player. The defense type is a type that attacks the game elements of the opposing player as the main purpose, in order to protect the other game elements of the player. In addition, the types and their numbers are just examples, and are not limited to such types and numbers. For example, there may be a plurality of types that can be set up that can attack only X types of game elements of the opposing player, and an attack type that can attack only Y types of game elements of the opposing player, so that the types of attack can be set according to the types of the game elements of the opposing player.

As the second game element, there are types of mounts, such as attack type (first type) and defense type (second type). The attack type is a type that attacks the game elements of the opposing player as the main purpose, and attacks the game elements of the opposing player without protecting the other game elements of the player. The defense type is a type that attacks the game elements of the opposing player as the main purpose, and attacks the game elements of the opposing player in order to protect the other game elements of the player. As more types, a range (attack) type (third type) corresponding to the range (attack) distance of the weapon that can be used by the mount can also be set. For example, the case where the usable weapon is a long-range weapon is a long-range type, and the case where the usable weapon is a close-range weapon is a close-range type, and so on. In addition, the types and quantities are just examples and are not limited to those types and quantities.

These categories do not necessarily correspond one-to-one between each game element and each category, but may also correspond one-to-many. For example, the second game element, namely the mount, may also have two types: a defense type and a long-range type. In order to protect the player's other game elements, the mount of this type may use a weapon with a longer range to attack the game elements that are far away from the opponent.

Furthermore, the first game element and the second game element have various parameters suitable for the type (level, health, attack power, defense power, terrain suitability, weapons used, etc.) in addition to the character information of the type or type of the first game element or the second game element. For example, if it is an attack type, it is a parameter dedicated to attack. These various parameters can also change as the battle game progresses.

Furthermore, in the first game element or the second game element, there is a special ability called a skill. The skill is an ability to develop in order to advance the game advantageously, and is an ability to strengthen the game element. For example, when a certain activation condition is met, it is an ability to increase the attack power of the game element against the opponent player for a specified period of time. The activation of skills may be automatically activated when the activation condition is met, or may be arbitrarily activated by the player's operation when the activation condition is met. In addition, there are skills that can only be activated once during a battle, or there are skills that can be activated multiple times. In addition, after activating the skill, even if the game element becomes unable to fight (destroyed) due to an attack from the opponent's game element, it can be returned (transformed) to a battle-able state by the passage of a specified time (transition time). In addition, there are cases where the transition time is longer than the transition time of a normal game element that does not activate a skill.

FIG. 2 is a diagram showing an example of a game card P1 in which the first game element is a pilot and its type has character information of an attack type. By reading the identification information recorded on the game card P1 by the game element reading unit, the game device 1 can obtain the character information or skill of the game card P1. FIG. 3 is a diagram showing an example of a game card M1 in which the second game element is a vehicle and its type is an attack type and has character information of breaking (attack when the locked enemy game group enters the attack range) as a skill. By reading the identification information recorded on the game card M1 by the game element reading unit, the game device 1 can obtain the character information or skill of the game card M1.

Furthermore, in the battle game of this embodiment, a game element called a game team (hereinafter referred to as a unit) appears. The game team is composed of the first game element, the pilot, and the second game element, the vehicle, and is composed of the combination of the two. That is, the player can associate the pilot as an element that moves the vehicle in the battle game and register it. In this way, the player can make a game team consisting of a vehicle and a pilot appear in the battle game.

The ability of a game set may be, for example, the sum of the role information (various parameters) of the pilot, which is the first game element constituting the game set, and the role information (various parameters) of the vehicle, which is the second game element. Furthermore, the game set has an action characteristic that specifies (or restricts actions) what actions can be taken in a battle of a battle game. The action characteristic of the game set is subordinate to (depends on) at least one of the first game element constituting the game set, namely, the type (type) of the pilot, or the second game element, namely, the type (type) of the vehicle.

When the action characteristics of the game team are made subject only to the first game element, that is, the type (type) of the pilot, the action characteristics that reflect the type of the pilot do not reflect the type (type) of the vehicle. For example, when the type of the pilot constituting the game team is a defense type and the type of the vehicle constituting the game team is an attack type, the action characteristics of the game team do not reflect the type of the vehicle, and the attack on the game element of the opposing player is limited to other game elements that protect the player. In addition, when the action characteristics of the game team are made subject only to the second game element, that is, the type (type) of the vehicle, the action characteristics that reflect the type of the vehicle do not reflect the type (type) of the pilot.

In this way, when the action characteristics of the game set are subordinate to only one of the game elements, the player needs to consider the types of pilots and mounts and select the pilots and mounts that constitute the game set. The reason is that since the ability of the game set is, for example, the total value of the character information of the game elements (pilots and mounts) that constitute the elements, if the type is selected incorrectly, the ability of the game set cannot be brought into play. On the other hand, when the types of the game elements (pilots and mounts) that constitute the elements are appropriately and correctly selected, for example, when the type of the pilot and the type of the mount are the same defense type, the ability consistent with the action characteristics of the game set can be brought into play.

On the other hand, when the action characteristics of the game team are made subordinate (dependent) to both the first game element, the type (type) of the pilot and the second game element, the type (type) of the vehicle, which are the constituent elements, this is effective when the first game element, the type (type) of the pilot and the second game element, the type (type) of the vehicle are completely different. For example, there are attack types and defense types for the first game element, the type of the pilot, and the second game element, the type of the vehicle, is a range (attack) type. In this case, the action characteristics of the game set of a combination of a defense-type pilot and a long-range-type vehicle become the action characteristics of a game element that uses a weapon with a long range (attack distance) to attack a distant opponent player in order to defend against other game elements of the player. In this way, a game with high strategic value can be provided to the player.

Furthermore, as the ability of the game set, the skills possessed by the first game element or the second game element may be added. For example, when the vehicle of the second game element has a skill, the game set that sets the vehicle of the second game element as a component element may have the skills of the vehicle of the second game element. For example, the game set that sets the game card P1 (pilot) of FIG. 2 and the game card M1 (vehicle) of FIG. 3 as a component element may have the skills of the game card M1 (vehicle).

Next, the second game element is explained.

The difference between the second type of game elements and the first type of game elements is that the second type of game elements do not correspond to physical objects such as game cards. The second type of game elements are game elements that can appear in the game through rewards obtained by completing game events, exchange with in-game currency, etc. However, like the first type of game elements, it does not exclude those that correspond to physical objects such as game cards.

The second game element includes the first game element and the second game element. In this embodiment, the first game element is a battleship, and the second game element is the captain of the battleship. Hereinafter, the combination of the battleship of the first game element and the captain of the second game element is described as a battleship set. In addition, in this embodiment, only the combination of the battleship and the captain of the battleship set is allowed, and it is not possible to select only the battleship or only the captain. However, it does not exclude the possibility of changing the combination.

The first game element, namely, battleships, has various parameters (attack power, defense power, etc.). And, they become the target of attack by the game team of the opposing player. Moreover, the parameters of attack power, defense power, etc. of any battleship in multiple battleship teams are the same, and even if the battleships in the initial battleship team are changed to other battleship teams, the attack power and defense power will not change. However, it does not exclude the possibility of changing the parameters of attack power and defense power in specific events, etc.

Furthermore, the battleship of the first game element has a support capability of assisting a co-player in a battle game in response to a co-player request from the co-player described below. The support capability varies depending on the type of battleship.

On the other hand, the second game element, the ship captain, provides players with advice information in various screens of the game (attack screen or battle screen). However, the advice information is just a display suggestion and does not provide strategic information that is beneficial to the battle.

Furthermore, the second game element is provided to the player as a combination (battleship set) of the first game element (battleship) and the second game element (captain), and the first game element and the second game element are not provided separately, and the first game element (battleship) and the second game element (captain) cannot be freely combined.

Furthermore, the difference between the first type of game elements and the second type of game elements also lies in whether they are the objects of operation in the game. As mentioned above, the game set consisting of the first type of game elements or a plurality of the first type of game elements becomes the object of operation of the player in the game. A representative example of the object of operation is the object of movement. In contrast, the second type of game elements (battleships, captains) are not the objects of movement of the player.

Next, we will explain the outline of the battle game.

The battle game of this implementation form has a normal battle mode in which players fight against each other individually, and a co-battle battle mode in which two or more players form a team and the team fights against each other. The co-battle battle mode is a battle mode in which a team is formed with players other than friends, and in a two-way battle game, the team can receive support (support) from battleships set by other players in the team. The co-battle battle mode of this implementation form sets the number of people constituting a team to two, records the team of two people as a co-battle pair, and records the player who forms a co-battle pair with the player as a co-battle player. However, the number of people in a team is not limited to two, and can be three or more.

The battle game includes the first stage and the second stage. The first stage is the battleship setting stage, which is the stage of setting the battleships (the second game element) used in the battle game. The second stage is the stage of registering various game cards (the first game element), generating game sets, and using these game sets to fight.

The battle (Phase 2) of this implementation form is carried out by deploying (deploying) the game groups (troops) registered by each player on a game field of a specified size while performing movement/attack actions (the implementation of these actions is accepted by the operation input unit described later).

FIG. 4 is a diagram showing an example of a game field in a battle game of the present embodiment. In one embodiment shown below, the game field includes an attacking game group area 30, a first area 31, and a second area 32. The attacking game group area 30 is configured with game groups that can attack (appear). The first area 31 is the area of the player, and is configured with bases (game elements) such as the player's base. The battleships set in the first stage are also configured in the first area 31. The second area 32 is the area of the opposing player, and is configured with bases (game elements) such as the opposing player. The battleships of the opposing player set in the first stage are also configured in the second area 32. In addition, it should be noted that the battleships of the player and the opposing player are automatically configured at designated positions and are not the points of the player's movement. Furthermore, as a result of an attack action by any one of the game teams, the player who destroys (makes the durability value 0) the base of the opponent player becomes the winner of the battle game.

Therefore, for the game team of the opposing player that wants to attack the base established by itself, each player needs to configure the game team and perform counter-action (defensive action) in order to prevent the attack, or needs to control the attack of the game team in order to destroy the base of the opposing player faster than the game team of the opposing player.

Here, it is important to note that the movable area differs depending on the type of the game group. For example, when the type of the game group is a defense type, since the game group is a game group for defending a base or other base of the player, and the base or other base of the player is arranged in the first area 31, the defense type game group can only move within the first area 31. On the other hand, when the type of the game group is an attack type, the game group is a game group that attacks the base of the opponent player or the base of the opponent player's battleship, etc., which comes to attack the base of the own player. Since the base of the opponent player is arranged in the second area 32, and the base of the opponent player's battleship, etc. can invade (can be arranged in) the first area 31, as a result, the attack type game group can move between both the first area 31 and the second area 32.

At the start of the battle game, the information of the game team registered by the opposing player is not yet known. The player can deploy each of the game teams registered by himself on the game field at any time after the battle game starts. When the opposing player deploys the game team on the game field, the game team is informed of what kind of game elements (mounts and pilots) the game team is composed of. By configuring in this way, the player can understand the game team or actions of the opposing player and develop the game strategically.

Furthermore, in the co-fighting battle mode, a player can issue a co-fighting request to a co-fighting player in a battle. The co-fighting request can be made by selecting the co-fighting request button 34 displayed on the game field. When the co-fighting request is selected, one of the support capabilities of the battleship set by the co-fighting player is activated to attack the fighting player (attack support) or to provide supply support to the player. The co-fighting request can only be executed a specified number of times in the battle game. For example, once or twice. The reason is that if the co-fighting request can be made multiple times, the game balance will be lost.

<Structure of the game device 1> Figure 5 is a front view of the game device 1 of the embodiment of the present invention.

The game device 1 comprises: a display unit 11 (display 11), which displays information or a game field etc. required for progressing in the game such as a menu; a first game element reading unit 121-125, which is used to register a first game element (pilot) that appears in the battle game from a game card held by a player; and a second game element reading unit 131-135, which is used to register a second game element (vehicle) that appears in the battle game from a game card held by a player.

The first game element reading units 121-125 are readers for reading the role information of the first game element, i.e., the pilot, that appears in the game from the game card. Since the game device 1 of this embodiment can register a maximum of (up to) 5 pilots as game elements, five first game element reading units 121-125 are provided. The first game element reading units 121-125 can read the identification information of the game card of the pilot (first game element) by setting (arranging) the game card P of the pilot (first game element) that appears in the battle game from the game card held by the player, etc.

The second game element reading units 131-135 are readers for reading the character information of the second game element, i.e., the vehicle, that appears in the game from the game card. The game device 1 of this embodiment is provided with five second game element reading units 131-135 because a maximum (upper limit) of five vehicles can be registered as game elements. The player sets (configures) the game card of the vehicle (second game element) that appears in the battle game on the second game element reading units 131-135 using the game card he holds, so that the second game element reading units 131-135 can read the identification information of the game card of the vehicle (second game element).

Furthermore, you can start the battle game by forming up to 5 teams, using the game element of a game team (troop), which is a team consisting of one registered pilot and one registered vehicle. That is, regarding the game team (troop), the maximum number of registered vehicles is the same as the maximum number of registered pilots (upper limit), which is set to 5.

In addition, for example, when the player has just started using the game device 1 or when the player does not bring a game card, the number of game cards that can obtain information does not meet the maximum number (upper limit) of each of the mounts or pilots, and the game elements that constitute the game team (troop) are not necessarily registered based on the information obtained from the game card. In this case, the prepared game elements are additionally registered on the game device 1 side, and the maximum number of mounts and pilots are registered to form 5 teams. In addition, in an embodiment in which the concept of cost is introduced at the time of registration, the number of game teams (troops) to be registered can also be set to a plurality less than the maximum number.

In addition, in this embodiment, although one pilot is associated with one vehicle and registered as one game set, the implementation of the present invention is not limited to this. That is, the game elements constituting one game set may also be to associate multiple pilots with one vehicle, or to associate one pilot with multiple vehicles.

FIG. 6 is a block diagram showing the functional structure of the gaming device 1 according to an embodiment of the present invention.

The game device 1 includes a processing unit 10, a display unit 11, a first game element reading unit 121-125, a second game element reading unit 131-135, an operation input unit 14, a price detection unit 15, a user information reading unit 16, a sound output unit 17, a communication unit 18 and a storage unit 19.

The processing unit 10 controls the operation of the game device 1 based on the program or data stored in the memory unit 19, the operation input signal from the first game element reading unit 12, the second game element reading unit 13, and the operation input unit 14. The functions of the processing unit 10 can be realized by electronic components such as a microprocessor such as a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit), an ASIC (Application Specific Integrated Circuit), and an IC memory. Specifically, the control unit 10 controls the operation of each unit by reading the operation program of each unit recorded in the recording unit 19, developing it in the memory, and executing it. The processing unit 10 includes, as main functional units, a game element acquisition unit 110, a game configuration unit 111, a game execution unit 112, a battleship setting unit 113, a co-op pair setting unit 114, and a co-op request execution unit 115. These units will be described later.

The display unit 11 displays various game screens based on the image signal output from the processing unit 10. The function of the display unit 11 can be realized by a display device such as a flat panel display such as a liquid crystal, a projector, a head-mounted display, etc. In FIG. 5 , the display unit 11 is equivalent to the display 11.

As described above, the first game element reading units 121 to 125 are the upper limit of the number of first game element registrations, i.e., five first game element reading units, and are readers for reading the first game element, i.e., the role information of the pilot, that appears in the game from the game card held by the player. The first game element can be read from the game card, for example, by printing a one-dimensional or multi-dimensional code obtained by converting the identification information of the game card, etc., on the game card, etc., and reading the one-dimensional or multi-dimensional code. In addition, when the identification information of the game card, etc. is recorded on a tag or IC chip for near field communication (NFC) contained in the game card, it can be read from the tag or IC chip. The read information is output to the processing unit 10 together with the identification information of the device, namely, the reading unit ID (for example, reading unit ID=121, etc.).

As described above, the second game element reading units 131 to 135 are the second game element reading units with the upper limit of the number of second game element registrations, i.e., five, and are readers for reading the character information of the second game element, i.e., the board, that appears in the game from the game card held by the player. The second game element can be read from the game card, for example, by printing a one-dimensional or multi-dimensional code obtained by converting the identification information of the game card, etc., on the game card, etc., and reading the one-dimensional or multi-dimensional code. In addition, when the identification information of the game card, etc. is recorded on a tag or IC chip for near field communication (NFC) contained in the game card, it can be read from the tag or IC chip. The read information is output to the processing unit 10 together with the identification information of the device, namely, the reading unit ID (for example, reading unit ID=131, etc.).

The first game elements read by the first game element reading units 121-125 and the second game elements read by the second game element reading units 131-135 constitute a game set. As described above, one game set is a combination of one first game element, i.e., a pilot, and one second game element, i.e., a vehicle. Therefore, in order to make it easy for the player to recognize the combination of the first game element, i.e., the pilot, and the second game element, i.e., the vehicle constituting the game set, the first game element reading units 121-125 and the second game element reading units 131-135 are arranged so that one side of the first game element reading units 121-125 and one side of the second game element reading units 131-135 constituting the set are at least adjacent to each other. For example, the lower side of the first game element reading unit 121 and the upper side of the second game element reading unit 131 are arranged adjacent to each other to form a set. In this way, the player can easily understand that the pilot of the game card read by the first game element reading unit 121 and the vehicle of the game card read by the second game element reading unit 131 are a set, which constitutes a game set. The same applies to the combination of the other first game element reading units 122 to 125 and the second game element reading units 132 to 135.

The operation input unit 14 is used for the player to input various operations related to the game, and outputs the operation input signal corresponding to the operation input to the processing unit 10. The function of the operation input unit 14 can be realized by a touch panel, a touch operation pad, a home button, a button switch, or a joystick, a trackball, etc., which are directly operated by the player with a finger, or by an acceleration sensor, an angular velocity sensor, a tilt sensor, a geomagnetic sensor, etc., which detects movement or posture. In this embodiment, the touch operation panel added to the display unit 11 is equivalent to this.

The price detection unit 15 detects the payment of the price in the game device 1. The payment of the price can also be determined by, for example, inserting a coin of a specified amount or an equivalent game coin into an unillustrated slot of the game device 1, or detecting the completion of the settlement process based on the communication with the chip of the specified electronic currency. The game device 1 of this embodiment is explained by starting to provide a service including a series of game competition experiences based on the payment of the price at the start of service provision. In addition, the payment of the price can also be detected after the start of service provision.

The user information reading unit 16 acquires information from an item having a player ID (player identification information) recorded thereon in order to identify the player using the game device 1. In the present embodiment, the item having the player ID recorded thereon is a player card in the form of a card.

The sound output unit 17 is a speaker or the like that outputs sound effects related to the game based on the sound signal output from the processing unit 10 .

The communication unit 18 is a communication interface with an external device. The communication unit 18 is connected to an external device via a communication line N (not limited to wired/wireless) and can send and receive data. The communication unit 18 converts information input as a transmission target into data in a specified format and sends it to an external device such as the server 2 via the communication line N. In addition, the communication unit 18 receives information from an external device via, for example, the communication line N.

The recording medium 19 is a recording device capable of storing data, such as a non-volatile memory or a HDD (Hard Disc Drive). The recording medium 19 stores not only the operation programs of each part of the game device 1, but also the information of the parameters required for the operation of each part, or various graphic data used in the fighting game executed by the game device 1.

In addition, a game element database 190 (game element DB 190) is stored in the recording medium 19. The game element DB 190 is a database that manages information (element information) of each game element that appears in the game. In the game device 1 of this embodiment, when playing the game, the player places the game card in the first game element reading unit 121-125 and the second game element reading unit 132-135 and obtains information, thereby making the game element corresponding to the game card appear in the game. The element information for managing one game element, for example, as shown in FIG. 7, includes category information 192 which is associated with an element ID (identification information) 191 which uniquely identifies the game element and indicates the category (type) in the game to which the game element is assigned, description information 193 which includes graphic data that can be used to generate a screen when the game element appears in the game, parameter information (role information) 194 which describes parameters determined for each element level of the game element in addition to the name and attributes of the game element, and skill information 195 which describes activation conditions and activation effects. The parameter information 194 and the skill information 195 are information for reference in the game in which the game element appears, and are related to the progress control of the game.

In addition, in this embodiment, although the game element DB 190 stores graphic data, parameter information, skill information, etc., and the element information includes these data, the implementation of the present invention is not limited to this. The element information may also include information indicating the storage location of the data of each information.

Next, the main functional units of the processing unit 10, namely, the game element acquisition unit 110, the game composition unit 111, the game execution unit 112, the battleship setting unit 113, the joint battle pair setting unit 114 and the joint battle request execution unit 115 are explained.

The game element acquisition unit 110 acquires the element ID 191 of the game card read by the first game element reading units 121 to 125 and the second game element reading units 131 to 135. At this time, the reading unit IDs of the first game element reading units 121 to 125 and the second game element reading units 131 to 135 that identify the element ID 191 of the read game card are also acquired (hereinafter, the reading unit IDs of the first game element reading units 121 to 125 are set as 121 to 125, and the reading unit IDs of the second game element reading units 131 to 135 are set as 131 to 135 for explanation). The game element acquisition unit 110 acquires the type information 192, the drawing information 193, the parameter information 194, and the skill information 195 associated with the element ID 191 of the acquired game card from the game element DB 190. The game element acquisition unit 110 associates the reading unit ID with the game element ID 191, the type information 192, the drawing information 193, the parameter information 194, and the skill information 195, and outputs them to the game configuration unit 111 and the game execution unit 112. In addition, the first game element reading units 121 to 125 and the game element acquisition unit 110 function as a first game element registration mechanism. Furthermore, the second game element reading units 131 to 135 and the game element acquiring unit 110 function as a second game element registration means.

The game set configuration unit 111 receives the reading unit ID, the element ID 191, the type information 192, the description information 193 and the parameter information 194 from the game element acquisition unit 110, and configures a game set (unit) from the first game element, i.e., the pilot, and the second game element, i.e., the vehicle. The game set configuration unit 111 identifies the first game element and the second game element that form a group from the reading unit ID. In this embodiment, a combination of the reading unit IDs (reading unit ID: 121, reading unit ID: 131), (reading unit ID: 122, reading unit ID: 132), (reading unit ID: 123, reading unit ID: 133), (reading unit ID: 124, reading unit ID: 134), and (reading unit ID: 125, reading unit ID: 135) corresponds to a game element constituting one game set. The game set component 111 specifies the first game element and the second game element constituting the set by specifying the element ID 191 associated with the reading unit ID of each set. The game set configuration unit 111 uses the type information 192, the description information 193, the parameter information 194, and the skill information 195 associated with the element ID 191 to configure the game set. The ability of the game set is, for example, the total value of the role information (various parameters) of the pilot, which is the first game element constituting the game set, and the role information (various parameters) of the vehicle, which is the second game element. Furthermore, the ability of the game set may also reflect other information associated with the player ID read from the player card by the user information reading unit 16, such as the player's level, the modified parameters of each game element, etc. There is a case where the parameters reflected by the game set are recorded as initial parameters. Furthermore, the action characteristics of the game set are subordinate to (dependent on) at least one of the first game element, i.e., the type (type) of the pilot, or the second game element, i.e., the type (type) of the vehicle.

Furthermore, the game set configuration unit 111 can add the skills of the first game element or the second game element as the ability of the game set. For example, when the vehicle of the second game element has a skill, the game set having the vehicle of the second game element as a configuration element can have the skill of the vehicle of the second game element.

The game execution unit 112 controls a series of games from the start to the end of the battle game (including the display of game images). When the price detection unit 15 detects the payment of the price, the battle game starts. The battle of the battle game is arranged on the game field by the game team (troops) formed by the game team composition unit 111 and the set battleships (the first game element of the second game element). In addition, the game execution unit 112 controls the progress of the battle according to the player's operation input on the game team (troops). In addition, the game execution unit 112 uses various parameters of each game team and battleship to calculate the attack and defense during the battle, and determines the battle-ready state and the battleship state of the game team and battleship. In addition, the game management unit 112 also displays various display images that can identify the game team's battle-ready state and battle-incapable state, or the activation of skills and other states.

The battleship setting unit 113 is a unit for setting/managing the player's battleship using the battleship information database 200 storing information related to the battleships that can be set. The battleship information database 200 is stored in the recording medium 19. The battleship information database 200 is prepared for each combination (combination) of a battleship and a captain and for each battleship group identification information (battleship group ID). FIG. 8 is a diagram showing an example of the battleship information database 200 of battleship group ID1. In the example of FIG8 , the battleship information database 200 of battleship group ID1 includes battleship identification information (battleship ID) 201 for identifying a battleship, the battleship name 202, captain identification information (captain ID) 203 for identifying the captain, the captain name 204, battleship image data 205, captain image data 206, battleship attack parameters 207, battleship defense parameters 208, and support capability information 209. Hereinafter, each information of the battleship information database 200 is collectively referred to as battleship information. The support capability information 209 is information on the content of support for the co-player when a co-player request is received from the co-player. The support content varies depending on the type of battleship. For example, as shown in FIG8 , it includes bombardment support from the battleship to the base of the co-player's battle game, supply support to the co-player, attack support from the game team of the player who is requested to fight, etc. In addition, in the case of being requested to fight, the support capability information 209 also includes the probability of drawing a lottery for which type of support is to be provided.

The battleship and captain combinations can be obtained through rewards obtained by completing game events, exchange with in-game currency, etc. The obtained battleship and captain combinations are associated with the player ID of the player database 210 described later and stored in the reward information 215.

The battleship setting unit 113 sets the player's battleship in the battleship setting screen of the first stage which is different from the battle stage. The battleship that the player can set is a battleship and captain combination registered in the reward information 215 in association with the player ID. The battleship setting unit 113 reads the battleship information of the battleship and captain combination registered in the reward information 215 from the battleship information database 200, and displays the battleship setting screen. FIG. 9 is a diagram showing an example of the battleship setting screen. In the battleship setting screen of FIG. 9, battleship combination 1 of battleship A and captain X and battleship combination 2 of battleship B and captain Y are displayed. The player can set the selected battleship set by selecting the battleship set to be set. The set battleship set is recorded in the ownership information 213 of the player database 210 described later.

The fighting pair setting unit 114 matches the fighting players to set the fighting pairs. The following methods are available for setting the fighting pairs.

(1) Setting a fighting pair between players using game devices 1 installed in the same store (in-store fighting pair setting). In the case of forming a fighting pair with friends, it is believed that in most cases, the game is played using the game device 1 installed in the same store. Therefore, the game devices 1 installed in the same store are matched with each other to set a fighting pair. Specifically, the players who want to form a fighting pair press the fighting pair setting button at the same time, and the server 2 detects the timing, and the game device 1 of the fighting player is specified to set the fighting pair. The specific operation will be described later.

(2) Set the player and the non-player characters prepared on the game device 1 or the game server 2 as a fighting pair (non-player character fighting pair setting). If you can request a fight when you are playing alone without friends, you can enjoy the game more. In this case, you can set a fighting pair with the non-player characters prepared on the game device 1 or the game server 2. Specifically, select the button to fight with non-player characters, and set the non-player characters prepared on the game device 1 or the game server 2 and the player as a fighting pair. The specific operation will be described later.

In addition, for the setting of the fighting pair described later, the fighting pair setting unit 114 stores the game device identification information that uniquely identifies the game device 1. Fig. 10 is a diagram showing an example of the game device identification information. The game device identification information of Fig. 10 is composed of 6 digits, the upper 3 digits are the values for identifying the store, and the lower 3 digits are the values for identifying the game device 1 of the store.

The co-fighting request execution unit 115 activates a support type from the support types of the battleships set by the co-fighting player when the player selects a co-fighting request in the battle game. The information of the battleships set by the co-fighting player is specified based on the battleship group ID included in the co-fighting player information sent from the server 2. The co-fighting request execution unit 115 reads the probability of the support type corresponding to the battleship group ID set by the co-fighting player from the battleship information database 200, and determines the support type based on the probability. Furthermore, the co-fighting request execution unit 115 activates the effect of the determined support type.

Next, the server 2 of this embodiment will be described. Fig. 11 is a block diagram showing the functional structure of the server 2 of the embodiment of the present invention. The server 2 includes a processing unit 20, a memory unit 21 and a communication unit 22.

The processing unit 20 is, for example, a CPU, and controls the operation of each block of the server 2. Specifically, the processing unit 20 reads the operation program of each block recorded in the recording unit 21, expands and executes it in the memory, thereby controlling the operation of each block. The processing unit 20 has a co-op pair matching processing unit 201, a battle player matching processing unit 202, and a management unit 203 as a main functional unit.

The fighting pair matching processing unit 201 matches players into fighting pairs. The matched fighting pairs are real players or real players and non-player characters. The fighting pair matching processing unit 201 has a game device identification information database 300 for matching fighting pairs. The game device identification information database 300 is a database that stores game device identification information of game devices 1 that are installed in stores and can be operated. Figure 12 is a diagram showing an example of the game device identification information database 300. In addition, the game device identification information database 300 can be prepared for each store, or it can be a database that lists all. The specific actions of the fighting pair matching processing unit 201 will be described later.

In addition, in case of selecting a non-player character as a combatant, the combatant matching processing unit 201 pre-sets the non-player character as a combatant, the battleship group of the non-player character, and the battleship information of the battleship group. In addition, there may be plural non-player characters as a combatant. In this case, the battleship group corresponding to each non-player character and the battleship information of the battleship group are pre-set.

The player matching processing unit 202 performs matching processing for the player-to-player game (player-to-player game) provided in the game system of this embodiment. Through the matching processing, a dialogue is set for two game devices 1 connected to the server 2, for example, which send matching requests at the same time, and the game devices 1 are changed to a state where information communication for the game can be performed.

Although the matching of the fighting players in the co-fighting mode of the fighting player matching processing unit 202 is performed, the matching is performed between the players who have selected the co-fighting mode. The reason is that when a fighting player is not in the co-fighting mode, he cannot receive support such as attacking, which damages fairness. Moreover, for each co-fighting player, it is matched with a fighting player corresponding to the level (ranking) of the player. FIG. 13 is a diagram showing an example of the matching of fighting players. In the example of FIG. 13, player A and player B are in a co-fighting pair relationship, player C and player E are in a co-fighting pair relationship, and player D and player F are in a co-fighting pair relationship. Here, the level difference between player A and player C is matched within the specified range, and the level difference between player B and player D is matched within the specified range. At this time, please note that the players of player A and player B in the co-op are not the same players. For example, the players of player A and player B are not all player C. In addition, the players matched do not need to be players in the same store as the co-op as in the co-op.

Furthermore, when the battle player matching processing unit 202 cannot match an actual player that meets the above conditions, it can also replace the actual player and match it with a non-player character that meets the conditions.

Furthermore, when the level of any player in the fighting pair is lower than the designated level, the fighting player matching processing unit 202 matches the player lower than the designated level with a non-player character. For example, the designated level is lower and the player lower than the designated level is a beginner. In this way, fighting players of a level suitable for beginners can be matched, and beginners can participate in a relaxed and happy mood. On the other hand, when the players of both parties of the fighting pair exceed the designated level, the fighting player matching processing unit 202 matches the players of both parties with actual players. The reason is that the players who exceed the designated level are experienced.

The management unit 203 manages the evaluation of the players of the game based on the competition content of the game performed in the game device 1. More specifically, the management unit 203 evaluates the players based on the competition content for each battle game competition, and generates or updates the evaluation information of the player information of the player described later.

The recording unit 21 is a recording device capable of storing data, such as a non-volatile memory or HDD. The recording unit 21 not only stores the operation programs of each block of the server 2, but also stores information such as parameters required for the operation of each block. The recording unit 21 also stores a player database 210 (player DB 210).

The player DB 210 is a database that manages information (player information) indicating the usage status of the game corresponding to each user (player) for the game provided by the game device 1 in the game system of this embodiment. The player information is used to manage the usage history of the game competition function of each player, or the information of various game elements that the player can use. The player information is updated in sequence according to the competition results of the game played after the player card is used in the game device 1, and is provided to the game device 1 when the player card is used again. In this way, the game competition in the state reflecting the previous game competition can be provided in the game device 1.

In this embodiment, the player information is associated with a player ID 211 for identifying the player, as shown in FIG. 14 , and includes progress information 212 indicating the progress of the player's game skills, possession information 213 indicating the game elements that the player can use in the game, enhancement information 214 indicating the enhancement status of each usable game element, and reward information 215 indicating the reward given to the player (which may also be other types of game elements).

Here, the progress status information 212 includes not only the progress information indicating the stage of the designated story, the performance information indicating the performance of the battle game, but also the evaluation information evaluating the player's competitive status. The possessed information 213 is constituted by sequentially adding the game elements corresponding to the game cards used by the player when playing the game, that is, the element ID 191 of the game elements that are in a state that the player can use. In addition, the possessed information 213 also records the battleship set ID of the battleship set set by the player. The enhanced status information 214 is constituted by establishing an association with the element ID 191 of at least the game element that has been enhanced (changed from the initial state), and managing the element level as an indicator of the parameter changed by the enhancement. In this embodiment, the enhanced status information 214 is explained as updating the content when the competition result of the game played in the game device 1 can be obtained for easy understanding of the invention, but it can also be updated based on information such as the result of the cultivation function using the cultivation function in the game device 1. The reward information 215 includes information such as the battleship set ID of the battleship set obtained in the event in the game.

The communication unit 22 is a communication interface with an external device. The communication unit 22 is connected to an external device via a communication line N (not limited to wired/wireless) to transmit and receive data. The communication unit 22 converts information input as a transmission target into data in a specified format and transmits it to an external device such as the game device 1 via the communication line N. In addition, the communication unit 22 receives information from an external device via, for example, the communication line N.

<Operation of Game Device 1 and Server 2> The operation of game device 1 is described. Figure 15 is a flowchart of the operation of game device 1. In addition, in the following description, the maximum number of cards that can be registered in the battle game (upper limit) and the number of pilot cards (first game element) and vehicle cards (second game element) are all set to 5.

At the beginning of the battle game, the player inserts a designated amount of hard goods or equivalent game coins as the price for executing the battle game service into the input port of the game device 1. When the price detection unit 15 detects the price (Step 100), the game execution unit 112 starts executing the battle game service (Step 101).

The player causes the user information reading unit 16 to read the player card (step 102). The user information reading unit 16 reads the player ID 211 from the player card and sends the player ID 211 to the server 2, and receives the progress information 212, the possession information 213, the enhancement information 214, the reward information 215, etc. associated with the player ID 311 from the server 2. Such information is transferred to the processing unit 10.

Next, the game execution unit 112 determines whether the player selects the battleship setting screen (step 103). When the battleship setting screen is selected (step 104), the battleship setting unit 113 starts the battleship setting process (step 105).

FIG. 16 is a flow chart of the battleship setting process.

The battleship setting unit 113 uses the battleship set ID obtained by the player from the reward information 215 of the player database 210 of the player to read the battleship information of the battleship set that the player can set from the battleship information database (step 200), and displays the battleship setting screen showing the battleship set that the player can set (step 201). The battleship setting screen is shown in FIG. 9, for example. At this time, if there is a battleship set that has been set from the owned information 213 of the player database 210 of the player, the battleship set is displayed.

The battleship setting unit 113 determines whether the battleship set by the player (set battleship) has been changed, and selects a new battleship to be set (step 202). When there is a change in the set battleship (step 203), the battleship setting unit 113 registers the selected battleship as the set battleship in the player database 210 of the player's ownership information 213 (step 204).

Return to the description of the flow chart of Figure 15.

The game execution unit 112 displays a battle mode selection screen and determines the battle mode (step 106). When the player selects the co-op battle mode (in-store co-op pair setting and non-player character co-op pair setting) (step 107), the co-op pair setting unit 114 executes the co-op pair setting process (step 108).

FIG. 17 is a diagram for explaining a series of actions for selecting a battle mode. In the example of the selection screen of FIG. 17 , as battle modes, normal battle mode and co-battle mode can be selected and buttons are displayed ( FIG. 17 (a) ). Furthermore, when the player selects the co-battle mode, buttons are displayed for selecting in-store co-battle pair settings and non-player character co-battle pair settings ( FIG. 17 (b) ).

FIG18 is a flowchart of the co-op pair setting process.

The fighting pair setting unit 114 determines the selection of the fighting mode (step 300). When the in-store fighting pair is selected (step 301), the fighting pair setting unit 114 displays the search start screen (step 302). Figure 17 (c) is an example of the search start screen. When the players in the store form a fighting pair, the players press the search start button at the same time. On the other hand, when a non-player character has been selected as a fighting pair, a matching request for the fighting pair is made to the server 2 (step 309). The matching request includes the game device identification information (game device ID) and the player ID obtained from the player card.

The co-op pair setting unit 114 determines whether the search start button is pressed (step 303). When the search start button is pressed (step 304), the co-op pair setting unit 114 sends a co-op pair matching request to the server 2 (step 305). The matching request includes the game device identification information (game device ID), the player ID obtained from the player card, and the time information when the button is pressed.

Here, the description is given of the co-op pair matching process performed by the server 2. FIG. 19 is a timing chart between the game device 1 and the server 2.

First, when the players in the store who want to form a fighting team press the search start button at the same time, the game device 1 of each player sends a matching request (steps 400, 401). The matching request includes the game device identification information (game device ID), the player ID obtained from the player card, and the time information when the button is pressed.

The server 2 that receives the matching request performs a matching process (step 402).

FIG. 20 is a flow chart of the collaborative pair matching process performed by server 2.

The co-op pair matching processing unit 201 of the server 2 receives the matching request (step 500).

The co-op pair matching processing unit 201 identifies the store value from the game device ID included in the matching request, and identifies the matching request sent from the game device 1 installed in the same store (step 501). When there is a matching request sent from the game device 1 installed in the same store (step 502), the co-op pair matching processing unit 201 determines the difference in the time information of the matching requests (step 503). When there is a pair of matching requests whose time information of the matching requests differs within a specified time (for example, within 1 second) (step 504), the co-op pair matching processing unit 201 specifies the player ID of the game device 1 that sent the matching request, and sets the players of the player ID as a co-op pair (step 505). Furthermore, the co-op match processing unit 201 sends co-op player information to the game device 1 that has made a match request (step 506). The co-op player information includes the player name that can be obtained from the player database 210 of the player and is identified from the player ID, and the battleship group ID set by the player.

On the other hand, when there is only one match request from the game device 1 installed in the same store (step 502), or when the match request is from the same store but the difference in the time information of the match request is not within the specified time (step 504), the co-op match processing unit 201 sets a non-player character as a co-op pair for the player of the game device 1 that makes the match request (step 507). Furthermore, the co-op match processing unit 201 sends the co-op player information to the game device 1 that makes the match request (step 506). The co-op player information includes the player name and battleship group ID of the pre-set non-player character.

In addition, when a match request with a non-player character is received as a co-player, the non-player character is set as a co-player for the player of the game device 1 making the match request, and the co-player information is sent to the game device 1 making the match request. The co-player information includes the player name and battleship group ID of the pre-set non-player character.

The above concludes the description of the co-op pair matching process performed by server 2.

The fighting pair setting unit 114 of the game device 1 receives the fighting player information (step 306). The fighting pair setting unit 114 uses the received fighting player information to display the fighting player information (step 307). For example, FIG. 17 (d) and (e) are examples of displaying the fighting player information. In addition, when the fighting pair setting unit 114 requests a match with a non-player character as a fighting pair, the non-player character information is displayed as the fighting player information. Furthermore, the fighting pair setting unit 114 sets the player and the player of the received fighting player information as a fighting pair (step 308).

The above is the end of the description of the setting process of the joint fight, and we return to the flow chart of Figure 15.

When the co-op pair setting process is completed (step 108), the game execution unit 112 displays a game element registration screen (step 109). FIG. 21 is a diagram showing an example of a game element registration screen. In the game element registration screen of FIG. 21, it is displayed that up to 5 pilot cards and 5 vehicle cards of the game cards held by the player XXXX can be set (placed) in the first game element reading unit 121 to 125 and the second game element reading unit 131 to 135, and when the setting (placement) is completed, it is notified to press the setting completion button. The player sets (places) the pilot card of the pilot to be played in the battle game among the game cards held by the player in the first game element reading unit 121 to 125, and sets (places) the vehicle card of the vehicle to be played in the battle game in the second game element reading unit 131 to 135. When the setting (placement) of the game card is completed, the player presses the setting completion button.

When the setting completion button is pressed (step 110), the first game element reading unit 121-125 and the second game element reading unit 131-135 read the element ID printed on the game card, and the read element ID is output to the game element acquisition unit 110 together with the reading unit ID of the first game element reading unit 121-125 and the second game element reading unit 131-135 (step 111).

The game element acquisition unit 110 acquires the element ID and the reading unit ID of the set (placed) game card. Furthermore, the game element acquisition unit 110 acquires the type information 192, the drawing information 193, the parameter information 194, and the skill information 195 associated with the element ID 191 of the acquired game card from the game element DB 190, associates the reading unit ID, the element ID 191, the type information 192, the drawing information 193, the parameter information 194, and the skill information 195, and outputs them to the game execution unit 112 and the game configuration unit 111 (step 112).

The game execution unit 112 counts the number of the reading unit IDs of the first game element reading units 121 to 125 in the reading unit IDs, and determines whether the first game element has reached the maximum number (upper limit) that can be registered (step 113). For example, when the player sets (configures) a pilot card in all the first game element reading units 121 to 125, the reading unit IDs are 5 from 121 to 125, reaching the maximum number (upper limit) that can be registered.

When the number of the reading unit IDs of the first game element reading unit reaches the maximum number (upper limit) that can be registered, the game execution unit 112 counts the number of the reading unit IDs of the second game element reading units 131 to 135 in the reading unit IDs to determine whether the second game element has reached the maximum number (upper limit) that can be registered (step 114). For example, when the player sets (places) the riding card in all the second game element reading units 131 to 135, the reading unit IDs are 5 from 131 to 135, reaching the maximum number (upper limit) that can be registered.

When the second game element reaches the maximum number (upper limit) that can be registered, the game execution unit 112 displays a battle approval button. When the player's approval for the battle is obtained (step 115), the game team formation unit 111 uses the reading unit ID, element ID 191, type information 192, description information 193, parameter information 194 and skill information 195 obtained from the game element acquisition unit 110 to form a game team (troop) with the first game element, i.e. the pilot, and the second game element, i.e. the vehicle (step 116).

In addition, when the number of registrations of the first game element or the second game element has not reached the maximum number of registrations (5 in this example) (step 113, step 114), the game execution unit 112 timely supplements the processing of the game elements corresponding to the player's level, etc. (step 118) to form a game set (step 116).

After the game group formation unit 111 completes the formation of the game group, the game execution unit 112 starts the battle player matching process (step 117). The game execution unit 112 sends the battle player matching process request to the server 2 (steps 405 and 406), and the battle player matching process unit 202 of the server 2 performs the battle player matching process (step 407). In addition, the battle player matching process unit 202 sends the matched battle player information to the game device 1, and each game device 1 receives the battle player information (steps 408 and 409).

The game execution unit 112 of each game device 1 starts the battle process (steps 118, 410, 411).

Next, the action of the co-fight request in the battle is explained. FIG22 is a flowchart of the co-fight request processing, and FIG23 is a diagram of the transition of the co-fight request screen.

As shown in FIG. 23(a), the fight request execution unit 115 displays the fight request button 34 on the battle field screen in the battle game (step 600). The fight request execution unit 115 determines whether the fight request button is pressed to select the fight request (step 601). When the fight request is selected (step 602), the fight request execution unit 115 displays the fight request (step 603). The display of the fight request does not immediately perform support, but is, for example, as shown in FIG. 23(b), a display such as requesting support from the fighting player.

Next, the co-op request execution unit 115 determines the support type from the co-op player's battleship group ID included in the co-op player information (step 604). The support type is determined by reading the support information 209 of the battleship information database 200 corresponding to the battleship group ID of the co-op player, and performing a lottery based on the probability of each support type. And, the co-op request execution unit 115 determines the selected support type as the support type for the co-op request.

The co-fighting request execution unit 115 activates the support capability of the determined support type in the battle game of the player who made the co-fighting request (step 605). For example, as shown in FIG. 23(c), artillery support is activated. The above is the description of the action of ending the game.

This embodiment allows players to enjoy battle games together with friends rather than alone. In addition, it can create opportunities for users who have never experienced battle games to participate in battle games. As a result, the fun of the game can be improved.

<Variation Example 1 of the First Implementation Form> In the first implementation form, an example has been described in which a game element composed of the first game element and the second game element is the main game element for attack or defense. However, it can also be applied to a game in which a single game element alone is the main game element for attack or defense.

<Variation Example 2 of the First Implementation Form> The first implementation form has described an example of setting up a battle pair between players of game devices 1 installed in the same store. However, in the case of friends competing with each other, it is believed that in most cases the players compete in game devices 1 that are close to each other. For example, they compete with adjacent game devices or opposing game devices. Therefore, even if the game devices 1 are installed in the same store, the example of limiting the game devices 1 that can be set as a battle pair to adjacent game devices and opposing game devices 1 is described.

When the game devices 1 that can be set as a fighting pair are limited to adjacent game devices or opposing game devices 1, the fighting pair matching processing unit 201 needs to identify the game devices 1 that require matching as adjacent game devices or opposing game devices 1. Therefore, the fighting pair matching processing unit 201 needs a game device identification information database 300 that specifies the installation position relationship of the game devices 1. FIG. 24 is an example of a game device identification information database 300 of a variation 2 of the first embodiment. The game device identification information database 300 of FIG. 24 is a database that takes the installation position relationship of the game devices 1 into consideration. For example, six game devices 1 are arranged in two rows in the same store as shown in FIG24 . The first row includes game device 1-1 (game device identification ID: 100001), game device 1-2 (game device identification ID: 100002), and game device 1-3 (game device identification ID: 100003). The second row is opposite to game device 1 in the first row and includes game device 1-4 (game device identification ID: 100004), game device 1-5 (game device identification ID: 100005), and game device 1-6 (game device identification ID: 100006). The game device identification information database 300 composed of columns and rows reflecting the positional relationship is the game device identification information database 300 of Figure 24.

For example, when the game device identification ID contained in the matching request is "100004" and "100005", because the two matching requests are sent from the adjacent game device 1, the co-combat matching processing unit 201 sets the player of game device 1 with game device identification ID "100004" and the player of game device 1 with game device identification ID "100005" as co-combat players. Similarly, when the game device identification ID contained in the matching request is "100002" and "100005", because the two matching requests are sent from the opposite game device 1, the co-combat matching processing unit 201 sets the player of the game device 1 whose game device identification ID is "100002" and the player of the game device 1 whose game device identification ID is "100005" as co-combat players.

According to this configuration, since the co-op pair matching processing unit 201 does not need to determine the time information, the burden of the matching processing of the co-op pair matching processing unit 201 is reduced.

<Variation 3 of the first embodiment> The battle game of this embodiment has a normal battle mode in which players fight against each other individually, and a cooperative battle mode in which two or more players form a team and the team fights against each other. However, the cooperative battle mode requires two or more players, and considering the processing burden of the server 2, the time when the cooperative battle mode can be implemented can also be limited in the store.

<Second Implementation Form> The first implementation form has described an example of setting up a battle pair between players of the game device 1 installed in the same store. However, if it is possible to set up a battle pair with a friend who is far away across stores, the fun will be further increased. Therefore, in the second implementation form, an example of setting up a battle pair across stores will be described.

FIG. 25 is a diagram for explaining the second embodiment.

As shown in FIG. 25 , the fighting pair setting unit 114 displays a fighting pair setting button of a matching code as the third matching method ( FIG. 25 (a) ).

The first player and the second player who want to form a fighting pair press the fighting pair setting button of the matching code. In this way, the fighting pair setting unit 114 changes to a selection screen for issuing or inputting a matching code (Figure 25 (b)).

The first player and the second player who want to form a fighting team are responsible for issuing the matching code and inputting the matching code respectively. Here, the first player is responsible for issuing the matching code, and the second player is responsible for inputting the matching code.

When the first player presses the matching code issuance button, the pair setting unit 114 of the first player's game device 1 sends a matching code issuance request to the pair matching processing unit 201 of the server 2. In addition to the matching code issuance request, the matching code issuance request also includes game device identification information (game device ID) and the player ID obtained from the player card. The pair matching processing unit 201 of the server 2 issues a matching code and sends it to the pair setting unit 114 of the first player's game device 1. The issued matching code is a code (text string, etc.) that is not repeated with others within a specified time and can uniquely identify the first player. The pair setting unit 114 of the first player's game device 1 displays the received matching code (123456) (Figure 25(c)). The first player tells the second player the displayed matching code (123456).

The second player who is notified of the matching code presses the matching code input button. The co-op setting unit 114 of the game device 1 of the second player displays the matching code input screen (Figure 25 (d)). When the second player enters the notified matching code (123456) and presses the confirmation button, the co-op setting unit 114 of the game device 1 of the second player sends a matching request including the input matching code (123456) to the co-op matching processing unit 201 of the server 2. In addition to the matching code (123456), the matching request also includes the game device identification information (game device ID) and the player ID obtained from the player card.

The co-op pair matching processing unit 201 of the server 2 receives the matching request, and compares the issued matching code (123456) with the received matching code (123456). Furthermore, when the matching codes are identical, the player ID of the game device 1 associated with the matching code is identified, and the players of the player ID are set as a co-op pair. Furthermore, the co-op pair matching processing unit 201 sends co-op player information to the game device 1 requesting the issuance of the matching code (matching code issuing side) and the game device 1 requesting the matching (matching code input side). The co-op player information includes the player name identified from the player ID and the battleship group ID set by the player.

The co-op pair setting unit 114 of the game device 1 of the first player and the second player uses the received co-op player information to display the co-op player information (FIG. 25(e), (f)).

With this configuration, players who are far away from each other can be set as fighting pairs, regardless of the store where the game device 1 is installed.

<Third Implementation Form> Description of the third implementation form of the present invention.

The third embodiment has the same configurations as the game device 1 of the first and second embodiments, and also has a benefit granting unit 116. Fig. 26 is a block diagram of the game device 1 of the third embodiment.

The benefit granting unit 116 grants a benefit to the player on the condition that the player has performed a battle in the cooperative battle mode. The benefits granted include a first benefit and a second benefit.

The first benefit is a benefit granted for each battle in the co-op battle mode. The first benefit is not limited to intangible objects or tangible objects, but is set to be intangible objects in this embodiment. The benefit granting unit 116 grants the first benefit to each player of the co-op battle mode when the battle in the co-op battle mode ends. The granted benefit is stored in the player's reward information 215.

The second benefit is a benefit that can be obtained by using the first benefit. For example, it is a benefit obtained by collecting 10 first benefits and using them. The second benefit is not limited to intangible objects or tangible objects, but is set as a tangible object in this embodiment. And, as an example of a tangible object, it is a pilot game card or a ride game card of the first game element. The benefit granting unit 116 redeems the number of first benefits set in advance and provides the game card to the player.

By such a configuration, players actively fight in the co-op battle mode, which can improve the fun of the game. In addition, since the co-op battle mode requires more than two players, the number of players participating in the game also increases.

Although part or all of the above-mentioned embodiments are described as follows, they are not limited to the following.

[Note 1] A program that enables a gaming device composed of a computer to execute a battle game; and enables the computer to function as the following mechanisms: a game element registration mechanism that registers the game elements of the first player; a team setting mechanism that sets the first player and the second player as a team; a game execution mechanism that uses the registered game elements of the first player to execute the battle game between the first player and the opponent player; and a support execution mechanism that can, during the execution of the battle game between the first player and the opponent player, execute the game elements of the second player to support the battle game on the condition that the second player chooses to support the first player.

[Note 2] The program described in Note 1, wherein the group setting mechanism can select at least one group setting mode in which the group setting methods of the first player and the second player are different and perform control.

[Note 3] The program described in Note 1 or Note 2, wherein in the above-mentioned team setting mechanism, as the above-mentioned team setting mode, the above-mentioned first player and the above-mentioned second player are set as a team on the condition that the execution device of the above-mentioned first player, i.e., the first game device, and the execution device of the above-mentioned second player, i.e., the second game device, are set in the same store.

[Note 4] A program as described in any one of Notes 1 to 3, wherein the team setting mechanism sets the first player and the second player into a team on the condition that a team setting request from the first game device and a team setting request from the second game device are made within a specified time.

[Note 5] A program as described in any one of Notes 1 to 4, wherein the group setting mechanism sets the first player and the second player as a group under the condition that the first game device and the second game device are adjacent to or opposite to each other.

[Note 6] A program as described in any one of Notes 1 to 5, wherein the team setting mechanism sets the first player and the non-player character as a team under the condition that the team cannot be set with the second player.

[Note 7] A program as described in any one of Notes 1 to 6, wherein in the above-mentioned team setting mechanism, as the above-mentioned team setting mode, the above-mentioned first player and the non-player character are set as a team.

[Note 8] A program as described in any one of Notes 1 to 7, wherein in the above-mentioned team setting mechanism, as the above-mentioned team setting mode, a temporary matching code is issued from the execution device of the above-mentioned first player, that is, the first game device, to set the above-mentioned first player and the second player of the second game device who inputs the above-mentioned matching code as a team.

[Note 9] A program as described in any one of Notes 1 to 8, wherein the support execution mechanism executes at least one of a plurality of support types on the condition that the support is selected to be provided to the first player.

[Note 10] A program as described in any one of Notes 1 to 9, wherein the plurality of supported types are different according to the types of game elements set by the second player.

[Note 11] For a program as described in any of Notes 1 to 10, the support execution agency will limit the execution of the support to a specified number of times or less.

[Note 12] A program as described in any one of Notes 1 to 11, wherein the computer functions as a battle mode selection mechanism that can select a first battle mode in which the first player can execute the battle game alone and a second battle mode in which the first player and the second player can execute the battle game in a team.

[Note 13] A program as described in any one of Notes 1 to 12, wherein the battle mode selection mechanism limits the time during which the second battle mode can be selected.

[Note 14] A program as described in any one of Notes 1 to 13, wherein the computer functions as a matching mechanism for matching the first player with the opponent player; and the matching mechanism matches an opponent player different from the opponent player of the second player as the opponent player of the first player.

[Note 15] A program as described in any one of Notes 1 to 14, wherein the matching mechanism selects a player who selects the second battle mode and matches the first player.

[Note 16] A program as described in any one of Notes 1 to 15, wherein the matching mechanism matches the first player with a player corresponding to the level of the first player.

[Note 17] A program as described in any one of Notes 1 to 16, wherein the matching mechanism, when at least one of the level of the first player and the level of the second player is lower than a specified level, matches a non-player character as a player against a player whose level is lower than the specified level; and when both the level of the first player and the level of the second player exceed the specified level, matches a real player as a player against the first player and the second player.

[Note 18] A program as described in any one of Notes 1 to 17, wherein the computer functions as a benefit granting mechanism that grants the first benefit on the condition that the battle game in the second battle mode is executed, and grants a second benefit different from the first benefit on the condition that a plurality of the first benefits are used.

[Note 19] A program as described in any of Notes 1 to 18, wherein the first benefit mentioned above is a virtual item; and the second benefit mentioned above is a physical item.

[Supplementary Note 20] A gaming device comprising: a game element registration mechanism for registering the game elements of a first player; a team setting mechanism for setting the first player and a second player as a team; a game execution mechanism for executing a battle game between the first player and a competing player using the registered game elements of the first player; and a support execution mechanism for executing the game elements of the second player to support the battle game during the execution of the battle game between the first player and the competing player, on the condition that the second player chooses to support the first player.

Although preferred embodiments have been described above to illustrate the present invention, the present invention is not limited to the above embodiments and can be variously modified and implemented without departing from the scope of the technical concept.

1: Game device 1-1 to 1-6: Game device 2: Server 10: Processing unit 11: Display unit 12, 121 to 125: First game element reading unit 13, 131 to 135: Second game element reading unit 14: Operation input unit 15: Price detection unit 16: User information reading unit 17: Sound output unit 18: Communication unit 19: Memory unit 20: Processing unit 21: Memory unit 22: Communication unit 30: Attack game group area 31: First area 32: Second area 34: Co-op request button 110: Game element acquisition unit 111: Game group configuration unit 112: Game Execution Department 113: Battleship Setting Department 114: Co-op Setting Department 115: Co-op Request Execution Department 116: Benefit Granting Department 190: Game Element Database 191: Element ID 192: Type Information 193: Description Information 194: Parameter Information 195: Skill Information 200: Battleship Information Database 201: Battleship Identification Information (Battleship ID) 201: Co-op Matching Processing Department 202: Battleship Name 202: Player Matching Processing Department 203: Management Department 203: Captain Identification Information (Captain ID) 204: Captain's name 205: Battleship image data 206: Captain's image data 207: Attack parameters 208: Defense parameters 209: Support capability information 210: Player database 211: Player ID 212: Progress status information 213: Possession information 214: Enhancement status information 215: Reward information 300: Game device identification information database A～F: Player M1, P1: Game card N: Communication line Step100～Step118, Step200～Step204, Step300～Step309, Step400～Step412, Step500～Step507, Step600～Step605: Steps

FIG. 1 is a diagram showing the system configuration of the game system of the present embodiment. FIG. 2 is a diagram showing an example of a game card P1 when the first game element is a pilot and its type has character information of an attack type. FIG. 3 is a diagram showing an example of a game card M1 when the second game element is a vehicle and its type has character information of an attack type. FIG. 4 is a diagram showing an example of a game field in a battle game of the present embodiment. FIG. 5 is a front view of a game device 1 of the present invention. FIG. 6 is a block diagram showing the functional configuration of the game device 1 of the present invention. FIG. 7 is a diagram showing an example of a game element database 190. FIG. 8 is a diagram showing an example of a battleship information database 200 of a battleship group 1. FIG. 9 is a diagram showing an example of a battleship setting screen. FIG. 10 is a diagram showing an example of game device identification information. FIG. 11 is a block diagram showing the functional configuration of the server 2 of the embodiment of the present invention. FIG. 12 is a diagram showing an example of a game device identification information database 300. FIG. 13 is a diagram showing an example of a battle player matching. FIG. 14 is a diagram showing an example of player information. FIG. 15 is a flow chart of the action of the game device 1. FIG. 16 is a flow chart of the action of the battleship setting process. FIG. 17 (a) to (e) are diagrams for explaining a series of actions for selecting a battle mode. FIG. 18 is a flow chart of the co-op pair setting process. FIG. 19 is a sequence diagram between the game device 1 and the server 2. FIG. 20 is a flowchart of the co-op pair matching process performed by the server 2. FIG. 21 is a diagram showing an example of a game element registration screen. FIG. 22 is a flowchart of the co-op request process. FIG. 23 (a) to (c) are transition diagrams of the co-op request screen. FIG. 24 is an example of the game device identification information database 300 of the variation example 2 of the first implementation form. FIG. 25 (a) to (f) are diagrams for explaining the second implementation form. FIG. 26 is a block diagram of the game device 1 of the third implementation form.

1: Game device 10: Processing unit 11: Display unit 121-125: First game element reading unit 131-135: Second game element reading unit 14: Operation input unit 15: Price detection unit 16: User information reading unit 17: Sound output unit 18: Communication unit 19: Memory unit 110: Game element acquisition unit 111: Game composition unit 112: Game execution unit 113: Battleship setting unit 114: Co-op pair setting unit 115: Co-op request execution unit

Claims (20)

A program that enables a gaming device composed of a computer to execute a battle game; and enables the computer to function as the following mechanisms: a game element registration mechanism that registers the game elements of a first player; a team setting mechanism that sets the first player and a second player as a team; a game execution mechanism that uses the registered game elements of the first player to execute the battle game between the first player and the opposing player; and a support execution mechanism that can, during the execution of the battle game between the first player and the opposing player, execute the game elements of the second player to support the battle game on the condition that the second player chooses to support the first player. As in the program of claim 1, the group setting mechanism can select at least one group setting mode in which the group setting methods of the first player and the second player are different for control. As in the program of claim 2, wherein In the group setting mechanism, as the group setting mode, the first player and the second player are set as a group on the condition that the execution device of the first player, i.e., the first game device, and the execution device of the second player, i.e., the second game device, are set in the same store. A program as claimed in claim 3, wherein the group setting mechanism sets the first player and the second player as a group under the condition that a group setting request from the first game device and a group setting request from the second game device are performed within a specified time. A program as claimed in claim 3, wherein the group setting mechanism sets the first player and the second player as a group under the condition that the first game device and the second game device are adjacent to or opposite to each other. A program as claimed in claim 5, wherein the group setting mechanism sets the first player and the non-player character as a group under the condition that the group setting mechanism cannot be set with the second player. A program as in claim 2, wherein in the group setting mechanism, as the group setting mode, the first player and the non-player character are set as a group. As in the program of claim 2, wherein In the above-mentioned group setting mechanism, as the above-mentioned group setting mode, a temporary matching code is issued from the execution device of the above-mentioned first player, that is, the first game device, to set the above-mentioned first player and the second player of the second game device who inputs the above-mentioned matching code as a group. A program as claimed in claim 1 or 2, wherein the support execution mechanism executes at least one of a plurality of support types on the condition that the support is selected to be provided to the first player. A program as claimed in claim 9, wherein the plurality of supported types are different according to the types of game elements set by the second player. A program as claimed in claim 9, wherein the support execution agency limits the execution of the support to a specified number of times. A program as claimed in claim 9, wherein the computer functions as a battle mode selection mechanism that can select a first battle mode in which the first player can execute the battle game alone, and a second battle mode in which the first player and the second player can form a team to execute the battle game. A program as claimed in claim 12, wherein the battle mode selection mechanism limits the time during which the second battle mode can be selected. A program as claimed in claim 12, wherein the computer functions as a matching mechanism for matching the first player with the opposing player; and the matching mechanism matches an opposing player different from the opposing player of the second player with the opposing player of the first player. A program as claimed in claim 14, wherein the matching mechanism selects a player who has selected the second battle mode and matches the first player. A program as claimed in claim 15, wherein the matching mechanism matches the first player with a player corresponding to the level of the first player. A program as claimed in claim 16, wherein the matching mechanism matches a non-player character as a player against a player whose level is lower than the specified level when at least one of the levels of the first player and the second player is lower than the specified level; and matches a real player as a player against the first player and the second player when both the levels of the first player and the second player exceed the specified level. A program as claimed in claim 12, wherein the computer is made to function as a benefit granting mechanism that grants the first benefit on the condition that the battle game of the second battle mode has been executed, and grants a second benefit different from the first benefit on the condition that a plurality of the first benefits are used. A program as claimed in claim 18, wherein the first benefit mentioned above is a virtual item; and the second benefit mentioned above is a physical item. A gaming device, comprising: a game element registration mechanism, which registers the game elements of a first player; a team setting mechanism, which sets the first player and a second player as a team; a game execution mechanism, which uses the registered game elements of the first player to execute a battle game between the first player and the opposing player; and a support execution mechanism, which can, during the execution of the battle game between the first player and the opposing player, execute the game elements of the second player to support the battle game on the condition that the second player chooses to support the first player.